[<prev] [next>] [day] [month] [year] [list]
Message-ID: <200306112019.h5BKJ0D7003193@dhcp22.swansea.linux.org.uk>
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
Powered by blists - more mailing lists