11 ms·

Windows System Exploit

92 points by maxdeliso 14y ago

deleted 14y ago
[deleted]
twoodfin 14y 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 14y 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/10009450.aspx http://blogs.msdn.com/b/oldnewthing/archive/2010/05/11/10009...
  - JoachimSchipper 14y 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.
    - mjpa 14y ago
      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
      - potkor 14y ago
        Sounds interesting. Anyone else have evidence for Microsoft's policy of ignoring local DoS vulns?
      - kevingadd 14y ago
        That sounds like a video driver bug, though.
      - kyberias 14y ago
        Most probably not universally true. Care to provide more information?
  - potkor 14y 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".
munin 14y 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 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!
- yuhong 14y ago
  You usually can get a backtrace using the right commands in WinDbg after opening the crash dump.
  - munin 14y 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 14y ago
>but to make life simple for programmer's Programmer's what?
- deleted 14y ago
  [deleted]
kyberias 14y ago
I think this it utterly irresponsible to publish without trying to contact Microsoft's security team first. Why on earth?
- darren_ 14y ago
  They don't have a vulnerability reward program, so why on earth would you?
  - upthedale 14y ago
    So you're saying you should only do the right thing if there's something in it for you?
    - ygra 14y ago
      It's probably a better incentive than getting nothing back :-)
      - upthedale 14y ago
        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.
        ygra 14y ago
        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.
        14y ago
easy_rider 14y 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 14y 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?
  - maxdeliso 14y 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_rider 14y 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.
- santaragolabs 14y 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.
easy_rider 14y 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.
wcchandler 14y 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.
- kyberias 14y 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.
  - wcchandler 14y 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.
    - kyberias 14y ago
      Look, I get it. I just don't approve it. I think it's irresponsible.
- gpvos 14y ago
  What this author has done is full disclosure. Writing a bug report falls under "responsible disclosure".
kyberias 14y 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.
- maxdeliso 14y 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.
  - kyberias 14y ago
    Yes, I used the makefile. Certainly it is possible that it has been fixed.
  - kyberias 14y 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.
    - yuhong 14y ago
      Was able to reproduce and get a dump on Win7 32-bit, but had to run the program more than once.
      - kyberias 14y ago
        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...
yuhong 14y 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

92 points by maxdeliso 14y ago

deleted 14y ago

[deleted]

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 14y 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/10009450.aspx http://blogs.msdn.com/b/oldnewthing/archive/2010/05/11/10009...
- JoachimSchipper 14y 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.
  - mjpa 14y ago
    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
    - potkor 14y ago
      Sounds interesting. Anyone else have evidence for Microsoft's policy of ignoring local DoS vulns?
    - kevingadd 14y ago
      That sounds like a video driver bug, though.
    - kyberias 14y ago
      Most probably not universally true. Care to provide more information?
- potkor 14y 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".

munin 14y 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 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!

yuhong 14y ago
You usually can get a backtrace using the right commands in WinDbg after opening the crash dump.
- munin 14y 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 14y ago

>but to make life simple for programmer's Programmer's what?

deleted 14y ago
[deleted]

kyberias 14y ago

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

darren_ 14y ago
They don't have a vulnerability reward program, so why on earth would you?
- upthedale 14y ago
  So you're saying you should only do the right thing if there's something in it for you?
  - ygra 14y ago
    It's probably a better incentive than getting nothing back :-)
    - upthedale 14y ago
      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.
      - ygra 14y ago
        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.
      - 14y ago

easy_rider 14y 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 14y 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?
- maxdeliso 14y 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_rider 14y 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.
santaragolabs 14y 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.

easy_rider 14y ago

wcchandler 14y 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.

kyberias 14y 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.
- wcchandler 14y 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.
  - kyberias 14y ago
    Look, I get it. I just don't approve it. I think it's irresponsible.
gpvos 14y ago
What this author has done is full disclosure. Writing a bug report falls under "responsible disclosure".

kyberias 14y 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.

maxdeliso 14y 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.
- kyberias 14y ago
  Yes, I used the makefile. Certainly it is possible that it has been fixed.
- kyberias 14y 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.
  - yuhong 14y ago
    Was able to reproduce and get a dump on Win7 32-bit, but had to run the program more than once.
    - kyberias 14y ago
      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...

yuhong 14y 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