Windows System Exploit | Hacker News Reader

Windows System Exploit

megafrock.com

92 pointsmaxdeliso45 comments

the bluescreen is because, well, "CRITICAL_OBJECT_TERMINATION". in Windows, some processes, if they terminate, cause the entire operating system to stop with a bugcheck. think of it like init dying in linux.

there sadly is no 'stack backtrace'. it looks like he's managed to send some message to csrss.exe that caused it to crash with an invalid memory operation.

this is bad, it might even be exploitable. even though the exploit would be in csrss, which is not kernel mode, it's still extremely important and trusted. also, untrusted low-user code could make this call to privilege escalate.

it's worth noting that thought the author states " I stumbled accross the bug inadvertently while working on something totally unrelated to security, and decided to publish my findings so that this can be fixed by Microsoft.", microsoft actually has a security team that can be found here: http://technet.microsoft.com/en-us/security/ff852094.aspx (google for "microsoft report security bug")

the bugs you report to them remain confidential until they are fixed. this way, potentially bad exploit code isn't floating around the internet for some indeterminate amount of time. like this!

You usually can get a backtrace using the right commands in WinDbg after opening the crash dump.

indeed!

a trouble here is that the original fault is in user-mode csrss. you cannot use a user-mode debugger to debug csrss, so, to debug it you must use a kernel debugger. the process is involved. it is documented by microsoft though...

another trouble is that it seems that, at least on my systems, the ability to create a full dump of memory from the faulting process has been removed in w7. all you can do now is dump kernel mode memory, which would not include the needed information...

This isn't really an exploit, except insofar as a local user can cause a DoS for the system. Until there's a demonstration that arbitrary code can be invoked with elevated privileges, it's just a bug.

Agreed. Raymond Chen refers to these types of problems as involving "being on the other side of this airtight hatchway": http://blogs.msdn.com/b/oldnewthing/archive/2010/05/11/10009...

That's not entirely true - non-privileged local users are not supposed to be able to bluescreen the system. Note that, e.g. Terminal Server exists.

You can cause a blue screen by trying to copy the device context of the screen to itself with BitBlt - a stupid thing to do but still causes a blue screen

Sounds interesting. Anyone else have evidence for Microsoft's policy of ignoring local DoS vulns?

That sounds like a video driver bug, though.

Most probably not universally true. Care to provide more information?

Actually, Chen implies that it would be a security bug if an unprivileged user could do it on her own:

"Enabling the kernel debugger requires administrative privileges, so it's not like unprivileged users can force a system halt on their own".

Untill proven otherwise this totally violates full Disclosure policies. I know they are like 'gentleman agreements' but this feels bad, and looks bad, like the author is only out for some internet fame. I can not believe that he in any way tried to contact Microsoft, but clearly took his time on this publication.

I kind of get the feeling that the author doesn't really know what he's doing. The actual exploit code is a fragment of what looks like a 'hello world' sort of console IO test. The 0xC0000000 he goes on and on about is just GENERIC_READ | GENERIC_WRITE, which is a totally legal combination. And he disassembles his own code for no particularly good reason.

Given all of this, it's not really a surprise that he's not clear on responsible disclosure policies (this doesn't really violate 'full disclosure policies' - he's fully disclosing it, after all!). It sounds like he was just playing around with things, found a way to crash his own machine by accident, and decided to post it online.

I also note that the code is incomplete, and looks reasonably straightforward and correct from casual inspection. I wonder if the real cause is elsewhere?

I haven't exactly pinpointed the cause of the problem, I just noted that that call was the last point in my code to get executed before the system was hosed.

Also, the code is complete: check the tarball listed at the end of the page.

> this doesn't really violate 'full disclosure policies'

Well he kinda marked it down like he was.. talking about compiling an exe and all to crash any Vista/7 in 30 secs.

There are tons of developers who've got no experience dealing with (potential) security issues or have any idea about the "gentleman agreements" that are prevalent in the security- versus the IT-industry. So it could very well be that he has no idea what he's doing.

Then again; every 12 months or so the debate regarding full/responsible/no disclosure flares up again in the security-/IT-industry after another public outcry regarding one specific bug, company or patch. In the end nothing is resolved and we still continue to rely on gentleman agreements.

