Windows System Exploit

by maxdeliso • 14 years ago

92 45 14 years ago

twoodfin• 14 years ago

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.

thedudemabry• 14 years ago

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...

JoachimSchipper• 14 years ago

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.

potkor2• 14 years ago

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".

munin2• 14 years ago

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!

yuhong3• 14 years ago

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

munin2• 14 years ago

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...

verroq• 14 years ago

>but to make life simple for programmer's

Programmer's what?

kyberias9• 14 years ago

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

darren_2• 14 years ago

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

upthedale2• 14 years ago

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

orik• 14 years ago

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

kyberias9• 14 years ago

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

exDM692• 14 years ago

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.

WalterGR• 14 years ago

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

santaragolabs3• 14 years ago

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.

easy_rider2• 14 years ago

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.

bdonlan• 14 years ago

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?

maxdeliso3• 14 years ago

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.

easy_rider2• 14 years ago

> 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.

santaragolabs3• 14 years ago

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.

maxdeliso3• 14 years ago

<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)

wcchandler2• 14 years ago

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.

kyberias9• 14 years ago

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.

wcchandler2• 14 years ago

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.

gpvos• 14 years ago

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

kyberias9• 14 years ago

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.

maxdeliso3• 14 years ago

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.

kyberias9• 14 years ago

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

kyberias9• 14 years ago

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.

yuhong3• 14 years ago

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

Windows System Exploit

Related Stories