search menu icon-carat-right cmu-wordmark

CERT Coordination Center


BSD-derived ftpd replydirname() in ftpd.c contains one-byte overflow

Vulnerability Note VU#593299

Original Release Date: 2000-12-21 | Last Revised: 2000-12-22

Overview

There is a off-by-one vulnerability in several BSD-derived ftpd servers.

Description

The ftp server in several BSD distributions contains a defect which allows one byte of the program memory allocated within a stack frame to be overwritten with a NUL byte ('\0'). The byte in question is located at the end of a buffer in the function replydirname() in ftpd.c. This buffer contains the name of a directory path to be used by some other calling function.

The first byte following this path name happens to be the lower address of the pointer to the stack frame of the function calling replydirname(). This is the address restored to the extended base pointer when replydirname() terminates. So for example, if the address of the ebp was originally 0xbfffacdc, after the overwrite occurs in replydirname() the ebp will be 0xbfffac00. In effect, Zeroing out the lower byte of the ebp causes the pointer stored in the register to shift by 0xdc (or 220 decimal) bytes.

If the new location being pointed to in memory is under the control of the attacker (as is the case here), a return address chosen by the attacker can be inserted to be used to execute malicious code elsewhere, possibly in the same buffer being used to overwrite the end of the directory name in the first place (as is the case in replydirname())

The vulnerable code in this case is in the replydirname() function in ftpd.c, as explained in OpenBSD's Security Advisory about this problem:

TECHNICAL DETAILS

The offending code is as follows:

char npath[MAXPATHLEN];
int i;

for (i = 0; *name != '\0' && i < sizeof(npath) - 1; i++, name++) {
npath[i] = *name;
if (*name == '"')
npath[++i] = '"';
}
npath[i] = '\0';

In <sys/param.h>, MAXPATHLEN is defined to be 1024 bytes.  The for()
construct here correctly bounds variable `i' to be < 1023, such that when
the loop has ended, no byte past npath[1023] may be written with '\0'.
However, since `i' is also incremented in the nested statements here,
it can become as large as 1024, and npath[1024] is past the end of the
allocated buffer space.

Impact

A local or remote user can execute arbitrary code with the privileges of the daemon, typically root.

Solution

Apply vendor patches

Disable the ftp service, or ensure no writable directories are accessible in the ftp base directory.

Vendor Information

593299
Expand all

NetBSD

Updated:  December 21, 2000

Status

  Vulnerable

Vendor Statement

NetBSD has published an advisory about this issue at:

ftp://ftp.NetBSD.ORG/pub/NetBSD/misc/security/advisories/NetBSD-SA2000-018.txt.asc

                 NetBSD Security Advisory 2000-018
                 =================================

Topic:          One-byte buffer overrun in ftpd
Version:        All official releases up to and including 1.5
Severity:       possible remote root compromise.
Fixed:          NetBSD-current: December 4, 2000
                NetBSD 1.4 branch: December 14, 2000
                NetBSD 1.5 branch: December 13, 2000

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

Good signature made 2000-12-20 18:48 GMT by key:

  1024 bits, Key ID F8376205, Created 1997-07-01
   "security-officer@netbsd.org"

If you have feedback, comments, or additional information about this vulnerability, please send us email.

OpenBSD

Notified:  December 04, 2000 Updated:  December 21, 2000

Status

  Vulnerable

Vendor Statement

OpenBSD made a patch available to fix this problem on December 4, 2000 in OpenBSD 2.8 Errata 005: SECURITY FIX: Dec 4, 2000:

http://www.openbsd.org/errata.html#ftpd

An OpendBSD Security Advisory: Single-byte buffer overflow vulnerability in ftpd, was published on December 18, 2000:

http://www.openbsd.org/advisories/ftpd_replydirname.txt

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

FreeBSD

Updated:  December 21, 2000

Status

  Not Vulnerable

Vendor Statement

The FreeBSD security officer, Kris Kennaway <kris@freebsd.org>, posted a statement to Bugtraq regarding this issue:

http://www.securityfocus.com/archive/1/152187

"FreeBSD is not vulnerable"

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

However, this message was not signed with the FreeBSD security officer key; it was signed with a key unknown to the CERT/CC at this time: "Signature by unknown keyid: 0x68E840A5", presumably Kris's personal key.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

IBM

Notified:  December 21, 2000 Updated:  December 22, 2000

Status

  Not Vulnerable

Vendor Statement

IBM's AIX operating system is not susceptible to this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.


CVSS Metrics

Group Score Vector
Base N/A N/A
Temporal N/A N/A
Environmental N/A

References

Credit

Thanks to scrippie@grafix.nl for reportedly finding the problem, Kristian Vlaardingerbroek for originally reporting the problem to OpenBSD, OpenBSD for publishing an excellent security advisory about the problem, and Olaf Kirch for his lucid explanation of the nature the off-by-one, poisoned NUL byte vulnerability and how it can be identified and fixed.

This document was written by Jeffrey S Havrilla.

Other Information

CVE IDs: None
Severity Metric: 38.56
Date Public: 2000-12-04
Date First Published: 2000-12-21
Date Last Updated: 2000-12-22 17:32 UTC
Document Revision: 21

Sponsored by the Department of Homeland Security Office of Cybersecurity and Communications.