Major Win32 API flaw

[cwk9]

Microsoft has done it again.

ChrisPaget writes: "I've just released a paper documenting and exploiting fundamental flaws in the Win32 API. Essentially, they allow you to take control of any window on your desktop, regardless of whether that window is running as you, localsystem, or anywhere in between. The technique has been discussed before, but AFAIK this is the first working exploit. Oh, did I mention it's unfixable?" You may want to read this CNET interview with Microsoft security head Scott Charney to learn even more about "trustworthy computing."

another interesting quote

Microsoft VP Jim Allchin who stated, under oath, that there were flaws in Windows so great that they would threaten national security if the Windows source code were to be disclosed.

I'm not sure if this occured to Jim but maybe they should of started working on fixing those flaws. Leaving any flaw unfixed is just plain dumb even if it is closed source.

Read the article here
http://security.tombom.co.uk/shatter.html
what I pasted above
http://slashdot.org/articles/02/08/0....shtml?tid=172

This kind of ties in with my thread about how exploits should be relesed. http://www.antionline.com/showthread...202#post558202
Should he of relesed a working example? Normaly I would say no but M$ has known about this for a long time. They had there chance and now the rest of us have to pay for it.

[Tedob1]

its unfixable, its the concept that microsoft uses that everything is a window thats, screwed up.

its up to the software manufacturers, he says, those that want to write expensive software for a dying system.

in order to secure this its going to have to be a whole new concept in design for their os, which will probably not be compatable with any existing windows software. If they havent been working on that since the first day they first discovered how vulerable the messaging system is, their history.

bye, bye, bill!

[cwk9]

Is this one of the api’s that was recently released?

If so….
<conspiracy theory>
I bet they did this on purpose just to help them out in there anti-trust case. They released those api’s as a sign of good faith by there own free will so I don’t think M$ can play stupid on this one. Now they can say lame stuff like “If you make us release the source code you’re going to expose security holes. That would help terrorist. Do you like helping terrorist?” But it doesn’t end there M$ will also use this as an excuses to push Palladium
</conspiracy theory>

Just my $0.02

[Tedob1]

wow, i don't know why i didn't see that! I bet your right cwk9!

its so obvious, now that you said it

[droby10]

i'm going to have to go against the grain here:

windows messaging as a whole is a common misunderstanding by programmers - my initial thoughts they shouldn't be developing for windows.

this goes back to the core fundamental theory that you perform bounds and integrity checks at any point of data acceptance or transaction..what has been illustrated is no different than a text field in an html form with a maxlength set and expecting it to protect you from longer values being submitted. it's laziness on the programmer's part and to be honest has nothing to do with windows in particular - the error can be made on any windowing platform;m messaging is just the mechanism which makes it possible to take advantage of these kinds of mistakes in windows.

[ammo]

Wow, I had seen the e-mail come in from bugtrack but hadn't bother reading it until I saw this post and read the original article...

I don't know how many of you (AO readers) read the actual article, but this is scarry stuff...

Like droby said though, it does seem that the fault lies mostly with apps/services programmers...:
1- for not cheking bounds correctly outside the controls such as editboxes...
2- because having services running as higher priviledges (such as localsystem) with interactive windows does seem stupid... on that, replies on bugtrack have brought up interesting secure desing concept that are made availible by the win32 api that would foil such attacks:

one of those mails (a couple of them said pretty much the same thing, hit the bugtrack archives if you want to see em):

Chris,

I read your paper with interest. However, I must disagree
with you in some respects. The Win32 API provides a concept
called "Window Stations" which offer the fine grained access
control you're looking for. By default, interactive applications
run in the default Windows Station, "WinSta0", but you can
create separate Windows Stations with appropriate DACLs.

By default, only Administrators can enumerate non-default Windows
stations, and only Administrators and the owner of a Windows Station
can access (send messages to) the windows within the desktop of
that Windows station.

I see the exploits you posted not as a defect in the API, but rather
as lack of care by the authors of certain interactive services, which
run under different credentials in an accessible Windows Station.

Everyone knows that interactive services are deprecated. They are
security risks, for the reasons you lay out in your paper. Read
chapter 5 of "Programming Windows Security" by Keith Brown. Microsoft's
response is therefore largely correct -- just because a feature is
there doesn't mean you have to use it.

Yours,
Chad Loder

So as scarry as it originaly sounds, it would seem that all is not lost. But I guess some developpers (especially for security software like antivirus scanners like McAfee (as described in the article)... (dunno anout norton though..?) are gonna have to hit the boards to acess those design vulnerabilities (considering that AVs are probably the most common app found on corporate desktops!)...


edit: forgot to mention/ask: anybody understand if these attacks result only in stack based buffer overflows or does it depend on the victimised code?

Could a non-exec stack be implementable in windows or is stack execution required in some obscured cases?

Also, one way to make sure no one sniffs the apps you design's controls would be to code in Java with swing as it doesn't use win32 controls...

Ammo

[allenb1963]

Bill modelled Windoze after the PGA tour......lots of green but plenty of holes....

[souleman]

Ok, this is NOT a new flaw. It is something that has been around since the Win32 API (windows 98) came out. It is not totally Microsofts fault either. Most of the problem is tha programmers are to lazy. There is NO microsoft program that can be exploited using this flaw. Other companies just haven't headed the warnings about this. Yes, the warnings have been around for years. This paper is just the first time that anyone has realease an actual example.

tedob1> from my understanding, some of the API's were somehow patched using thirdparty software or something. I don't remember where I saw it, but I guess it is possible to fix the flaw, just very difficult.

ammo> This is not a stack/buffer overflow. It is an entirely different concept. I don't have time to explain it right now cause I am on my way home, but read the paper...its pretty good.

[ammo]

No, you're right souleman... was a little late when I posted and followups e-mails on bugtrack refered to buffer overflows (so I got confused somewhere!)... but thats only because of the editbox control bounds check being overritten which could allow for buffer overflows if further bounds checking isn't done in the code...

Still, when, the raw binary code inputed in the editbox, would it get on the stack or the heap?

Ammo