Re: CVE request: ruby file creation due in insertion of illegal NUL character

[Simon McVittie <smcv () debian org>]

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
> > last position.
>
> 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
before.)

    S