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 11:03:35 -0600

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 <dkg () fifthhorseman net> wrote:
On 10/16/2012 08:40 AM, Matthias Weckbecker wrote:
Technically, this would also apply to Perl (at least with

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 - http://www.enigmail.net/


  By Date           By Thread  

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