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!
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.
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!
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."
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!
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.)
If all this should have a reason, we would be the last to know.
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.
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.
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.
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.
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.
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
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.
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
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!
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.
... 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.
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.
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.
I agree that secured platofms are important. Personally, though, I disagree that Dot Net is a panacea. It is possible to write insecure apps in any language or platform, and I can assure you that some .NET apps will be given admin privs.
As long as we programmers don't make security a priority, we will continue to have badly written apps.
You know... I usually don't defend Microsoft very much, but I guess all the "ARGH! The sky is falling" stuff got to me.
-- IANAEG - I am not an elder god.
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?
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!
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
then Dotnet will be in place and the party will be well and truly over.
yes and no. MS will (probably) eventually bring down the number of security bugs (though with their insistence on features,features,features and their gratuitous changes to APIs and protocols used to foil competition, it will never be 0 or even real low), but the real problem with Microsoft is not the stuff they do accidentally, it's the stuff they do with full knowledge and intention.
For example, if your files are in some proprietary format and you lose the right to run the software that reads that format, who owns your data? Before you scoff, remember that MS was one of the drafters and promotors of UCITA, which would/will permit software manufacturers to turn off software that they believe is not licensed correctly. (aka "electronic self help" - there are numerous ways to accomplish this even if you're behind a firewall.)
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
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.
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.
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 ?
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.
Good point, but it's perhaps a little optimistic to assume that Linux will have this edge.
If MS provide the tools someone else can easily finish the job, e.g. providing a secure email program with workflow scripting, without imposing nasty stuff like proprietary file formats.
I wasn't speaking of your "Sky is falling" remarks but of those of others who feel that this vuln represents something new and terrible on the Windows front.
As for DotNet, as much as I like C# (after working in it for almost a bloody year now) and appreciate the easy things being easy and the hard things being possible, I'll withold judgement on it's securability until it's been around for a few years.
-- IANAEG - I am not an elder god.
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!
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.
Dotnet (and Java) represent a quantum leap in the "securability" of a platform and one to which Linux has no answer
.Net is being implemented on Linux, so we can use the same answers. Also, User Mode Linux lets you run a full environment in a sandbox, with no modification to existing programs. That's better than anything Java or .Net offers.
Well, Java runs on Linux, and
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.
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.
and
Dotnet (and Java) represent a quantum leap in the "securability" of a platform and one to which Linux has no answer
I would like to point out that Java runs just fine under Linux. The Mono and DotGNU projects are in the works, both of which will be answers to .NET . You are assuming .NET will live up to Microsofts hype and that Linux will not improve over the next 2-5 years. The past has shown, that Linux is constantly improving and that Microsofts products never live up to the hype. Microsoft has spent the last 5 years playing catch up to Linux in security and stability. They are still at least 2-5 years behind in both of these areas and I don't see this changing anytime soon.
"Our products just aren't engineered for security,"
-Brian Valentine,VP in charge of MS Windows Development
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!
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....
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.
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
I was hoping someone would step in with these assertions - it's really time such complacency was examined:
1. Java runs on Linux. So it does, and will be well supported not by one product but by three (Sun JVM, IBM JVM, BEA JRockit). What a pity, then, that this commitment by the vendors is not matched by the Linux community at large. No significant GNOME or KDE application is written in Java, and KDE does not even have a LGPL Java binding!
2. Dotnet "being implemented" on Linux. Coincidentally, starting this morning, Dotnet is being implemented by me on my toaster, and I can say with confidence that with regard to the major APIs such as Windows Forms, both efforts have made similar progress, i.e. none. And if Mono / DotGNU does make progress, I'm betting they get sued for patent infringement.
3. User mode Linux 'superior' to Java or Dotnet. This is, frankly, a ridiculous statement. Firstly, Java and Dotnet provide guaranteed integrity of the application, something that's impossible to achieve when you have pointers floating about. Secondly, the rest of the system can be structured into a highly organized form where just the necessary amount of information is shared and rights given. For example, I can apply access controls to individual methods of an application, but a particular application may not itself even be able to read those controls, so it has no idea of who can do what.
The problem is really the same one that has bedevilled Linux already - choice is good when you can make it (KDE or GNOME), not so good when it is made for you via a chain of dependencies (Kmail requiring KDE requiring Qt). Coordination and control applied only to the kernel is no longer sufficient to warrant Linux being called a platform - unless enough momentum is built up behind some combination such as Kernel + IBM VM + SWT + Qt + KDE the platform will become so diverse and complicated that vendors will be unable to port their applications to it.
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
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.
User mode Linux 'superior' to Java or Dotnet.
This is, frankly, a ridiculous statement.
If you're asking for a platform to be secured, I can secure any program that runs on Linux using UML. UML allows you to use existing libraries and code, without breaking the sandbox). That's a huge advantage.
Firstly, Java and Dotnet provide guaranteed integrity of the application, something that's impossible to achieve when you have pointers floating about.
Nonsense. Having pointers does not prevent you from guaranting integrity of the application, nor does not having pointers mean that you can't get invalid data or malformed data structures. The only way to guarantee integrity is a formal proof of the program. In any case, Perl, Python, Scheme, Eiffel, Common Lisp and any number of other Unix programming languages make the same offer.
Secondly, the rest of the system can be structured into a highly organized form where just the necessary amount of information is shared and rights given.
Which can be done without Dotnet or Java. And frankly, I don't believe it will be done by any but the most anal programmers, and they could have done it in raw assembly on the bare hardware.
And THANK YOU very much for linking to e2. I'll be clicking around there for a good 2 hours now, thanks for killing my productivity.
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
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.
I think you're failing to distinguish between fundamental architecture principles and gossip.
Dotnet does protect against viruses - it allows precisely the appropriate level of privileges to be accorded to something like an email attachment. There may continue to be exploits, but unlike existing systems suffering from buffer overflows etc. the exploits can be fixed in the platform rather than the applications. A secure platform is a whole new ballgame over POSIX and Win32.
XP's own exploits are no more relevant to Dotnet than they are to Java - Dotnet has its own security model, and it is perfectly possible to put a secure environment on top of an insecure one, providing that the secure interface is the only public one.
You still seem to be confused about what a secure platform does. Essentially, Microsoft can ship you any 'binary' and you have the power to limit what it does (TCPA lock-downs excluded, of course - use Java as an example if you prefer). Therefore the issue of backdoors in an app need never arise - just deny it permission to open a socket.
On a positive note, I agree that having the source is the ultimate guarantee, though ideally you want both the source and a secured platform. The amazing thing is that Java has achieved this and put it on a plate for everyone - it's almost impossible to ship a Java application without allowing the source to be recreated - but still people persist in generating user applications with antedeluvian C tools. Java technologies and Open Source goals complement each other in fundamental ways, but the importance and potential of this has never been recognised.
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.
Comment removed based on user account deletion
If you're asking for a platform to be secured...
No, I'm asking for the whole system to be secured. That's where your approach comes unstuck.
Having pointers does not prevent you from guaranting integrity of the application...
You're using integrity in a much broader sense that most people do, particularly with regard to common security exploits. The advance that Java represented over traditional code models has been documented at length by academics - no other language in common use comes close, certainly not Perl, Scheme or Common Lisp.
The bottom line is that Java and Dotnet offer a a value proposition that no security-minded developer or user can afford to ignore, and for practical purposes no amount hand-waving about formal proof systems is likely to deliver anything remotely comparable.
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
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
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)
"fundemental architecture principles" are something that Microsoft has never cared about. They even had the architect of VMS on their side and they still failed to deliver a robust product. All of Microsoft's propaganda won't erase the last 20 years of their management practices.
There is far more than mere "gossip" supporting those of us that are skeptical of anything that Microsoft creates.
It would be more efficient to simply resurrect VMS.
A Pirate and a Puritan look the same on a balance sheet.
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
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?
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
Sounds great!
Remind me again, this delivers precisely what benefits over using the well-established Java VMs on Linux?
1) Deliver high media profile for Miguel de Icaza
2) ?
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.
You forgot
3) Profit
It had to be said...
Enigma
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!
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.
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.
I don't doubt your experiences, but I've also heard that some of the WinDrivers for the Sony Vaio series suck to the point that you can't expect stability if you're using them. However with fully updated BIOS and drivers, there's no reason to expect Windows to misbehave on that system -- unless it's a model that has some flaw that tickles Windows but not linux.
As an example (albeit in the opposite direction) in my collexion I have a buggy 486 CPU that runs Windows just fine, but throws up all over OS/2 Warp3, and also pukes on some 32bit DOS programs -- and tho I've not tried it, I'd bet it would refuse to play with linux.
~REZ~ #43301. Who'd fake being me anyway?
He makes a valid argument against Microsofts track record of producing software that does not work as promised, while you have trouble spelling simple words, HMM who am I going listen to.
BTW, it is spelled STUPID
Fascism should more properly be called corporatism, since it is the merger of state and corporate power - Benito Mussoli
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.
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.
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.
Windows NT/2000/XP all have problems with applications running at 'System' or another level below 'Administrator' ( root ).
For example:
1. Setup a win2k box with a user, and make it so that this user can only run the app MS Word using your little GUI profile editor.
No write access to drives, no shell, etc.
2. Log in as that user.
3. Now run MS Word and...
Press Alt+F11
Press F5
Enter "wolf" as the procedure name
Enter "Shell "cmd.exe", vb.normalfocusfoo"
Press F5
Now using commands like 'control userpasswords' you can fuck up your nice little system.
Also using command.com ( 'NT DOS' ) with your macros you can get beyond kernel rescrictions, which is like the ntsd kernel debugger bug a while back that the patch didn't fix.
Basicly you can still 'own' a network with your garden varity macro virus still.
Hell, I consider it a feature -- you forget your admin password or want to install something by sending a 'macro agent' around the network.
Also don't forget XML+IE+Outlook, DDE, and OLE holes. Btw I never report these exploits I find... I guess BugTraq hates me.
--
Yes, this is why you have to reimage windows so often besides dll hell...
Especially when one considers the fact that a large percentage of network attacks come from disgruntled employees.
So keep your employees happy or don't run Windows!
The race isn't always to the swift... but that's the way to bet!
C'mon, people! This is nothing new. We all should know by now that writing priviledged applications is way different from writing normal user-mode apps. In this case, we have an example of how a poorly written priviledged app that interfaces with a local user might give the local user a chance to escalate priviledges. How is this different from the fact that a poorly written SUID app gives the user a chance to escalate?
Knowing what this guy brought up in his paper, it seems a lot more obvious why you are NOT SUPPOSED TO INTERACT WITH THE DESKTOP AS "SYSTEM" if you are running as a service. This has been common knowledge among Win32 programmers for a LONG time.
The UNIX model has some exploits to which Windows is immune, due to structural/design differences. And the reverse is just as true. If you don't understand the security practices required on your platform of choice, you shouldn't be programming apps on systems that need to be secure.
Time flies like an arrow. Fruit flies like a banana.
You're using integrity in a much broader sense that most people do, particularly with regard to common security exploits.
Shell scripts have no pointers. Shell scripts are bitch to make secure, because every line you have to make sure that there's no stray ` or $ in your input data that you aren't properly escaping. Any language that only has or encourages the use of fixed length strings has a potential integrity problem there.
The advance that Java represented over traditional code models has been documented at length by academics
What advance? Sandboxing is certainly nothing new, nor is pointerless languages, and many Lisps follow both rules.
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 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.
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.
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.
But Code Red and friends still propagate. Seems like Microsoft's idea of security has some problems.
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.
Yes, but which party?
These is something of a progression of Melissa to Code Red and Nimda to Klez. The worms and viruses are getting smarter and Microsoft still doesn't have a clue as to security.
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
Microsoft has spent the last 5 years playing catch up to Linux in security and stability. They are still at least 2-5 years behind in both of these areas and I don't see this changing anytime soon. ...".
.NET will live up to Microsofts hype
And Linux is maybe 2-5 years behind the *BSDs.
OpenBSD: "One remote hole in the default install, in nearly 6 years!" (And that fish looks mad;) Methinks that is actually a stronger statement than when they were running "No remote holes
You are assuming
No matter how good a job Microsoft does, it's a monoculture and there's always a crack somewhere. Linux does not have that problem because there's a bunch of subtly different ones out there and there's always a few wiseacres who insist on doing things their way. Security through obscurity can work, but it does presuppose obscurity. A monoculture is *not* obscure.
Therefore the issue of backdoors in an app need never arise - just deny it permission to open a socket.
Right. Close one hole and ignore any communications with apps that DO have permission to open a socket.
Security is a perimeter-type thingee. There is no "just" about it.
The only way to guarantee integrity is a formal proof of the program.
It's funny you mention that.... that's exactly what the .NET runtime does - it effectively proves the program doesn't violate any security or integrity restrictions before it allows it to run. To be able to do this programmatically requires heavily restricting the use of pointers.
And yes, you can write a program that uses pointers in .NET - but such code is marked as 'unsafe' and requires special privileges to run.
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,
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!
And Linux is maybe 2-5 years behind the *BSDs...".
I am 100% in agreement with everything you said. Linux security does leave something to be desired when compared to *BSD and I encourage anyone who has serious concerns about security, should use *BSD. Microsofts biggest security problem is the monoculture they are trying to force on everyone, if they would back away from thier monopoly and allow a diverse computer environment to develope, things like VB Script virus's would be a minor annoyance instead of headline news.
"Our products just aren't engineered for security,"
-Brian Valentine,VP in charge of MS Windows Development
Not really - in some cases (subclassed windows, for example), a control's window procedure might want to trap a message, and then re send it.
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