mailing list archives
Re: CVE request: ruby file creation due in insertion of illegal NUL character
From: Simon McVittie <smcv () debian org>
Date: Thu, 18 Oct 2012 17:36:43 +0100
On 18/10/12 11:51, Matthias Weckbecker wrote:
On Wednesday 17 October 2012 20:14:22 Simon McVittie wrote:
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
Although this is a very elegant solution it's on the other hand probably not
trivially implemented, because NUL is mostly treated as the end of a string.
In languages like Perl and Python where a string can contain NULs, the C
representation of a high-level-language string is not just a C string
(NUL-terminated char *); it's a struct with a buffer and a length,
similar to a Pascal string or GLib's GString object. The buffer is
typically guaranteed to be at least 1 byte longer than the "official"
length, and contain a NUL after the "official" length, so that it can be
passed to APIs that expect a C string without copying.
For instance, Python has the function PyString_AsStringAndSize() to
access both the buffer and the length in one call.
From a quick look at, for instance, PerlIO_openn() in Perl 5.16.1's
perlio.c, it would be necessary to use SvPV_const() instead of
SvPV_nolen_const(), which gives you a length and a buffer instead of
just the buffer; at which point it's possible and safe to check that no
NUL appears in the first length-1 bytes. To have its new semantics, Ruby
must be doing something pretty similar.
(I'm not volunteering to write a patch - I've never used Perl's C API