Major Win32 API flaw
Results 1 to 9 of 9

Thread: Major Win32 API flaw

  1. #1
    Senior Member cwk9's Avatar
    Join Date
    Feb 2002
    Posts
    1,211

    Exclamation Major Win32 API flaw

    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.

  2. #2
    Senior Member
    Join Date
    Nov 2001
    Posts
    4,786
    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!
    Bukhari:V3B48N826 “The Prophet said, ‘Isn’t the witness of a woman equal to half of that of a man?’ The women said, ‘Yes.’ He said, ‘This is because of the deficiency of a woman’s mind.’”

  3. #3
    Senior Member cwk9's Avatar
    Join Date
    Feb 2002
    Posts
    1,211
    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
    Its not software piracy. I’m just making multiple off site backups.

  4. #4
    Senior Member
    Join Date
    Nov 2001
    Posts
    4,786
    wow, i don't know why i didn't see that! I bet your right cwk9!

    its so obvious, now that you said it
    Bukhari:V3B48N826 “The Prophet said, ‘Isn’t the witness of a woman equal to half of that of a man?’ The women said, ‘Yes.’ He said, ‘This is because of the deficiency of a woman’s mind.’”

  5. #5
    Senior Member
    Join Date
    Jun 2002
    Posts
    165
    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.
    -droby10

  6. #6
    Senior Member
    Join Date
    Sep 2001
    Posts
    1,027
    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
    Credit travels up, blame travels down -- The Boss

  7. #7
    Old Fart
    Join Date
    Jun 2002
    Posts
    1,658
    Bill modelled Windoze after the PGA tour......lots of green but plenty of holes....
    Al
    It isn't paranoia when you KNOW they're out to get you...

  8. #8
    AntiOnline Senior Member souleman's Avatar
    Join Date
    Oct 2001
    Location
    Flint, MI
    Posts
    2,884
    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.
    \"Ignorance is bliss....
    but only for your enemy\"
    -- souleman

  9. #9
    Senior Member
    Join Date
    Sep 2001
    Posts
    1,027
    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
    Credit travels up, blame travels down -- The Boss

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •