From @tamias

On Thu, Dec 30, 1999 at 12​:31​:19PM -0800, ap296@​torfree.net wrote​:

Phrack finds a major perl bug​:
http​://www.wiretrip.net/rfp/p/doc.asp?id=6&iface=2

So where's the bug? The only thing described here is bugs in Perl
programs, not in perl itself.

I recommend that you read the perlsec documentation, which discusses security
issues, including all the ones mentioned on that web page.

Ronald

From [Unknown Contact. See original ticket]

ap296 <ap296@​torfree.net> writes​:

Phrack finds a major perl bug​:
http​://www.wiretrip.net/rfp/p/doc.asp?id=6&iface=2

If you're actually trying to be helpful, providing some actual details on
what you think is a Perl bug would be nicer. None of the three items
listed on that page are actually called bugs in Perl.

To summarize for p5p, the first item on that page is a discussion of
weirdness related to adding nul characters to strings that will be passed
to system calls. The example used was passing "rfp\0" as a file name to a
script that only opens files ending in .db, so that Perl would try to open
"rfp\0.db" and actually open "rfp". This is probably worth a note in the
documentation; it's generally hard to get nul characters into situations
where this could be a problem, but it is possible with CGI scripts as the
article points out. Just use %00. This one may be somewhat more
interesting than the others given that it also affects sysopen().

The offered additional example, the fact that "root" and "root\0" compare
as inequal in Perl but are treated the same by system calls, is very
artificial and manufactured given that one doesn't generally ever pass a
username to a system call anyway (one uses UIDs instead).

The second item is a discussion of shell metacharacters and pointing out
that it's necessary to escape backslashes as well as other metacharacters.
No Perl bugs here.

The third item reduces basically to "people don't realize open is magic."
This is clearly documented in Perl's documentation and isn't a bug, and
we've had this argument on this list before.

The fourth item is a catalog of the insecurities in several Perl CGI
scripts pulled off the web, most of which appear not to use the CGI
module, not to run with tainting turned on, and are generally bad examples
of Perl programming.

--
Russ Allbery (rra@​stanford.edu) <URL​:http​://www.eyrie.org/~eagle/>

From [Unknown Contact. See original ticket]

Ronald J Kimball [rjk@​linguist.dartmouth.edu] quoth​:
*>
*>So where's the bug? The only thing described here is bugs in Perl
*>programs, not in perl itself.
*>
*>I recommend that you read the perlsec documentation, which discusses security
*>issues, including all the ones mentioned on that web page.

I don't recall Phrack being the pillar of useful information...nice to see
that this hasn't changed much. Ron, you should write a point by point
reply...maybe he'll give you greets in the next issue. 'Greets to my homie
Ron' Letting stuff like this go unanswered or unaddressed perpetuates
misinformed people.

e.

From @chipdude

According to Russ Allbery​:

Just use %00. This one may be somewhat more interesting than the
others given that it also affects sysopen().

Hm. I wonder if we should address this by forbidding NUL bytes in
sysopen() filenames.
--
Chip Salzenberg - a.k.a. - <chip@​valinux.com>
  "Fleagal. Bingo. Drooper. Snork. They're cops." //MST3K

From [Unknown Contact. See original ticket]

Hi,

Chip Salzenberg​:

Hm. I wonder if we should address this by forbidding NUL bytes in
sysopen() filenames.

I'm all for it. It _should_ have been caught using the taint checks which
already exist, though...
--
Matthias Urlichs | noris network GmbH | smurf@​noris.de | ICQ​: 20193661
The quote was selected randomly. Really. | http​://www.noris.de/~smurf/
--
Life is like quotations. Sometimes, it makes you laugh.
Sometimes, it makes you cry. Most of the time, you don't get it.
  -- Unknown

From @timbunce

On Sun, Jan 02, 2000 at 01​:27​:30AM -0800, Chip Salzenberg wrote​:

According to Russ Allbery​:

Just use %00. This one may be somewhat more interesting than the
others given that it also affects sysopen().

Hm. I wonder if we should address this by forbidding NUL bytes in
sysopen() filenames.

Perhaps with "perl -U" as an escape mechanism.

Tim.

From @chipdude

According to Matthias Urlichs​:

Chip Salzenberg​:

Hm. I wonder if we should address this by forbidding NUL bytes in
sysopen() filenames.

I'm all for it. It _should_ have been caught using the taint checks which
already exist, though...

Ah, yes, quite so. I knew there was something I was missing!
So that should be our primary reply to the reporter of the "bug".
--
Chip Salzenberg - a.k.a. - <chip@​valinux.com>
  "He's Mr. Big of 'Big And Tall' fame." // MST3K

From [Unknown Contact. See original ticket]

Tim Bunce <Tim.Bunce@​ig.co.uk> wrote

Perhaps with "perl -U" as an escape mechanism.

Escape to where ? Since NUL is disallowed in filenames at the C level.
it's hard to see what use that would be.

Mike Guy

From [Unknown Contact. See original ticket]

At 03​:05 PM 01/03/2000 -0800, Chip Salzenberg wrote​:

