15 ms·

Bypassing Windows 10's Protections Using a Single Bit

358 points by 2510c39011c5 12y ago

Animats 12y ago
When your OS kernel handles scroll bars, you're doing something wrong. NT 3.5 had the GUI entirely outside the kernel. For compatibility with Windows 95, much of the Windows 95 GUI code was moved into the kernel. 20 years later, that decision is still causing bugs.
- api 12y ago
  Backward compatibility is the root of quite a bit more evil than premature optimization.
  - InclinedPlane 12y ago
    Modern CPUs still implement the A20 gate functionality, for example.
  - barrkel 12y ago
    Backward compatibility, OTOH, is key to a large fraction of upgrade revenue.
- wvenable 12y ago
  I thought the big reason for moving the GUI into the kernel was for performance rather than compatibility.
  - CurtHagenlocher 12y ago
    That is correct.
  - 2510c39011c5 12y ago
    in terms of GUI, performance is responsiveness... and for a windows system, it needs to support a range of hardware configurations...Some could be really slow...
  - Animats 12y ago
    That was the official word from Microsoft at the time, but Mark Russinovich, who had Sysinternals.com at the time, benchmarked and said that pushing low-level graphics commands (draw line, fill, etc; stuff graphics cards do) across the kernel boundary wasn't a bottleneck. He was critical of those decisions. Microsoft eventually hired him to shut him up.
    - jen729w 12y ago
      And because he was clearly a genius.
      - Animats 12y ago
        There's a story behind that buyout. Russinovich had a business called Winternals, and had written NTFSDOS [1], which allowed access to NT file systems under DOS.[2] Microsoft didn't like that, because it allowed booting from a floppy, bypassing NT's security restrictions, and resetting the administrator password, copying, or modifying files. (The concept that a computer could be secure when someone had enough physical access to boot a new OS seems silly now, but back then, the opposition was script kiddies, not intelligence agencies and organized crime.) So Microsoft bought Russinovich out. Wikipedia: "Winternals was acquired by Microsoft mid-2006. Microsoft has removed any traces of NTFSDOS..." [1] https://en.wikipedia.org/wiki/NTFSDOS https://en.wikipedia.org/wiki/NTFSDOS [2] https://web.archive.org/web/20000126093942/http://sysinternals.com/ntfspro.htm https://web.archive.org/web/20000126093942/http://sysinterna...
        asveikau 12y ago
        > Microsoft didn't like that, because it allowed booting from a floppy, bypassing NT's security restrictions, and resetting the administrator password, copying, or modifying files. This sounds nonsensical, like folk history. You can already create a boot disk to do this using all Microsoft tools: Assuming the volume is not BitLocker'd it's pretty simple to do all of this stuff with WinPE [1], including the version that shipped in 2006, or with a Windows setup DVD. Or you could simply move the drive to a machine where you are an admin. I am pretty sure they bought winternals because they wanted to hire MarkRuss. [1] http://en.wikipedia.org/wiki/Windows_Preinstallation_Environment http://en.wikipedia.org/wiki/Windows_Preinstallation_Environ...
- userbinator 12y ago
  Windows started out as being for a single-user personal computer, and such a use-case is going to emphasise different features than something more security-oriented for large multi-user systems. The NT family was widely known for being more sluggish and resource-consuming than 9x, even in regular usage - I dualbooted with 98SE and XP for a long time, and the difference in responsiveness was very noticeable. Also, it could be argued that vulnerabilities like these which are only locally exploitable are not all that scary, as a personal computer should be by definition one that obeys its user no matter what. It's a bug, but not a "someone can take over your computer without you doing anything". Maybe it's because I grew up with personal computers that practically invited you to do whatever you want with them and had absolutely no "protection" whatsoever (early 8-bit machines, then DOS on a PC) that I find it hard to get scared or excited by local-only exploits like these.
  - nitrogen 12y ago
    Local privilege exploits are problematic for corporate environments where not all users can be trusted 100%, and for the gullible less-technical users.
  - comex 12y ago
    Today, with public hosting nearly universally offering VMs instead of traditional user accounts on a single operating system - never mind the whole Docker trend of giving every single piece of the application its own virtual OS install - are "large multi-user systems" even worth worrying about anymore? But this is basically orthogonal to the modern application of (OS-level) privilege boundaries, which is to protect the user from compromised application processes. This escalation doesn't let someone "take over your computer without you doing anything" by itself, but once someone has exploited an IE bug and found themselves able to run arbitrary code on users' computers in a sandbox - which happens all the time - that's exactly what it allows.
    - mjevans 12y ago
      The short answer is yes; such operating systems are required to run Docker, LXC and other approaches which all utilize similar tools. I'm not that familliar with Docker but looking at http://en.wikipedia.org/wiki/Docker_%28software%29 http://en.wikipedia.org/wiki/Docker_%28software%29 it is built on the same resource isolation features as LXC which I am using on two of my test systems. The resource isolation features are, in fact, built on top of a large multi-user system, which happens to have powerful security context support and abstractions built in. The contained applications operate, from a userspace perspective, as if they are their own system when in reality their kernel is actually the host kernel and their users really virtually re-mapped to distinct accounts within the host kernel.
