- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Fri, 25 Feb 2000 20:22:40 +0100
- 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 UTC