COMMAND
Internet Explorer
SYSTEMS AFFECTED
IE5 when run on a Windows NT 4.0 system
PROBLEM
IE 5 includes an Offline Browsing Pack that is not installed by
default. The Offline Browsing Pack provides a Task Scheduler
that replaces the native Windows NT Schedule Service (the
schedule service is also known as the "AT Service"). A
vulnerability in the Task Scheduler poses a privilege elevation
risk and could allow normal users to execute code on the local
machine in System context. (The Windows NT Schedule Service does
not have this vulnerability).
The IE 5 Task Scheduler controls who can create and submit "AT
jobs." The utility that is used to create AT jobs can only be run
by an administrator, and the Task Scheduler will only execute AT
jobs that are owned by administrators. However, if a malicious
user had change access to an existing file owned by an
administrator (it would not need to be an AT job), he or she could
modify it to be a valid AT job and place in the appropriate folder
for execution. This would bypass the control mechanism and allow
the job to be executed. The affected components are part of the
IE 5 Offline Browsing Pack, which is not installed by default.
Windows NT 4.0 includes a native scheduling service, but it does
not have this vulnerability.
Arne Vidstrom and Svante Sennmark found this issue originally.
Their test setup was the following:
TARGET:
* Windows NT 4.0 Server
* SP 5
* IE 5.00.2014.0216
* Task Scheduler running
* Default permissions on the disks and in the registry
* The account "test" is a User and the attacker knows the
password for this account
* There exists a file "file.txt", owned by Administrators and
with Change permissions for "test"
* Hex Workshop or similar is installed (can be installed by
the attacker)
ATTACKER:
* Windows NT 4.0 Server
* SP 5
* IE 5.00.2014.0216
* Task Scheduler running
* The attacker knows the password for an administrator account
on ATTACKER
* The clock has been set fairly close to the clock in TARGET
The interactive attack scenario we used was the following:
1) The attacker creates a job at ATTACKER to be run at hh:mm, with
the command:
at hh:mm net localgroup administrators test /add
This results in a job file c:\winnt\tasks\At1.job being created
2) The attacker copies the At1.job file to TARGET and opens it in
Hex Workshop.
3) The attacker opens file.txt in Hex Workshop, and deletes the
contents of the file.
4) The attacker copies the contents of At1.job to file.txt in Hex
Workshop, deletes At1.job and saves file.txt. He/she then
closes Hex Workshop.
5) The attacker renames file.txt to At1.job.
6) The attacker *moves* At1.job into the c:\winnt\tasks directory.
7) At hh:mm, the Task Scheduler runs the job, which adds "test" to
the Administrators group.
8) The attacker logs out and logs back in again, now being an
administrator.
Note: If the job file isn't owned by Administrators but by "test",
the attack will fail, thus the need for file.txt. The attacker
must *move* the file at step 6 instead of copying it, in order to
maintain the Administrators ownership of the file.
If you create a job file with the GUI interface on ATTACKER, you
have to specify under which account the job is supposed to run.
Even if you construct a valid job file like this and get it into
TARGET like we describe above, the job will not run. This is
because the access credentials are not copied with the job file.
However, if you use the "at" command, the Task Scheduler will be
backwards compatible with the Schedule service and run the job
under a preselected account, the so-called "AT Service Account".
This account can be changed to any account (but only by an
administrator), but as default it is SYSTEM (the same account as
the Schedule service uses). This special case job file doesn't
have any real access credentials tied to it, the only check that
the Task Scheduler does for its validity is that of file
ownership. You have to be an administrator to use the "at"
command, so the check is if the file is owned by Administrators
or not. The designers probably relied on the fact that in Windows
NT, there is no way to give away ownership to another user.
However, by changing the contents of a file that is already owned
by an administrator, and to which you have Change permissions,
you can circumvent that. This is why/how this attack works.
*Network attack is not possible on a default installed machine.*
However, it could be performed with slight modifications if the
configuration is changed from the default.
Except a default installation of Windows NT and Internet Explorer
5, there must at least exist a shared directory on TARGET where
"test" have Change permissions, and a file there that is owned by
Administrators and to which "test" have Change permissions. Even
if the attacker doesn't have access to c:\winnt\tasks, he/she can
change the tasks directory to the shared directory by changing:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SchedulingAgent\TasksFolder
remotely and waiting for somebody to reboot TARGET for the change
to take effect. *But this can only be performed if the default
permissions on the winreg key have been changed so "test" has
network access to the registry.* Also note that there is no need
for anybody to be logged in for the job to run.
SOLUTION
The vulnerability is eliminated by IE 5.01, which is available at:
http://www.microsoft.com/msdownload/iebuild/ie501_win32/en/ie501_win32.htm