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

Re: Validator patch (tiny)

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Fri, 25 Feb 2000 20:22:40 +0100
Message-ID: <016f01bf7fc5$d780a380$c784fcc3@de>
To: "Terje Bless" <link@tss.no>
Cc: <www-validator@w3.org>, "Brian Gilkison" <gilkison@one.net>
* Terje Bless <link@tss.no> wrote:
| >delete $ENV{PATH};

| The problem is that $ENV{PATH} is insecure -- possibly tainted -- which
| means that if we call system(3) we are potentially vulnerable to a trojan
| attack.

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

| A safer workaround may be explicitly setting the path to a known quantity
| that includes the path for CMD.EXE,

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.

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

Impracticable.

| (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.

| You can probably just cut and paste the original windows PATH entry and
| then, for added security-by-obscurity, remove the suspicious parts (like
| "C:\\Program Files\").

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.

There are no real-world-conditions where keeping $ENV{PATH}s value makes this
script vulnerable, but it breakes the script, so I plead for deleting it.

kind regards,
--
Björn Höhrmann · http://www.bjoernsworld.de · mailto:bjoern@hoehrmann.de
Received on Friday, 25 February 2000 14:26:11 GMT

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