<secure@microsoft.com>: host microsoft-com.mail.protection.outlook.com[207.46.100.11] said: 550 5.7.1 Service unavailable; Client host [66.175.217.21] blocked using Blocklist 1; To request removal from this list please forward this message to delist@messaging.microsoft.com (in reply to RCPT TO command)

Call stack from WinDbg:

  ChildEBP RetAddr  
  8942ec9c 82b1d2a1 nt!KeBugCheckEx+0x1e
  8942ecc0 82a9ae5a nt!PspCatchCriticalBreak+0x71
  8942ecf0 82a9ad9d nt!PspTerminateAllThreads+0x2d
  8942ed24 8287b8fa nt!NtTerminateProcess+0x1a2
  8942ed24 77b87094 nt!KiFastCallEntry+0x12a
  00f8f260 77b868d4 ntdll!KiFastSystemCallRet
  00f8f264 75d3301f ntdll!ZwTerminateProcess+0xc
  00f8f2a4 75d34d7c CSRSRV!CsrUnhandledExceptionFilter+0xcb
  00f8f2ac 75d36f48 CSRSRV!CsrApiRequestThread+0x3e2
  00f8f2c0 75d36cde CSRSRV!_EH4_CallFilterFunc+0x12
  00f8f2e8 77b87199 CSRSRV!_except_handler4+0x8e
  00f8f30c 77b8716b ntdll!ExecuteHandler2+0x26
  00f8f330 77b5f98f ntdll!ExecuteHandler+0x24
  00f8f3bc 77b86ff7 ntdll!RtlDispatchException+0x127
  00f8f3bc 77b92cc7 ntdll!KiUserExceptionDispatcher+0xf
  00f8f708 77b92c78 ntdll!RtlpLowFragHeapFree+0x31
  00f8f720 75c6b349 ntdll!RtlFreeHeap+0x105
  00f8f734 75c72ce2 sxs!operator delete+0x1c
  00f8f740 75c724f6 sxs!RawStack::~RawStack+0x12
  00f8f74c 75c72484 sxs!XMLParser::~XMLParser+0x68
  00f8f758 75c72e7c sxs!XMLParser::`scalar deleting destructor'+0xd
  00f8f76c 75c686f3 sxs!_unknown<IXMLParser,&IID_IXMLParser>::Release+0x27
  00f8f77c 75c73e1f sxs!CSmartRef<IXMLParser>::~CSmartRef<IXMLParser>+0x1b
  00f8f7fc 75c74a37 sxs!SxspIncorporateAssembly+0x5db
  00f8f83c 75c78001 sxs!SxspIncorporateAssembly+0xb8
  00f8f874 75c6a944 sxs!SxspCloseManifestGraph+0x7c
  00f8f928 75ce28c7 sxs!SxsGenerateActivationContext+0x48f
  00f8fa90 75ce1ad3 sxssrv!BaseSrvSxsCreateActivationContextFromStruct+0x490
  00f8fac8 75d34d65 sxssrv!BaseSrvSxsCreateActivationContextFromMessage+0xdb
  00f8fc40 77b45e7a CSRSRV!CsrApiRequestThread+0x3cb
  00f8fc80 77ba374e ntdll!__RtlUserThreadStart+0x28
  00f8fc98 00000000 ntdll!_RtlUserThreadStart+0x1b

I think this it utterly irresponsible to publish without trying to contact Microsoft's security team first. Why on earth?

This would put more pressure on Microsoft to fix the issue at hand, no?

Perhaps but it also increases the probability that a possible security issue gets exploited. I suspect the author just wants publicity first. Ego talks.

They don't have a vulnerability reward program, so why on earth would you?

So you're saying you should only do the right thing if there's something in it for you?

It's probably a better incentive than getting nothing back :-)

You get better security back for all the Windows machines that are in your local network, the ones that your customers use or the Windows/Azure servers you use for your day to day business.

If you dump it online way more people start looking at it. They might be able to turn it into a reliable exploit leaving you, your customers and your servers at risk.

But the last thing HN needs is another debate on the pro's and cons of full disclosure; that's been done to death in the past decade all over the web :)

OK, conversely, you're saying that you should do the wrong thing (as in this case), if there is no financial incentive?

Given you aren't going to get a reward either way, why not do the right thing?

Frankly, I can't believe I need to discuss the morality of this. Is it not obvious?

And yes yes, I realise this is probably a case of Hanlon's Razor, not a moral failing, but justifying it on the grounds of there being no reward is crazy.

This case is not 'the wrong thing'. The wrong thing is selling this data to criminals, or not publishing it at all because odds are someone else is going to find it eventually.

What you're calling "the right thing" isn't zero cost. It takes a fair bit of time (spaced out over a period of months, by the way, so it's not a fire and forget it report) to report a vulnerability to microsoft and follow up with their security team. More so if your vuln is at all interesting or complex. You may have to write PoCs. Your vulnerability will be patched in 4-6 months (not exaggerating, although this will obviously be quicker if it's made the news somehow), and you'll get a minute credit in their patch tuesday notes.

So no, the morality of this is not obvious. Where is my moral obligation to effectively do charity work for a megacorp that can't be bothered to keep up with industry standards in security?

Well, I was just trying to guess their reasoning. I'd have no problem doing The Right Thing™, but I'm nowhere skilled enough to find a vulnerability anyway.

As it stands I don't think there is much harm done because it's a local vulnerability, crashing a user-mode process. Annoying, maybe, but my graphics driver has a far worse track record as far as bluescreens are concerned.

Is stuffing the cracks in Windows the right thing in the end though?

I wonder how easy it is to actually contact Microsoft on matters like this? It would probably take hours upon hours of searching convoluted corporate websites just to get an e-mail address or phone number to contact. Just slamming it on the web and posting on hacker news will take less time and is sure to reach Microsoft's attention quickly :) Sure, it's not responsible but not everyone is.

You could go to microsoft.com and type "report a security vulnerability" into the search box. Then click the first result.

Well that was easy. It even worked on the internationalized version in my native language, which is not common with corporate websites. But that's just the first step, anyway.

Pretty easy; you just email secure@microsoft.com (there are PGP or S/MIME keys available too) and you generally receive a response in a maximum of 48 hours. In most cases you get a reply within a few hours stating that you've passed their spamfilters, that they've done an initial overview of your report and that they will start looking into it.

If you google for "microsoft report security vulnerability" the first page you get is this: http://technet.microsoft.com/en-us/security/ff852094.aspx. Doesn't get much clearer than that in my opinion.

Ok, tried it. This DOES NOT trigger blue screen on Windows 8 (64bit) / Visual Studio 2012. I'm pretty sure the author has some other problems in his environment.

This is not the case.

Did you use the makefile to build it? I'm thinking that those specific compile and link flags are key to the triggering condition.

I've gotten it to crash at least three or four times on several windows 7 boxes of wildly differing configurations. No confirmed trials on a windows eight box, the bug may have been fixed there.

I also ran it on Windows 7 (64-bit). Nothing happens, although the prompt was displayed. It wasn't on Windows 8. The program doesn't do anything special. Either you're running some other version of the program, or your report is incorrect.

Was able to reproduce and get a dump on Win7 32-bit, but had to run the program more than once.

I think I was able to reproduce it myself. Yesterday I ran your program on one particular laptop, tried to get it to crash but it didn't. Then today when it woke up from sleep, it suddenly bluescreened. I think you may onto something here...

Yes, I used the makefile. Certainly it is possible that it has been fixed.

I hate the idea of "full disclosure." I, instead, love what this author has done. You found a bug, you're posting about it. Great. Any decent, respectable, commercial enterprise should have somebody watching sites like this, looking for posts like these. They shouldn't rely on somebody taking time away from themselves or their projects and write up a bug report. No.

I don't get it. It takes the exact same time to write a report to Microsoft about it. The author clearly didn't even consider it.

We don't know the author. He may very well enjoy writing these types of articles. Filling out a form online? Maybe not so much. He also has complete freedom in writing anything he wants with no obligation of providing further proof or information. To some, that's enough motivation.

Look, I get it. I just don't approve it. I think it's irresponsible.

What this author has done is full disclosure. Writing a bug report falls under "responsible disclosure".

>but to make life simple for programmer's

Programmer's what?

Reply on news.ycombinator.com