- nbevans 12y ago
  Are you on crack? Windows does no such thing. It's called User32.dll for a reason. If what you say was true it would be called User32.sys i.e. a kernel driver. You're getting confused from the fact that graphics drivers and DirectX are primarily kernel mode components in Windows, which is done purely for performance reasons. It is not done for any backward compatibility reasons like you wildly claim. I would recommend that you read the NT Internals book by Mark Russinovich. Then you might actually show some respect to the NT kernel.
  - na85 12y ago
    Ever try showing some respect to your fellow HN users?
    - 72deluxe 12y ago
      Anyone else noticed the rise of offensiveness here?
      - spacemanmatt 12y ago
        Goes with the territory; the front door stays open here. But yeah, I've noticed. It ebbs and flows.
  - asveikau 12y ago
    This vulnerability seems to be in win32k.sys. The UI side of NT is something I know less about than other pieces, however, my understanding is that a lot of user32.dll in an NT-based system is simply trapping into win32k.sys. Similar to the fact that most stuff in ntdll is just a syscall stub. I respect the NT kernel but it has visible warts. I will give you that they are not always the same warts as what people complain about on HN.
  - dang 12y ago
    > Are you on crack? Personal attacks are not allowed on Hacker News, regardless of whether someone else is wrong.
- logicallee 12y ago
  >When your OS kernel handles scroll bars, you're doing something wrong. it's pretty core to the idea of windows though. kind of like a printer - i wouldn't be surprised if a printer driver was in the kernel. or age of empires, which is a Microsoft property. just load it into the kernel in case you need it and you dont need much DRM, if people end up buying it it can get unlocked.
  - goldenkey 12y ago
    A game residing in the kernel. Have you gone mad?!
    - logicallee 12y ago
      I cannot imagine how anyone didn't get that I was making a joke. Originally I ended by saying that I'd draw the line at including all of creative suites (photoshop, illustrator, etc) would be too much, since it's a third party and Microsoft shouldn't be playing favorites with what's in the kernel like that. in essence i was agreeing that a microkernel is no place for a scroll bar!
      - goldenkey 12y ago
        Your joke was a bit deadpan. But I'm laughing now ;-)
        logicallee 12y ago
        sorry, i wasn't actually in a funny mood.
- est 12y ago
  More than that, Vista (along with .NET) put http stack into kernel. It's called http.sys
- drzaiusapelord 12y ago
  The kernel move was, reportedly, for performance reasons. I think if you use NT workstation at the time, you'd probably notice this compared 95/98. I believe MS also runs http in kernel space under http.sys. There's no backwards compatability there for legacy 8 or 16-bit apps as, you know, the web is younger than those apps and even then a browser would not need to interface with them. I think MS is eternally hamstrung by performance and legacy issues because those two things are in demand for so many of their customers. Windows fits this market, which is fairly sizeable. Of course now with hardware at the speed its at, you can get a lot more slack. I've found the linux desktop to be horribly slow until the past couple of years where there's a glut of CPU/GPU performance on even the most commodity equipment. I can run, and have run, Win7 on equipment that shipped with XP and its been a fairly pleasant experience. Running, say, a gnome or KDE WM on that equipment is a nightmare. MS, for all its faults, is fairly conservative in many regards, especially performance. At the end of the day this is yet another security issue that needs to be patched. The larger issue in my mind isn't MS decisions from 15 years ago, but why so much of our software infrastructure is being written in languages that more or less beg for stack/malloc vulnerabilities. These constant tirades about MS are just more "the beatings will continue until morale improves" and not really a constructive conversation about security. I think in the near future we'll be looking at all our stuff written in Rust-like languages and wonder why the hell it took so long to do. Lastly, Win10 is a technical preview. Finding bugs is exactly what should be going on here. Are we really being this critical on pre-release software? I don't see any other software held up to such a standard.
  - CognitiveLens 12y ago
    > Lastly, Win10 is a technical preview. Finding bugs is exactly what should be going on here. FTA: "We have verified this exploit against all supported Windows desktop versions, including Windows 10 Technical Preview." The specific "Windows 10" aspect is click-bait; the exploit is for Windows
  - floatboth 12y ago
    "we managed to create a reliable exploit for all versions of Windows – dating back as of Windows XP to Windows 10 preview"
