tftpd - timeouts and possible Denial-Of-Service
Ronald F. Guilmette
rfg at tristatelogic.com
Fri Oct 29 18:41:04 UTC 2010
Although the tftp protocol has, apparently, been intended from the outset
to provide support for finite-time file transfers, I myself would like to
see if I can use it in the context of a (near-)continuous streaming data
This raises a number of issues and questions, and I'm hoping that somebody
here might have some answers for me.
First, with regards to the FreeBSD tftpd daemon, I see that unlike its
client counterpart (tftp), this server daemon doesn't, apparently, have
any way of specifying any sorts of per-packet or per-transfer timeouts.
That naturally makes me wonder whether or not a determined and malicious
attacker could perhaps engineer an effective denial of service attack
against the tftp daemon, simply by continuously creating new file
transfer sessions and then never terminating any of those, thus causing
tftpd to use up all of its available file descriptors (and possibly all
available file descriptors, system-wide, e.g. if tftpd is running as
Can anyone here speak to this? Is this a plausible threat?
It seems to me that there are only two possibilities here, i.e. either
(1) tftpd indeed has no per-transfer timeouts, thus apparently enabling
a denial-of-service on the daemon (or the system) via exhaustion of file
descriptors or else (b) tftpd does in fact have a built-in per-transfer
timeout, but that is entirely undocumented in the man page.
Either way, it appears to me that _something_ may perhaps need to get fixed.
My second question only comes into play if there is (or will be, in future)
some sort of per-transfer timeout implemented within tftpd... and this
question may sound more than a bit odd, given that I have just expressed
a concern, above, regarding a possible DoS due to the lack of tftpd per-
Basically, for my application, where I want to use tftpd (together with a
client that I myself will be coding from scratch) to do continuous or nearly-
continuous data logging, if there is in fact some per-transfer timeout
implemented within tftpd, then I would need to know how to defeat it, e.g.
so that I could keep a single "file transfer" session/transaction open for,
say, 24 hours, continuously.
I understand that some may perhaps take umbrage at my desire to make use
of the TFTP protocol for a application context that it was never really
designed for, but still, this protocol fits, or nearly fits most of my
needs, so I would still like to use it anyway, regardless of the history
or current common usage. However if the sever side implements no timeouts,
I see that as opening up a possible DoS attack hole, whereas if there is,
or will be, per-transfer timeouts in tftpd, then for my specific application,
I will need to know how to engineer an effective "keep alive" for my
particular (long lived) tftp sessions. (And I have some ideas of how
such "keep alive" functionality might be implemented in a way that would
not do too much violence to the existing protocol, but I'll wait and see
what the responses, if any, are to this message before I go off on _that_
P.S. If anyone wants to suggest to me some different sort of streaming
protocol for which (a) BSD/Linux servers & clients already exist and are
generally available, and which (b) uses UDP in preference to TCP, and
which (c) is generally reliable (e.g. retransmittingf dropped packets,
when necessary) and which (d) is suitable for low-volume data logging
where latency is not at all an issue, then by all means, please proceed
and _do_ suggest some alternatives. Keep in mind however that the main
reason I am looking in particular at TFTP right now is that it should be
quite "trivial" for me to code up my own specialized (embedded?) client.
And that's an important consideration. I really don't have the time to
code up from scratch any big and complex protocol.
More information about the freebsd-net