Slashdot Mirror
Shattering Windows
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."
Film at 11
Je t'aime Stéphanie
That's really OLD. Like >15 years or so. It's not comparable at all to X-Windows where the clients run on a multi-user system.
another flawed API that is not fixable..
"Essentially, they allow you to take control of any window on your desktop".. sounds like it's straight out of Microsoft's new EULAs.
Never email donotemail@WeAreSpammers.com
Does that mean that you could make them all stop crashing? Please?
/run/. I have no illusions about it being secure.
I'm on reboot #26 today. And this with the supposedly stable Windows XP. Trustworthy computing--I can't even trust it to
So basically you're saying that if you can get a user to run arbitrary code and that user has access to applications with higher access rights, you can get those access rights.
If you can get the user to run arbitrary code, they're already dead.
Not to say that windows is secure, but this seems to be picking nits to me.
-- IANAEG - I am not an elder god.
http://saintaardvarkthecarpeted.com/mirror/shatter .html
Carousel is a lie!
I went to University of Michigan with Scott Charney and he's a really cool guy. A little background info is in order here. I really hope that he improves the Microsoft security record, and I really think he's enough of a go-getter to do just that.
I got a 1600 on the SATs.
This class of attack is not new, it has been discussed before. While you can assert that the blame lies with Microsoft (and I'll admit they do
have some responsibility to address the problem you describe) the chief blame lies with the vendor of the software whose bad programming you are exploiting. There is no excuse to put a window for a process with the LocalSystem security context on a user's desktop. I am not aware of any Microsoft application that makes such a mistake.
How is it unfixable? Is it unfixable in the way that many current applications rely on this feature?
Microsoft was told about this flaw when it was first discovered 7 years ago. They still haven't fixed it.
In other news, microsoft is sueing the cnet for making a flaw public news. They claim they needed more time to fix it, 7 years just isn't enough time to fix the bug and test the patch...
---
Programming is like sex... Make one mistake and support it the rest of your life.
This whole exploit seems flawed in its assumptions...I mean, how can it be classified as a security risk of ANY sort if it requires that someone is sitting in front of the computer? It seems like this is something that could easily (EASILY) be avoided by - wait for it - preventing unauthorized access! Something that Windows has been doing pretty well since Windows 2000 (flame on, zealots, but it's true).
Sounds like this guy is just trying to gain cool-guy points with the slashbot crowd by showing off his 1337 windoze hacking skillz. Pass.
That means I essentially could write a version of paint that when you open it closes all other windows you have open on your system and flashes up a window that says "PAY YOUR ALLEGANCE TO PAINT ALONE!"
What's to prevent an administrator from installing a Message Hook that eats all EN_* or WM_TIMER messages sent between processes? Since your DLL would be living in each process space, you could detect inter-process message sending and block the attack from ever leaving the Shatter process. I don't see any reason why this shouldn't work
Or if the process belongs to me.
kill processname
[Scott Charney, Microsoft]
We're doing this thing called "Trustworthy Computing." It's an evolving concept. We've come up with our new paradigm, SD3[...]
A-ha! It's just a small leap to go from SD-3 to SD-6. Insert joke about covert evil organizations here.
Yes, it's funny. Laugh.
"Sometimes a woman is a kind of religion, she can save your soul & set you free from all your sins" - Bad Examples
Before jumping to conclusions, read the reply to the "vulnerabilities" on the BugTraq mailing list here. Doesn't look like its something unknown to the public and its really more of a vendor problem, not MS one.
Simple fix: require each user to wear a straightjacket with their legs and arms bound to the chair; have them type via the mouth-to-pencil-to-keyboard method.
SELECT * FROM USERS WHERE A_WINNER = "YUO";
This "vulnerability" only effects poorly-written applications, running with system priviledges, which create windows in user-space.
You're not supposed to do that.
If you want to have a service which is user-configurable, create two separate programs (one service & one gui) and communicate via a named pipe.
This isn't a flaw in the win32 API. This is a flaw in some applications which run under windows.
Tarsnap: Online backups for the truly paranoid
GUI Windows are only part of the problem. Ideally, one should be able to limit the sections of disk and RAM that are used, and also how much disk and RAM are used.
Why fuss about just the GUI? There is more to applications and security than GUI's.
(It would be easier to clean off old apps if we could limit their installation range.)
Table-ized A.I.
With the gettext, sendmessage, memory and various other api calls you can do just about anything to other programs.
Then if you care to fire up your favorite hex editor...
i looked at the paper and i couldn't figure out what the opportunity for remote exploit is... can it be done from java? .NET? jscript? other network software?
Seems like it could be useful for the autobot gaming crowd... EverQuest is certainly simple enough to automate...
Does this effect Citrix? ...
Morphing Software
The END of WINDOWS? Christ, could you pack just a little more apocalyptic FUD into that statement?
This "exploit" is hardly even an exploit - it requires the ability to run arbitrary code. And if just anybody can acquire the ability to run arbitrary code, then i would say the problem runs a bit deeper than msgsvr32.dll.
Here's something to chew on, zealot: use this exploit on my win2k server. I dare you. What? You can't get in? Oh, you mean the BASIC SECURITY FEATURES BUILT INTO THE OPERATING SYSTEM HAVE THWARTED THIS EXPLOIT BEFORE IT COULD EVEN GET OFF THE GROUND? That's what I thought.
Christ, your drivel is actually making me sick. Do you actually believe what you just wrote?
Then it evolves to mean "You trust us."
Then it evolves to mean "You trust only us."
Then it evolves to mean "All your base are belong to us."
I'll bet you $100 that this is not the "end of Windows". Seriously.
I'd be happy to lose this bet... But I doubt I will.
Does your mouth hurt? You just got trolled.
Moon Macrosystems. Sun's biggest competitor.
I'm sorry, nothing personal here. But 26 reboots? I know serious Linux users here can't take you too seriously but I also know there are some young impressionable minds here.
Here is some advice kids: When you come across any computer "expert" who has a computer they have to reboot 26 times in a day. Run!!!
And here is a real-life experience from someone (me) who makes his living developing on Windows:
I've used Win2k Pro since the day I bought it over 2 years ago. I've rebooted because of a crash or a freeze maybe 10 or 12 times in that time frame. I've had to reinstall the system once. I can say with some confidence that 99% of my reboots are caused by badly designed third party drivers.
hmm. where? i don't see it.
Windows 98 allowed any user with console access to operate as root for years... Now you think an obscure exploit that has been around for over 10 years is going to cause the downfall of windows?
Excuse my extreme skepticism.
If all this should have a reason, we would be the last to know.
If you have physical access to the box, there are n ways to get your code executed in a Windows app. WM_TIMER (the callback version) is one, as are window hooking, CBT hooks (computer-based-training, although I've never seen it used for this purpose) forcible DLL loading (if you have access to the Registry), debug process attachment, CreateRemoteThread, thunking well-known DLLs (which is why Red Alert 1 won't play on Win2K without a patch--they can't thunk kernel32), etc., etc., etc.
Windows programmers have been using these methods for non-evil reasons for many years--the "3D look" of MS Office apps before Windows 95 was done this way.
The insecurity of the desktop model for Windows shouldn't surprise anyone. It wasn't designed to be secure OR multi-user, and patching after the fact doesn't make it so. It's comparable to complaining that telnet and ftp send passwords in clear text. Well, no kidding, they weren't designed to be secure, so they're not.
And like the case of telnet, making a secure but still 100% backwards compatible solution is pretty much impossible, as the article states.
How many normal families have secretive and technically savey hacker hanging around their homes, waiting for the opportunity to take over their home XP system. Give me a break.
You know who this effects? Practically no one, or maybe the stupid. Worst case scenario is that government computers are at risk, but only if the hacker is physically present to take over.
"Most of the Windows base will have been compromised"? By who? Someone breaking into people's homes, door to door, to gain root access to their home computers! Oh no, the humanity!
And finally "Welcome to the world without Windows" has to be the most karma-whoring, better-than-thou comment I have ever read.
Awesome exploit, props to Foon.
I think that the larger picture here is simply that Windows (even NT derivitaves) isn't really a multiuser OS. The kernel is technically multiuser-capable, but just about every other part of the OS has been designed by lazy programmers with the assumption that there is only one user on the system, and Microsoft isn't interested/able to go through the effort to remove that assumption.
The lack of ubiquitous remote shell / remote gui on Win32 is the main reason that this assumption has gone unchallenged for so long. Unix ships with the ability to have multiple users simultaneously logged in remotely by default, which is why it's been so well tested for stuff like this.
I can see the idiot lobby is well funded.
When I put a service on Win2k, running under 'System' and that service listens to a port and executes all the crap that is posted to that port, is it MS' fault? No. It's the fault of the developer of the service.
Now, under win32, the application you start, runs under the user you log in with. The virusscanner window in the example, SHOULD run under the user that is logged in, but instead, it's a GUI created from the service, running under 'System'.
Bad programming. Not from Microsoft, but from the Virusscanner developer. They should have created, AS stated by MS, a GUI less service (the virusscanner engine) and a GUI application which talks to that service via a named pipe or any other process communication mechanism. That GUI should then be started by the logged in user (since that user sees the gui and works with it), so there wouldn't have been ANY flaw like this, since the GUI isn't ran under 'System', but under the user who's logged in, in the example the 'guest' account.
It sounds serious, it's absolutely nothing.
Oh, and it takes a local user to exploit it. Get a huge hammer and give it to the local user. Ask that user to smash the computer. There ya go, a DoD attack which isn't fixable, you can get that attack-script at any hardwarestore.
Never underestimate the relief of true separation of Religion and State.
FWIW, mirror at http://paginar.net/matias/shatter.html.
Their EULA reads "Essentially, you will allow us to take control of any window on your desktop." Glad I could clear that up.
"The best argument against democracy is a five minute chat with the average voter."
--Winston Churchill
It's true that once you're logged into a desktop, all apps that respond to Windows messages within that desktop are vulnerable, there are ways to secure your app from that.
Beginning with Windows 2000 (and possibly later editions of NT4), THE desktop became "Desktops" and they all run in their own space with their own Windows messaging stacks. "Desktops" cannot request window handles from other "Desktops" so this exploit is stopped. All Screensavers will be spawned into their own desktop, so that they can't affect running apps.
All apps can be set to run in their own "Desktop" as well. But it has to be proactively designed that way IN THE PROGRAM. The operation is not by default, and users cannot specify that apps run in their own space. (AFAIK)
Secondly, the documentation for making use of this feature doing so is (as usual) very fuzzy and poorly written.
It is also still possible to develop a ring 0 DLL which can query the existing desktops, get the desktop handles, and then query windows from within them.
Hmmm, another post about how Windows is lacking this and lacking that, and how it has this and has that.
Yet there's alot more that can be done for GNU/Linux itself which it doesn't have...
article was a waste of my time.
[ducks]
it is about time the white hat community saw what is actually possible.
I think the white hats have always known Windows is insecure. Maybe they all work for Microsoft :-)
These API exploits only work on pre-2000 versions. Try again Slashdot.
Unpacked the zip and my Norton Antivirus prog just yelled
Object name: sploit.bin
Virus Name: W32.Beavuh
Is it infected or is the antivirusprog fucked up?
What does this mean for ASP providers?
I can't share my work because of bandwidth problems, but it was indeed groundbreaking. Through raw HWND handles or Microsoft's (or my own version) of the WinFinder control found in Spy++, one is able to select any existing window in the system. Arbitrary messages can be sent or posted. One can draw pixels over windows, enable disabled controls (as often found in shareware), send text to edit controls (I developed a simple scripting language to automate this process), right/left/middle/double click at any position (useful in closing annoying dialogs, like the dialup reconnection message for those on 56k), and even move or kill any window one choses.
As for the vulnerability itself...its well worth the read. Basically, shellcode is injected into an edit box by removing the CEdit's length restrictions. This is a valuable lesson to all Windows programmers out there -- do not rely on a control's restrictions to validate data! Its as dangerous as using JavaScript to validate web forms. Always in all cases check for buffer limits in the application code.
Of course, not all flaws can be blamed on the application developer:
I've only skimmed the article, but this is the first documented exploit I've heard of in my half a decade of Windows programming. But its worth mentioning that these fundamental flaws have existed since Windows 95, and Foon is correct in that there's absolutely nothing Microsoft can do about it, except ditch the current Win32 API and start anew. Guess we'll have to wait until Longhorn. -sr
Shattered Windows? Nick Lowe's "I Love the Sound of Breaking Glass" comes to mind -- perhaps it could be RedHat's first theme if/when it finally creates TV ads:
I love the sound of breaking glass
Especially when I'm lonely
I need the noises of destruction
When there's nothing new
Oh nothing new, sound of breaking glass
I love the sound of breaking glass
Deep into the night
I love the sound of its condition
Flying all around
Oh all around, sound of breaking glass
Before the lawyers get wind of it that is.
What kind of sick asshole are you? I am assuming there isn't even an Easter Egg, as Orbitz would be making a RIDICULOUS mistake to do such a thing. You just think it would be funny for a few hundred people to look up flights for that date this year. Pathetic
Someone high up at Microsoft is mapping a drive across the net on their XP powered laptop.
A theif grabs the laptop and takes it home, logs in as guest, gives himself administrator access, dials into the private microsoft dialup account using the saved dialup networking profile and then has access to the mapped drive and what else? VisualSourceSafe? Microsoft Passport backend?
I feel safe...
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
[quote] The second thing is the Palladium model, which is a couple years off, will require hardware with a different chipset. You know, a security chip. While it works side by side with Windows, it won't replace Windows. It will enable all sorts of things for both consumers and businesses. For example, you will have "trusted agents"--pieces of code that are signed by people you trust. This is a good thing because it can eliminate a lot of viruses. So if you get code and it's not from anyone you trust, you can choose to not run it.[/quote]
Call me paranoid, but is he (Scott Charney) actually saying Microsoft dellibritely created a environment in which virii thrive so they could justify the Palladium platform? I mean, he is implying that you can not choose to NOT run virri on current systems. (Well ofcourse there are the alternative office and email programs, but still ...)
You know it makes sense, a little reminder from jointm1k.
To use VBA and send information between applications is the main reason it is setup this way. Want to write a program that populates a database with data generated by say Autocad.. Anyone who knows anything about programming windows already know this.
...which is one reason why secured platforms like Java and Dotnet are so important to the future of IT.
(The other is the availability of cross [hardware] platform applications - and no, compiling code yourself is not a substitute).
Linux has about another two years to continue poking fun at Windows security defects, then Dotnet will be in place and the party will be well and truly over.
If it were funny, you wouldn't have to tell us.
I knew it was bad, but holy schnidt.... good thing I'm running Linux and OS/2. =^_^=
This sig no verb.
Click to randomly close a window on another user's desktop somewhere in the world.
Sweet!
correct me if i'm wrong, but couldn't this guy be thrown in jail for documenting and sharing all this stuff?
I've been using this "exploit" to develop add-ons for automation software. In order to take control of another software package, windows messaging is by far the most efficient system for getting a non-automated package to do something unattended. For every minus, there are pluses too...
An oldy but a goody. This one's even better
Declare Function mciSendString Lib "winmm.dll" Alias _
"mciSendStringA" (ByVal lpstrCommand As String, ByVal _
lpstrReturnString As String, ByVal uReturnLength As Long, _
ByVal hwndCallback As Long) As LongProcedure
'Open the CD
retvalue = mcisendstring("set CDAudio door open", _
returnstring, 127, 0)
'Ask
msgbox "Scratch my Tongue Please, it Itches!!"
'Close the CD
retvalue = mcisendstring("set CDAudio door closed", _
returnstring, 127, 0)
Well, not sure, is this "new" exploit technique worth our attention, if in those operating systems the system directory is writeable by anyone by default?
How do you think PCAnywhere works?? Citrix?? Terminal Server (well... ok TS is Citrix).
/.'ers would react if Microsoft came out with a "fix" and then suddenly Citrix and PCAnywhere didn't work?? On Slashdot I suppose it would be "That's just like The Borg ^h^h^h^h^hMicrosoft... they couldn't compete with Symantec so they made a change to put them out of business".
It's been there since day one, and there is software to "exploit it". All you have to do isinstall PCAnywhere... or write an agent that is just like PCAnywhere, and then when a "highly priveledged user" gets on the machine, you just watch what they do. Anyone I know that's been doing Windows driver or kernel work has known about this all along... it's nothing new to anyone. Anyone want an "exploit" that traps the calls to the Windows API and records the programs being run??? You don't even have to watch the message queue go by to decipher the screen contents.
I have to wonder how
If I understand this right, this escalates priviledges to those of the window being attacked. Does this mean on a box running terminal services, I could get domain admin priviledges if that user is also logged on?
So, let's say that I'm Joe User. I turn on XP Remote Connection because I'm going out of town. I also click the "Enable Guest Login" box.
So Leet HaXoR notices my Remote Connection port is open, runs Microsoft's helpful Remote Connection Agent, logs in as Guest, and then inside of 30 seconds is Administrator?
Wow. Welcome to the age of cracking systems without using a keyboard. Or time to spare.
As Far As I Know
For example, the virus scan writer probably tests, develops and uses windows while logged into the "administrator" account interactively, as do most users. In Win98, it's not even a question -- you're always the "root" of the box. I'd wager that "What access could a non-administrator user obtain through our GUI/message interface?" hardly occurred to the GUI programmers for this particular virus scan software, even though their interface ran at LocalSystem (geeez).
As mentioned elsewhere, there are ways to avoid these problems: If you really need to use gui elements as administrator, run them under a separate desktop or windowstation where the interactive user can't touch it. Run the GUI interface impersonated down to a lower level, such as that of the interactive user. If you have to be administrator or local system, treat all input as untrusted, including (especially) window messages! Don't use edit box constraints as buffer limits. Don't use the default window procedure. etc etc etc.
It's true, however, that the default behavior for WM_TIMER is a pretty big security flaw (IMHO). But contrary to what this writer inaccurately claimed, you can still intercept the WM_TIMER message and handle it yourself, and any security-conscious program should never pass unexamined WM_TIMER functions to the default window procedure. This makes me start to wonder about other flaws in the default window procedures... as Microsoft wants you to think that the defaults it gives you are safe and secure. hmmmm...
The following sentence is true. The preceding sentence was false.
If MS can implement a way to forcefully remove instances of windows associated with programs running as localsystem, the problem maybe solved.
I don't think a guest user is intended to modify a localsystem process anyways, then why give the guest user a GUI to do so?
... but it will also be illegal! So you don't have anything to worry about.
Unless you're one of those crooks who would publish the vulnerabilities to anyone but the company itself or the government, of course....
Libertarianism is rich wolves and poor sheep playing gambler's ruin for dinner.
...or did you realize that? Sorry if I missed some irony in there.
In the shatter exploit he's linking on his website, there is a virus in the sploit.bin file. It's a W32.Beavuh, and Norton Corporate flagged it immediately. So, surfer beware! It's hard to take security fame-seekers seriously when their code is trojaned.
One of the arguments for open source is that the hivemind's access and ongoing audit of the source code leads to more secure applications, as well as benefiting from a community that is proactive and agile in addressing new security issues.
But Windows, historically one of the most closed-source and yet widely used pieces of software on the planet, seems to get the benefit of security audits from the hivemind all the time.
I'd love to write more code on Linux. But I can't, I have to make a buck and my clients use Windows, and that's that. Also, none of my clients read Slashdot. They read EOnline. They use Windows because it's easy and familiar for them. So I get frustrated sometimes, but there's not a lot I can do to proselytize Unix or Linux to these people. They read EOnline.
So maybe we could highlight less front page articles on the latest security flaw in an OS that is widely known as security flawed, and we could do more work to put up stories about ease-of-use work on Linux. Otherwise it seems like we've got a sharp sword to use against a dragon that doesn't seem to be wounded by swords.
Bam! Root access.
This works on the systems of the DMV, FBI, DOD, Equifax, Telephone and Utillity companies.
I couldn't believe it myself! I said, "This is so easy, even Sandra Bullock could hack this!"
The method in the article seems like a lot of trouble.
This software provides you a new administrator password: Locksmith.
Essentially, they allow you to take control of any window on your desktop
Isn't that what your mouse and keyboard are for?
"Karma can only be portioned out by the cosmos." -Homer Simpson
It's "addendum", NOT "addemdum". Sheesh.
Windows Is a VIRUS!!!! ;)
Under Windows (at least Win2K), look at your Services control and find out how many of them are set to run as LocalSystem. Most to all of them? Ah, yes. Now look at how many of those are built-in Microsoft Windows components. Most to all of them? Ah, yes.
I suppose, by this token, that it's not the fault of the Win32 API, but instead each and every Windows service that Microsoft shipped and each and every third-party service delivered post-install.
Bad programming, indeed.
--
Please do not feed or tease the trolls.
Since we just learned that the desktop is moving to tactile, physical interfaces,, does that mean the Win64 version of this exploit will involve hijacking, say, breasts instead of windows? "Just grab the PornoScan breasts to get the 3D handle..."
1 this is old
2 this is old
3 this is definite windows bashing
4 if you really understand what is going on here, its not a big deal.
5 this is old
"Karma can only be portioned out by the cosmos." -Homer Simpson
There is a well know programming language for doing this....
Its called Winbatch, and its a commercial product....
Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
It's called "window stations" and "desktops". There are separate hooks, message queues and so on. In short: everything that is necessary. Maybe there are implementation flaws, maybe the interfaces are extremely difficult to program (I don't know, I haven't tried), but the design is sound.
15 minutes of MSDN browsing were required to discover this (and I spent 10 minutes on finding the entry point to the API documentation using Mozilla). Why can't people read the documentation?
good points all around, nice post.
-Jon
since when has slashdot been fair to windows?
They want to be 'cool'
The paper is very, very clear and I am very, very glad that I don't run Windows. =)
While "Shatter" is a great name, it would have been a great inside joke if he called it "Defenestrate". =)
My
Limekiller
Any X11 window on the desktop can take over any other X11 window. This is well documented and is not a hack/crack. it was done by design.
I have written a couple of X11 applications that have done this. It is, actually, a nice feature. I was able to change to look of third party application to look like the applications that we packaged with our product (my old job). The user never knew that it was not our application. Took out their toolbar, replaced it with ours, never even needed the source.
The security exposures in the Windows GUI are nothing compared to X11. I wonder how Mac OS-X is? I am sure it is the same.
Many applications actually use Windows messages to synchronize themselves between threads and processes.
In fact, there is also an API called PostThreadMessage that will post any windows message to any win32 application (all you need is the thread handle) with a message pump.
Out of process COM interfaces using windows messages will also be broken by removing this functionality.
Microsoft's excuse that having physical access to a machine is required is abysmal.
Do not spread "09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0" over the internet, thank you.
it works across terminal server, also, which means you bring in a terminal client and plug in, get access to a user account (think there aren't any giant post-it notes of "my login/password" on half the desks in any given office?), and viola. they have rooted the terminal server and can do whatever the hell they want.
the terminal server may be behind 8 inches of steel and plexi-glass. but this compromise shatters that, too.
MORTAR COMBAT!
The problem isn't unfixable. It's just more work than MS and other sw authors are willing to commit to. Sounds like the Interface between the window manager and the kernal needs to be reworked, either by all programs with root privileges, or implemented generically in the OS. Anyway, I'm glad someone exposed the weakness so it can be analysed, and appropriate steps taken to fix it.
Vote for Pedro
Ever read Hardcore Visual Basic programming? Using the API to enumerate other windows and send signals to them is what it is all about. I've often used Visual Basic to automate other programs by detecting windows, dialog boxes, etc. and sending key strokes to them. This is basically how all those really cool screen readers for the blind used to work before MS opened up and API for them.
Windows isn't really a multi-user system anyway (at least not simultaneously). If you are running multiple programs at the same time and they have access to the windows API, COM, OLE, etc. then you just have to assume that they can control each other...
What else shatters windows? That's right, opera!
Okay, bad, bad, BAD pun. I just couldn't resist.
Why this is only a Unix problem I don't understand, as sprintf is defined in ANSI C, so I would think it'd be a problem on any system with a C compiler.
Hopefully someone more knowledgeable will explain.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
I'm sorry, but telling an engineer that something is unfixable is probably the single best way to get them to fix it.
Again, the Old Guard of the Anti-Microsoft "Can't do right anytime" Regime (read: Timothy), attacks with a flawed premise: attack Trustworthy Computing.
.Net and Palladium.
Newsflash, Tim: First the shatter exploit requires some unusual circumstances, and relies on shoddy programming. Second, the Trustworthy Computing concept is nary a few months old at Microsoft. Somehow they're supposed to magic all kinds of bugfixes to your old Win9x box? Give me a break. You'll see these advancements in security in
Of course, you could just come up with the ASCII-keypad sequence to do a \n\b\t or something like that...backspace followed by tab results in a BSOD in versions of NT/2k, and is short enough to hack in by any user.
Is there a way, with dot net, to write an Internet application that enumerates Windows that are local to the machine, searches an Edit Box in one of them, pastes malicious code to it, and sends a WM_TIMER message so that it executes the malicious code locally with the privileges of the user ?
The point Microsoft made in their response was that this can be fixed on an application by application basis. I personally would be interested in seeing this attack carried out against a program that is part of the standard Microsoft desktop.
Curiously, when I downloaded "Shatter" from the article, Norton AV flagged the file with the exploit code, sploit.bin, as the "W32.Beavuh" virus. However, Symantec provides no further detail of this. I suspect this is merely NAV doing its part to beef up security, forcing would be crackers to actually come up with their exploit code.
bance.net
as others pointed out below, you should separate the parts of your service (or whatever) that need to run with system privs and have them talk to a separate GUI app (which isn't running with system privs).
The real problem is third-party apps. It doesn't surprise me that there are a TON which don't do this. There are a ton of things which just don't function when run under anything other than an account in the local admin group). I think this is a holdover from the 9x days. Hopefully, these problems are getting fewer, but I had a scanner which simply wouldn't work with a non-admin account. Tech support thought I was nuts "I don't want to do that! why not?".
the "culture" on NT/2k/xp is you are running under admin. The "culture" of unix is: Don't run as root! I would prefer to not have my usual account in the admin group and instead use a "run as" shortcut when I need it (or log in under the account). Everytime I've done this, I've gotten tired of handling all the little crap permissions and just switched my account back.).
DO NOT DISTURB THE SE
I'm really, really disgusted that this even got posted. This isn't a Win32 vulnerability, it's a Virusscan vuln. (Watch my karma burn, I'm actually defending MSFT... but hear me out.)
For those of you who aren't familiar with Windows programming, here's what he's doing. Viruscan's GUI is very poorly written and doesn't check for a maximum length on a text box's input. So, he adjusts the size of a textbox using an outside program to 4GB. (Windows unfortunately allows this, since the message format doesn't include a "sender" field to check against the owner handle.) He then inserts shellcode in it, attaches a debugger to the process and searches all of memory for the start of the shellcode. Real efficient, this one.
He then sends it a WM_TIMER message to trigger it. WM_TIMER is usually sent to your window on a regular interval when you've called SetTimer(), and contains either an integral ID or a pointer to a callback in memory. So, he sends it a fake WM_TIMER, and Viruscan executes the callback blindly.
You know what, I use WM_TIMER too in my apps - but, there's two simple ways to defend against it.
if ((void *) msg.lparam != known_cb_address)
{
return false;
}
if (0 != IsBadCodePtr((FARPROC) msg.lparam))
{
go_fuck_yourself();
}
And if I'm not using it, special-case it so that it doesn't fall through to DefWindowProc().
Seriously, all this guy is doing is buffer overflowing a poorly written program to get Administrator privs. That's like claiming that glibc is insecure and should be thrown out because it has sprintf() or gets(). Ya know, I can buffer overflow a poorly written suid app too, but that doesn't make the libc to blame, nor have we published articles lambasting the GNU Project for not putting bounds checking into those functions.
This guy's just trying to sell himself, and you guys were more than helpful. Maybe I should write a system service that subclasses MSIE's WndProc with a single function that calls ExitProcess(1), and see if Slashdot will find me a security job.
His "technique" is kidde fare, nothing any experienced Windows developer doesn't know. His whole premise is based on the idea that "running as SYSTEM" is bad - SYSTEM is designed to be used to run non-interactive services such as SMTP or MSMQ. Installing a service requires administrative rights, as does telling the SCM (Service Control Manager) to allow a given service to interact with the desktop. Microsoft's response is the one I expected to see given how long this "vulnerability" has been known. If you must run a service that interacts with the desktop, run it under a local account which can be locked down and prevented from doing specific things. If anything, this is more the AV vendor's stupid mistake than anything else.
There are tons of actual, real vulnerabilities and problems in Windows (outside of IIS), and most of them reside in the shell code. But those are significantly more difficult to get at than this.
So Mr. "Foon" has proved himself a real bofoon, showed us he sorta kinda understands the process messaging architecture and he knows how to use a debugger and, h^xx0r him, netcat. Woopdedoo!
Not to criticize the editor's "integrity" of course. Who would even consider posting this article for half a million people to see before checking the facts.
Hey, I know! I'll get a website, a kewl IRC handle like "boon", post some techie-sounding text related to some vague problem with Windows and then call it a paper.
Law #1-- "If a bad guy can persuade you to run his program on your computer, it's not your computer anymore,"
and Law #3 -- "If a bad guy has unrestricted physical access to your computer, it's not your computer anymore."
Poor MS users, they finally admit it's not your computer anymore. 8P
Isn't "available as a freelance blah blah" the same thing as "unemployed?"
I smell another motive here... what a convenient way to tell the world, and potential employers, about all your Mad SkillZ.
-CausticPuppy "Of all the people I know, you're certainly one of them." -Somebody I don't know
I'm asking a legal question: does removal of the software constitute rescinding your agreement? Or if Microsoft has somewhere noted your initial agreement, is it in perpetuity? Does Microsoft permanently own that box?
In Windows, every application has a Window Handle, whether it displays a Window or not.
Worse, if you do not know of any particular Window that has high privileges, why not write your malicious program so that it tries with every Windows ?
Does this particular problem suggest that Windows was not designed as a true multi-user network server OS. All apps can be accessed via a single desktop regardless of who the user is? WTF?
I started to worry about this when the Microsoft support site suggested a valid fix to get MS-Money to work was to give the user full administrator access.
Now it looks like they've built the whole API with this mindset.
Do you mind, your karma has just run over my dogma.
This foon character is a moron. He should of wrote a paper called, "How to speak authoritatively on things you know little about." This is not even a big deal because it requires physical access to a machine. With that level of access, you could kick the machine with a boot or throw a grenade at it. Nothing can be secure that way--even linux. Find some remote security holes that can comprimise "national security" This idiot made a fool of himself
What, by the way, makes you think sprintf() is only a problem on Linux? You do have that on Windows too, don't you?
My House, Universe of Highly Probable Parallels: In a recent twist on the discovery of a way of hijacking your MS Windows computer using simple API calls, it was revealed today that there is an undocumented API function called RIAATakeOverComputer() that can also be used to fully exploit Windows. Microsoft VP Jim Allchin could not be reached for comment as he was in security talks with RIAA executives...
And you might want to learn how to give a "paper" the once over (at least) before allowing fucktards like this one to root you in front of all your readers.
I don't think that it is fair to characterize the original developers of Windows as lazy. The typical PC was running MS-DOS, a primitive single-user operating system, when they were making the fundamental decisions about the architecture and design of Windows. Many of the design decisions that people like to bitch about can be traced back to what was necessary to implement a usable GUI on a grossly underpowered computer without protected memory or any semblance of a modern operating system. The Macintosh developers made similar decisions when they implemented MacOS on an 8 MHz 68000 with 128K of RAM. There is a huge chasm between a single-user microcomputer with limited RAM, CPU and no networking, and a modern networked multitasking workstation with a security model.
Mea navis aericumbens anguillis abundat
At lot of people are saying that this is an application level problem and not a flaw in Windows. That is wrong.
The core result of the attack is that it is impossible for a high privilege program to display a GUI interface to a low privilege user. That is a silly limitation, certainly one that that other GUI systems like X Windows do not share. Sure, you can work around the weakness by having a low privilege GUI talk to a high privilege service over a local socket, but it shouldn't be necessary. This gross "fix" will complicate the situation, potentially opening additional security holes.
Microsoft tried to deflect the issue by hiding behind, "If the user is local to the machine, or can run his own binaries, he owns your machine." It sounds nice in theory, but falls apart when the "user" in question is actually an opportunistic virus looking to add the machine to a distributed denial of service cluster. Many corporate environments lock down the machines not for fear of user attack, but to limit the damage of viruses and other malware. If the malware can exploit this technique to gain elevated privileges, your security steps are worthless.
Ultimately, with a bit of care, a high privilege program should be able to safely interact with a user through any means, be it command line, GUI, network, or otherwise. If the operating system makes this impossible, the operation system has a flaw.
If it is, then it seems a bit dishonest for the microsoft message author (Dave at the Security Response Center) to say that they don't consider it to be a bug.
If it isn't, then there must be another problem which is even more serious. Oh dear!
Who this effects? Try every corporation running windows, every university, all government offices running windows and so on. In these, all non-admins have less than admin access, and with this, they can gain admin access. You, sir (or madam), are an idiot.
and then mod me down. posting this one at +1 to attempt to get some attention...
MORTAR COMBAT!
*cough*Mac*cough*
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
- Unix power users & sysadmins write scripts and programs; I assume that Windows users and sysadmins do the the same.
- Large corporations develop custom software to do things the way they want.
- Scientists and engineers write programs to process their data because nothing exists to do what they need.
- At universities, colleges and high schools areound the world, students write programs.
- And let's not forget all the software developers everywhere, writing the code which will eventually be assigned keys
How will all these un-keyed programs run on Palladium?I don't see why this is unfixable. The program that actually must see and use the windows of another program is rare, and I would contend that such programs are poorly written and should be redesigned using some true method of IPC. It may break programs, but I personally don't see any issue with doing such if it prevents this from being attacked. For example there is no reason that a program should be able to send WM_TIMER to any other program. That message should be restricted entirely to the current process only. Perhaps the entire control message range can be locked while keeping the WM_USER band open to communication between PID.
Your primary problem here is that messages are being sent which aren't expected. Most message processing routines just toss these messages off to DefWindowProc(), which is what's doing the damage here. You could fix a few of the problems stated here, especially the abuse of the callaback function with a timer, by simply making DefWindowProc() do nothing as the default behavior with certain messages. This would reduce the effectiveness of attacks to those that utilize messages intercepted by programs which are not properly checked. For the adventurous among the readers, user32.dll defines DefWindowProc(). Feel free to write it as you please. Granted, there are fundamental problems in Windows that are nearly unfixable without a huge redesign. This is not one of them.
You like splinters in your crotch? -Jon Caldara
Isn't the point that if an app is running as guest then functions that mess with other processes should fail? The debugger must be using CreateRemoteThread or *something* to run code in another process.
To all of those people who say "this isn't a big issue, it's only a local exploit", I ask them to consider poor people like me, who run open-access computer labs at Universities. It's not like we can put a firewall between us and the exploits, is it?
When was the last time there was something newsworthy posted on slashdot?
I sware for a while there I was able to pick up material that could kinda be classed as 'news' on this site...
Ahh well, at least the register still reports news.
...flaming this idiotic story, let alone the idiotic responses. If you would like me to completely debunk this "vulnerability", email me at the address:
get@fucking.clue
So you can hack Windows once you're in... wow. I agree with MS on this one, this isn't either new or a vulnerability, per se. It is annoying, but that's how it goes. Besides using a proggie to up your rights once you own a box is silly, if you owned the box correctly you'd be root/Administrator and then it wouldn't matter now would it?
My answer is what took him so long to get around looking at the Win32 APIs. Hey dude there's a whole another world of undocumented API's to play with too. Windows has security holes, that is so five minutes ago. Show me an major OS that doesn't have security patches rolling out. Yes even OpenBSD has security patches. It's a fact of life when your code base of that large.
My mouse does the same thing as these exploits! I can take control of any window on my desktop with it. Guess I will have to keep visiting windowsupdate.microsoft.com looking for a solution to this mouse problem.
From the interview: So if you get code and it's not from anyone you trust, you can choose to not run it.
Well, that's good. /. made it sound like Microsoft would be able to decide what everyone could run. I'm not sure why I care anyway, there's no way I will ever run Palladium or get a "security chip".
As far as I know all an update to Windows would have to do is check the privlege levels of the requesting application and the target application and if they don't match, it isn't going to happen.
This is an issue for Terminal Server and for shared-hosting operations. It's also an issue if someone finds a Windows servlet with an exploitable buffer overflow. But if IIS is already running as administrator, as soon as you find a server-side buffer overflow, you're done anyway.
It's a nonissue only because Windows security already sucks.
Sounds like a pretty fundamental flaw, indeed.
Note down the memory location that the string appears at; it'll probably appear a couple of times, don't ask me why.
Somebody needs a lesson in memory segmentation, eh?
If you have the patience to read through his smarmy instructions on how to reproduce the defect, you'll discover that he has indeed hit upon a rather serious security flaw. He then proceeds to give three strawmen--er, I mean possible solutions to the problem--and argues that since these three things can't fix it, nothing can. Well, I'm not convinced.
What if Windows' messaging were changed so that certain messages that are considered insecure (like WM_TIMER) can only be sent to windows owned by the sending process? What if the text inside an edit control were held in some piece of memory with no execute priviledges? These are two things that, I think, could solve this problem immediately, with little inconvenience to users.
Also, check out this guy's pompous letter to Microsoft, in which he states, "Since Microsoft already know about this issue, and any of your programmers will be able to replicate and verify the issue in less than an hour given the information in my advisory, I'm not prepared to wait very long." Clearly this, er, fellow has no experience in large software companies. Even good software has perhaps hundreds of defects outstanding at any given moment, at various levels of urgency, competing for developers' attention. Apparently he either thinks he's so important that he can jump the queue, or else he imagines that these armies of developers are sitting idly at their desks waiting for people like him to give them something to do.
Well, that's enough ranting. The upshot of it is, I wouldn't be too woried. He has not done a Jenga on Windows.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Another unhappy computer science student, who has not quite graduated out of sixth-form ego-trips.
I take it you learned VBScript before you taught yourself zx81 basic/asm.
Ego-fuck-wit.
That's why command-line interface are so superior!!!
Now watch my badassbashskillz...
A message from the system administrator: 'I've upped my priority. Now up yours.'
He never said it wouldn't. What he said was that between Java and .Net there would be an improvement in the security of applications running on the Windows platform.
He isn't considering whether .Net will live up to the hype or not; he's just stating that the security frameworks implemented in .Net and Java will create a more secure system.
tlhf
Oh - and nice arbitrary '2-5 years' figure. Making up figures make your point seem more valid....
You just threw away two points, saying they're for other discussions. But your point is, they shouldn't crash the OS and *do*. So they are relevant, IMHO.
Bill
Upon seeing the box was too small, Schrodinger's Elephant breathed a sigh of relief.
Noise
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
My brand-new Sony Vaio laptop crashes frequently
*on bootup* with a blue screen of death.
Its running XP home
Where exactly was this "paper" published?
Putting up a plain text webpage with some lame ramblings about some well known programming mistakes does not count as publishing a paper.
What a fucking retard.
In the dictionary next to POSER there is a picture of Chris Paget.
Couldn't said it better myself :)
3.243F6A8885A308D313
Currently the X server almost always runs as root because it needs direct hardware access for accelerated video. If there were a buffer overflow bug or something similar in XFree86, a malicious X client could run code as root. This needn't even be in XFree86, it could be in an extension that isn't tested as well. For all we know, the binary NVidia drivers may be exploitable.
This IMHO is a great argument to stop running X as root and just implement acceleration in the kernel framebuffer driver when necessary.
-- 2 + 2 = 5, for very large values of 2
Like I said, noise.
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
I disagree with this assessment for several reasons. Even if the virus scanner code is junk, the attacker is successfully manipulating this program in ways that the program should not have to deal with.
1. If the program creates an edit control and specifies that the maximum input size is X, then it better stay X until it is changed by authorized code- namely the process that created it.
2. The means for fetching text out of that edit control is WM_GETTEXT. This message takes a destination buffer length as a parameter. It should not be possible to overrun the destination buffer regardless of how many characters are in the edit control. The input would merely be truncated.
3. The exploit code is most likely in the edit control's internal buffer- not the application's dynamic memory. Unless the user clicks OK or some sort of OnChanged handler has copied that data to a new location, the application has not had the chance to touch it. The attacker merely needs to guess the location of the edit control's internal buffer. Apparently, it's less difficult than one would hope.
And finally, even if none of that were the case:
4. Being able to send any message that passes a pointer across applications is foolish. I could send WM_GETTEXT or a raft of similar calls to an application and have it trash itself. The destination address could be any valid place in the target's dynamic memory. If the application attempted to validate the pointer, it would pass. Moreover, important information resides in dynamic memory, not the least of which is the vtbl pointers of important objects like MFC's global CWinApp.
Now, I have a question. How is that this code can be executed at all? Unless the permissions on the pages holding the exploit code permit execution, I don't see how the exploit can even run. Instead, I would expect to see some sort of access violation. Apparently not.
I will research this more.
-Hope
This guy is just another fat ugly wannabe hax0r.
The fellow that wrote this paper lacks an understanding of how X works. Using Xlib I can do essentially what this does in Windows with XSendEvent in X. People have known about this exploit for years in X. You need this capability for things like drag and drop and it comes in handy for application testing/automating. XTerm actually has a resource to enable/disable events sent via XSendEvent. I don't consider it much of an issue. As long as the programs you are running are trusted then you should be safe. I sincerely hope that this doesn't encourage kids to start writing awful hacks that end up deleting the files of a user. I don't consider this a flaw in Windows, because disabling this feature would severely limit Windows.
Microsoft's documentation for WM_TIMER indicates that the code is run by the "Default Window Procedure". This is DefWindowProc, the function you call to handle messages that have gone unhandled by the application. If this is correct, the problem is fixable; the application needs to simply not call DefWindowProc for WM_TIMER messages with non-zero second parameters (unless it actually wants the code in question called).
This could be solved without major disruption in windows if DefWindowProc simply checked the address passed to it against a list of functions that had been previously registered by the process with SetTimer().
I haven't personally verified this, it's possible that the documentation is incorrect.
--
Benjamin Coates
Why do all that work just for WM_TIMER? Why not just go for the throat by sub-classing any window with privs? SetWindowLongPtr
LONG cbMyProc(HWND hWnd, LONG uMsg, LONG wParam, LONG lParam)
/* Any sploit you like. */
/* doesn't matter what you send,
{
}
hwnd = FindWindowWithRoot();
cbProc = SetWindowLongPtr(hwnd, GWLP_WNDPROC, cbMyProc);
it call cbMyProc() to process it */
SendMessage( hwnd, msg, wp, lp );
Now cbMyProc is the message handler for all msgs to hwnd, any code in cbMyProc is executed within the memory space, and priv of the target.
The author writes:
Is this just a Win32 problem?
Probably, yes. The only mainstream competitor to Windows in terms of windowing systems is X windows. X is based on a similar underlying technique, that of queueing messages that are passed between windows.
Are Macs susceptible to such an attack?
The author has addressed Microsoft's response in his writeup. Given that there are numerous windows running as LocalSystem on any desktop, Microsoft's response is a load of tripe.
___
If you think big enough, you'll never have to do it.
Check out Enabler on my site, this program has been around for over a year and does what you describe and more.
. ex e
http://www.securitysoftware.cc/Programs/Enabler
-Pertinax
Too bad you got modded down for being off topic. Good response though.
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
--
Benjamin Coates
Look... I'm in no hurry to defend Microsoft but being as I develop for their OS on a daily basis - its common knowledge (or should be) that anybody who runs a service under system privileges that presents a GUI to any old user - is a fucktard that simply needs to die. Yes this problem can be fixed by MS using the 2nd option indicated in the paper and yes it would mean these crappy designed apps written by third parties would have to be rewritten.
Microsoft specifically reccommends that you do not run services and allow them to interact with the local desktop. Doing so is security suicide. Thats how VirusScan was running. Therefore its a McAfee issue since there are about a bazillion better ways to write this app.
J
I love idealists not because I am one, but because they make life bearable for pragmatists such as myself.
Microsoft also is trying to take security more seriously.
One can only guess at what jokes they make...
Worker1: knock knock.
Worker2: who's there?
Worker1: CQ.
Worker2: CQ Who?
Worker1: Security.
Carbon based humanoid in training.
This is not a security vulnerability in windows. In windows the security boundary for GUI objects is the window station/desktop. Within the same winstation or desktop you can send any message to any window you want. You can set ACLs on the window station to prevent low privileged users from accessing a window station or desktop. Services by default run in an isolated winsta/desktop on a per user basis (i.e. all the SYSTEM services share a winsta/desktop). No low privileged app can send anything to that desktop. If you check the let this service interact with the desktop option for a service then it is moved into the main user window station and desktop. That service can then present UI to the first user which logs into the system if it wants. The service also gets all the security risks of running in that desktop. If you choose that option then you get what you asked for and need to secure that code for running in the interactive session. Running this way also doesn't work with fast user switching or terminal server since you can have multiple users logged in at the same time. If a service wants to present UI to the user then it needs to run in a client server model and a process running in the user session and communicate back to the parent using COM/RPC/whatever.
Spoke too soon. My program just controls windows and other objects in applications. No code insertion.
Doesn't seem like a good way to execute code with higher privledges anyway. Dll insertion techniques have been well known for some time.
-Pertinax
Yesterday, on one of those rare occasions that I was using my Windows partition and surfing along downloading an mp3, I decided to preview my selection before it was complete...and, lo, my hard disk starts churning and Netsape (my default browser because of the requirements of Britannica -- thank you!) opens to a pr0n page! When I think of what a black-hat hacker might have done had I allowed IE to be my default browser or use MS Outlook express and its addressbook, I am driven back to Linux. I DO believe one gives up all control of one's computer when using Windows. Don't know why, exactly, but it's so.
Mod this fucker up, I think I fixed it... well, almost. I'm not done, but I've got one function down out of a dozen, and with the method operating, the rest is cake.
Windows hooking permits the forced injection of a DLL into the space of all processes. From here I can access the Import Access Table (IAT) of all processes. From here I can find and redirect the IAT of the messaging functions back to my injected DLL. From here I can compare the hWnd to the PID for control range messages to ensure that the message is valid. Then I could either eat the message, or continue the original IAT address of the function to continue it on it's merry way. I'll post back if/when I completely succeed.
I don't believe it is the responsibility of the receiving process to have to validate window messages beyond it's own functionality. That is the job of the OS. The OS doesn't do it, so I'll make it the job of the sending process.
from the interview:
It's pretty obvious that not all 8,000 developers were looking at the same line of code. So, followed to the logical conclusion, MS admits that open source software is more trustworthy. Endgame.
Comment removed based on user account deletion
to say that its unfixable. sounds like fud to me trying to smear microsoft from somebody who has no idea what they're talking about.
...inform him he has been presented with an opportunity to obtain additional funding for the OpenBSD project, with many thanks to the copyright violation perpetrated by Scott Charney. "Secure by Default" is the intellectual property of the OpenBSD project. The footer of the OpenBSD homepage clearly indicates a copyright notice, and the evidence of violation can be found here:
http://www.openbsd.org/security.html#default
So, looks like Microsoft will have to settle for SD2.
---
If pro is the opposite of con, what is the opposite of progress?
Yah, it's the vendor's fault for not treating the insecure services running "windowless" under Windows as damage and routing around them.
Comment removed based on user account deletion
With the MS Palladium initiative "you will have "trusted agents"--pieces of code that are signed by people you trust. This is a good thing because it can eliminate a lot of viruses. So if you get code and it's not from anyone you trust, you can choose to not run it."
./run_program or rm -fr run_program. Brilliant.
Sounds alot like me using
--Kevin
Why are people pretending that this is not a problem with the design of Windows?
It seems perfectly obvious to me that all you would have to do to fix this would be to associate applications credentials with messages as they are passed around, and not permit messages from a process with a lower priviledge to be sent to a process with a higher priviledge, unless a security association is established.
This would mean changing the messaging API, but it's fixable. It would merely mean recompiling all third party code that needed t communicate across priviledge boundaries, and adding code to programs designed to operate at higher priviledges to accept the new message type, rather than dropping it on the floor (making that the default), and make a decision based on that.
This is the standard "capabilities" security model, and is the same model that used for NT file permissions, in terms of a hierarchical inherited rights arrangement.
There would be a significant impact on "remote control", some install tools, and other packages that are not written with the idea of priviledge domain seperation, but it's *possible* to fix.
-- Terry
At my work most of us developers have a task manager window running, executed using the 'at' command. This means the task manager is running as LocalSystem and can kill practically anything. Especially good for bugs which cause endless warning boxes to appear.
Go to file|new task and run cmd. Do a whoami to see who you are now 'NT_AUTHORITY\SYSTEM'.
Now I believe this one is wholly an MS problem. Their OS, their at command, their task manager.
"She's a West Texas girl, just like me" - G.W Bush Iraqis
We've actually been doing this for a couple of years with a couple of methods and used them in legitimate software products, one being eFX a Window GUI changer and another being Napigator v2.0+ but a different and what I believe is more powerful approach since you don't need to paste code into edit boxes and use debuggers was formed.
/imports blah.exe to see what's available for the taking).
Step 1: Howto get into another processes memory space
The easiest way todo this is via a global system-hook, or via a DLL that you must put in a special regkey and Windows will automatically load your DLL into every process as it starts, another more complicated method is to use CreateRemoteThread() (NT only?) and run a small function which performs LoadLibrary() on the DLL of your choice. I'll refer to a hook method for now as it's simple and works on all flavours of 32-bit Windows. SetWindowsHookEx documentation Usually this function is only used to set a hook within the specified thread ID to keep the hook localized however by setting the thread ID to 0 and putting the HOOKPROC inside a DLL and using WH_CBT, WH_GETMESSAGE etc hooks, Windows will automatically load your hook DLL into each process which the hook applies to which is usually all of them. That's it.
Step 2: Doing something useful
If you chose to use WH_GETMESSAGE for your hook then you have a hook function which is being called each time a process calls GetMessage() as part of its message loop, during the time in GetMessage() you are in the processes memory space as if it was your own and you may execute any code you like, prevent the process from getting messages.. whatever you like.. since we're on the discussion of exploits though let's do something interesting and take over the process.
Step 3: API hooking
When a process calls a shared function from a DLL it looks up the address of the function in the import table of the process. This is the main executable PE usually but you can also do recursive API hooking and modify the IATs of each module/DLL loaded in the same way. If you want to learn more on that just study up on the PE module format. My method of API hooking works by modifying the import table to change the address of where the actual functions are. This lets you replace shared DLL functions including most of the Win32 API with your own, here's a small example.
int (PASCAL FAR *orig_connect)(SOCKET s, const struct sockaddr FAR *name, int namelen) = 0;
int PASCAL FAR new_connect(SOCKET s, const struct sockaddr FAR *name, int namelen)
{
printf("[new_connect] socket(0x%08X) host(%s) port(%d) orig_connect(0x%08X)\n",
s, inet_ntoa(((struct sockaddr_in *)name)->sin_addr), ntohs(((struct sockaddr_in *)name)->sin_port), orig_connect);
return orig_connect(s, name, namelen);
}
Now to actually install the hook i've written a universal function kind of like GetProcAddress() todo it for me, I can't divulge the code because its company property however it's pretty easy to figure out if anyone needs todo it. The place I choose to install the hook is in DllMain() which is called when your DLL is loaded into each process, so you could hook every process running on the system since the global system hook we set earlier will be loading us into all of them or you could for example use GetModuleFileName(GetModuleHandle(0)...) to see which process you are now working in and if you want to hook it.
BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
switch(ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
{
(FARPROC&)orig_connect = HookModuleImport(GetModuleHandle(0), "WSOCK32.DLL", (LPCSTR)4, (PROC)new_connect, TRUE);
}
break;
}
return TRUE;
}
PROC HookModuleImport(HMODULE hModule, LPCSTR szModule, LPCSTR szImport, PROC pNewProc, BOOL bOrdinal);
The first parameter to the function is the process of whos import table you wish to modify, all you have todo is build up the PE headers and you'll get there. The second parameter is the module which contains the function you want to replace, in this case its WSOCK32.DLL. The third parameter is normally the function name however we are hooking by ordinal instead here because the string "connect" wasn't available to search for with this particular module, I can't remember the exact details but I think it was Windows 2000 copy only exported ordinals but not exactly sure off hand has been a while. The fourth parameter is the address of the new function and the last just says to look for ordinals instead of strings. The address of the old function is returned so you can call it if you wish or un-install your hook by calling HookModuleImport again with orig_connect as parater 4 (a good place todo this is in DLL_PROCESS_DETACH).
Whats happening now is in the process whos IAT we patched, each time it calls the Winsock connect() function, our new_connect is now called instead. We can do anything we like here, calling SetLastError(WSAECONNREFUSED); return SOCKET_ERROR; would make the particular process think the connection was refused (hmm, how bout a filter that prevents all spyware from connecting to its destination on every process on the system transparently by checking the destination address). I've only used Winsock::connect() as an example but this method can be applied to any function a process imports in any DLL (if you have VC++ just type dumpbin
we have seen working code that demonstrates how to get backdoor software onto an internal, secured network.
.com address with no ~ in the url? Even more.
It's called spyware, and its deployment mechanism is Kazaa.
You want to root a bunch of machines? Write a piece of spyware, and hook it into the latest and greatest gnutella client. Grab the Gnotella source, patch your exploit into it, and release it, and the source to comply with GPL.
Do you know how many people blindly download and install GPL'd apps because the presence of source gives them a false sense of security? A lot. You know who installs closed-source, non-GPLed software because they think it looks cool or assume it's safe because they have a
One word: Webshots.
Webshots is on so many damned systems in internal, "secured" networks that you couldn't root it out if you tried. All it does is change the wallpaper for those too dumb to figure out how to do it themselves. It also installs a load of fun tracking and marketing tools. These people proved you can make software do something that IS ALREADY BUILT INTO THE OS and people will blindly download it and install it. And if the spyware you bundle with it isn't spyware and is instead a remote controller for DDOS attacks, have fun. It's a field day.
Whine about how "well, their network doesn't lock down their computers so they deserve it" all you want. This affects EVERYONE, not just the dumb receptionist who wants bonzi buddy on her laptop. If someone distributes a DDOS zombie client in a popular free download (like the next AIM or something), some poor dude who runs a blog on his bedroom DSL who has never even HEARD of these insecured networks is going to be on the receiving end of it.
And don't get me started on how easy it is to reset the local admin password on a locked down company laptop to give bonzi buddy admin rights.
Xarph's first law of root paranoia: There are more idiots with root in the world than there are locked-down users.
Xarph's second law of root paranoia: Everyone has console access to the dumb terminal they're sitting at.
-Lx?
Ok, so I took a look at the paper and then the e-mail response from Microsoft; and found this in the 4th paragraph, "In our essay, the 'Ten Immutable Laws of Security'i, these are Law #1-- "If a bad guy can persuade you to run his program on your computer, it's not your computer anymore," and Law #3 -- "If a bad guy has unrestricted physical access to your computer, it's not your computer anymore." (see http://www.microsoft.com/technet/columns/security/ essays/10imlaws.asp
for the full essay)."
So does this mean when those of us apply the Microsoft backdoors, I mean Service Packs to our systems, that give them unrestricted access to our systems, aren't we breaking one of Microsoft's rules, rule #3? I guess if it favors them it really doesn't matter.
Yeah those of us who run Microsoft software probably should deal with it; but it does raise some interesting ideas, expecially with Palladium. I guess if it [Palladium] comes about, those of us who run it truly will not own a PC, Microsoft will.
What this guy's *supposed* Windows shattering discovery does is allow a person to gain further control of AN ALREADY COMPROMISED COMPUTER. So if you do a good job of securing your computers, his "Windows Shattering" code is worthless. Not only that, but he isnt even using Windows to do it, he is using third-party programs. So the flaws are with programs that interface into Windows, and not Windows itself. Nice troll...
Manipulate the moderator system! Mod someone as "overrated" today.
One of the primary rules when designing a service is that a service does not provide ANY USER INTERFACE WHATSOEVER.
A service listens on a TCP/IP port, named pipe, etc. If the virusscan writers had written their stuff PROPERLY, it would run the virusscanning engine as a service, and the user interface would be a user-mode program, posting and receiving messages from the service via named pipes or an IP port or whatever.
Imagine that you had a daemon running as root on your linux box that somehow popped up a UI in your X-windows session. Would you be AT ALL surprised if there was a way to exploit that to get root? I thought not.
The proper way would be to have a user program running in X that could communicate with the service.
Natural != (nontoxic || beneficial)
Please forgive me if the answer is obvious, but how do you attach the debugger to the process, if you do not have admin privileges? I see you can run this on a different system, one on which you do have admin, and the address should be the same. However, if this is not possible/practical, can you accomplish this without admin privileges?
Back in the days of Windows 3.11, you could record mouse macros and play them back (i.e. to automate stuff). Can this type of stuff still be done today? If so, an exploit doesn't even need a user to open a window for it (like the exploit paper suggested), it can do it itself. Also, perhaps an exploit can sit in the background and just wait for an appropriate window to open.
But you are already at the windows machine, logged in! Really if you want to elevate your privileges once logged in simply run at interactively to execute task manager, and from the task manager run anything you like.
How many utilities are there floating around, and have been floating around for years, that let you get access, change passwords, etc as long as you are actually sitting down in front of it.
I'm not saying that this isn't a security issue. I do think that being able to grab a handle to anything and mess around with it is not good at all. It is a poor design. But tell me when you can exploit this remotely.
MS knows how easy it is to get 'root' if you are sitting at the machine that I doubt they'll care about this long winded way until it can be done remotely. As for remotely exploiting this security hole, I doubt it can be done since it relies on messaging.
How are you arriving at the conclusion that this dialog runs with system priviliges?
IT DOESN'T
The GUI comes from a DLL running inside the process space of MMC.EXE. It uses a fairly secure RPC/IPC mechanism to talk to Windows.
A simple trip through spy++ will even tell you the owner process in about 5 seconds.
Second, on the finger-pointing issue, yes the specific example he used is McAffee's fault for not seperating the GUI from the service, but as he said, there are several built-in ways to get a LocalSystem window with controls on it without resorting to exploiting 3rd party apps. In other words, if MS is going to point the finger at service developers, they had better include themselves in that category.
Third, a question about how controls respond to windows messages. I've never had cause to send messages directly (except custom messages), but AFAIK it's not a case where you can send a EM_SETLIMIT message to a control and it automatically sets it's limit. The application has to receive the message, interpret it, and set the limit on the control. The problem is that no major vendor I know of, particularly not MS, write straight to the API, they use libraries for their controls. And every control library I've seen defaults to handling EM_SETLIMIT messages by setting the limit on the control. If this works the way I think it does, then by not using libraries with open defaults, or by changing those defaults, you can write an app that only handles messages it expects to receive, hence this problem doesn't happen. (IE, do you know of any app where one thread really needs to change the length limit on a control in another thread? I can't think of any off the bat...) Can anyone confirm or deny this?
Want to change history? It's easy. Here's how. First, design and build a time machine. Okay, second, get in, pull the lever back until you get to when you want to be. Get out! It's that simple. And this guy wants to take over an edit box. Who are you with? Petty geeks or uber geeks?
.
Comment removed based on user account deletion
So Sorry, The Bungi, that Foon isn't up to par with such dynamic nomenclature as :The Bungi.
Shame on you, poor little critic.
Balzac once remarked, "Noone has ever made a statue of a critic." Said before or after the Rodin, I don't know.
But goddamnit if I don't laugh anytime someone says, "my. . . Balzac!"
GTK+ has the same issue. It was a *huge* deal when people started fighting about this, and eventually the decision was to just not let GTK apps run suid root.
Given the huge outcry about GTK+, I'm impressed that MS has had the same flaw, but for so much longer, with no one talking about it.
May we never see th
This is the worst article I have read from slashdot in a long time.
I have a funny feeling that if I wrote an article about how applications which are setuid on *nix, take user arguments and contain buffer overflows are vulnerable!!! I wouldn't get on the front page of slashdot.
I'm amazed that MS even took the time to reply to this joker - I bet Linus or any other Linux guy would either ignore a similar piece of junk or start a public flame war.
A better analogy is setuid. It's the exact same problem thousands of apps running setuid root need to be carefully checked to make sure they're not exploitable by the users too.
If this is a security flaw within the Win32api, setuid functionality is an equally problematic security flaw in POSIX.
It's open season on Foon. Do you have anything copyrighted by you (that limerick that you wrote 10 minutes ago will do), stored on a machine that runs NT? If so, then you can sue Foon for trafficking in a program primarily intended to circumvent a technological measure that effectively controls access to your copyrighted work.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Apart from some general fishy facts about this article (how do they build a suitable hangar and keep it hidden, how do they never have a crash with an private airplane which "did not see it" etc), there is the question why Boeing would buy into Cargolifter in order to develop lighter-than-air-vehicles:
0 20 730m.html
:-)
http://www.boeing.com/news/releases/2002/q3/nr_
They _should_ know what their major competition (Lockheed) is up to already and not invest in inferior foreign technology, right?
If you guys want to know what lighter-than-air-technology means today, check out the Cargolifter web site (www.cargolifter.com) and have your babelfish ready.
Everyone that uses windows should stop running programs that run with higher privileges. That means antivirus programs, . Damned if you do and damned if you don't. bye bye windows :-D
So, I click to read a story about flaws in the Win32 API and what embedded doubleclick ad do I see? One for Visual Studio .NET.
Gah, slashdot is continuing to suck.
----- LoboSoft specializes in Digital Language Lab
Only an admin can run 'at'.
Guest cannot become localsystem with that trick.
On a locked down box, misc apps downloaded from internet cannot be run anyways. . . .
Give users ability to run any app they want, and of course your security is going to be broken through sooner or later,
duh
Need help treating your acne? Come here!
this is hilarious. we should mod them both up so that everyone can witness the brilliance of /.
"I assumed blithely that there were no elves out there in the darkness"
And how hard is it for a guest to get make themselves administrators?
... up comes the user manager.
... even MS exploits require you to reboot these days!
Step 1. copy musrmgr.exe over the top of logon.scr
Step 2. reboot
Step 3. when the logon screen appears just wait for a while until the screensaver kicks in and poof
Step 4. Make yourself an administrator
So I should have changed my subject to Takes Imin plus reboot for me.
Damn
"She's a West Texas girl, just like me" - G.W Bush Iraqis
Of course, the owner's manual states clearly that the button should never be pushed while the vehicle was in motion.
By default the .NET CLR does not allow assemblies downloaded from an untrusted source (ie: internet) to have that kind of access to the system.
FYI.
On the Log On tab of the service properties there is a checkbox that allows you to disable interaction with the desktop when Local System account is seleted.
NO CARRIER
i don't know where my head has been, probably in the sand. posting this as an AC because (1) it's sad to admit i'm so behind the news, and (2) well, here it comes.
a friend just told me today about what will happen to my use of the nice "FCKGW-RHQQ2-..." windows XP pro corp. code as soon as i install windows xp service pack 1. boom. no more windows, because naturally they want to stop pirates like me, which they have every right to do.
the problem is, here is what i do with nearly all my spare time. i build low cost machines for people who can't afford them -- i build them with the lowest priced crap i can find on pricewatch, the lowest priced crap i can find used, in salvage, etc, etc. and i put a pirated copy of windows on them. every single one.
and now, every single pirated copy of windows xp i've built into one of these machines will go "boom" unless i tell everyone to not upgrade their software anymore. so basically there will be a bunch of machines with security holes, a ripe field for virus infestation, sitting all over the area.
the other option, buying $200 microsoft licenses for these people, when that is about the cost of the entire PC which i built for them.
yes, it's stealing, and there's no justification. but it is the end of the freebies, now only the rich and the big-time commercial pirates, and the people who can really afford it anyway, will be able to run the software which will be required for just about every other software out there, the software they'll need for school, to play games, etc.
i was just putting the finishing touches on one more $200 PC for a family of foster kids. now i don't know what to do about the XP license.
shame on me for being a pirate, and i don't know how i missed the news about this -- going back and looking i can see it is all over the place. but there will be at least 12 windows xp installs which will be permanently stuck at pre-service pack 1, and i'm sure there are thousands of others.
so virus writers, have a nice field day with all these. pay special attention to future windows security updates, and exploit the hell out of the holes, because just about half the machines won't be getting updates.
-ac
Log on as Administrator. Go into "Services". Look through your services, looking at the "log on as" tab of each service. Make sure "Allow service to interact with desktop" is unchecked. Keep in mind that some services require this to have a GUI.
From the Microsoft Platform SDK:
t ro l\Windows
Interactive Servives
An interactive service is a service that can interact with the input desktop. Other desktops do not receive user input. For more information, see Window Stations and Desktops.
An interactive service must run in the context of the LocalSystem account and be configured to run interactively. Services are configured to run interactively when the dwServiceType parameter in a CreateService call is set to include the SERVICE_INTERACTIVE_PROCESS flag. However, the following registry key contains a value, NoInteractiveServices, that controls the effect of the SERVICE_INTERACTIVE_PROCESS flag:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Con
The NoInteractiveServices value defaults to 0, which means that services marked with the SERVICE_INTERACTIVE_PROCESS flag will be allowed to run interactively. When the NoInteractiveServices value is set to a nonzero value, no service started thereafter, regardless of whether it has been configured with SERVICE_INTERACTIVE_PROCESS, will be allowed to run interactively.
Note It is possible to display a message box from a service, even if it is not running in the LocalSystem account or not configured to run interactively. Simply call the MessageBox function using the MB_SERVICE_NOTIFICATION flag. Do not call MessageBox during service initialization or from the HandlerEx routine, unless you call it from a separate thread, so that you return to the SCM in a timely manner.
It is also possible to interact with the desktop from a non-interactive service by modifying the DACLs on the interface window station and desktop or by impersonating the logged-on user and opening the interactive window station and desktop directly. For more information, see Interacting with the User in a Service.
Built on Wednesday, July 26, 2000
Well, what do you know, a "0-day exploit"
http://hoopajoo.net/projects/xautomation.html
xautomation
Control X from the command line for scripts, and do "visual scraping" to find things on the screen. The conrol interface allows mouse movement, clicking, button up/down, key up/down, etc, and uses the XTest extension so you don't have the annoying problems that xse has when apps ignore sent events. The visgrep program find images inside of images and reports the coordinates, allowing progams to find buttons, etc, on the screen to click on.
-- I speak only for myself.
I am definately going to remember this. It might work at a place where there are NT4 terminals that authenticate off a domain, but local administrators have unrestricted access.
The author claims that he sent a message to Microsoft, and Microsoft responded that it is not really a threat because, well, it can only be done locally, and I can see that a lot of people who pasted comments stated that it was clearly stupid of them to do such a thing, however, Microsoft, in this case, has a point.
Mac OS X, the operating system that we have all ignored, as a lot of us think that it is secure, is very insecure locally. While booting your Maciontosh computer with OS X installed on it, hold down ApplCtrl (the key with the symbok) + s it would boot in single user mode. And guess what? The system starts out with you as root, without asking for a single password.
Clearly, most local exploits are not extremely devastating to security, and although I agree that this is a very silly system of window management, people shouldn't be so suprised, as if something like this didn't present itself before.
IIS runs as IUSER_ NOT as the System account, and it has done this for years. The default install of SQL Server 2000 runs as a normal Domain user account NOT LocalSystem.
I am wondering if this exploit will work with
Wine (as in "Wine Is Not an Emulator")?
If so does it mean wine is a vulnerability in
linux?
He's talking about how it changes the ticket to have a destination of NY or Washington. I couldn't make it do middle of butt fuck Pennsylvania.
Windows NT/2000/XP all have problems with applications running at 'System' or another level below 'Administrator' ( root ).
For example:
1. Setup a win2k box with a user, and make it so that this user can only run the app MS Word using your little GUI profile editor.
No write access to drives, no shell, etc.
2. Log in as that user.
3. Now run MS Word and...
Press Alt+F11
Press F5
Enter "wolf" as the procedure name
Enter "Shell "cmd.exe", vb.normalfocusfoo"
Press F5
Now using commands like 'control userpasswords' you can fuck up your nice little system.
Also using command.com ( 'NT DOS' ) with your macros you can get beyond kernel rescrictions, which is like the ntsd kernel debugger bug a while back that the patch didn't fix.
Basicly you can still 'own' a network with your garden varity macro virus still.
Hell, I consider it a feature -- you forget your admin password or want to install something by sending a 'macro agent' around the network.
Also don't forget XML+IE+Outlook, DDE, and OLE holes. Btw I never report these exploits I find... I guess BugTraq hates me.
--
Yes, this is why you have to reimage windows so often besides dll hell...
Especially when one considers the fact that a large percentage of network attacks come from disgruntled employees.
So keep your employees happy or don't run Windows!
The race isn't always to the swift... but that's the way to bet!
C'mon, people! This is nothing new. We all should know by now that writing priviledged applications is way different from writing normal user-mode apps. In this case, we have an example of how a poorly written priviledged app that interfaces with a local user might give the local user a chance to escalate priviledges. How is this different from the fact that a poorly written SUID app gives the user a chance to escalate?
Knowing what this guy brought up in his paper, it seems a lot more obvious why you are NOT SUPPOSED TO INTERACT WITH THE DESKTOP AS "SYSTEM" if you are running as a service. This has been common knowledge among Win32 programmers for a LONG time.
The UNIX model has some exploits to which Windows is immune, due to structural/design differences. And the reverse is just as true. If you don't understand the security practices required on your platform of choice, you shouldn't be programming apps on systems that need to be secure.
Time flies like an arrow. Fruit flies like a banana.
You can automate the whole sequence in Perl :
1. Search for windows, paste data : use Win32::SetupSup module - http://jenda.krynicky.cz/perl/
2. Inject code, attach to process for debugging : use wdeb module - http://www.wolf.vigelin.de/mathe/ntcont.html
3. Shatter windows : That is your part ! Happy hacking !
At least we use it for bad behaving install programs under Windows...
if(strlen(funhappytext) > 119) funhappytext[119] = '\0';
sprintf(woot, "%s", funhappytext);
Forcing sprintf out of C would be, quite frankly, so fscking stupid that I'd find and open up several cans of whoop ass on the persons responsible.
Adding new functions would be great. Point out in the manpage that it isn't ANSI compliant, and boom. Why should we delay progress because some standards commitee wishes to?
Carpe diem and so forth.
"I think GNU can pull this off"
HAHAHAhahaha... that's so funny I wet my pants.
GLIBC have had more exploits than anything I can possibly recall, GNU delusions - programming by idiots.
man this dude must feel so stupid right now after making a big fool of himself in front of 250,000 people, haha...
I'm thinking that unix was designed from the ground-up to be a multi-user environment, so for example students could compile their C apps for their CS101 class assignments on their own little shell account, while not being readily able to wreak havoc on the system ...
When microsoft states "If a bad guy can persuade you to run his program on your computer, it's not your computer anymore", this means to me:
are there still easy/obvious ways to root a unix/linux/bsd shell from compiling and running a piece of C code? aside from attempting to kill the CPU, infinite loops, and/or render the machine useless?
Extraordinary Vacations. Exceptional Prices
I.e., something that will not happen. possibly, one might deal with the problem by running the broken apps on a chroot/sandbox "virtual desktop"... i.e., externally impose seperate-priviledges-for-backend-vs-gui.
Then again, the types of bug described in the paper isnt nearly as bad as, say, default Outlook Express :-)
SUV's support terrorism !
A service with no gui can't be exploited by this 'get handle for window and exploit it'-hack, stated in the article.
MS doesn't release services with a gui. Never. All services in windows coming from MS are gui-less, i.e.: the process ITSELF isn't opening a gui. Therefor the user has to open an application, thus it runs under the user's SID, to communicate with the service, via a process-communication scheme.
Never underestimate the relief of true separation of Religion and State.
Since this requires access to the machine (sitting at the console) its not that surprising.
I mean you can get root on a linux box if you are sitting at the console and they are running lilo...
1) Reboot
2) at lilo prompt: [name of kernel] init=/bin/sh
Linux boots, and drops you to a root prompt. Remount the drive as read/write and away you go!
Granted in this case you'd have to find another way to get your shellcode into the priveliged process' address space, but that's not too hard. eg using McAfee you could append it to a virus-infected file, then do a scan and send your WM_TIMER when the 'infected file' dialog box is showing.
Or perhaps I'm talking crap.
You fool, haven'ty you learned anything from them? Start at version number 3, and not .0 becauase people avoid those.
Heres Microsoft Standard Post 2002.
It seems this exploit allows local users
You can still type malicious code with a pencil. Better is to solve the "local" problem: Send the use to the north pole.
Why the hassle with the editfield? As far as I can see, code is being executed with the address space of the security relevant process by receiving WM_TIMER or any other message that accepts callback addresses.
So any method to inject code into the target address space is okay, even writing the exploit into configuration files, registry keys, or sending it in network packages so that it ends up in any input buffer. Just send the WM_TIMER to activate it.
You know, I remember when you could do all sorts of fun stuff with X11. For example, you could layer a transparent window on top of a display, that passed keypresses and mouse events to the window beneath it - and capture everything the user did. You see, most people used xhost for security - which meant that you gave control of your display to anyone who had access to the machine your X client application was running on.
Due to this, we now have xauth and MIT Magic Cookie. Anyone who says a security hole "can't" be fixed is naive - even if the fix is a kludge. MIT Magic Cookie is easily snoopable, so that's another security problem. The X11 protocol itself is easily intercepted, so we have to tunnel over SSH.
I could go on, but I've made my point. Linux users who take it on faith that they are secure are sadly misguided - as are those who believe that Windows is inherently less secure. Ultimately, it comes down to the skill of the sysadmin to secure any OS.
What if the gcc/libc people made sure that the compiler issued big, loud warnings whenever sprintf() and other vulnerable functions were used/compiled? Would that explicitly break the standard?
The man page needs updating too, there is a mention of the overflow potential in the "bugs" section, but it's not explicit enough (IMHO).
Stop the brainwash
This white paper makes several allegations, not the least among which is that there is no way for a user-mode app to mitigate the security risk it presents. This is untrue, however, and appears to be the result of a failure to investigate properly on the part of the author! User mode applications can be rewritten to guard themselves against malicious Win32 message-based attacks. That's because every user-mode app has full say in how every message is handled, contrary to the white paper.
From the paper: "As far as I know, the message [WM_TIMER] doesn't even go into the message queue, so the application doesn't even have a chance to ignore it."
The previous post follows the theme with: "It's like opening a socket for doing basic network communication and Windows API allowing certain pre-determined 'helper' messages to be handled by OS before your app has any say to handling."
Dave at Microsoft did a thorough investigation with the developers who were familiar with the relevant code and replied to the author before he released his white paper (8/5/2002): "It is the implementer of a program that decides what messages to handle and how to handle them."
The author could possibly have arrived at his erroneous conclusion by writing a test app and monitoring calls to a message handling routine when certain types of messages were sent to the app. Observing that a WM_TIMER message sent to the app was processed without the application-supplied message handler being invoked, one might conclude that it is therefore impossible for an application to guard against WM_TIMER-triggered attacks. This test is flawed.
The standard message dispatching pattern you'll find in common Win32 programming books (e.g. "Teach Yourself Windows 95 Programming in 21 Days" by Charles Calvert) and even in sample code from Microsoft goes like so:
No message is processed until the application calls DispatchMessage. DispatchMessage contains special-case logic which handles WM_TIMER and WM_SYSTIMER events *without* invoking the application-supplied message handler, which is why tests similar to the case I mentioned above don't show a call to the message handler for WM_TIMER messages. However, the message will only be processed if the app calls DispatchMessage.
Applications can guard themselves by inserting a (possibly non-trivial) step 2.5 into the pattern above: security filtering of messages prior to dispatch.
So, the basic Win32 thread messaging API calling patterns are flawed when used in situations where applications with different privilege levels coexist on the same desktop. Dave already pointed this out in his email response to the white paper author on 8/5/2002. Message filtering needs to be added to those specific applications in those cases if there is to be any measure of security.
Also, the most privileged service applications (those that run as LocalSystem) can't create windows on the interactive desktop by default, which means that they aren't vulnerable unless someone checks a box that says that they should be! That feature must specifically be enabled (see the "Allow service to interact with desktop" checkbox in the Services UI). Services that run in security contexts other than LocalSystem don't even support the "interact with desktop" functionality.
The conclusion of the whitepaper -- that there is no way to write a service to be secure -- was not proven. The author should have done a better job of investigating his claims before publishing this paper.
This really boils down to a case of poorly written services exposing more "services" to users than they intended to. Several good posts on this /. topic echo that too. At least we've raised awareness.
D
Destroy-Windows-NOW!!!
Watch out when downloading the 'shatter' application!!!!!!! It contains a virus!
a tion: Quarantine
This is not a troll. Check it yourself: This an infected file
Norton reports:
Scan type: Realtime Protection Scan
Event: Virus Found!
Virus name: W32.Beavuh
File: H:\Documents and Settings\Username\Desktop\shatter\sploit.bin
Loc
Computer: MACH5
User: Username
Action taken: Clean failed : Quarantine succeeded : Access denied
Date found: Wed Aug 07 13:26:14 2002
--
who in the world thought XP was secure?!
The win32 reference states that the "WH_GETMESSAGE hook enables an application to monitor messages about to be returned by the GetMessage or PeekMessage function. You can use the WH_GETMESSAGE hook to monitor mouse and keyboard input and other messages posted to the message queue."
Read the reference... SendMessage does not place messages into the thread's message queue. They are not being posted. They are also not being picked up by GetMessage or PeekMessage; instead, the window procedure is called directly.
The beauty of slashdot is that anyone with an opinion counter to the "Linux Rules" mindeset is listed as -1. Unfortunately you can't mod down reality. I'm sure someone could break into your house and do some serious damadge, but if this happened would you say that the maker of your house did a crappy job because you didn't have security?
While there needs to be security, there also needs to be usability. Microsoft has admitted they need to secure Windows and are working on it. Linux is an ancient, outdated piece of crap. What are you guys doing about it? Where's multi-threading in Linux? Oh, that's right. If Linux doesn't have something then it's not needed. How long did it take to get a reliable file system that doesn't cause you to loose your whole hard drive if you have a power outage?
Right now Linux is a confused mess of new and old technologies trying to build on top of an outdated foundation that, while it works, doesn't reach the ultimate goal of making computers easier for people to use. And maybe that's the issue. Maybe noone here WANTS computer to be easier because then you couldn't feel superior to the rest of the world.
-Reality
Windows regularly process thousands of messages per second. Checking each one for security credentials would slow down everything. I would even go so far as to say that on older hardware, when Windows 3.1 was being developed, it would have made the system completely unusable.
Windows 3.1 dosn' have memory protection, so messages are the least of my worries. I can just rewrite code pages willy-nilly, instead of having to be clever and use messages.
We ware talking about fixing Windows as it exists today, and as it is being claimed to be "unfixable".
Unix checks credentials *all over the place*, any time you make a call into the OS.
In Windows, the only place you'd need to check is in the message sending functions, in KERNEL32.
One of those credentials, the sender's is going to be cached, and the receivers is going to be available with an add and a register dereference, since you have to have the queue available to enqueue it anyway.
Also, don't forget that the vast majority of these messages come from the UI, which is connected to a human being, whih is significantly limited in it's ability to generate messages as fast as Windows can sink them.
The major issue would be Winsock's hidden window for asyn WSOCK32 API implmentation. That's not an issue on any version of Windows that uses the BSD stack, rather than implementing it in user space (quick rule of thumb: if you can register a File I/O completion event, then your socket is a file descriptor, and your TCP/IP is implemented in the kernel, rather than in user space).
In other words, it's not a problem.
-- Terry
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Windows\NoInteractiveServices = true
done and done.
The only situation where this will really affect security is the home user. Any situation where this could affect a corporate network.... well... they deserve it then.
The only thing this exploit will allow you to do is root the machine. Big deal, this gives you access to files on that machine, but you already had access to that machine, and in a Domain, local admin access doesn't get you squat. Only situation where it really matters is if the domain admin runs it on a domain controller, at which point he deserves what he gets.
Microsoft: "Security"
Everyone else "You keep using that word. I do not think it means what you think it means."
"Reality is merely an illusion, albeit a very persistent one " -Albert Einstein
you didnt read the friggen article did you buckweat?
It's even easier to fix than that. Only the OS is meant to write WM_TIMER messages to the queue, so Post/SendMessage could filter out any attempts to post WM_TIMER. Simple.
Only if you didn't secure your bootloader like a good little boy/girl. There are measures that can be taken. (Admittedly, none are foolproof.)
Sam: "That was needlessly cryptic."
Max: "I'd be peeing my pants if I wore any!"
It gives you warnings, but it is removable.
im doing a c++ unit at charles sturt uni (www.csu.edu.au) not prestigious by any standard.
we get told, and a subject readings say to use strcpy() and strcat()
what should i be using to copy and join strings?
Being marked interactive is OK as long as they don't create windows (which they don't).
Running Win32 does.
HUGE difference.
use strncpy() and strncat(). This functions let you specify that byte length of the destination buffer, so the function does not write past the end.
// null-terminate the string just in case!!
WARNING! strncpy() and strncat() are still dangerous. If the destination buffer is too small, the string in the destination buffer will NOT be null-terminated! So every time you call strncpy(), strncat(), or snprintf(), you should manually null-terminate the destination buffer just in case. For example:
char destBuffer[20];
strncpy(destBuffer, srcBuffer, 20);
destBuffer[19] = '\0';
cpeterso
How entering data in Entry Field can corrupt executable code ??? Entering data in Entry Field should at maximum corrupt the same Data Segment. NOT the Code segment. What has Microsfot done with protected mode programming ? Fix this and bye bye - Nimds, CodeRed, EntryField exploits.
The 14 platforms would be: ZX81, BBC B (huh?), Windows 3.1, Windows for Workgroups, Windows 95, Windows 98, Windows ME, Windows NT 3.51, Windows NT 4.0 Workstation, Windows NT 4.0 Server, Windows 2000 Professional, Windows 2000 Server, Windows XP Home Edition and Windows XP Pro Edition. And that's not even counting service packs!
Black holes are where God divided by zero
Have you?