develooper Front page | perl.perl5.porters | Postings from October 2012

Re: Security Issues in perl-5.16.x

Thread Previous
From:
David Golden
Date:
October 2, 2012 19:41
Subject:
Re: Security Issues in perl-5.16.x
Message ID:
CAOeq1c-jhUWPCe-GhG_qVgoem67XgB4AJZaRA-vNCekTNdDzWw@mail.gmail.com
[Assuming this was meant for the list, so replying there.]

On Tue, Oct 2, 2012 at 10:30 PM, Craig A. Berry <craig.a.berry@gmail.com> wrote:
>
>> (1) Attacker needs a way to get a "payload" of malicious data into memory
>> (2) Attacker needs a way to execute said payload
>>
>> Does the NUL issue relate to #1 or #2?  If so, how?
>
> #1.  That's the easy part.  "foo\0payload" means that 'payload' is
> sitting there beyond where syscalls that take null-terminated strings
> will see it.  Whether someone could do something evil with it is a bit
> harder but most people seem to think you can't.  SVs can store UCS-2
> characters, binary data, etc., so it's not clear that this form of
> hiding something really amounts to anything you can't already do by
> just making a string with your payload in it.

This part I do understand, even if I've been intentionally playing a
bit dumb. :-)

Let me ask in a more refined question:

Is there something about NUL's in strings that come from external
sources that could somehow defeat tainting or the "usual" sort of
checks that people do to validate input (e.g. regular expressions)?

So we don't get into fruitless debates about shooting one's own foot,
let's avoid thinking about obvious security holes like "format=FOO"
CGI parameters that are written to load "Some::Module::Backend::FOO"
without any sanity checking on FOO.

David

-- 
David Golden <xdg@xdg.me>
Take back your inbox! → http://www.bunchmail.com/
Twitter/IRC: @xdg

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About