XP local privilege escalation demonstrated
An excellent Flash animation showing the latest XP local privilege escalation has been published and it clearly demonstrates how trivial it is to "upgrade" from a user with administrative privileges to SYSTEM (the same but for unprivileged users is currently disputed, more at the CVE entry covering the issue and on the Bugtraq archives).
How does it work?
It is actually quite simple: normally a scheduler is used for running non-interactive programs unattended, for example anti-virus updates (in the "baddies" world it is used for scheduling netcat backdoors but this is hardly "normal usage").
In this example the user decides to schedule running "cmd.exe" (the Windows command line prompt) rather than a non-interactive program. When the scheduler triggers it starts cmd.exe which opens a new command-line window.
The problem is that the scheduler runs as the "SYSTEM" user which under Windows is an all-powerful user used for system tasks (the Windows equivalent of "root" under Unix) and, as this video demonstrate, it does not "drop privileges" (that is to say: "take on the privileges of the user requesting the scheduled job") before running the command.
When the command is finally run at the specified time it therefore hands you a command line prompt with SYSTEM privileges.
Is there a fix? Or indeed, why is this a problem? Well, the fix would be to stop the scheduler which breaks lots of other things (e.g. anti-virus updates) but which an adminstrator can easily restart... Now, is it really a problem since an administrator doesn't gain much? Well, it should not be the case that running a scheduled job lands you different privileges by default and, of course, should it turn out that administrative privileges are not needed then it becomes a far bigger issue as any user could gain SYSTEM privileges.
Important note: do not watch this at work with your loudspeakers turned on (bad language disclaimer...). Headphones strongly recommended.
Thanks to fellow-handler Swa for precious extra information.
How does it work?
It is actually quite simple: normally a scheduler is used for running non-interactive programs unattended, for example anti-virus updates (in the "baddies" world it is used for scheduling netcat backdoors but this is hardly "normal usage").
In this example the user decides to schedule running "cmd.exe" (the Windows command line prompt) rather than a non-interactive program. When the scheduler triggers it starts cmd.exe which opens a new command-line window.
The problem is that the scheduler runs as the "SYSTEM" user which under Windows is an all-powerful user used for system tasks (the Windows equivalent of "root" under Unix) and, as this video demonstrate, it does not "drop privileges" (that is to say: "take on the privileges of the user requesting the scheduled job") before running the command.
When the command is finally run at the specified time it therefore hands you a command line prompt with SYSTEM privileges.
Is there a fix? Or indeed, why is this a problem? Well, the fix would be to stop the scheduler which breaks lots of other things (e.g. anti-virus updates) but which an adminstrator can easily restart... Now, is it really a problem since an administrator doesn't gain much? Well, it should not be the case that running a scheduled job lands you different privileges by default and, of course, should it turn out that administrative privileges are not needed then it becomes a far bigger issue as any user could gain SYSTEM privileges.
Important note: do not watch this at work with your loudspeakers turned on (bad language disclaimer...). Headphones strongly recommended.
Thanks to fellow-handler Swa for precious extra information.
Keywords:
0 comment(s)
×
Diary Archives
Comments