It was reported [1] that tftpd-hpa suffers from a buffer overflow vulnerability in the function where it sets the utimeout option. This is an option that can be provided by clients, which means the buffer overflow could be remotely exploited. This has been corrected upstream already [2]. [1] http://seclists.org/oss-sec/2011/q2/587 [2] http://git.kernel.org/?p=network/tftp/tftp-hpa.git;a=commitdiff;h=f3035c45bc50bb5cac87ca01e7ef6a12485184f8
This bug exists in all tftp versions in Red Hat Enterprise Linux 3, 4, 5 and 6. As mentioned above, a sufficiently long utimeout option value triggers a buffer (b_ret[] in set_utimeout()) overflow. The buffer is located in the data/bss segment. Due to the existing checks, this overflow is limited to up to 5 numeric characters ('0' - '9'), followed by a nul byte ('\0'). On Red Hat Enterprise Linux 6, this overflow is caught by FORTIFY_SOURCE, and hence this bug has no security impact there. The abort of the tftpd process does not impact tftp service availability. By default, tftpd is started from xinetd, hence the abort of the tftpd process only affects session that triggered the abort (attacker's session). tftpd can also be run in a stand-alone mode. New child process if forked to handle user's session. Crash of such child process does not impact parent tftpd process, and hence tftp service availability. There's no plan to address this bug on Red Hat Enterprise Linux 6 as a security flaw. There are mitigations reducing the impact if this flaw is exploited. tftpd drops privileges and the affected code is run as user nobody. In the default configuration, tftpd is run with -s (secure mode) option, which makes tftpd chroot into a specified tftpboot directory. It is possible to completely mitigate this problem by disabling handling of the utimeout option. This can be achieved by running tftpd with -r command line option (newer versions also recognize --refuse as a synonym of -r). Assuming default configuration using xinetd, the utimeout option can be disabled by changing the line as: server_args = -s /tftpboot in the /etc/xinetd.d/tftp file to: server_args = -s -r utimeout /tftpboot and reloading xinetd service. Note: RHEL6 uses /var/lib/tftpboot directory by default instead of /tftpboot that is default in earlier RHEL versions. Further information on options disabling can be found in the "RFC 2347 OPTION NEGOTIATION" section of the tftpd(8) manual page.
Even though this overflow is not caught by FORTIFY_SOURCE on Red Hat Enterprise Linux 4 and 5, I've not been able to reproduce a crash either. Looking at the compiled version on several RHEL5 architectures, such limited overflow could only clobber contents of b_ret[] buffers in set_timeout(), set_tsize() and set_blksize2() functions. Overwrite of those buffers is completely harmless.
I had a closer look at the latest builds in RHEL4 (tftp-0.39-3.el4) and RHEL5 (tftp-0.49-2) to see what gets overwritten. On RHEL5, depending on the architecture, b_ret[] buffers in set_timeout() and set_tsize() or set_blksize2() functions gets overwritten. As previously mentioned, such overwrite is harmless. Those static b_ret[] buffers are only accessed from the do_opt() function that calls various set_*() functions, and only immediately after set_*() function returned. The overwritten b_ret[] content is not accessed before next call to set_*() function. On RHEL4, memory layout is different. Overwrite changes tftp_recvfile()'s ap and block. tftp_recvfile() is called after options were parsed. ap is always initialized in tftp_recvfile() before being used. block is a counter used to stay in sync with client's data packets during the file upload. If that counter is initialized incorrectly, it may prevent successful upload in the given session. However, it's attacker's session that is affected, service availability for other users is not affected. Given the above, there's no real security impact on the current Red Hat Enterprise Linux tftp packages.
Created tftp tracking bugs for this issue Affects: fedora-all [bug 714261]
Given the lack of security impact of this bug on Red Hat Enterprise Linux tftp packages, we do not plan to release a security update addressing it. The fix may be included in the future tftp updates as non-security fix. Statement: Not vulnerable. The Red Hat Security Response Team has reviewed this bug and determined it has no security impact on the tftp packages as shipped with Red Hat Enterprise Linux 4, 5, and 6. Refer to the following bugzilla for additional details: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-2199
Related PRE-CERT Security Advisory: http://www.pre-cert.de/advisories/PRE-SA-2011-05.txt