Windows Vista winsat.exe Integer Overflow

[Jose Carlos Norte]

There is a flaw in windows vista benchmarking tool, called winsat.exe, that runs withs administrative privileges.

The problem, is an integer overflow in -totalobj argument, example:

winsat d3d -texshader -totalobj 2147483648

this result in a overflow of the signed int that stores the totalobj argument, and turns it negative, and then, the program crashes.

I'm not sure if you can control some memory using other options in winsat.exe arguments to take advantage of this issue, and exploit it.

Even if the bug is exploitable, the User Access control present in vista, shows a message asking for privileges before execute it, the only advantage of this issue, I think that is the message asking for privileges, shows information about the process, and this is the information that the user have in mind to decide if accept or not, and if you execute a windows util, it asks for privileges, the information about WHO is asking for privileges, is a trusted windows util (winsat.exe, in system32) and then, if you can control the process, you can use this kind of bugs as way to trick the user to bypass the UAC and get admin.

[Steve Shockley]

jose@... wrote:
> if you can control the
> process, you can use this kind of bugs as way to trick the user to
> bypass the UAC and get admin.

You'd still have to convince the user to bypass UAC when he wasn't
expecting a UAC prompt, in addition to getting them to run it in the
first place.

[Valdis.Kletnieks]

On Fri, 28 Mar 2008 23:03:55 EDT, Steve Shockley said:

> You'd still have to convince the user to bypass UAC when he wasn't
> expecting a UAC prompt, in addition to getting them to run it in the
> first place.

Experience has proved that neither of these should be all that difficult
for an attacker - an incredibly large percentage of users will go ahead and
run a .exe, clicking through multiple security warnings, if it promises to
do something interesting (usually having to do with somebody famous wearing
too little clothing while misbehaving...)

[Thor (Hammer of God)]

> -----Original Message-----
> From: listbounce@...
> [mailto:listbounce@...] On Behalf Of
> Valdis.Kletnieks@...
> Sent: Sunday, March 30, 2008 8:52 PM
> To: Steve Shockley
> Cc: vuln-dev@...
> Subject: Re: Windows Vista winsat.exe Integer Overflow
>
> On Fri, 28 Mar 2008 23:03:55 EDT, Steve Shockley said:
>
> > You'd still have to convince the user to bypass UAC when he wasn't
> > expecting a UAC prompt, in addition to getting them to run it in the
> > first place.
>
> Experience has proved that neither of these should be all that
> difficult for an attacker - an incredibly large percentage of users
> will go ahead and run a .exe, clicking through multiple security
> warnings, if it promises to do something interesting (usually having

to
> do with somebody famous wearing too little clothing while
> misbehaving...)

Right - however, by default, you only get the UAC "prompt for consent"
when you are *already* running as admin.  A normal user would have to
input the administrator username and password to continue the
installation.  Of course you can require even the administrator to enter
username and password, and can even make non-administrative requests for
elevation automatically fail.

So, if you have someone who is going to run as administrator anyway,
download the untrusted .exe, execute it, and then confirm the execution
of the program without concern for what happens, we can't really fault
the OS for that at this point in the game.

t

[Valdis.Kletnieks]

On Wed, 02 Apr 2008 13:39:36 PDT, "Thor (Hammer of God)" said:

> So, if you have someone who is going to run as administrator anyway,
> download the untrusted .exe, execute it, and then confirm the execution
> of the program without concern for what happens, we can't really fault
> the OS for that at this point in the game.

I wasn't faulting the OS - I was pointing out it's still a viable attack
vector, despite the OS's best efforts to stop it.

[Valdis.Kletnieks]

On Thu, 03 Apr 2008 10:58:14 PDT, "Thor (Hammer of God)" said:

> Hey Valdis -
>
> > > So, if you have someone who is going to run as administrator anyway,
> > > download the untrusted .exe, execute it, and then confirm the
> > > execution of the program without concern for what happens, we can't
> > > really fault the OS for that at this point in the game.
> >
> > I wasn't faulting the OS - I was pointing out it's still a viable
> > attack vector, despite the OS's best efforts to stop it.
>
> I know you weren't specifically faulting the OS for this -- it's just
> that when I see posts that combine the "non-issue of the day" with a
> requirement of "this is bad because if I can get the user to run
> arbitrary code as administrator first, then I use that code to exploit
> his vulnerability" coupled with "and this is easy because it's trivial
> to get people to run malicious code and we all know they all just click
> through all warnings" that it just gets to be too much.
>
> I'm aware that you didn't say all of the above, but it's what the net
> result of the thread became.

From the *prevention* side of the fence, it's true - once you get the user
to run untrusted code as administrator, the box is pwned good and thoroughly.
And since there's a wide variety of things that can happen, "nuke it from
orbit and re-install, it's the only way to be sure" is the operative phrase.

The number of *different* things that can be done once you get an initial
foothold of executing code is more probably interesting to those of us who
do computer forensics, where the exact mechanism *is* relevant to figuring
out what happened, and (possibly) how to prevent it from happening again.