According to Matthias Urlichs​:

Chip Salzenberg​:

Hm. I wonder if we should address this by forbidding NUL bytes in
sysopen() filenames.

I'm all for it. It _should_ have been caught using the taint checks which
already exist, though...

Ah, yes, quite so. I knew there was something I was missing!
So that should be our primary reply to the reporter of the "bug".

With all of the flames in this thread. I don't know if your last statement
is suppose to be funny or has honest intentions. :/

From [Unknown Contact. See original ticket]

Hi,

ap296@​torfree.net​:

So that should be our primary reply to the reporter of the "bug".

With all of the flames in this thread. I don't know if your last statement
is suppose to be funny or has honest intentions. :/

It's not Perl's fault that Perl defaults to "strings may contain \0
characters", unlike C which defaults to "strings may not contain \0
unless you explicitly carry the length around", or some others where not
even that is possible.

It's the programmer's job to make sure that file names from external
sources are properly filtered. Perl's taint checks are supremely useful
for doing this.

One can write programs that are a security nightmare in any language.
Secure programs need care and forethought. Perl's tainting (among other
features) actually helps with the "care" part (in fact, I don't know any
other language which does this). It's therefore not very useful to single
out Perl's "security problems".

--
Matthias Urlichs | noris network GmbH | smurf@​noris.de | ICQ​: 20193661
The quote was selected randomly. Really. | http​://www.noris.de/~smurf/
--
"Batton down the hatches, several thousand Zulus approaching from the north."
  -- Christopher Commision report of LAPD car-to-car computer message, 7/91

From [Unknown Contact. See original ticket]

Matthias Urlichs <smurf@​noris.net> writes​:

It's the programmer's job to make sure that file names from external
sources are properly filtered. Perl's taint checks are supremely useful
for doing this.

While I largely agree with this, I think that it may be worth making a
special exception for nul characters embedded in the middle of file names
passed to sysopen(). To the user, sysopen is part of Perl, and should be
able to handle any Perl string or return an error saying that it can't
create that file. It's impossible in the Unix file system to create or
open the file "foo\0bar", so sysopen should return an error. It should
*not* silently open "foo" and not tell you that.

Don't think of it as a security issue. Think of it as a correctness
issue. What are the guarantees offered by sysopen? I would assume that
part of the documented interface to sysopen is that it either opens
exactly that file name (allowing for symlinks) or it fails with an error.
Since Perl allows nuls in strings and the C library can't detect them,
Perl is responsible for doing so and returning some appropriate error,
probably EACCES.

--
Russ Allbery (rra@​stanford.edu) <URL​:http​://www.eyrie.org/~eagle/>

From [Unknown Contact. See original ticket]

Hi,

Russ Allbery​:

While I largely agree with this, I think that it may be worth making a
special exception for nul characters embedded in the middle of file names
passed to sysopen().

... plus stat()/lstat()/access().

I agree (somewhat ;-).

--
Matthias Urlichs | noris network GmbH | smurf@​noris.de | ICQ​: 20193661
The quote was selected randomly. Really. | http​://www.noris.de/~smurf/
--
Allen's Axiom​:
  When all else fails, read the instructions.

From [Unknown Contact. See original ticket]

Or anything that takes a file name, nay? Like chown, -x, etc.

--tom

From @samtregar

On 6 Jan 2000, Russ Allbery wrote​:

While I largely agree with this, I think that it may be worth making a
special exception for nul characters embedded in the middle of file names
passed to sysopen(). To the user, sysopen is part of Perl, and should be
able to handle any Perl string or return an error saying that it can't
create that file. It's impossible in the Unix file system to create or
open the file "foo\0bar", so sysopen should return an error. It should
*not* silently open "foo" and not tell you that.

I wouldn't be surprised if there are scripts that actually use this
feature. My reasoning​: sticking a null in the middle of a char buffer and
passing it to a system call is a useful C idiom. The expectation (and the
reality) is that the system call will only look at the pre-null part of
the buffer. I think it is possible that transplanted C programmers may be
using the same idiom in perl, currently successfully.

Maybe it should be a warning, if it's going to be anything but acceptable?

-sam

From @chipdude

According to Sam Tregar​:

On 6 Jan 2000, Russ Allbery wrote​:

... nul characters embedded in the middle of file names
passed to sysopen().

I wouldn't be surprised if there are scripts that actually use this
feature.

Nor would I. Just about any doggone weird thing than can be done with
Perl has probably been done. Twice.

Maybe it should be a warning, if it's going to be anything but
acceptable?

Hmph. A warning normally, an error in taint mode?
--
Chip Salzenberg - a.k.a. - <chip@​valinux.com>
  "He's Mr. Big of 'Big And Tall' fame." // MST3K

From [Unknown Contact. See original ticket]

Tom Christiansen <tchrist@​jhereg.perl.com> writes​:

Or anything that takes a file name, nay? Like chown, -x, etc.

Or system() or qx{} or exec().

Chip

--
Chip Turner chip@​ZFx.com
  Programmer, ZFx, Inc. www.zfx.com
  PGP key available at wwwkeys.us.pgp.net