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 11:03:35 -0600
From: Kurt Seifried <>
CC: Matthias Weckbecker <>
Subject: Re: CVE request: ruby file creation due in insertion
 of illegal NUL character

Hash: SHA1

On 10/17/2012 04:25 AM, Matthias Weckbecker wrote:
> On Wednesday 17 October 2012 11:44:35 Fabian Keil wrote:
>> Daniel Kahn Gillmor <> wrote:
>>> On 10/16/2012 08:40 AM, Matthias Weckbecker wrote:
>>>> Technically, this would also apply to Perl (at least with
>>>> 5.12.3).
>>> It's also the case with perl 5.14.2 (just tested). :/
>> At least for Perl I consider this a feature.
> I agree. I also think that an application which lets such things
> happen (ie allow arbitrary content to be passed to open()) is
> rather to blame than the language (/interpreter) itself. But the
> same applies to Ruby, IMO.

One thought is if you're interfacing to things like file systems which
generally don't handle NUL bytes in file names[filesystems] I would
hope the programming language does the smart thing and spit out an
error. 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).


Plus I'm looking for documentation on this, in ruby for example:

Create a Pathname object from the given String (or String-like
object). If path contains a NUL character (\0), an ArgumentError is

and I would have generally assumed that to be the case across all
related functions.

As for Perl:

If magic open is a bit too magical for you, you don't have to turn to
sysopen. To open a file with arbitrary weird characters in it, it's
necessary to protect any leading and trailing whitespace. Leading
whitespace is protected by inserting a "./" in front of a filename
that starts with whitespace. Trailing whitespace is protected by
appending an ASCII NUL byte ("\0" ) at the end of the string.

This assumes, of course, that your system considers dot the current
working directory, slash the directory separator, and disallows ASCII
NULs within a valid filename.

So as we can see from the file system comparison table this is almost
always the case.

I think it's disingenuous to blame every app that uses something as
common as "open" for doing something dangerous when it's pretty clear
that this behaviour is not expected, I think solving it in open/etc
makes a lot more sense than trying to fix every app that uses open
(which is.. probably all of them).

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

- -- 
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.