A recent white paper suggesting that an architectural flaw exists in Windows has generated interest in the press and on security mailing lists. While some of the report’s findings are correct, its core assertion – that there is an architectural flaw in Windows – is inaccurate, Microsoft says. The Microsoft Security Response Center has thoroughly investigated the report’s claims, and they would like to provide information about our findings and the planned future steps.
Information About Reported Architectural Flaw in Windows
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Gee, MICROSOFT said that MICROSOFT’S product didn’t have an architectural flaw. What a surprise.
Who would have thought that the company that bullies competitors, got investigated by the Government, and copied Apple’s (or is that Xerox’s) ideas would say that their super-insecure OS is, in reality, fine?
In other news, the sky is up. Water is wet. Film at 11.
It’s been a while since I’ve done any win32 programming, but the API hasn’t changed much… I read an article about this flaw a while back, and it just struck me how obvious the problem is. You have GUI (which becomes more of an OS extension in windows) that relies heavily on message passing… yet has no authentication system whatsoever for those messages. And to put the icing on the electric chair, there are messages that pass around pointers without any safety.
This articly by Microsoft effectively dismisses it as being a nonissue. Sure, what else are they going to do?
I think i’d have to side with Microsoft on this one. The report shows more of a flaw in the services installed with the virus scanner than anything else. Just like buffer overflows, programmers have to cover their ass on this one too. While i do concur its a security risk, i do agree that the system has already been compromised via security messup if someone got that far in the first place.
MS does need to get someone besides themselves to verify and/or examine it, just for the sake of credibility. If i were on the outside and didn’t know any better, i’d have agree’d with the two nuts above me. Is there money in company bashing? You’d think it was the highest paying profession if there is.
The “Shatter” attack is not a major threat, because it requires full unrestricted access to the console. Damn near any OS is vulnerable in that situation.
However, when you combine the insecure messaging system, interactive field size reconfiguration via messages, and some kind of lesser-privileged remote exploit, it is concievable however unlikely that this “design flaw” could be used as one component in a multi-faceted major remote exploit.
My 2 cents.
From bug to flaw, that’s a major step forward.
Hey, this is less flawed than Unix suid programs…
This sort of problems occur in every os. This is kinda joke.
NFS is also insecure where lots of people use it. There is no authentication. Saying that there is an architecture flaw in the design is stupid, because NFS shows you how to prevent security issues. If you don’t apply them, then the problem is not in NFS, but you. The problem with NFS is that, if you are allowed to mount to an NFS server, you can create your own user id and then read other people’s file. NFS doesn’t ask you every time whether you are who you say you are. This technology is from Sun by the way.
By the way, this is pretty old news. We already talked about this. There is no flaw, it is just a stupid claim to be famous on the news.
This sort of problems occur in every os. This is kinda joke.
[…]
By the way, this is pretty old news. We already talked about this. There is no flaw, it is just a stupid claim to be famous on the news.
Wrong, the flaw is threefold:
* Any Win32 GUI application can send messages to any other Win32 GUI application’s message queues, and pretend to be the kernel in the process.
This is just bad design. There’s absolutely no reason why the message queues used for GUI events should be accessible by anything other than the kernel.
Failing that, message queues should have permissions in the same way that SVR4 message queues/named pipes/Unix domain sockets do. The bottom line: Unix has done this right for the past two decades, Windows has done it wrong.
* Any application can therefore send messages which resize the size of text input buffers. This means that the potential exists for a buffer overflow in any Win32 application.
* Any application can send messages which cause another application to jump to any arbitrary address.
So let’s see, complete absence of permissions, buffer overflows, and execution of arbitrary code. I’d say those are some pretty big design flaws.
Of course this is old news… it stems from the legacy of a system which relied on cooperative multitasking.
is 100% secure on any network (LAN, WAN, PAN, SAN, internet, anything where machines are connected) period! Prying eyes can hack into any system if you let them stare at it long enough.
Only way to secure yourself is to disconnect.
Lets see I am concerned about the safety of children when driving to school in the morning.
Option A:
—————————–
I select a car with advanced safety features, I drive sensibly obeying all traffic rules and avoid reckless drivers, making sure never to drive drunk or with no sleep.
Option B: (Doug Ly’s option)
—————————-
My children stay home because school is dangerous because of the chance of a road accident.
* Any Win32 GUI application can send messages to any other Win32 GUI application’s message queues, and pretend to be the kernel in the process.
This is just bad design. There’s absolutely no reason why the message queues used for GUI events should be accessible by anything other than the kernel.
No… sending and posting messages are common and reliable ways of inter-thread and inter-process communication on Windows.
* Any application can therefore send messages which resize the size of text input buffers.
OK…
This means that the potential exists for a buffer overflow in any Win32 application.
…huh? Yes; potential exists for buffer overflow in any application (strcpy(“hi”, “world”)). So you put in checks for it.
* Any application can send messages which cause another application to jump to any arbitrary address.
That is the flaw here: the ‘feature’ of the lParam parameter to the WM_TIMER message. This is an anachronism from Win16 and should have been dropped in Win32. Some way of identifying the sender of a message would also be useful.
However: the major way security is enforced in the Windows GUI is to put sensitive windows into a different window station or desktop. The screen saver does this: it is impossible to grab a user’s screen saver password without going to a lot of trouble in User Manager (if at all — you’d need LocalSystem account permissions). The Locked Workstation window does this, as do the other Winlogon windows.
This is why Microsoft and anyone with even a little specific knowledge of Windows security urges developers not to give services access to the user’s desktop, because windows belonging to a privileged process (the service process running in the LocalSystem account) can mingle with unprivileged windows (the processes belonging to the pleb currently logged on).
If you want to secure your box, remove any services whose “Allow service to interact with desktop” box is ticked. Try to obtain replacements for those programs, and give the [lazy] developers hassle*. Otherwise, prepare to suffer the consequences.
—
* The recommended way of getting around having to give services access to the desktop is to write a separate GUI control program which communicates with the service over some secure IPC channel. The GUI doesn’t have any specil permissions; the service doesn’t stray outside its own window station.
“Wrong, the flaw is threefold:
* Any Win32 GUI application can send messages to any other Win32 GUI application’s message queues, and pretend to be the kernel in the process.”
erm.. the kernel doesn’t send window messages to apps. Processes higher up the chain do. Win32 apps dont typically sit and wait for window messages from specific processes anyway unless a developer goes out of his/her way to make it do so.
“This is just bad design. There’s absolutely no reason why the message queues used for GUI events should be accessible by anything other than the kernel.”
Applications generate GUI events for applications. Plain and simple. The kernel has nothing to do with sending messages etc. Nothing even has access to the kernel address space unless its running in ring 0. Sure some functions enter ring 0 to do their job (ie: file io), but try writing to that chunk of memory, nt will tell you to get lost.
“Failing that, message queues should have permissions in the same way that SVR4 message queues/named pipes/Unix domain sockets do. The bottom line: Unix has done this right for the past two decades, Windows has done it wrong.”
Apples and oranges. SVR4 message queues and named pipes are completely different things from the win32 message system. It deals with GUI aspects of an app, not the internals. Applications respond to messages themselves to update displays, etc. For the most part it works just like Event’s in X11.
“* Any application can therefore send messages which resize the size of text input buffers. This means that the potential exists for a buffer overflow in any Win32 application.”
So what? The window controls handle this on their own. Their buffer size can be whatever you want it to be, when querying the text inside a buffer. The “GetWindowTextLength” function is there for a reason. If someone is hacking you, talk to the person who’s problem it is instead of making shit up.
“* Any application can send messages which cause another application to jump to any arbitrary address.”
jeez..
“So let’s see, complete absence of permissions, buffer overflows, and execution of arbitrary code. I’d say those are some pretty big design flaws.”
Of course this is old news… it stems from the legacy of a system which relied on cooperative multitasking.”
Actually the only thing that is completely missing is your understanding of the subject matter. I won’t sit and talk about quantum mechanics because i don’t know jack about it, you should take a lesson.
I’m usually not this harsh, but the quality of conversation really goes down the tubes with shit heads such as yourself getting hardons on some big “conspiracy, we hate microsoft, unix or die” crap. Once and for all, give it a f’n rest. Stop trying to cram your half-assed judgements down everyones throat. Keep it between you and your ignorant cronies. If you like unix, a-fucking-men, if you hate microsoft, good for you too.. stop trying to convince everyone how stupid you think they are. If they were so stupid, they wouldn’t be where they are now and you know it.
the only thing ms was smart about was their marketing. thats it. windows as a product is a big joke.
…huh? Yes; potential exists for buffer overflow in any application (strcpy(“hi”, “world”)). So you put in checks for it.
Yes, however in the case of Win32 you can have a program that would otherwise be correct were it not for the ability of any application to arbitrarily resize any text input buffer.
erm.. the kernel doesn’t send window messages to apps. Processes higher up the chain do. Win32 apps dont typically sit and wait for window messages from specific processes anyway unless a developer goes out of his/her way to make it do so.
Okay, assuming NT, which process is doing event handling?
Applications generate GUI events for applications. Plain and simple.
Which applications?
The kernel has nothing to do with sending messages etc. Nothing even has access to the kernel address space unless its running in ring 0.
Of course… that’s what IPC is for…
Sure some functions enter ring 0 to do their job (ie: file io)
Umm, you don’t “enter” ring 0 when you make a system call.
but try writing to that chunk of memory, nt will tell you to get lost.
See, this is funny, because later you ridicule my ignorance.
Apples and oranges. SVR4 message queues and named pipes are completely different things from the win32 message system.
They serve the same purpose, IPC.
Actually the only thing that is completely missing is your understanding of the subject matter. I won’t sit and talk about quantum mechanics because i don’t know jack about it, you should take a lesson.
Do you care to point out any specific fallacies in the statements I’ve made? It sounds like you’re just talking out your ass.
And ultimately, you’re both missing the point, which is that a little foresight and better design on Microsoft’s part and none of this would be an issue.
“Okay, assuming NT, which process is doing event handling?”
[sigh] CSRSS.EXE (what, its not the kernel?!) since you’re too lazy to look it up yourself. http://www.win2000mag.com/Articles/Index.cfm?ArticleID=2984&pg=2 3rd or 4th paragraph from the bottom. Read the entire thing while you’re there, you’ll learn something i’m sure. Here’s the first part for good measure. http://www.win2000mag.com/Articles/Index.cfm?IssueID=29&ArticleID=2…
“Which applications?”
If you write DUMBASS.EXE and it has a window, and you move that window around via code, say using SetWindowPos(), SetWindowPos which is executing in YOUR process sends WM_WINDOWPOSCHANGING and WM_WINDOWPOSCHANGED, which in turn will get handled by the default window procedure (DefWindowProc, which is an API call). This the part you don’t get, so pay attention. DefWindowProc then changes the window position via CSRSS.EXE using a completely different mechanism. You and the guy claiming this is a security hole dont’ seem to understand that windows messages (WM_*) aren’t the only form of IPC in the system, and that the aren’t the keystone to the whole thing. NT implements a posix and an os/2 layer that run along side the “NT” layer which CSRSS is. Why are you going to send a bunch of window messages to a posix app?? You’re not because it has no use for them.
“Of course… that’s what IPC is for…”
You might want to read up on that too.
“Umm, you don’t “enter” ring 0 when you make a system call.”
You do if you call for instance, OpenFile(). It in turn is calling NtOpenFile(), which will in turn cause a switch from Ring 3 to Ring 0. Here’s an article from CMT that explains it quite well. http://cmt.tstc.edu/database/os/nt/ntarch.html
“See, this is funny, because later you ridicule my ignorance.”
Stop making it so obvious that you’re ignorant on the subject.
“They serve the same purpose, IPC.”
I realize interprocess-communication and its acronym are very schnazzy buzz words to toss around, but its a very generic term. Your named pipes and SVR4 messages would be more equivilent to the IPC used between perhaps the kernel and a driver, or a networking layer. But they are *NOT* similar to windows messages in any way other than they fall under the umbrella of IPC. Compare it to X11 events, that’s the only appropriate comparison.. like i said the first time.. apples and oranges.
“Do you care to point out any specific fallacies in the statements I’ve made? It sounds like you’re just talking out your ass.”
If you read the links i pointed you to, you might close that floundering hole of yours. The point is more or less proven.. and if you still don’t get it, then i’ll leave you be because nothing i can do is going to help whatever issue it is you have against the evil empire.
“And ultimately, you’re both missing the point, which is that a little foresight and better design on Microsoft’s part and none of this would be an issue.”
Actually, you’re missing the point. The point is that everything you’ve said prior is pure BS-lets-dog-microsoft-propaganda shit. I don’t care for them much myself, but i’m not going to start making up things so i have something to complain about. A little better forsight and better choice of things to talk about on your part, and i wouldn’t be wasting my time typing to you.
See ya in the next thread.
All I can say is ROTFLMAO.
Umm, let’s take a little look at that article you pasted, eh? Specifically this paragraph:
The Win32 environment includes graphics and user-interface functions, which are implemented in its graphics device interface (GDI) and User components. In NT 3.51, whenever a Win32 program makes a drawing or user-interface call, the GDI or User client-side DLLs make LPC calls to the Win32 server (CSRSS.EXE). Those LPC calls to the server cause Win32’s sluggish performance–the bane of microkernel-based operating systems. In NT 4.0, the User and GDI components move from user mode into kernel mode as a new Executive subsystem, Win32K.SYS. When a drawing call is made, the client-side GDI’s DLL makes a new native system call into kernel mode, where the request is carried out (Win32 native system calls didn’t exist in NT 3.5x). There is no message passing and no context switches–just a switch from user mode to kernel mode and back. This optimization has a dramatic effect on the performance of Win32 applications.
Gee, that doesn’t bode well for your argument… thanks for proving yourself wrong.
“Of course… that’s what IPC is for…”
You might want to read up on that too.
I’ve read Steven’s UNP volume 2… how about you?
I realize interprocess-communication and its acronym are very schnazzy buzz words to toss around, but its a very generic term.
Uh huh, which means I’m wrong.
Your named pipes and SVR4 messages would be more equivilent to the IPC used between perhaps the kernel and a driver
LOL
or a networking layer. But they are *NOT* similar to windows messages in any way other than they fall under the umbrella of IPC.
It’s a mechanism which allows processes to send datagrams to each other. This is functionally equivalent to SVR4 message queues.
To be honest, it’s quite straightforward. Don’t allow applications to send unchecked messages to windows owned by a different user. Problem solved.