Home page logo

oss-sec logo oss-sec mailing list archives

Re: CVE request: ruby file creation due in insertion of illegal NUL character
From: Kurt Seifried <kseifried () redhat com>
Date: Wed, 17 Oct 2012 13:41:48 -0600

Hash: SHA1

On 10/17/2012 12:14 PM, Simon McVittie wrote:
On 17/10/12 18:03, Kurt Seifried wrote:
Avtually looking at that page it appears that no modern file 
systems allows NUL in a file name (and in general I suspect it's
a bad idea/leads to some nasty edge case issues).

Anything that, directly or indirectly, uses Unix-style APIs to
access files can't possibly support NUL in a filename anyway, since
those APIs receive the filename as a NUL-terminated string.

Personally I think the perlopentut case makes sense, using NUL
as an end of string marker. What happens if stuff comes after it 

For Perl, one possibility would be to continue to treat an input
of "foo\0" as equivalent to "foo" (so that you can use "./ foo \0"
to mean " foo ", as documented), but disallow NULs anywhere except
the last position.


Wow so this goes back a ways:


- -------[  Phrack Magazine --- Vol. 9 | Issue 55 --- 09.09.99 --- 07 of
19  ]

- ----------------[  The Beef

- ----[  Poison NULL byte

Note:  The name `Poison NULL byte` was originally used by Olaf Kirch
in a Bugtraq post. I liked it, and it fit...  So I used.  Greetings to

When does "root" != "root", but at the same time, "root" == "root"
(Confused yet)?  When you co-mingle programming languages.

One night I got to wondering, exactly what would Perl allow, and could
I get anything to blow up in unexpected ways.  So I started piping
very weird data out to various system calls and functions.  Nothing
spectacular, except for one that was quite notable...

You see, I wanted to open a particular file, "rfp.db".  I used a fake
web scenario to get an incoming value "rfp", tacked on a ".db", and
then opened the file.  In Perl, the functional part of the script was
something like:

        # parse $user_input
        open(FILE "<$database");

Great.  I pass 'user_input=rfp', and the script tries to open "rfp.db".
Pretty simple (let's ignore the obvious /../ stuff right now).

Then it got interesting when I passed 'user_input=rfp%00'.  Perl made
$database="rfp\0.db", and then tried to open $database.  The results?
 It  opened "rfp" (or would have, had it existed).  What happened to
the ".db"?   This is the interesting part.

You see, Perl allows NUL characters in its variables as data.  Unlike C,
NUL is not a string delimiter.  So, "root" != "root\0".  But, the
underlying system/kernel calls are programmed in C, which DOES
recognize NUL as a delimiter.  So the end result?  Perl passes
"rfp\0.db", but the underlying libs stop processing when they hit the
first (our) NUL.

......... and so on.

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]