Date: Fri, 29 Oct 2010 11:24:47 -0700 From: "Ronald F. Guilmette" <rfg@tristatelogic.com> To: freebsd-net@freebsd.org Subject: tftpd - timeouts and possible Denial-Of-Service Message-ID: <10398.1288376687@tristatelogic.com>
next in thread | raw e-mail | index | archive | help
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 collection application. 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 root). 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- transfer timesouts... 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_ tangent.) Regards, rfg 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?10398.1288376687>