Front page | perl.perl5.porters |
Postings from March 2013
Oops, I accidentally sent this to Reini only when I meant to send it to
the list. Sorry about that.
-------- Original Message --------
Subject: Re: [perl #117265] [PATCH] e213661 no warnings 'safesyscalls',
fatal nul checks
Date: Sat, 23 Mar 2013 16:05:04 +0100
From: Lukas Mai <plokinom@gmail.com>
To: Reini Urban <reini@cpanel.net>
On 23.03.2013 15:49, Reini Urban 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.
>
> There are four possible reactions: ignore, silently strip, warn and strip, or die.
I don't understand what you mean by "strip". Something like:
my $foo = "XYZ\0ABC";
unlink $foo;
# $foo eq "XYZ"
?
> 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.
So it works unlike every other warning category? AFAIK all other
warnings are simply ... well, warnings. They don't cause fatal errors
(unless you explicitly make them fatal).
> I explicitly allow typical harmless programmer errors adding another \0
> at the end.
My favorite semantics would be to not treat \0 specially, regardless of
warnings. That means failing with ENOENT if you pass such a string to
open, unlink, stat, ... etc, because as far as Perl is concerned, there
is a \0 in that string, and as far as the file system is concerned, no
such file exists. Similarly, glob("*\0") should return ().
The only problem I see with this is that it might break older scripts
that use a 2-arg open call of the form open(F, "< $foo\0") but we could
add a special exception for this case (only). That is: In a call to
2-arg open where the filename $X contains exactly one \0 and it is the
last character, treat it as substr($X, 0, -1) instead.
--
Lukas Mai <plokinom@gmail.com>
Thread Next