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
"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
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.
Why on earth is it crashing? Check your event logs. That should NOT be happening--sounds for sure like a hardware failure.
Here's the output from the "systeminfo" command on my work computer fyi:
Original Install Date: 3/15/2002, 11:24:37 AM
System Up Time: 60 Days, 6 Hours, 36 Minutes, 21 Seconds
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.
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
[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.
This is a huge risk. As any security administrator knows, more security breaches come from within a computer network than from without. Even if computers are locked in a computer room, what about the desktop machines? We currently use profiles to prevent people from installing unlicensed software. But with this exploit, that probably would not be very hard. This is a huge problem in Windows.
Moderation: Put your hand inside the puppet head!
Does this effect Citrix? ...
Morphing Software
You're either full of shit or have some bad hardware in your box. Alternatively, you could just be incompetent or want to join in on the MS bashing with all the others. Either way, BS.
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?
How the hell is the parent post "Redundant"? Is a moderator simply so narrow-minded as to want to slap-down any post which posits an explanation why a system might seem incredibly unstable instead of assuming that it's always Microsoft?
And yes, if it's crashing 26 times in a day, the obvious suspects are (a) bad hardware, (b) severe misconfiguration caused by manually editing the registry, mangling system files, et al, (c) worms, trojans and viruses, (d) a VERY badly written OS (and WinXP != DOS or Win9X...).
Only the dead have seen the end of war.
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.
Terminal access and shared access to a server can be used to perform the same attack on a server from a client. If the Shatter attack is as easy as he makes it out to be, practically anyone could do it within the company fence, for those who install ms on the wire I am not sure what attacks could be performed. If a system on the wire has shares activated or terminal services running, it is only a matter of time before they can use this attack.
A user opens a damn attachment, which you've told them not to do a hundred times, but one of them does it anyway...
No problem right, the attachment runs as that user and the damage is restricted? Only it isn't, because the attachment escalates itself to localsystem privledge and now starts really screwing around.
With any luck it drops itself on the network somewhere and some other soul mistakenly runs it and it gets domain privledges...
Read the article. This is an escalation-of-privileges attack. Very few businesses give every user 'root' on their desktop. Now Microsoft has done it for them.
Envy my 5 digit Slashdot User ID!
Scenario:
- I am a user on a corporate machine. I have very basic access to the machine, ie: I cannot install s/w that requires admin access.
- I install a utility that does not require admin access.
- The utility runs, but in the background raises MY access to 'local System' (read root), using this exploit.
- Now that utility can do anything it wants.
It's the equivalent of a Linux user gaining root access simply by running an app.
- - - - - - - - - - -
I am a programmer. I am paid to produce syntax not grammar. Deal with it.
The fact that it may require an attacker to be physically in front of the computer is the -point-. As others have mentioned, it's a matter of being assigned a certain (low) level of access, and giving yourself a higher level. Sort of equivalent to a local root exploit under un*x.
Think of the "Family Computer". Mom + dad put some content blocking software on it in order to block their son/daughter from accessing some particular type of content on the web. Mom + dad also install, to use the example from the white paper, anti-virus software.
Little billy logs in as himself, uses the shatter exploit to give himself admin privledges, and disables the content blocker.
At least, that's the way I understood it...
(btw, if it was me 15 years ago, I'd probably lock out mom + dad's accounts just for kicks, but that's besides the point.)
A user's ability to crash his or her desktop machine does NOT constitute a HUGE risk, as you put it (especially when considering that it requires binary/hex editors and various other obscure tools that your typical user just doesn't have).
And any competent netadmin/sysadmin will make sure that those same users don't have the ability to run arbitrary code on a server.
I agree that this is a serious flaw in MS's design, but christ, aren't you blowing it just a BIT out of proportion? Seriously...can you think of a single situation where this would ACTUALLY create a real security risk?
Does your mouth hurt? You just got trolled.
Moon Macrosystems. Sun's biggest competitor.
It doesn't really require someone to be sitting at the console.
Socially engineer yourself a login and hijack the machine remotely via Terminal Services (or Remote Desktop Connection, which is ENABLED by default in XP). Owie.
Yes, clueful sysadmins or netadmins will make sure that port 3389 (IIRC) is firewalled, but there's lots of admins that are either not clueful or overrided by a PHB.
Don't believe me? Check with a sysadmin running a web server. Ask them how many Code Red or Nimda hits they still get per hour.
Pax, Ardax
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.
Jerk. (it crashes for me too)
Policies? I remember a handy little program that would reset a system's policies and prevent them from being pulled from the server at next boot.
:)
I've probably still got it sitting on my hard drive somewhere. I don't know if this will still work XP, or even 2k. Should I ever get the opportunity again, I might check.
Pax, Ardax
Bull. Local exploits are just as important to avoid as remote ones. Anyone who thinks otherwise has their head in the sand. Ignoring the proliferation of remote exploits on the Windows platform, the fact is, people want to run multiuser systems on Windows-based networks (why do you think Microsoft rolled TS into their main product line? To promote this very thing!) And the minute you start allowing multiuser access like this, local exploits become a real concern. Imagine you're running a University using TS and a bunch of thin clients, and you happen to have a cracker enrolled in your program? The point is, in this sort of environment, you CAN'T trust the user, and so you can't take the chance that a local exploit could leave you vulnerable.
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.
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.
Sure, you can't run unauthorized software on the servers. But what about fun stuff like packet sniffers and the like? Remote exploit tools? I could go on. The fact is, there's a TON of malicious code you probably don't want a regular user to be able to run from INSIDE your network.
Actually X doesn't care where the clients come from. This is a similar situation to X events. However X11 is more secure because you can tell when an event is synthetic (made by another client) rather than one generated by the trusted server. However, you can't tell which client made the event... there is no ownership or authentication scheme for events. However you can deny clients the ability to connect to the server even if they are on the same system (MIT magic cookies).
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.
Depends on what you mean by "bad hardware." If you mean hardware that XP hasn't been well designed for, you may be right. I have had similar problems, specifically, an external serial modem that XP loses track of when I reboot, and a SCSI card it intermittently loses the driver for. I haven't had the kind of constant crashing I had with 98SE--but considering how long this series of OSes has been around, that's not saying very much--and I do have to reboot every now and then because it loses track of the location of the IP address server. Don't even get me started on why they rewrote the USB part of the OS so every USB equipment manufacturer had to extensively rewrite their drivers.
Get back under your bridge.
Hic iacet Arthurus, rex quondam rexque futurus.
FWIW, mirror at http://paginar.net/matias/shatter.html.
Yes, it is. The implication is that an authorized user, without administrator access, could be the victim of a Trojan of some kind. This in turn could compromise the whole box. Even the parts that the orignal user didn't have access too.
Any system is potentialy vulnerable to local exploits (ex local ssh exploit). They are usually not this easy to implement, however.
I've got news for you: local priviledge escalation exploits are still exploits.
Sure, it isn't as serious as a remote exploit. However, if you take the stance that once a user logs on to your system then you are 0wned, you don't have a real multi-user O/S. What is the point of having multiple user accounts with priviledge separation if you don't fix local exploits? Would you give every user on a system you admin root (Adminstrator) privs?
The fact that Microsoft is dismissing a local priviledge escalation as "not a problem" just tells me they still don't understand how to make a real multi-user enterprise O/S.
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
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
Here's a thought. Read the article.
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.
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 :-)
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
It isnt necessarily an exploit, as he explains in his vuln-dev post: This is not a bug. This is a new class of vulnerabilities, like a buffer overflow attack or a format string attack. As such, there is no specific vendor to inform, since it affects every software maker who writes products for the Windows platform. A co-ordinated release with every software vendor on the planet is impossible.
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
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.
I knew it was bad, but holy schnidt.... good thing I'm running Linux and OS/2. =^_^=
This sig no verb.
completely agree. nearly ever XP and 2K blue screen i had was due to:
1) faulty hardware, e.g., bad memory chip
2) incredibly bad driver (which admittedly shouldn't crash the OS... but that's another discussion)
3) incredibly, incredibly bad software (which again shouldn't crash the OS... but that's yet another discussion)
MORTAR COMBAT!
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?
bah. thats nothing.
check mine out.
Original Install Date: 2/1/2000, 01:42:37 PM
System Up Time: 700 Days, 8 Hours, 4 Minutes, 15 Seconds
C:\> ver
Windows 98 [Version 4.10.2222]
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?
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.
Actually the attack seems to involve getting a handle to a window running in a process with higher privledges, which is trivial in windows. There is a nice function call WindowFromPoint that given a point on the screen, it returns the window handle under that point. After I have the window handle, a simple call to GetWindowThreadProcessId will give me the thread and process id that's in that window handle. After getting the process id, it's not that much more difficult to see what the userid/security class of the application is.
My point is that there doesn't have to be any user interaction at all, and that the program can determine which windows have a higher priority and escalate their privledges via this exploit. Also, it's not all that difficult anyways to just iterate through all the toplevel windows in the system (via the EnumWindows function) and check them that way instead of using WindowFromPoint.
Things you think are in the Constitution, but are not.
It is unfixable because it would require to change an API used by... All windowed windoes applications.
I'd rather be sailing...
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
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.
Perhaps I wasn't clear. What you are saying is not my point. I mean that when you're using Windows, all Windows are yours by definition, since it isn't really multi-user, so the 'vulnerability' point is moot.
Install in this case means copy a file to some place where it can be executed. This would include on removable media like floppies or cdroms.
Can you really prevent people from running any executable other than the ones you intall? I suspect that you cannot.
Remove floppy drive, disable floppy drive in BIOS and then password it, or simply configure the ACL to not allow floppy or CD access for anyone who is not an administrator.
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?
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
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.
In MANY networked windows environments, the network admins do not allow end users to have administrator right on the machines on their desk. The network admins, typically MCSE's, perform a variety of admin tasks using automated tasks (either login or chron based) at an elevated permission.
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
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.
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?
Scripts to drop in a Domain Admin's startup folder and own a Domain are already preset in the wild. The tough part is putting them there, because you already have to own the box... using this, it's not bad.
Put those two together, along with the tunneling trick we saw in an earlier article, and suddenly you're tunneled in to a corporation's domain controller as a Domain Admin... and from there the sky is the limit.
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.
The windows aren't yours by definition because if you're an unpriviledged user, and Virus Scan(from the article) is running as a priviledged user, you can hi-jack that widow and execute arbitrary code(as stated in the article).
Jesus saves and takes half damage.
What I liked was the response from microsoft. This program violated one of their 'laws' (of secure computing I guess) and therefor it doesn't count.
According to that philosphy no security holes count...
Man it must be nice being omnipotent. There are numerous reasons for this, maybe it was just one of the 20% of M$ boxes that improperly install for no apparent reason. Personally I kind of like WIN2k (*ducks*), but there are loads of issues that can cause the system to be very unstable, from OEM patch problems, to software driver incompatabilities, to of course as you mentioned an Ignoranus running the machine. I've seen disk rom cause XP to fail when trying to write a full buffer, which took more than 2 months to surface, and many hours of tracking down.
errr....umm...*whooosh* *whoosh* Is this thing on ?
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.
Get real. 26 crashes a day is not even anywhere close to being the truth. I run Linux, *BSD, and various windows and never have I had any of them crash more than 5 times a day. Even then it was a faulty app or hardware. Troll!
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!
Well, not exactly: X11, by default, does not allow other users to connect to a X server running by other users. You have to do either "xhost +" or "xauth add ..." to allow other users, so X11 is not a problem.
MacOS X does not allow other users to connect to the Display server at all. It's done via Mach messages, which are read/write for the specific user running the UI server only.
Lenny Primak PP-ASEL-IA,Heli
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?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
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?
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".
Every blue screen on win2k pro I've ever had was a direct result of an ISAPI filter apparently crashing the kernel.
I'm not kidding. I was developing the filter, and in its early stages, it had memory leaks, dangling pointers, double free()s, etc. Blue screens! By killing the web server! Wow!
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
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.
Every blue screen on win2k pro I've ever had was a direct result of an ISAPI filter apparently crashing the kernel.
:)
your first mistake was using a kernel-privileged web server (IIS).
I was developing the filter, and in its early stages, it had memory leaks, dangling pointers, double free()s, etc.
your second mistake was writing bad code.
but i'll agree that writing bad code shouldn't crash the OS. but when you're developing on windows, that's the modus operandi (sp?). but who am i to kvetch? i learned my C code on UNIX, where i got segmentation faults, bus errors, all kinds of evil crap, and the program terminated, and the OS chugged along.
but try playing a bit with framebuffer programming on linux, and see how fast you bring down the OS
MORTAR COMBAT!
There's always copy files over the net, over ftp, from email. From a command prompt, you can use paste (copy con go.exe) over a terminal services client. There's a basic telnet session, there's the ability to share files. You could use Word to import a "Gif" file. And I know nothing very much about this stuff. I'm thinking that if somebody really wants to get a file onto a machine, they can. The question is (And I'm pretty sure you can do this unix) is whether you can stop people executing files which are downloaded into a user space.
Training monkeys for world domination since 1439
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....
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....
This is not a commentary on XP's stability. I wouldn't know (and I have trouble believing 26 re boots in a day... that's insane). I just find your argument a little bit disingenuous.
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.
My brand-new Sony Vaio laptop crashes frequently
*on bootup* with a blue screen of death.
Its running XP home
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
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
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.
on 98? ahem, *COUbullshitGH*
Jeremy
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
copy con foo.exe
MZ[lots of alt-numberpad typing, hope you don't need 26]
^z
foo.exe
Windows doesn't even need chmod +x
Bill - aka taniwha
--
Leave others their otherness. -- Aratak
--
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.
So you think it's unfair to blame Windows when the exploit is in the default behaviour it gives you when you do nothing about one of the GUI messages?
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
I can get the program into my home directory by emailing it to myself. Save attachment and run it from there.
There are lots of ways to get information from there-to-here.
If you're a zombie and you know it, bite your friend!
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.
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
No, his first mistake was running IIS.
The second was running an internet-visible server on Windows.
*shudder*
I'm a big fan of Windows workstations. They let you work quickly and get the stuff done that needs to be done. However, the need for user friendliness isn't there with servers. A server should be run and maintained by someone who knows what they're doing, both in the arenas of security and optimization. Running a webserver on Windows is somewhat indicitive of a lack of both.
I in no way, shape, or form advocate, condone, or approve of Windows servers. Not good.
I'm not a Windoze expert, but, I'm guessing that device drivers run in kernel space, whereas apps run in user space. It's understandable that something in kernel space can take down the system. Device drivers have a higher standard to meet than regular apps. It is, however, never even kind of okay for something in user space to be able to take down the system.
...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.
If you could in properly configured setup with good hardware make even WIN95 or DOS crash 26 times a day, I would be very impressed.
Unless you count letting crappy software crash the OS as an OS problem.
I used DOS for autocad and still do sometimes (version 12), and it is very stable, even when running a TSR cd player in the background.
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
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)
Yes, quoting one of the more sensible /. readers:
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.
"Karma can only be portioned out by the cosmos." -Homer Simpson
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.
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?
It's not really fair to say that the OS can prevent bad drivers from crashing the system - there are many cases in which misprogramming the hardware will cause problems that the OS can't reasonablly avoid. For instance, lots of DMA or bus-mastering devices don't know about the memory virtualization, so they work in the space of physical addresses, without protection.
Trees can't go dancing
So do them a big favor
Pretend dancing stinks!
Comment removed based on user account deletion
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
Glad you said 'nearly'.
One of our 2K server went blue after migrating to Athlon-MP. We had similar experience migrating NT to different hardware platforms.
And the hardware in question are hardly faulty. Well, is it our fault to migrate system to new hardware in the first place? I don't know.
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.
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
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!
Why shouldn't bad drivers crash Windows? They crash pretty much every other OS. My computer (which is 100% Linux) crashes sometimes due to a bad webcam driver.
...both in the arenas of security and optimization.
I cant comment too much about IIS but I have developed ASAPI with IIS and thought it was very optimized. Flame me if I am wrong but I think ISAPI is an optimized technology (my book certainly said so and I understood it as being optimized).
Pixels keep you awake!
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"
If I had to reboot 26 times in a *year*, I'd wonder WTF was wrong with my box. That said... when I first installed WinXP, it had (count them) *30* logged background crashes in the first six hours of operation, only two of which were presented to me as visible events. (Don't blame my hardware, that same machine dual boots WinME which has not crashed ONCE in almost two years now. An identical machine runs Win98 24/7 for weeks at a crack, and *never* crashes.) After the HD took a crap and was replaced, I had to reinstall XP.. this time it installed 600mb more files in \system (wtf??!) and has had a grand total of two background crashes (logged but not user-visible).
:)
Anyway, occurs to me that if this guy's system has something screwy, like bad RAM or a buggy CPU or a crappy chipset, could well be that background crashes (normally disposed of transparently by XP) are being expressed as BSODs instead. (I *have* wondered what these background crashes do to memory, tho..)
I have four active WinBoxen -- the two above and two Win95 systems -- and I doubt if they've had 26 crashes in their combined total lifetimes, even tho WinME and the older Win95 box (which has *never* crashed in the year or so I've had it) are used to test every sort of crap. Amazing what sound hardware and drivers (and NOT installing M$Office, which is Windows' worst enemy!!) does for stability.
~REZ~ #43301. Who'd fake being me anyway?
Please read the post before trolling--3/15 was the original install date.
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
700 dayes without installing any programs and having to reboot to update the registry (or whatever happens)? Impressive.
Pixels keep you awake!
your second mistake was writing bad code.
Uh-huh. STFU -- I suppose that all of your early code in a new project is perfect. Are you really serious?
After all, now that I'm finished with it, it works, no memory leaks, crashes or anything -- running on production NT and Win2k servers (pays the bills, even though I want to gnaw my hands off some days) for about six months now.
But, of course, I am a total moron for doing a double free() anywhere, ever, regardless, right?
Gone are those heady days when you had to be REALLY CAREFUL, or your application could hose the whole operating system and crash the computer. Ah, those thrilling days of Windows 1.x, 2,x, 3.x, 9x, 2000, er... yeah, where you make any little mistake with memory, or locks, or pointers, and you're watching the BIOS POST again... uh-huh...
I didn't think that any part of IIS was part of the kernel in Win2k. But I have trouble explaining why a bad pointer access in an ISAPI filter blue screens the OS, other than... there's some kernel stuff happening there! I wonder if the buffer and ISAPI filter gets handed is kernel memory...
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
Of course, the owner's manual states clearly that the button should never be pushed while the vehicle was in motion.
So, you just blithely moved your NT install from one PC platform to another, without re-installing? If I'm reading your post wrong, please ignore the advise below.
If you *did* do what I surmised above, I take it that you've never heard of NT's Hardware Abstraction Layer (HAL)?
If you move your installed and functioning NT Harddrives, etc to a new hardware platform, be prepared for continual BSOD's - the HAL provides a uniform set of hardware interfaces to the OS kernel and services - and there are differences enough in motherboards and CPUs that simply moving your HD's to a new mobo and CPU will cause you nothing but pain until you COMPLETELY RE-INSTALL NT/Win2K.
ScottKin
I don't give a rat's behind about "karma" here or anywhere else. Don't like what I have to say here? Deal with it!
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.
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.
Yes, DOS is very stable by itself(who has ever seen a C prompt stop responding for no reason?), because there is so fraggin' little to it! Basically, it gives the coders disk access, XMS and EMS, and jumps out of the programmers way.
:)
:P
That's the reason I like programming for DOS, incidently,
mmmmmmmmmm....real-mode...
It's been a long time.
Win2k was very happy on this hardware - XP is crashing four or five times daily - with purely MS applications and the most recent drivers.
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.
Only a similar problem. Unless there's something dire about xlib that I've forgotten, POSIX systems don't tend to bundle user interface libraries that accept messages from any user, interpret a field as a function pointer in the server's address space, and immediately call that function whenever the app doesn't specifically overrides that behavior. That's somewhat exploitable even if you don't have a buffer overrun to take advantage of.
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?
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.
Troll for this. I have suddenly had the same problem. An XP system that was reasonably stable, if very slow to boot up, suddenly blue screens all over the place, with various error message such as IRQL_LESS and something about POOL memory being release twice. It wouldn't even run in safe mode. Tried booting it up with the rollback to last stable configuration option, and it appeared to become stable again. Thought it was a hardware problem it was so bad. Perhaps one of those patches it downloads for you was a dud. Anyway, Can't say the previous post was a troll based on my own experiences.
Microsoft - Where would you like to go today, Maybe Jail?
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 !
I know that that is the recommendation from MS. The difference of opinion is that you think telling programmers to not use it absolves MS of responsibility for their insecure GUI. I do not. If an application fails to jump through the reccomended hoops to avoid the flaw in MS's default behaviour, that doesn't magically shift the blame to the app. Note the word "default". It's very important here. The bug is what surfaces if you *don't* do anything special in your application program. If I burned a CPU chip that had a flaw that started the chip on fire whenever you execute an illegal instruction, it would still be my fault, even if I say "please don't have illegal instructions" in the programmer's manual for it.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
hmm, mod parent up.
once again, tho, i want to point out that escalation-of-priviledges doesnt seem quite as bad as automatically execute any code that is emailed to you, a-la Outlook.
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!
-- james
Unless you count letting crappy software crash the OS as an OS problem.
Well crappy software crashing the OS is an OS problem. If you mean crappy drivers crashing the OS, then that would be different.
However, I have easily crashed Windows 9x > 30 times a day. It's very easy - just try and debug an application with a particularly type of bad pointer reference in it which you accidentally create every so often. Your computer is almost guaranteed to crash in less than 10 minutes of running the debugger.
use Win98, and of course, those security updates don't work very well unless you have a firewall, so why not give them win98 and teach them how to use zonealarm?
p.s. not to sound RMS'sh but showing people how to use linux for basic chores (i.e. show them to that elusive source of aid called man pages) would save them from Palladium in the future
p.s.s. anyone knows if MS can enforce Palladium and DRM on countries not in the US export ban list?
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
> However, the need for user friendliness isn't there with servers.
This, of course, is not true. Servers also have to be maintained by mortals. Userfriendliness is always needed. BUT: servers are supposed to have an other kind of user though and as result an other kind of friendliness. Basicly, server admins are supposed to have a clue and a well documented text config file is a wonder of friendliness as far as I'm concerned. I can use search, search and replace, spellcheckers, grep, etc. etc.
Nobody expects the spanish inquisition!
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.
Actually, I have, and it doesn't work. From what I've read on Usenet, it doesn't seem to work for anybody else, either. Just more useless "Windows technology." I did notice that the losing-the-modem problem didn't happen when I accidentally hit the reset button instead of the fan speed control and it rebooted after checking the file structure. Windows is still as quirky as ever. The quirkiness is just more deeply buried now. Now if it would just STAY buried.... ;o) Maybe I could try driving a stake through its heart. :O)
Hic iacet Arthurus, rex quondam rexque futurus.
I don't think it's a virus *per se*. It's just shellcode
which your anti-virus software probably matches to the
signature of a known virus.
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.
Troll - win98 counts its uptime as milliseconds, so it can't report an uptime of over 2^32 milliseconds (less than 2 months)
So your AV is doing its job properly. It doesn't know that you actually *want* that exploit.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
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
bzztt.. sorry Buckwheat, Kaspersky AV doesn't detect a virus. Likely Norton sees Evil 3l337 sh3ll c0d3 and gives you a false positive.
Trolling is a art,
PLEASE NOTE: Some virus scanners are alerting people to the presence of a "Win32/Beavuh" virus within the sploit.bin file in the Shatter zipfile. This is not a virus. The scanner is correct in flagging it - the code in this file is designed to open a command shell and bind it to a network socket. This is a bad thing to do in general, so the scanner is correct in generating an alert. This code is designed to be malicious in terms of its functionality, but the scanner is incorrect when labelling it as a virus.
So, it looks to the virus scanner to be a trojan horse, and the antivirus is smart to see it -- but in this case you want it.
"Giving money and power to government is like giving whiskey and car keys to teenage boys" P. J. O'Rourke
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
I'm no MS basher, but I have experiences similar to all those who are saying XP performance and reliability seem to be degrading w/ each new update. At first the problem was that my Athlon processor was overheating, but now I'm running around 80-84F (26-29C). That should be cool enough, right? Why am I still getting the BSoD even while just running the desktop? My system startup time is also take MUCH longer (and that was one of the things XP was supposed to be so great about). Based on your experience, it seems possible to configure a stable system. So, what's your secret?
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!"
thank you.
MORTAR COMBAT!
i guarantee that when you're using IIS on Win2K, many of the messages get tied up in the kernel. hence the BSODs you get using bad filters on IIS. otherwise, the bad code would just halt IIS, now wouldn't it?
MORTAR COMBAT!
It gives you warnings, but it is removable.
Being marked interactive is OK as long as they don't create windows (which they don't).
Caps in subject: check
Abuse of exclamation points: check
Claim of authenticity: check
Misinformation: check
A nice effort, but I have to deduct points for the omission of "Forward this to everyone in your address book!!!!".
Anyone who has used both Windows and Linux will probably agree with me - Linux is harder to use out of the box, but it's much more powerful, much more secure, and much more suited to an environment that will be under constant attack.
the point he was making was the writing bade code shouldn't bring down the OS. don't be so damn defensive that you can't read the words in front of you.
You're right. My bad. Sorry, everyone! Sorry! Won't happen again...
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
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
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
Thank you I am grateful for your keen eye.
Namaste