On Mon, 2020-08-24 at 09:42:23 +0300, Adrian Bunk wrote: > On Sun, Jan 26, 2020 at 02:51:05AM +0000, Debian Bug Tracking System wrote: > >... > > inetutils (2:1.9.4-11) unstable; urgency=medium > > . > > * Add patches from upstream: > > - telnet: Validate supplied environment variables. CVE-2019-0053. > > Closes: #945861 > >... > > Using [1] I am getting in unstable: > > # python3 telnet_term_0day.py > [+] Multiple vendor telnet.c client environment handling PoC (IAC SB > TELQUAL_IS) > [-] connected, corrupting client heap > [-] done. merry haxmas. > # > > $ `perl -e 'print Ax"50000"'` inetutils-telnet -l`perl -e 'print "A"x5000'` > 127.0.0.1 > Trying 127.0.0.1... > Connected to 127.0.0.1. > Escape character is '^]'. > Segmentation fault (core dumped) > $ > > I assume this means the bug is not yet completely fixed?
I've been checking this on and off, but have run out of time to track it down in the past. A couple of days ago I sat down and traced this to a recursive loop on one of the error exit codes, which then proceeds to try to process the remaining input ring buffer, which goes back to that exit return path. The crash seems to be due to stack exhaustion, so I don't think this is really related to the original security issue, but having a local program susceptible to be crashes by a remote server still gives me uneasiness, and given that I've not really checked whether it's possible to overwrite buffers controlled by the remote side or similar, I'm not going to really contest whether this is really a security issue too. In any case I prepared a tentative patch fixing the issue (with the suspicion is was not entirely correct, given the protocol and code flow) and proposed it to Simon Josefsson, who subsequently found an existing fix in NetBSD, which got merged now upstream. So I'll upload a new release today including that. Thanks, Guillem
