Skip to comments.
Exploiting design flaws in the Win32 API for privilege escalation.
Chris Paget ^
| 03/06/2002
| Chris Paget
Posted on 08/06/2002 2:31:20 PM PDT by sourcery
click here to read article
Navigation: use the links below to view more comments.
first 1-20, 21-40, 41-45 next last
1
posted on
08/06/2002 2:31:20 PM PDT
by
sourcery
To: sourcery
If Microsoft had its way, you could be prosecuted for disseminating this.
To: *Microsoft; *tech_index
To: sourcery
circumcised BTTT
To: E. Pluribus Unum
If Microsoft had its way, you could be prosecuted for disseminating this. Yeah. I work there myself and I can attest to how everyday we rape young women, ravage wives, and assassinate revered clergymen all in our powermad lust to despoil the entire world! I have been thoroughly assimilated into the capitalist-frenzied organism, MSFT.
We can't help ourselves; we just want to rape, pillage and burn constantly. Prosecute him? Heck, that's the LEAST of what we plan on doing to him.
5
posted on
08/06/2002 2:50:44 PM PDT
by
CaptBlack
To: SlickWillard
circumcised BTTTWhoops, wrong recipient...
To: E. Pluribus Unum
If Microsoft had its way, you could be prosecuted for disseminating this.
No, they would outlaw stupidity. Boy, are you screwed...
7
posted on
08/06/2002 2:51:38 PM PDT
by
Bush2000
To: Bush2000
they would outlaw stupidity. Carefull what you wish for...MS has done some awfull stupid things.
They should replace the default paste message handlers for any controls that are part of an app that will be running as admin (frequently SQL server for example). Short of that they need to build a mechanism for checking callback addresses (no callbacks across application boundries, which should be verboten to begin with).
8
posted on
08/06/2002 3:00:39 PM PDT
by
Dinsdale
To: Dinsdale
Execution of an "external" callback (one that is permitted to cross an application boundary) should occur using the privileges of the application that specified/provided the callback address, instead of using the privileges of the caller. Disallowing all callbacks that cross application boundaries would be too restrictive.
9
posted on
08/06/2002 3:26:06 PM PDT
by
sourcery
To: Dinsdale
Correct. You have the legacy of the weak-protection Win95 model infecting the NT code base here. No reason why it should be so fully backward compatible, and MS has made bigger changes before. Anyone coding using modern class libraries wouldn't do this kind of thing. So yes it would be painful to fix, but not impossible.
Also, if I were running IT for a foreign government, I would ban Windows because I could count on MS sharing this info with U.S. netional security. It's just too tempting for the NSA not to be beavering away at sploits that take advanatge of secret holes.
10
posted on
08/06/2002 3:26:42 PM PDT
by
eno_
To: Bush2000
Why don't you just admit that the Win32 API was never designed for a multi-user environment and no one should be using it as such?
11
posted on
08/06/2002 3:42:33 PM PDT
by
sigSEGV
To: sourcery
Disallowing all callbacks that cross application boundaries would be too restrictive. Why? You can always send a message back to tell the callback requestor something has occured/completed. You can still do callbacks between processes in an application. Granted it will break some apps, and require extra code in COM+ (create local proxys ahla network OLE, er ActiveX, er COM, er Windows RNA (renamed network architecture)).
In this case it seems the problem is being able to put arbitrary data into another application's memory then being able to jump to an arbitrary place in that code. Perhaps 'mangling' pointers that should be GPF bait to begin with is a solution (of course you would have to consistantly unmangle them where appropriate). That's such an ugly solution MS might like it.
12
posted on
08/06/2002 3:57:14 PM PDT
by
Dinsdale
To: sourcery
Even worse is the case of Terminal Services (or Citrix). Imagine a company providing terminal service functionality to their clients, for whatever purpose. That company is NOT going to give their users any real privileges Which is why any decent Citrix administrator (like myself) will use policies to TOTALLY lock down the system and use mandatory profiles to ensure that NO ONE gets access to the box without his say so.
When 20 other sysadmins and the security guy can't break out to a command prompt or anything like task manager and you have no FILE access on every single window you open; you're NOT going to gain access.
To: Dinsdale
Why?Lambda Calculus. Services. Components. Polymorphism. The denotational semantics of a class library should not depend on whether or not it will be used intra-process or inter-process. Security can be provided without converting inter-process function invocations into second-class citizens.
14
posted on
08/06/2002 4:19:10 PM PDT
by
sourcery
To: Dinsdale; sourcery
I am totally ignorant of windows programming, but what exactly do you guys mean when you talk about "doing callbacks between processes." In an environment like VxWorks, all processes share the same memory space and it is no sweat invoking any function from any library from anywhere. On the other hand, I wouldn't have the fainest idea how to do this in a standard Linux/Unix environment, without doing something really complicated using shared memory. I assume that this is not just a euphemism for some kind of high level communication mechanism built around socket/pipe/etc connections.
To: sourcery
This research was sparked by comments made by 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. He mentioned Message Queueing, and immediately regretted it.Little wonder MS is so anti-Open Source, if this kind of analysis (and an exploit) can be put together without a single byte of source, based on a hint from a senior VP.
Repeat after me: Closed Source is no less secure than Open Source. Right. < /snort >
To: Bush2000
If Microsoft had its way, you could be prosecuted for disseminating this. No, they would outlaw stupidity. Boy, are you screwed...
As a matter of fact, Dude, Microsoft believes that bugs should not be publicized.
If ignorance is bliss, you must be in heaven.
To: CaptBlack
If Microsoft had its way, you could be prosecuted for disseminating this. Yeah. I work there myself and I can attest to how everyday we rape young women, ravage wives, and assassinate revered clergymen all in our powermad lust to despoil the entire world! I have been thoroughly assimilated into the capitalist-frenzied organism, MSFT.
We can't help ourselves; we just want to rape, pillage and burn constantly. Prosecute him? Heck, that's the LEAST of what we plan on doing to him.
So Richard L. Smith was misquoted in this article?
To: Dinsdale; sourcery
I am totally ignorant of windows programming, but what exactly do you guys mean when you talk about "doing callbacks between processes." In an environment like VxWorks, all processes share the same memory space and it is no sweat invoking any function from any library from anywhere. On the other hand, I wouldn't have the fainest idea how to do this in a standard Linux/Unix environment, without doing something really complicated using shared memory. I assume that this is not just a euphemism for some kind of high level communication mechanism built around socket/pipe/etc connections. Pinging you guys one more time...
To: KayEyeDoubleDee
That's why VxWorks is an embedded systems OS. If you don't have general-purpose interfaces like browsers or RPC or exec servers running, you don't need a secure OS, and security adds overhead. Often, a system running VxWorks boots from flash and no code or even a general-purpose script is ever run on such a system that wasn't shipped with that system.
If you have Win2k or XP desktop, however, you are running all kinds of code that didn't originate on your system and that you didn't install. Because the UI is architected the way it is, it is fairly easy for this code to reach out and touch other apps running on your system, and, in this case, to reach inside your system in ways you thought your system would be protected against.
This kind of explains Microsoft's otherwise suicidal embrace of "trusted computing" (Palladium). Maybe they see Palladium as a magic bullet for all their vulns.
20
posted on
08/07/2002 8:03:56 AM PDT
by
eno_
Navigation: use the links below to view more comments.
first 1-20, 21-40, 41-45 next last
Disclaimer:
Opinions posted on Free Republic are those of the individual
posters and do not necessarily represent the opinion of Free Republic or its
management. All materials posted herein are protected by copyright law and the
exemption for fair use of copyrighted works.
FreeRepublic.com is powered by software copyright 2000-2008 John Robinson