![[LWN Logo]](/images/lwn.banner.gif)
Date: Tue, 23 Feb 1999 21:42:06 -0600
From: Mike Gleason <mgleason@NCFTP.COM>
Subject: Comments on NcFTPd "theoretical root compromise"
To: BUGTRAQ@NETSPACE.ORG
--=====================_65021500==_.ALT
Content-Type: text/plain; charset="us-ascii"
Summary: Don't Panic! Exactly one byte can be corrupted.
There is an off-by-one bug which may cause one byte on the stack to be zeroed.
This can occur if an attacker uses 64 or more characters in the range of '0' to
'9' in an FTP "PORT" command. This can cause the child process handling the
FTP connection to crash and respawn, but does not leave an attacker with root
privileges. Nevertheless, NcFTPd 2.4.1 is available which fixes this problem.
See the download page at http://www.ncftp.com/download/ or the mirror domain at
http://www.ncftpd.com/download/ . As usual, users of any version of NcFTPd can
upgrade to version 2.4.1 free of charge.
ObPlea: I think we're making progress. Rather than hearing about a bug second
hand, I at least got an email at the same time a message goes out to Bugtraq.
However, I'd like an opportunity to verify that a bug actually exists, *AND*
verify the severity of it. A lot of people get thrown into a frenzy by the
words "remote root compromise" even though it appears in the same sentence as
"theoretical." In the event of an actual emergency, I'd like to ask that in
addition to verification, I request 5 working days to provide an official fix
and time for users to upgrade prior to posting an "exploit". That's not too
much to ask. (Didn't we just go over this whole shitbag in the HERT thread?)
For reference, here is a snippet which illustrates the actual problem:
static int
ftp_aton(const char *cp, struct sockaddr_in *sinaddr)
{
char buf[64];
char *dst;
char *dstlim;
int i, c;
unsigned int octets[6], u;
memset(sinaddr, 0, sizeof(struct sockaddr_in));
dst = buf;
- dstlim = dst + sizeof(buf);
+ dstlim = dst + sizeof(buf) - 1;
for ( ; ; ) {
c = (int) *cp++;
if (c == '\0')
break;
if (! isdigit(c))
c = ' ';
if (dst < dstlim)
*dst++ = c;
}
*dst = '\0';
Mike Gleason
NcFTP Software
At 12:37 PM 2/23/99 -0400, Julien Nadeau wrote:
>Proof of Concept - Security Advisory 02/23/99
>http://poc.csoft.net Released by
>poc@csoft.net sw3wn@poc.csoft.net
>
>---
>
>Affected Program NcFTPd <http://www.ncftp.com>
>Description FTP server (commercial)
>Severity Theoretical root compromise, logs compromise
>
>
>Synopsis:
>
>NcFTPd is a commercial FTP (File Transfer Protocol) server, in the
>NcFTP product line. The source code is not publicly released. This
>was tested on Linux with libc5 (there's a glibc2 specific version
>available).
>
>Problem:
>
>NcFTPd's PORT parsing function has a stack buffer overflow
>problem, which would basically allow a user to remotely execute
>arbitrary code - the thing here is that the PORT parsing function
>seem to change characters, that are not in the range 0x30-0x39
>(ASCII '0'-'9'), into 0x20 (ASCII space), hence making an exploit
>almost impossible (note that, if ascii 0x40 would be allowed that
>would be a different story =p).
>
>The program only parses for characters out of the 0-9 range in a
>specific area in memory (the one that contains return address heh)
>- the rest is kept unchanged, and you can't really go further in
>memory, input line size is restricted.
>
>However, since NcFTPd does not come with source code, I'm not sure.
>Like with most buffer overflows there are probably work-arounds to
>exploit it - this could have been a particulary neat exploit, since
>it runs as a child and one could gain access transparently without
>crashing the parent.
>
>The current bug is not really a problem, it can crash the child process
>with a segfault, the parent process receives a signal 6 (abort) and the
>child process stay zombie for a few seconds and a brand new one is
>created.
>A few minor DoS attacks are possible but, who cares. Oh and this could
>be
>used to not get listed in the logs too.
>
>Example:
>
>--
>evil:$ nc victim ftp
>220 victim NcFTPd Server (unregistered copy) ready.
>user anonymous
>331 Guest login ok, send your complete e-mail address as password.
>pass some@thing
>230-You are user #1 of 50 simultaneous users allowed.
>230-
>230 Logged in anonymously.
>port 00000000000000000000000000000000000000000000 (...)
>501 Syntax error in parameters.
>evil:$
>--
>
>Status:
>
>I couldn't come up with a patch, since the source code doesn't
>come with NcFTPd. I contacted the authors about the bug.
--=====================_65021500==_.ALT
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
Summary: Don't Panic! Exactly one byte can be=20
corrupted.<br>
<br>
There is an off-by-one bug which may cause one byte on the stack to be
zeroed. This can occur if an attacker uses 64 or more characters in
the range of '0' to '9' in an FTP "PORT" command. This
can cause the child process handling the FTP connection to crash and
respawn, but does not leave an attacker with root privileges.
Nevertheless, NcFTPd 2.4.1 is available which fixes this problem.
See the download page at
<a href=3D"http://www.ncftp.com/download/" eudora=3D"autourl">http://www.ncf=
tp.com/download/</a>
or the mirror domain at <a href=3D"http://www.ncftpd.com/download/"=
eudora=3D"autourl">http://www.ncftpd.com/download/</a> . As usual,=
users of any version of NcFTPd can upgrade to version 2.4.1 free of=
charge.<br>
<br>
ObPlea: I think we're making progress. Rather than hearing about=
a bug second hand, I at least got an email at the same time a message goes=
out to Bugtraq. However, I'd like an opportunity to verify that a bug=
actually exists, *AND* verify the severity of it. A lot of people get=
thrown into a frenzy by the words "remote root compromise" even=
though it appears in the same sentence as "theoretical." In=
the event of an actual emergency, I'd like to ask that in addition to=
verification, I request 5 working days to provide an official fix and time=
for users to upgrade prior to posting an "exploit". That's=
not too much to ask. (Didn't we just go over this whole shitbag in=
the HERT thread?)<br>
<br>
For reference, here is a snippet which illustrates the actual problem:<br>
<dl>
<dd> static int
<dd> ftp_aton(const char *cp, struct sockaddr_in *sinaddr)
<dd> {
<dd> char buf[64];
<dd> char *dst;
<dd> char *dstlim;
<dd> int i, c;
<dd> unsigned int octets[6], u;
<dd>
<dd> memset(sinaddr, 0,=
sizeof(struct sockaddr_in));
<dd> dst =3D buf;
<dd>- dstlim =3D dst + sizeof(buf);
<dd>+ dstlim =3D dst + sizeof(buf) - 1;
<dd>
<dd> for ( ; ; ) {
<dd> =
c =3D (int) *cp++;
<dd> =
if (c =3D=3D '\0')
<dd> =
break;
<dd> =
if (! isdigit(c))
<dd> =
c =3D '=
';
<dd> =
if (dst < dstlim)
<dd> =
*dst++ =
=3D c;
<dd> }
<dd> *dst =3D '\0';<br>
<br>
<br>
<br>
</dl>Mike Gleason<br>
NcFTP Software<br>
<br>
<br>
<br>
<br>
At 12:37 PM 2/23/99 -0400, Julien Nadeau wrote:<br>
>Proof of Concept - Security=
Advisory &=
nbsp; =
02/23/99<br>
><a href=3D"http://poc.csoft.net=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0/"=
eudora=3D"autourl">http://poc.csoft.net =
&nbs=
p; &n=
bsp; </a> Released by<br>
>poc@csoft.net  =
; &nb=
sp; =
sw3wn@poc.csoft.net<br>
><br>
>---<br>
><br>
>Affected Program NcFTPd <<a=
href=3D"http://www.ncftp.com/"=
eudora=3D"autourl">http://www.ncftp.com</a>><br>
>Description &=
nbsp; FTP server (commercial)<br>
>Severity &nbs=
p; Theoretical root compromise, logs compromise<br>
><br>
><br>
>Synopsis:<br>
><br>
>NcFTPd is a commercial FTP (File Transfer Protocol) server, in the<br>
>NcFTP product line. The source code is not publicly=
released. This<br>
>was tested on Linux with libc5 (there's a glibc2 specific version<br>
>available).<br>
><br>
>Problem:<br>
><br>
>NcFTPd's PORT parsing function has a stack buffer overflow<br>
>problem, which would basically allow a user to remotely execute<br>
>arbitrary code - the thing here is that the PORT parsing function<br>
>seem to change characters, that are not in the range 0x30-0x39<br>
>(ASCII '0'-'9'), into 0x20 (ASCII space), hence making an exploit<br>
>almost impossible (note that, if ascii 0x40 would be allowed that<br>
>would be a different story =3Dp).<br>
><br>
>The program only parses for characters out of the 0-9 range in a<br>
>specific area in memory (the one that contains return address heh)<br>
>- the rest is kept unchanged, and you can't really go further in<br>
>memory, input line size is restricted.<br>
><br>
>However, since NcFTPd does not come with source code, I'm not sure.<br>
>Like with most buffer overflows there are probably work-arounds to<br>
>exploit it - this could have been a particulary neat exploit, since<br>
>it runs as a child and one could gain access transparently without<br>
>crashing the parent.<br>
><br>
>The current bug is not really a problem, it can crash the child=
process<br>
>with a segfault, the parent process receives a signal 6 (abort) and=
the<br>
>child process stay zombie for a few seconds and a brand new one is<br>
>created.<br>
>A few minor DoS attacks are possible but, who cares. Oh and this=
could<br>
>be<br>
>used to not get listed in the logs too.<br>
><br>
>Example:<br>
><br>
>--<br>
>evil:$ nc victim ftp<br>
>220 victim NcFTPd Server (unregistered copy) ready.<br>
>user anonymous<br>
>331 Guest login ok, send your complete e-mail address as password.<br>
>pass some@thing<br>
>230-You are user #1 of 50 simultaneous users allowed.<br>
>230-<br>
>230 Logged in anonymously.<br>
>port 00000000000000000000000000000000000000000000 (...)<br>
>501 Syntax error in parameters.<br>
>evil:$<br>
>--<br>
><br>
>Status:<br>
><br>
>I couldn't come up with a patch, since the source code doesn't<br>
>come with NcFTPd. I contacted the authors about the bug.<br>
<br>
</html>
--=====================_65021500==_.ALT--