- deleted 12y ago
  [deleted]
- outworlder 12y ago
  Not to mention that the scrollbar code is triggered by a LOT of window messages. If you wanted to draw scrollbars yourself, you'd have to eat a bunch of messages, not just WM_PAINT and the like. On my last count, you needed to swallow 11 different types of messages.
- yuhong 12y ago
  They finally created a separate font server process in Win10.
deepakexpert 12y ago
Thanks for share this news
mdriley 12y ago
This doesn't "bypass all Windows security measures". As of Windows 8, processes can disable win32k syscalls using SetProcessMitigationPolicy with ProcessSystemCallDisablePolicy. https://msdn.microsoft.com/en-us/library/windows/desktop/hh769088%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/hh7...
- XbcL4QZQ 12y ago
  Is ProcessSystemCallDisablePolicy somehow similar to seccomp on Linux? I understand that seccomp allows to selectively allow/disallow individual system calls while this disallows all win32k calls. But I don't know how similar these features are in the security impact. Apparently, chromium - which uses seccomp on linux - uses ProcessSystemCallDisablePolicy on windows: https://src.chromium.org/chrome/branches/1312/src/sandbox/win/src/process_mitigations.cc https://src.chromium.org/chrome/branches/1312/src/sandbox/wi...
  - mdriley 12y ago
    They're comparable features. In both cases, a simple but hardened filter is placed in front of some part of the kernel attack surface. Vulnerable processes (e.g. renderers) opt in to these protections so that, in the event of compromise, they're less likely to be vectors for a successful escalation of privilege attack against the kernel syscall interface.
sandworm 12y ago
It's a flaw. A bad one. But things like this get patched every day. Only an idiot would believe there aren't plenty of other undiscovered security flaws in windows, or any other OS. What matters is whether this flaw was ever exploited, whether it was ever spotted in the wild, before it was patched. I am more than happy to criticize microsoft. I truly hate windows and everything it represents. But the system seems to have worked here. The bug was reported and patched before it became a widespread issue. I'll save my venom for those all-to-common days where Microsoft fails to address a problem in a timely manner. (or also Apple, plenty of venom for them too.)
- sillysaurus3 12y ago
  I am more than happy to criticize microsoft. I truly hate windows and everything it represents. Why's that? I'm hoping for an in-depth substantive analysis of the factors leading you to come to such a conclusion, but I don't want to take up a bunch of your time or make it seem like I'm asking you to justify anything.
  - sandworm 12y ago
    Windows is a proprietary ecosystem where choices are made for the benefit of microsoft's shareholders and nobody else. It is full of compromise. From DRM to hamstrung "student" versions, Windows is not your friend. Microsoft's business practices, specifically the way they market windows on oem machines, are also downright deceptive. I never use windows at home but, because I buy laptops, I actually own many windows licenses. Those "sales" are part of Microsoft's bottom line and are pitched to shareholders as if I am actually using microsoft products. I have never met anyone who truly likes windows. They tolerate it. They are used to it. But they never say "Yes, I am happy with this new version. The upgrade sure made my life easier!" I'd rather have my wisdom teeth re-installed and re-pulled than be part of another office transitioning from one version of windows to another. I gave up on windows when, after buying a little netbook, I decided to give it a chance. I plugged in an MS-brand optical mouse and was told that windows needed to connect to the internet to download the driver to run the mouse. That was windows's last breath on any of my personal machines. And death to docx.
