W3C home > Mailing lists > Public > www-validator@w3.org > February 2000

Re: Validator patch (tiny)

From: Terje Bless <link@tss.no>
Date: Fri, 25 Feb 2000 21:36:36 +0100
Message-Id: <200002252119.WAA19595@vals.intramed.rito.no>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
cc: Brian Gilkison <gilkison@one.net>, W3C Validator <www-validator@w3.org>
[ BTW, why are we CCing all over the place? Aren't everyone on the list? ]

On 25.02.00 at 20:22, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:

>The script does not (better: it should not) access $ENV{PATH} in any way
>so the line is superfluous.

The key word is "should". Unfortunately, we live in an imperfect world
where all the programmers are fallible; including both those working on the
validator and those who are working on the interpreter for the language we
are using. As a point in fact...

>The full path to the commando processor is always stored in $ENV{ComSpec};
>i wonder why Perl does not use this variable to find it.

...Perl /shouldn't/ use $ENV{PATH} to find a command interpreter. QED.


>| but that will obviously never make it
>| into the official distribution. The syntax would be:
>|
>| $ENV{PATH} = '<path_string_for_windoze_here>';
>
>Impracticable.

Why? It's harder then having the validator work out of the box, but it's no
harder then any other modification you make as a workaround. In fact, it's
easier, because CVS will happily add in the extra line, but will force you
to manually intervene if you've altered the original line.


>| (TIP: Add it after the delete() call and leave it in place so it'll be
>|       easier to sync local mods to the W3C version.)
>
>I hash your 'delete'-line out and everything works fine as it did before.

Yes -- That's what I said, wasn't it? -- but that is potentially unsafe.


>The PATH is set by myself and maintained by myself. I know whats it's
>value, and I'm responsible for it, as I am for my whole system. If the
>PATH is tainted it's _my_ problem and not the scripts one.

So if the script installs Back Orifice that's ok too? Or if it will
blissfully hand out any file you ask it to with a "special" CGI parameter?
Or overwrite any file just because it was asked to? Or...

There is _no_ guarantee that the path was set, _correctly_, by a _trusted_
party. The first rule of secure programming is "Trust No One!" and that
includes yourself, the user, the system, and certainly any user input.

You are paranoid, but are you paranoid *enough*?


>There are no real-world-conditions where keeping $ENV{PATH}s value makes
>this script vulnerable,

Yes there are. Plenty!


>but it breakes the script, so I plead for deleting it.

It doesn't "break" the script, but security is orthogonal to functionality.
A tradeoff must be made. In this case maybe we can lean more in the
direction of convenience, or possibly work around it, but it needs to be
rather carefully considered.


In the final analyses, you are free to do whatever you want on your own
system. If it's physically disconnected from any cables, inside a locked
room, and embedded in a block of concrete, it's probably secure enough that
you can run software with holes in it. Your call. :-)
Received on Friday, 25 February 2000 16:20:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 25 April 2012 12:13:53 GMT