Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 17 Oct 2012 13:41:48 -0600
From: Kurt Seifried <>
CC: Simon McVittie <>
Subject: Re: CVE request: ruby file creation due in insertion
 of illegal NUL character

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 
>> though?
> 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.
> S

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 -


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.