peterkelly 12y ago
> This particular vulnerability appears in the GUI component of Microsoft Windows Kernel There's your problem right there.
- 72deluxe 12y ago
  Are you saying that Microsoft are incapable of releasing a decent product or a stable API? If so, you'd be wrong on the second count, and I'd say the first too but then argument would ensure. The Windows API and all related systems are stable and mature. And I'm saying this as an OSX user.
  - peterkelly 12y ago
    > Are you saying that Microsoft are incapable of releasing a decent product or a stable API? No, I'm saying that implementing scrollbar handling in the kernel is a bad idea. It's not something which requires privileged system access, and thus should be done in user mode where bugs like this won't lead to privilege escalation.
    - 72deluxe 12y ago
      But everything in the OS will use a scrollbar, so put it in the kernel, right? :-) Only kidding. I think OSX got around this problem by removing scrollbars haha only kidding You make an excellent point, sorry to misunderstand your original post.
MichaelGG 12y ago
How many of those new protections listed (DEP, ASLR, page 0 mapping) are still useful with a system like Rust? Cause it seems like a hell of a lot of effort is going into hardening the environment cause the code is just that leaky, but I'm probably misunderstanding something.
- nly 12y ago
  Theoretically if you had a kernel written in Rust, I suppose you could implement the system call interface such that all pointers passed to the kernel from user space would be considered "borrowed" under the Rust type system, and then have all your "return to user space" mechanisms recognised by the compiler as terminating their lifetime. I'm not sure if that's enough though, considering that, in general, the kernel can't assume anything passed to it by reference via a system call isn't mutated by another userland thread. Furthermore, even if everything were written in Rust, the kernel can't just trust that a userland process was actually compiled in a way that faithfully employed Rusts compile-time safety guarantees... so I think any notion of shared garbage collection is tricky without a program loader that did code verification. Microsoft have done some work in this area with their Singularity and Midori projects[0]. Singularity in particular eliminates hardware isolation between processes. I think the simple answer here is that the kernel should be copying anything passed to it by reference if it intends to do anything beyond a single atomic read operation. This is why, on Linux for instance, send() can't return to user space until the data has been copied in to kernel controlled memory, and why we have nice things like splice() and sendfile() to deal with the performance hit of doing so for common cases. [0] https://en.wikipedia.org/wiki/Midori_%28operating_system%29 https://en.wikipedia.org/wiki/Midori_%28operating_system%29
  - TheLoneWolfling 12y ago
    Removing hardware isolation in general is not a good idea. There are enough hardware errors to cause problems. You don't want a bitflip to cause everything on your server to become corrupted. (Bitflips can be reduced by using ECC ram. But still, the principle remains.) (Worse: you don't want someone to be able to take over your entire physical server from one of the virtual servers) One option would be for the kernel to temporarily mark the page(s) referenced as read-only, and do copy-on-write where necessary. This would prevent the (presumably) common case of not having the page modified by another thread while the kernel processes the data to not incur the delay of copying the data. Might only be worth it for larger amounts of data, though.
laurent123456 12y ago
How do they find exploits like this? Do they check every single kernel functions for unchecked pointers? Do they have some automated way to discover this?
- gldalmaso 12y ago
  On figure 4 the legend says that static code analysis made it possible to discover the chain of calls.
  - pbhjpbhj 12y ago
    How many billions are MS making from Windows? Why aren't they doing that static analysis??
    - ToastyMallows 12y ago
      Maybe they are and this was already documented internally, but potentially marked as a low threat, but now that it was found outside of Microsoft it's a bigger problem? I'm just spitballing here, one would have to assume that Microsoft is doing static code analysis.
      - pbhjpbhj 12y ago
        OK, but it wasn't found before the current OS cycle presumably because one would imagine they'd fix it ... ha-ha! So it either wasn't found or they found it and continued to bake it in to the OS nonetheless. Which is better?
