[12790] in bugtraq
Subst.exe carelessness (fwd)
daemon@ATHENA.MIT.EDU (Ben Greenbaum)
Wed Dec 1 12:50:32 1999
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.GSO.4.10.9911301605310.27970-100000@www.securityfocus.com>
Date: Tue, 30 Nov 1999 16:07:01 -0800
Reply-To: Ben Greenbaum <bgreenbaum@SECURITYFOCUS.COM>
From: Ben Greenbaum <bgreenbaum@SECURITYFOCUS.COM>
X-To: bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM
This was sent to vuldb@securityfocus.com and is a good workaround for the
subst problem posted here earlier. I repost it to the list with the
author's permission. Thanks David!
Ben Greenbaum
Site Content Manager
Security Focus
http://www.securityfocus.com
---------- Forwarded message ----------
Date: Tue, 30 Nov 1999 16:18:38 -0500
From: dmanders@worldnet.att.net
To: vuldb@securityfocus.com
Subject: Subst.exe carelessness
In our environment, we use both the subst and net use commands to setup
the users' environment during logon. In order to avoid any errors, our
logon scripts simply include subst *drive_letter* /d statements for all
drive letters that we use. This ensures that the machine has no previous
mappings before the rest of the script is run.
if exist g: subst g: /d
if exist h: subst h: /d
if exist t: subst t: /d
if exist z: subst z: /d
subst g: c:\data
subst h: c:\apps
net use t: \\server\server_apps
net use z: \\server\user_home
We find that this solution is simple for our environment. And as the
exploit that you point out will only work to spoof drive mappings that
*should* exist in a normal user environment, this simple script addition
will eliminate that problem.
David Anders
dmanders@worldnet.att.net
