- From: Terje Bless <link@tss.no>
- Date: Fri, 25 Feb 2000 18:10:45 +0100
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- cc: W3C Validator <www-validator@w3.org>, Brian Gilkison <gilkison@one.net>
On 25.02.00 at 17:11, Bjoern Hoehrmann <derhoermi@gmx.net> wrote: ># [(check,v 1.64 / line 125)] ># delete() the, possibly tainted, $PATH. >delete $ENV{PATH}; > >If the path is deleted, Perl cannot locate my commando processor. >What are the reasons for this line Paranoia. >how about removing/replacing it? I'll look into it (I introduced it). 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. You windoze folks should be particularly worried about that! On a more pragmatic level this is mostly to shut Perl's taint checks up. We do need those checks for other issues, but it's less clear when looking at the path in isolation. The line in question can be deleted with no ill effect, but you'd better understand the security implications of this pretty clearly first. I wouldn't reccomend it! OTOH, this got introduced just a few revs ago and there are no recorded exploits, that I'm aware of, of this problem. It's also a rather obscure problem which requires access to the local machine to exploit. However, that can be accomplished through the network or by some means (Internet, Sneakernet, etc.) introducing a trojan on your system. A safer workaround may be explicitly setting the path to a known quantity that includes the path for CMD.EXE, but that will obviously never make it into the official distribution. The syntax would be: $ENV{PATH} = '<path_string_for_windoze_here>'; (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.) 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\").
Received on Friday, 25 February 2000 13:03:45 UTC