72deluxe 12y ago
The dead code comment at the end was informative. Does anyone else use code analysis of C/C++ to find dead stores etc.? I have used flawfinder, cppcheck and Xcode (clang's) analysis which has helped me find issues.
TheCraiggers 12y ago
> After some hard word, however, we managed to produce a fully working exploit which we’ll describe. Wait, now I'm confused... was it a single bit, or an entire word that triggers this bug? ;)
thclark 12y ago
Remove those unnecessary lines of code and you will be surprised how the security holes close by themselves.
zaroth 12y ago
I'm sorry, wait... they hacked it through the scroll-bars? You can't make this shit up.

358 points by 2510c39011c5 12y ago

When your OS kernel handles scroll bars, you're doing something wrong. NT 3.5 had the GUI entirely outside the kernel. For compatibility with Windows 95, much of the Windows 95 GUI code was moved into the kernel. 20 years later, that decision is still causing bugs.

api 12y ago
Backward compatibility is the root of quite a bit more evil than premature optimization.
- InclinedPlane 12y ago
  Modern CPUs still implement the A20 gate functionality, for example.
- barrkel 12y ago
  Backward compatibility, OTOH, is key to a large fraction of upgrade revenue.
wvenable 12y ago
I thought the big reason for moving the GUI into the kernel was for performance rather than compatibility.
- CurtHagenlocher 12y ago
  That is correct.
- 2510c39011c5 12y ago
  in terms of GUI, performance is responsiveness... and for a windows system, it needs to support a range of hardware configurations...Some could be really slow...
- Animats 12y ago
  That was the official word from Microsoft at the time, but Mark Russinovich, who had Sysinternals.com at the time, benchmarked and said that pushing low-level graphics commands (draw line, fill, etc; stuff graphics cards do) across the kernel boundary wasn't a bottleneck. He was critical of those decisions. Microsoft eventually hired him to shut him up.
  - jen729w 12y ago
    And because he was clearly a genius.
    - Animats 12y ago
      There's a story behind that buyout. Russinovich had a business called Winternals, and had written NTFSDOS [1], which allowed access to NT file systems under DOS.[2] Microsoft didn't like that, because it allowed booting from a floppy, bypassing NT's security restrictions, and resetting the administrator password, copying, or modifying files. (The concept that a computer could be secure when someone had enough physical access to boot a new OS seems silly now, but back then, the opposition was script kiddies, not intelligence agencies and organized crime.) So Microsoft bought Russinovich out. Wikipedia: "Winternals was acquired by Microsoft mid-2006. Microsoft has removed any traces of NTFSDOS..." [1] https://en.wikipedia.org/wiki/NTFSDOS https://en.wikipedia.org/wiki/NTFSDOS [2] https://web.archive.org/web/20000126093942/http://sysinternals.com/ntfspro.htm https://web.archive.org/web/20000126093942/http://sysinterna...
      - asveikau 12y ago
        > Microsoft didn't like that, because it allowed booting from a floppy, bypassing NT's security restrictions, and resetting the administrator password, copying, or modifying files. This sounds nonsensical, like folk history. You can already create a boot disk to do this using all Microsoft tools: Assuming the volume is not BitLocker'd it's pretty simple to do all of this stuff with WinPE [1], including the version that shipped in 2006, or with a Windows setup DVD. Or you could simply move the drive to a machine where you are an admin. I am pretty sure they bought winternals because they wanted to hire MarkRuss. [1] http://en.wikipedia.org/wiki/Windows_Preinstallation_Environment http://en.wikipedia.org/wiki/Windows_Preinstallation_Environ...
userbinator 12y ago
Windows started out as being for a single-user personal computer, and such a use-case is going to emphasise different features than something more security-oriented for large multi-user systems. The NT family was widely known for being more sluggish and resource-consuming than 9x, even in regular usage - I dualbooted with 98SE and XP for a long time, and the difference in responsiveness was very noticeable. Also, it could be argued that vulnerabilities like these which are only locally exploitable are not all that scary, as a personal computer should be by definition one that obeys its user no matter what. It's a bug, but not a "someone can take over your computer without you doing anything". Maybe it's because I grew up with personal computers that practically invited you to do whatever you want with them and had absolutely no "protection" whatsoever (early 8-bit machines, then DOS on a PC) that I find it hard to get scared or excited by local-only exploits like these.
- nitrogen 12y ago
  Local privilege exploits are problematic for corporate environments where not all users can be trusted 100%, and for the gullible less-technical users.
- comex 12y ago
  Today, with public hosting nearly universally offering VMs instead of traditional user accounts on a single operating system - never mind the whole Docker trend of giving every single piece of the application its own virtual OS install - are "large multi-user systems" even worth worrying about anymore? But this is basically orthogonal to the modern application of (OS-level) privilege boundaries, which is to protect the user from compromised application processes. This escalation doesn't let someone "take over your computer without you doing anything" by itself, but once someone has exploited an IE bug and found themselves able to run arbitrary code on users' computers in a sandbox - which happens all the time - that's exactly what it allows.
  - mjevans 12y ago
    The short answer is yes; such operating systems are required to run Docker, LXC and other approaches which all utilize similar tools. I'm not that familliar with Docker but looking at http://en.wikipedia.org/wiki/Docker_%28software%29 http://en.wikipedia.org/wiki/Docker_%28software%29 it is built on the same resource isolation features as LXC which I am using on two of my test systems. The resource isolation features are, in fact, built on top of a large multi-user system, which happens to have powerful security context support and abstractions built in. The contained applications operate, from a userspace perspective, as if they are their own system when in reality their kernel is actually the host kernel and their users really virtually re-mapped to distinct accounts within the host kernel.
nbevans 12y ago
Are you on crack? Windows does no such thing. It's called User32.dll for a reason. If what you say was true it would be called User32.sys i.e. a kernel driver. You're getting confused from the fact that graphics drivers and DirectX are primarily kernel mode components in Windows, which is done purely for performance reasons. It is not done for any backward compatibility reasons like you wildly claim. I would recommend that you read the NT Internals book by Mark Russinovich. Then you might actually show some respect to the NT kernel.
- na85 12y ago
  Ever try showing some respect to your fellow HN users?
  - 72deluxe 12y ago
    Anyone else noticed the rise of offensiveness here?
    - spacemanmatt 12y ago
      Goes with the territory; the front door stays open here. But yeah, I've noticed. It ebbs and flows.
- asveikau 12y ago
  This vulnerability seems to be in win32k.sys. The UI side of NT is something I know less about than other pieces, however, my understanding is that a lot of user32.dll in an NT-based system is simply trapping into win32k.sys. Similar to the fact that most stuff in ntdll is just a syscall stub. I respect the NT kernel but it has visible warts. I will give you that they are not always the same warts as what people complain about on HN.
- dang 12y ago
  > Are you on crack? Personal attacks are not allowed on Hacker News, regardless of whether someone else is wrong.
logicallee 12y ago
>When your OS kernel handles scroll bars, you're doing something wrong. it's pretty core to the idea of windows though. kind of like a printer - i wouldn't be surprised if a printer driver was in the kernel. or age of empires, which is a Microsoft property. just load it into the kernel in case you need it and you dont need much DRM, if people end up buying it it can get unlocked.
- goldenkey 12y ago
  A game residing in the kernel. Have you gone mad?!
  - logicallee 12y ago
    I cannot imagine how anyone didn't get that I was making a joke. Originally I ended by saying that I'd draw the line at including all of creative suites (photoshop, illustrator, etc) would be too much, since it's a third party and Microsoft shouldn't be playing favorites with what's in the kernel like that. in essence i was agreeing that a microkernel is no place for a scroll bar!
    - goldenkey 12y ago
      Your joke was a bit deadpan. But I'm laughing now ;-)
      - logicallee 12y ago
        sorry, i wasn't actually in a funny mood.
est 12y ago
More than that, Vista (along with .NET) put http stack into kernel. It's called http.sys
drzaiusapelord 12y ago
The kernel move was, reportedly, for performance reasons. I think if you use NT workstation at the time, you'd probably notice this compared 95/98. I believe MS also runs http in kernel space under http.sys. There's no backwards compatability there for legacy 8 or 16-bit apps as, you know, the web is younger than those apps and even then a browser would not need to interface with them. I think MS is eternally hamstrung by performance and legacy issues because those two things are in demand for so many of their customers. Windows fits this market, which is fairly sizeable. Of course now with hardware at the speed its at, you can get a lot more slack. I've found the linux desktop to be horribly slow until the past couple of years where there's a glut of CPU/GPU performance on even the most commodity equipment. I can run, and have run, Win7 on equipment that shipped with XP and its been a fairly pleasant experience. Running, say, a gnome or KDE WM on that equipment is a nightmare. MS, for all its faults, is fairly conservative in many regards, especially performance. At the end of the day this is yet another security issue that needs to be patched. The larger issue in my mind isn't MS decisions from 15 years ago, but why so much of our software infrastructure is being written in languages that more or less beg for stack/malloc vulnerabilities. These constant tirades about MS are just more "the beatings will continue until morale improves" and not really a constructive conversation about security. I think in the near future we'll be looking at all our stuff written in Rust-like languages and wonder why the hell it took so long to do. Lastly, Win10 is a technical preview. Finding bugs is exactly what should be going on here. Are we really being this critical on pre-release software? I don't see any other software held up to such a standard.
- CognitiveLens 12y ago
  > Lastly, Win10 is a technical preview. Finding bugs is exactly what should be going on here. FTA: "We have verified this exploit against all supported Windows desktop versions, including Windows 10 Technical Preview." The specific "Windows 10" aspect is click-bait; the exploit is for Windows
- floatboth 12y ago
  "we managed to create a reliable exploit for all versions of Windows – dating back as of Windows XP to Windows 10 preview"
deleted 12y ago
[deleted]
outworlder 12y ago
Not to mention that the scrollbar code is triggered by a LOT of window messages. If you wanted to draw scrollbars yourself, you'd have to eat a bunch of messages, not just WM_PAINT and the like. On my last count, you needed to swallow 11 different types of messages.
yuhong 12y ago
They finally created a separate font server process in Win10.

deepakexpert 12y ago

Thanks for share this news

mdriley 12y ago

This doesn't "bypass all Windows security measures". As of Windows 8, processes can disable win32k syscalls using SetProcessMitigationPolicy with ProcessSystemCallDisablePolicy. https://msdn.microsoft.com/en-us/library/windows/desktop/hh769088%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/hh7...

XbcL4QZQ 12y ago
Is ProcessSystemCallDisablePolicy somehow similar to seccomp on Linux? I understand that seccomp allows to selectively allow/disallow individual system calls while this disallows all win32k calls. But I don't know how similar these features are in the security impact. Apparently, chromium - which uses seccomp on linux - uses ProcessSystemCallDisablePolicy on windows: https://src.chromium.org/chrome/branches/1312/src/sandbox/win/src/process_mitigations.cc https://src.chromium.org/chrome/branches/1312/src/sandbox/wi...
- mdriley 12y ago
  They're comparable features. In both cases, a simple but hardened filter is placed in front of some part of the kernel attack surface. Vulnerable processes (e.g. renderers) opt in to these protections so that, in the event of compromise, they're less likely to be vectors for a successful escalation of privilege attack against the kernel syscall interface.

sandworm 12y ago

It's a flaw. A bad one. But things like this get patched every day. Only an idiot would believe there aren't plenty of other undiscovered security flaws in windows, or any other OS. What matters is whether this flaw was ever exploited, whether it was ever spotted in the wild, before it was patched. I am more than happy to criticize microsoft. I truly hate windows and everything it represents. But the system seems to have worked here. The bug was reported and patched before it became a widespread issue. I'll save my venom for those all-to-common days where Microsoft fails to address a problem in a timely manner. (or also Apple, plenty of venom for them too.)

sillysaurus3 12y ago
I am more than happy to criticize microsoft. I truly hate windows and everything it represents. Why's that? I'm hoping for an in-depth substantive analysis of the factors leading you to come to such a conclusion, but I don't want to take up a bunch of your time or make it seem like I'm asking you to justify anything.
- sandworm 12y ago
  Windows is a proprietary ecosystem where choices are made for the benefit of microsoft's shareholders and nobody else. It is full of compromise. From DRM to hamstrung "student" versions, Windows is not your friend. Microsoft's business practices, specifically the way they market windows on oem machines, are also downright deceptive. I never use windows at home but, because I buy laptops, I actually own many windows licenses. Those "sales" are part of Microsoft's bottom line and are pitched to shareholders as if I am actually using microsoft products. I have never met anyone who truly likes windows. They tolerate it. They are used to it. But they never say "Yes, I am happy with this new version. The upgrade sure made my life easier!" I'd rather have my wisdom teeth re-installed and re-pulled than be part of another office transitioning from one version of windows to another. I gave up on windows when, after buying a little netbook, I decided to give it a chance. I plugged in an MS-brand optical mouse and was told that windows needed to connect to the internet to download the driver to run the mouse. That was windows's last breath on any of my personal machines. And death to docx.

peterkelly 12y ago

> This particular vulnerability appears in the GUI component of Microsoft Windows Kernel There's your problem right there.

72deluxe 12y ago
Are you saying that Microsoft are incapable of releasing a decent product or a stable API? If so, you'd be wrong on the second count, and I'd say the first too but then argument would ensure. The Windows API and all related systems are stable and mature. And I'm saying this as an OSX user.
- peterkelly 12y ago
  > Are you saying that Microsoft are incapable of releasing a decent product or a stable API? No, I'm saying that implementing scrollbar handling in the kernel is a bad idea. It's not something which requires privileged system access, and thus should be done in user mode where bugs like this won't lead to privilege escalation.
  - 72deluxe 12y ago
    But everything in the OS will use a scrollbar, so put it in the kernel, right? :-) Only kidding. I think OSX got around this problem by removing scrollbars haha only kidding You make an excellent point, sorry to misunderstand your original post.

