bugtraq - Low risk vulnerabilities in ftp file list handling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Wed, 11 Jun 2003 21:19:00 +0100
From: alan@...p22.swansea.linux.org.uk
To: bugtraq@...urityfocus.com
Subject: Low risk vulnerabilities in ftp file list handling

Several ftp parsing libraries are vulnerable to attack by simply feeding
them too much data. While the library authors have taken care to be robust
in parsing ftp NLST returns they don't iterate the data as they receive it
but store the data until the NLST completes.

In the case of rpm a user using

	rpm -Uvh ftp://foo.bar.com/updates/*

and hitting a rogue server can be fed 1Gb of data at which point rpm does
a <<2 and allocates 0 bytes of memory to copy the data into.

In the case of gnome-1.x the gnome library string routines are used and
these use an int for size management. Gnome 2.x fixes this problem and uses
size_t so is not exploitable.

Even in the non vulnerable applications there are out of memory annoyance 
value attacks as a result of this way of handling file lists.

This attack is not actually that useful fortunately. The end user has to
trigger the access, and has to accept >1Gb of data without getting
suspicious. In addition the gnome-1.x variant is only exploitable on
systems where sizeof(int) < sizeof(ptrdiff_t) - typically 64bit only.

I have not inspected other ftp NLST parsing applications but it seems people
should take a look to see who else is buffering too much data in RAM or
not checking for size wraps. 

Gnome and RPM maintainers were informed in advance in April.

Alan