On Fri, Jan 25, 2019 at 07:41:52PM +, Ian Jackson wrote:
> Holger Levsen writes ("Re: Potentially insecure Perl scripts"):
> > On Thu, Jan 24, 2019 at 03:18:40PM +, Ian Jackson wrote:
> > > To the Debian Perl maintainers: [...]
> > > To the Debian se
[resent with group-reply, sorry]
On 2019-01-25 10:36:42 +, Dominic Hargreaves wrote:
> Also, I think it's worth trying to identify what the worst extent
> of the issue is. Whilst I don't agree with some who say that this isn't
> a security issue at all, I don't know of any real-world cases whe
On 2019-01-25 10:36:42 +, Dominic Hargreaves wrote:
> Also, I think it's worth trying to identify what the worst extent
> of the issue is. Whilst I don't agree with some who say that this isn't
> a security issue at all, I don't know of any real-world cases where
> it would be exploitable for r
On 2019-01-25 13:55:47 +, Ian Jackson wrote:
> The easiest way to sanitise a string to make it safe for 2-argument
> open involves:
> * prepending ./ if the string does not start with /
> * appending \0 (a nul byte)
> The result is also a valid operand for 3-argument open.
However, the null
Sorry for not reading the whole thread first, so my last mail didn't
take account of this one...
Dominic Hargreaves writes ("Re: Potentially insecure Perl scripts"):
> No, I don't think you did; thank you for putting it so succinctly.
> As is obvious from the discu
Holger Levsen writes ("Re: Potentially insecure Perl scripts"):
> On Thu, Jan 24, 2019 at 03:18:40PM +, Ian Jackson wrote:
> > To the Debian Perl maintainers: [...]
> > To the Debian security team: [...]
>
> I've read the whole thread and am surprised &qu
Vincent Lefevre writes ("Re: Potentially insecure Perl scripts"):
> I fear that this is not that simple: I suppose that this will break
> scripts that modify @ARGV to make <> secure. :(
The easiest way to sanitise a string to make it safe for 2-argument
open involves:
On Thu, Jan 24, 2019 at 08:00:12PM +, Holger Levsen wrote:
> On Thu, Jan 24, 2019 at 03:18:40PM +, Ian Jackson wrote:
> > To the Debian Perl maintainers: [...]
> > To the Debian security team: [...]
>
> I've read the whole thread and am surprised "talking to upstream" (and
> fixing the iss
On 2019-01-24 15:18:40 +, Ian Jackson wrote:
> Ian Jackson writes ("Re: Potentially insecure Perl scripts"):
> > The right answer is to fix the behaviour to be secure and sane by
> > default. We can arrange for an environment variable for people who
> > want to
On Thu, 2019-01-24 at 21:08:00 +, Niels Thykier wrote:
> Ian Jackson:
> > I asked codesearch about
> >while.*\<\>
> > and got 10780 results.
>
> I had a similar thought but tried a slightly more complex pattern:
>
> (while\s*|for(each)?\s*(my)?\s*\$.*)\(.*<>\s*\)
>
> The pattern also
Ian Jackson:
> Ian Jackson writes ("Re: Potentially insecure Perl scripts"):
>> Even if we care only about scripts which are part of Debian, rather
>> than scripts which people merely expect to run on Debian (and where
>> they trust Debian to not blow their leg off),
Ian Jackson writes ("Re: Potentially insecure Perl scripts"):
> Even if we care only about scripts which are part of Debian, rather
> than scripts which people merely expect to run on Debian (and where
> they trust Debian to not blow their leg off), there will probably be
&
Mark Fowler writes ("Re: Potentially insecure Perl scripts"):
> Wouldn't a less drastic approach be to change the vulnerable scripts to use
> <<>> instead of <>?
That is surely a much more drastic change. It would invoke changing
probably literally mil
On Thu, Jan 24, 2019 at 02:49:29PM -0500, Mark Fowler wrote:
> On Thu, Jan 24, 2019 at 10:18 AM Ian Jackson <
> ijack...@chiark.greenend.org.uk> wrote:
> > To the Debian Perl maintainers: if I make a patch to make
> > -p -n <>
> > use the 3-argument form of open (or equivalent), will you apply it
On Thu, Jan 24, 2019 at 03:18:40PM +, Ian Jackson wrote:
> To the Debian Perl maintainers: [...]
> To the Debian security team: [...]
I've read the whole thread and am surprised "talking to upstream" (and
fixing the issue there as well) hasn't really been on the table. :/ Did I
miss that?
--
On Thu, Jan 24, 2019 at 10:18 AM Ian Jackson <
ijack...@chiark.greenend.org.uk> wrote:
> To the Debian Perl maintainers: if I make a patch to make
> -p -n <>
> use the 3-argument form of open (or equivalent), will you apply it ?
>
> To the Debian security team: would you ship it in a security up
Ian Jackson writes ("Re: Potentially insecure Perl scripts"):
> The right answer is to fix the behaviour to be secure and sane by
> default. We can arrange for an environment variable for people who
> want to turn the crazy back on.
To the Debian Perl maintainers: if I make a
Guillem Jover writes ("Re: Potentially insecure Perl scripts"):
> Part of the problem might also be that perlcritic recommands this in its
> InputOutput::ProhibitExplicitStdin policy, you can see the description
> with «perlcritic --doc InputOutput::ProhibitExplicitStdin».
On 2019-01-24 11:18:06 +0100, Adam Borowski wrote:
> On Thu, Jan 24, 2019 at 04:41:29AM +, Ben Hutchings wrote:
> > On Wed, 2019-01-23 at 09:07 -0800, Russ Allbery wrote:
> > > Ian Jackson writes:
> > > > Apparently this has been klnown about for EIGHTEEN YEARS
> > > > https://rt.perl.org/Pu
On 2019-01-24 09:46:56 +0100, Ansgar wrote:
> But "<>" isn't the only problem, there are way too many uses of the
> two-argument form of Perl's "open" too...
Perhaps, but at least "open" had correctly been documented since the
beginning, and I quickly learnt to preprend "<" to the filename in
the
On 2019-01-24 11:12:43 +0100, Alex Mestiashvili wrote:
> On 1/24/19 2:40 AM, Vincent Lefevre wrote:
> But I disagree that a language can be considered insecure, just because
Note: just a feature, not the language itself.
> it lets you shoot in the foot.
> The first thing I learned when doing CGI
Hi!
On Wed, 2019-01-23 at 14:05:54 +0100, Vincent Lefevre wrote:
> I've just reported
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920269
>
> against gropdf (also reported upstream to bug-groff), about the use of
> the insecure null filehandle "<>" in Perl, which can lead to arbitrary
On Thu, Jan 24, 2019 at 04:41:29AM +, Ben Hutchings wrote:
> On Wed, 2019-01-23 at 09:07 -0800, Russ Allbery wrote:
> > Ian Jackson writes:
> > > Apparently this has been klnown about for EIGHTEEN YEARS
> > > https://rt.perl.org/Public/Bug/Display.html?id=2783
> > > and no-one has fixed it o
On 1/24/19 2:40 AM, Vincent Lefevre wrote:
> On 2019-01-23 17:23:10 +0100, Alex Mestiashvili wrote:
>> On 1/23/19 4:44 PM, Vincent Lefevre wrote:
>>> On 2019-01-23 15:32:00 +, Ian Jackson wrote:
This is completely mad and IMO the bug is in perl, not in all of the
millions of perl scri
Russ Allbery writes:
> Ben Hutchings writes:
>> People have said this about ASLR, protected symlinks, and many other
>> kinds of security hardening changes. We made them anyway and took the
>> temporary pain for a long-term security gain.
>
> Well, Perl has a deprecation mechanism with warnings an
Ben Hutchings writes:
> People have said this about ASLR, protected symlinks, and many other
> kinds of security hardening changes. We made them anyway and took the
> temporary pain for a long-term security gain.
Well, Perl has a deprecation mechanism with warnings and so forth,
although I don'
On Wed, 2019-01-23 at 09:07 -0800, Russ Allbery wrote:
> Ian Jackson writes:
>
> > Apparently this has been klnown about for EIGHTEEN YEARS
> > https://rt.perl.org/Public/Bug/Display.html?id=2783
> > and no-one has fixed it or even documented it.
>
> It's been documented for pretty close to ei
On 2019-01-23 17:23:10 +0100, Alex Mestiashvili wrote:
> On 1/23/19 4:44 PM, Vincent Lefevre wrote:
> > On 2019-01-23 15:32:00 +, Ian Jackson wrote:
> >> This is completely mad and IMO the bug is in perl, not in all of the
> >> millions of perl scripts that used <> thinking it was a sensible th
On 1/23/19 6:23 PM, Colin Watson wrote:
> On Wed, Jan 23, 2019 at 06:09:39PM +0100, Alex Mestiashvili wrote:
>> On 1/23/19 5:31 PM, Colin Watson wrote:
>>> On Wed, Jan 23, 2019 at 05:23:10PM +0100, Alex Mestiashvili wrote:
On 1/23/19 4:44 PM, Vincent Lefevre wrote:
> I agree that it would
Colin Watson writes:
> Ah, I see. I think it would have been clearer what you meant with a bit
> more context, so here it is for others:
>If one can be sure that a particular program is a Perl script
>expecting filenames in @ARGV, the clever programmer can write
>somethi
On Wed, Jan 23, 2019 at 06:09:39PM +0100, Alex Mestiashvili wrote:
> On 1/23/19 5:31 PM, Colin Watson wrote:
> > On Wed, Jan 23, 2019 at 05:23:10PM +0100, Alex Mestiashvili wrote:
> >> On 1/23/19 4:44 PM, Vincent Lefevre wrote:
> >>> I agree that it would be better to drop this "feature" of Perl.
>
On 1/23/19 5:31 PM, Colin Watson wrote:
> On Wed, Jan 23, 2019 at 05:23:10PM +0100, Alex Mestiashvili wrote:
>> On 1/23/19 4:44 PM, Vincent Lefevre wrote:
>>> I agree that it would be better to drop this "feature" of Perl.
>>> It is probably never used, and probably useless (I would rather
>>> use
Ian Jackson writes:
> Apparently this has been klnown about for EIGHTEEN YEARS
> https://rt.perl.org/Public/Bug/Display.html?id=2783
> and no-one has fixed it or even documented it.
It's been documented for pretty close to eighteen years too. See
perlop(1):
The null filehandle "<>" is
On Wed, Jan 23, 2019 at 05:23:10PM +0100, Alex Mestiashvili wrote:
> On 1/23/19 4:44 PM, Vincent Lefevre wrote:
> > I agree that it would be better to drop this "feature" of Perl.
> > It is probably never used, and probably useless (I would rather
> > use the features from the shell if I need a pip
On 1/23/19 4:44 PM, Vincent Lefevre wrote:
> On 2019-01-23 15:32:00 +, Ian Jackson wrote:
>> This is completely mad and IMO the bug is in perl, not in all of the
>> millions of perl scripts that used <> thinking it was a sensible thing
>> to write.
>
> I agree that it would be better to drop t
On Wed, Jan 23, 2019 at 04:44:07PM +0100, Vincent Lefevre wrote:
> On 2019-01-23 15:32:00 +, Ian Jackson wrote:
> > This is completely mad and IMO the bug is in perl, not in all of the
> > millions of perl scripts that used <> thinking it was a sensible thing
> > to write.
>
> I agree that it
On 1/23/19 2:05 PM, Vincent Lefevre wrote:
> Hi,
>
> I've just reported
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920269
>
> against gropdf (also reported upstream to bug-groff), about the use of
> the insecure null filehandle "<>" in Perl, which can lead to arbitrary
> command exe
On 2019-01-23 15:32:00 +, Ian Jackson wrote:
> This is completely mad and IMO the bug is in perl, not in all of the
> millions of perl scripts that used <> thinking it was a sensible thing
> to write.
I agree that it would be better to drop this "feature" of Perl.
It is probably never used, an
Ian Jackson writes ("Re: Potentially insecure Perl scripts"):
> Vincent Lefevre writes ("Potentially insecure Perl scripts"):
> > I've just reported
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920269
> > against gropdf (also reported up
Vincent Lefevre writes ("Potentially insecure Perl scripts"):
> I've just reported
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920269
> against gropdf (also reported upstream to bug-groff), about the use of
> the insecure null filehandle "<>" in Perl, which can lead to arbitrary
> command
40 matches
Mail list logo