MichaelGG 12y ago

How many of those new protections listed (DEP, ASLR, page 0 mapping) are still useful with a system like Rust? Cause it seems like a hell of a lot of effort is going into hardening the environment cause the code is just that leaky, but I'm probably misunderstanding something.

nly 12y ago
Theoretically if you had a kernel written in Rust, I suppose you could implement the system call interface such that all pointers passed to the kernel from user space would be considered "borrowed" under the Rust type system, and then have all your "return to user space" mechanisms recognised by the compiler as terminating their lifetime. I'm not sure if that's enough though, considering that, in general, the kernel can't assume anything passed to it by reference via a system call isn't mutated by another userland thread. Furthermore, even if everything were written in Rust, the kernel can't just trust that a userland process was actually compiled in a way that faithfully employed Rusts compile-time safety guarantees... so I think any notion of shared garbage collection is tricky without a program loader that did code verification. Microsoft have done some work in this area with their Singularity and Midori projects[0]. Singularity in particular eliminates hardware isolation between processes. I think the simple answer here is that the kernel should be copying anything passed to it by reference if it intends to do anything beyond a single atomic read operation. This is why, on Linux for instance, send() can't return to user space until the data has been copied in to kernel controlled memory, and why we have nice things like splice() and sendfile() to deal with the performance hit of doing so for common cases. [0] https://en.wikipedia.org/wiki/Midori_%28operating_system%29 https://en.wikipedia.org/wiki/Midori_%28operating_system%29
- TheLoneWolfling 12y ago
  Removing hardware isolation in general is not a good idea. There are enough hardware errors to cause problems. You don't want a bitflip to cause everything on your server to become corrupted. (Bitflips can be reduced by using ECC ram. But still, the principle remains.) (Worse: you don't want someone to be able to take over your entire physical server from one of the virtual servers) One option would be for the kernel to temporarily mark the page(s) referenced as read-only, and do copy-on-write where necessary. This would prevent the (presumably) common case of not having the page modified by another thread while the kernel processes the data to not incur the delay of copying the data. Might only be worth it for larger amounts of data, though.

