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
-----BEGIN PGP SIGNED MESSAGE-----
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
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
-----END PGP SIGNATURE-----