develooper Front page | perl.perl5.porters | Postings from March 2013

Re: [perl #117265] [PATCH] e213661 no warnings 'safesyscalls', fatal nul checks

Thread Previous | Thread Next
Reini Urban
March 23, 2013 14:49
Re: [perl #117265] [PATCH] e213661 no warnings 'safesyscalls', fatal nul checks
Message ID:
On Mar 23, 2013, at 8:54 AM, Dave Mitchell via RT <> wrote:

> On Thu, Mar 21, 2013 at 12:37:27PM -0700, Reini Urban via RT wrote:
>> Add the fatal warnings category safesyscalls.
>> Disallow binary pathnames and arguments to other syscalls, strings
>> with embedded \0, which are ignored in the syscall but kept in
>> perl. Allow an ending \0 though, as several modules add a \0 to
>> such strings without adjusting the length.
>> The hidden payloads in these invalid string args may cause unnoticed
>> security problems, as they are ignored by the syscalls but kept around
>> in perl PVs.
> Thanks for this.
> Your description of this this change is a bit unclear; in particular, I'm
> assuming that "Disallow binary pathnames" only refers to disallowing \0,
> rather than some more general non-ASCII prohibition???
> From what I understand of this patch, it makes the following changes:
> First in the absence of 'use warnings' (or in the presence of
> 'no warnings "safesyscalls"), it makes system calls like
>    open my $fh, ">", "foo\0bar"
> return false and sets $! to 'no such file' or some such appropriate
> error.

No, it actually follows the old behavior: silently ignore and go on.

> Second, in the presence of 'use warnings', it instead causes the open to
> croak (captureable with eval as usual).
> Is this a correct assessment?

Yes, the die part is correct.

> Before discussing the detailed implementation on the patch, I think we
> need a rough concensus on what semantics we desire.
> My own personal opinion is that I like the first part: causing system
> calls to mandatorally (and unchangeably) return failure in the presence of
> \0.
> I'm not very keen on the second part. For a start, it doesn't add that
> much over the first part: the file won't have been opened under any
> circumstances and writes to it will still fail, even if the return code
> isn't checked. It's just that suddenly the whole program dies, just because
> the code contains 'use warnings'.  This seems a big escalation, If people
> want that behaviour, they can always use autodie.

There are four possible reactions: ignore, silently strip, warn and strip, or die.

Without warnings or with no warnings 'syscalls' perl behaves as before: ignore.

With warnings enabled I went for die, because such a string argument is 
almost always a breakin attempt.
The second option would be a warning with strip of the string (reset the SvCUR).
But since the typical use case for this is harmful and an aggressive breakin 
attempt I went for die. 

I explicitly allow typical harmless programmer errors adding another \0
at the end.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About