laurent123456 12y ago

How do they find exploits like this? Do they check every single kernel functions for unchecked pointers? Do they have some automated way to discover this?

gldalmaso 12y ago
On figure 4 the legend says that static code analysis made it possible to discover the chain of calls.
- pbhjpbhj 12y ago
  How many billions are MS making from Windows? Why aren't they doing that static analysis??
  - ToastyMallows 12y ago
    Maybe they are and this was already documented internally, but potentially marked as a low threat, but now that it was found outside of Microsoft it's a bigger problem? I'm just spitballing here, one would have to assume that Microsoft is doing static code analysis.
    - pbhjpbhj 12y ago
      OK, but it wasn't found before the current OS cycle presumably because one would imagine they'd fix it ... ha-ha! So it either wasn't found or they found it and continued to bake it in to the OS nonetheless. Which is better?

72deluxe 12y ago

The dead code comment at the end was informative. Does anyone else use code analysis of C/C++ to find dead stores etc.? I have used flawfinder, cppcheck and Xcode (clang's) analysis which has helped me find issues.

TheCraiggers 12y ago

> After some hard word, however, we managed to produce a fully working exploit which we’ll describe. Wait, now I'm confused... was it a single bit, or an entire word that triggers this bug? ;)

thclark 12y ago

Remove those unnecessary lines of code and you will be surprised how the security holes close by themselves.

zaroth 12y ago

I'm sorry, wait... they hacked it through the scroll-bars? You can't make this shit up.