Front page | perl.advocacy |
Postings from October 2000
Re: backlash on rewrite/redesign of Perl -- feedback
Thread Previous
|
Thread Next
From:
Nicholas Clark
Date:
October 21, 2000 23:40
Subject:
Re: backlash on rewrite/redesign of Perl -- feedback
Message ID:
20001021155930.A14624@Bagpuss.unfortu.net
On Tue, Oct 10, 2000 at 04:16:24PM -0400, Adam Turoff wrote:
> On Tue, Oct 10, 2000 at 12:38:39PM -0700, Steve Fink wrote:
> > Adam Turoff wrote:
> > >
> > > Message #1: Perl5 isn't going away, even after Perl6 is released.
> > >
> > > Proof: Perl4 is still around.
> >
> > Doesn't help this need. Perl4 is unsupported.
>
> By the same token, so is 5.005_03.
>
> Older versions of Perl are solving problems, and older versions of
> Perl aren't going away. If Perl were used today as part of a five
perl 5.005_03 isn't said to be unsupported, is it? If so, then I guess
peoples' fears are valid about the "support" level they can expect for
perl5 current stable when perl6 comes out.
I feel a lot of reassurance about perl5's future in perl6 times would be
given if a perl5.005_04 came out soon after 5.6.1, with as many bug fixes
for bugs fixed between 5.005_03 and 5.6.1 back ported and fixed in it. (This
would shut up critics saying "show me the code")
I don't think I'm going to be using 5.6 series while certain "surprises"
happen:
$ /usr/local/bin/perl -wle '$a = chr (48); $a=~s/././; print length $a'
1
$ /usr/local/bin/perl -wle '$a = chr (448); $a=~s/././; print length $a'
2
/usr/bin/perl -wle '$a = chr (448); $a=~s/././; print length $a'
1
(/usr/local/bin/perl is 5.7, /usr/bin/perl is 5.005_03)
and there's the chance that code that I haven't inspected changes behaviour
even when perl5.6 is perfect and all the UTF glitches have been ironed out:
/usr/bin/perl -wle '$a = chr (448); print ord $a'
192
/usr/local/bin/perl -wle '$a = chr (448); print ord $a'
448
I'm not the only person who doesn't like the idea of subjecting old code to
Unicode, see the appended message
Nicholas Clark
------------------------------------------------------------------------------
From SECPROG@SECURITYFOCUS.COM Fri Oct 20 18:10:15 2000
Message-ID: <Pine.NEB.3.96L.1001019134744.80893A-100000@fledge.watson.org>
Date: Thu, 19 Oct 2000 13:48:13 -0400
Reply-To: "Andrew R. Reiter" <arr@WATSON.ORG>
Sender: Secure Programming Mailing List <SECPROG@SECURITYFOCUS.COM>
From: "Andrew R. Reiter" <arr@WATSON.ORG>
Subject: Re: IIS %c1%1c remote command execution (fwd)
To: SECPROG@SECURITYFOCUS.COM
Status: RO
FYI.. take a look at this post. He's very correct in his thinking.
*-------------.................................................
| Andrew R. Reiter
| arr@fledge.watson.org
| "It requires a very unusual mind
| to undertake the analysis of the obvious" -- A.N. Whitehead
---------- Forwarded message ----------
Date: Thu, 19 Oct 2000 21:07:57 +1100
From: Cris Bailiff <c.bailiff@E-SECURE.COM.AU>
To: BUGTRAQ@SECURITYFOCUS.COM
Subject: Re: IIS %c1%1c remote command execution
> Florian Weimer <Florian.Weimer@RUS.UNI-STUTTGART.DE> writes:
>
> This is one of the vulnerabilities Bruce Schneier warned of in one of
> the past CRYPTO-GRAM isssues. The problem isn't the wrong time of
> path checking alone, but as well a poorly implemented UTF-8 decoder.
> RFC 2279 explicitly says that overlong sequences such as 0xC0 0xAF are
> invalid.
As someone often involved in reviewing and improving other peoples web code, I
have been citing the unicode security example from RFC2279 as one good reason why
web programmers must enforce 'anything not explicitly is allowed is denied'
almost since it was written. In commercial situations I have argued myself blue
in the face that the equivalent of (perl speak) s!../!!g is not good enough to
clean up filename form input parameters or other pathnames (in perl, ASP, PHP
etc.). I always end up being proved right, but it takes a lot of effort. Should
prove a bit easier from now on :-(
>
> It's a pity that a lot of UTF-8 decoders in free software fail such
> tests as well, either by design or careless implementation.
The warning in RFC 2279 hasn't been heeded by a single unicode decoder that I
have ever tested, commercial or free, including the Solaris 2.6 system libraries,
the Linux unicode_console driver, Netscape commuicator and now, obviously, IIS.
Its unclear to me whether the IIS/NT unicode decoding is performed by a system
wide library or if its custom to IIS - either way, it can potentially affect
almost any unicode aware NT application.
I have resisted upgrading various cgi and mod_perl based systems to perl5.6
because it has inbuilt (default?) unicode support, and I've no idea which
applications or perl libraries might be affected. The problem is even harder than
it looks - which sub-system, out of the http server, the perl (or ASP or PHP...)
runtime, the standard C libraries and the kernel/OS can I expect to be performing
the conversion? Which one will get it right? I think Bruce wildly understated the
problem, and I've no idea how to put the brakes on the crash dive into a
character encoding standard which seems to have no defined canonical encoding and
no obvious way of performing deterministic comparisons.
I suppose as a security professional I should be happy, looking forward to a
booming business...
Cris Bailiff
c.bailiff@e-secure.com.au
Thread Previous
|
Thread Next