COMMAND
AT Jobs
SYSTEMS AFFECTED
WinNT
PROBLEM
Shawn Wright found following. Drive Mappings in Interactive Login
affect Processes running in context of Schedule User. Points
indicating this is a bug/security exploit and not by design (as
somehave indicated to Shawn).
1. Drive mappings are individual to each user, as seen by their
location in the registry under HKCU\Network. This point alone
indicates a bug. Why should the *personal* drive mappings of
an interactive login session have *any* affect on a service
running in a different user context, in a supposedly secure
environment? They shouldn't, plain and simple.
2. KB Article Q130668 is the only article I could find which has
any relationship to this issue, but it deals with a "bug" when
the drives are mapped to Netware Volumes using GSNW. However,
reading between the lines, one can see that the behavior
described (which is identical in both Netware and NT drive
mappings) is not by design, otherwise, why would they state
this: Microsoft has confirmed this to be a problem in Windows
NT Workstation and Server versions 3.5, 3.51, and 4.0... They
do offer up a solution to one half of the problem - that is
when the scheduled process leaves a mapped drive, which then
affects any interactive processes by preventing the use of this
drive (unless appropriate permissions exist for the interactive
user). But they make no mention of the other half - that a
non-privileged user can affect the environment of the scheduled
process, which is often in a priviliged account context.
Take the following scenario. A "secure" NT workstation is
configured with scheduler running in a user context that has
specific elevated rights in order to perform unattended
administrative functions based on scripts that are stored on a
server. But one of the tasks performed in these scripts requires
a mapped drive letter; UNC paths won't work. So to be sure, the
scripts begins by mapping a drive letter to the shared network
resource containing the patches and updates placed there when
required. Often these patches are security fixes and the like,
and the scheduler dutifully applies them to some large number of
machines as directed in the script.
Here comes the exploit. If an interactive login is present, and
the same drive letter is already mapped by a user, the net use in
the scheduled script will fail, as will the required hotfix or
update. Not a pretty picture in a large LAN whose security and
stability may rely on timely installation of these updates. This
is the simplest "exploit".
Next we extend this a bit further: the user maps a drive letter in
an interactive login, and places in it a script with the same
filename as that called by the scheduled update, and makes sure
the schedule user has permissions to this file and network
resource. All of this could be performed by a non-privileged
user. The schedule service will now execute this script in the
elevated user context, and the script could be instructed to
install a trojan, add the user to the local Admin group, or
whatever. The bottom line is that this design flaw can be easily
exploited to allow any user with interactive login rights to a
workstation to elevate himself to the rights of the schedule user,
which is often Administrator of the workstation.
This was tested on NT4 SP5 and 6a. (Note this is without IE5
installed, just the built in AT scheduler). Also this was tested
with all combinations of Local and Domain accounts for both the
scheduler and the interactive user. It was tested with and
without persistent drive mappings present for either user - in
each case, whoever gets the login first gets the drive letter.
It was failed to mention above that this with shares does not
work in this case. This effect was implied by closing statement
"whoever gets the login first gets the drive letter", but here is
how this behaviour manifests itself.
Example 1:
==========
Interactive user has drive X: and H: mapped. Here is what the
schedule user sees when attempting to view network connections:
C:\WINNT\system32>whoami
SHAWNIGAN\Virus
C:\WINNT\system32>net use
New connections will be remembered.
There are no entries in the list.
Then delete the X: drive:
C:\WINNT\system32>net use x: /d
The network connection could not be found.
More help is available by typing NET HELPMSG 2250.
Then map the X: drive:
C:\WINNT\system32>net use x: \\lonsdale\repairs$
System error 85 has occurred.
The local device name is already in use.
Then change to the X: drive which "does not exist", but for which
the schedule user has permissions:
C:\WINNT\system32>x:
X:\>dir /w
Volume in drive X is SLS
Volume Serial Number is 36AE-092C
Directory of X:\
[.] [..] [nt4] [RedHat5.2]
[95images] [Setup] [Drivers] [winfax]
[RedHat6.0] [OldLogs] NetCPS.exe [mc-4.x]
ntregmon.zip handleex.zip SP6a-128.EXE dk5srupdate_i.exe
Apps-Feb27.cl3 pcplus52.exe
46 File(s) 163,128,793 bytes
2,021,892,096 bytes free
Then change to the H: drive which "does not exist", but for which
the schedule user does NOT have permissions:
X:\>h:
H:\>dir
Access is denied.
Launching File Manager from the Schedule User context shows the
drives X: and H: as network connections, but they cannot be
deleted, as no connections exist.
Example 2:
==========
Map a drive using the schedule user command window. Immediately,
this drive appears in my explorer window, running as the
interactive user. If permissions exist for the interactive user,
you can view the drive, but it cannot be deleted, nor does it
appear in the list of connections. We could repeat the above
sequence of steps, but the results are the same: a drive mapped
in one user context will appear in another user context as a
"permanent" mapping, and may be accessible, dependent on network
permissions.
SOLUTION
Which brings us to the next question: Obviously this behaviour
does not exist in NT TSE, or it would surely wreak havoc on
things. And MS recently re-released the RDISK vulnerability
patch, originally strictly for TSE, and made it for all NT
releases, after conceding that the vulnerability could exist in
all NT versions. Is it possible that a patch originally written
for TSE could be applied to plain vanilla NT to resolve this
rather unsettling behaviour of the OS?