Hi all, On Fri, Aug 23, 2024 at 10:56:30PM -0700, Collin Funk wrote:
> I've pushed the attached patch removing an integer overflow from telnet. > > The overflow occurs went sending 'send dont <value>' but the value > exceeds INT_MAX. I was curious if the original integer overflow possibility could lead to problems. The code already attempted to detect out-of-range values for the "send do/dont/will/wont <value>" commands, but this did not work reliably. At least on Ubuntu GNU/Linux 20.04 on x86-64 one could crash the GNU Inetutils telnet client with some values greater than INT_MAX: $ uname -p x86_64 $ gcc --version | head -n1 gcc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0 $ jobs [1]+ Running nc -dkln 127.0.0.1 7777 > /dev/null 2>&1 & $ git log -n1 --pretty=oneline e29e76b37b31eef27c5d53cc87306e7b80376762 (HEAD -> master, origin/master, origin/HEAD) ftp: Cleanup port number to string conversion. $ echo %send do $(echo 2^31 | bc) | ./telnet/telnet --escape=% 127.0.0.1 7777 Telnet escape character is '%'. Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '%'. telnet> send do 2147483648 Segmentation fault (core dumped) This wrong memory access happens in the "send_do()" function from telnet/telnet.c where the integer value is used to index into an array of size 256. This is similar for "send_dont()", "send_will()", and "send_wont()" from the same file. This no longer happens with the integer overflow fix in commit a6d9848a32fafa763548e54b44cb094abdac915d: $ echo %send do $(echo 2^31 | bc) | ./telnet/telnet --escape=% 127.0.0.1 7777 Telnet escape character is '%'. Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '%'. telnet> send do 2147483648 '2147483648': bad value ('send do ?' for help). telnet> Connection closed. Br, Erik