Front page | perl.perl5.porters |
Postings from March 2013
On Mar 23, 2013, at 8:54 AM, Dave Mitchell via RT <perlbug-followup@perl.org> 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