Windows has security holes too ("single bit" exploit)
-
They manage to overflow a single bit in the scrollbars visibility code, then use that to mess with window properties list and cause a buffer overrun.
An amazingly convoluted exploit. They acknowledge it themselves that this was HARD to figure out, much harder to break Windows than it used to be.
Moneyshot:
https://www.youtube.com/watch?v=ukAr6MiA788
Very good explanation on their site. They made it understandable even for a non-C non-assembly programmer like myself.
-
The Evil Bit™
-
Responsible disclosure: although this blog entry is technical, we won’t reveal any code, or the complete details, to prevent any tech master from being able to reproduce an exploit.
s/tech master/script kiddie/
-
-
If it only works in Windows 10 which is a tech preview, I'd say let the script kiddies try whatever they want.
-
-
-
Nope, all versions down to XP.
To be fair, it's a little buried in the article. But yeah.
-
They manage to overflow a single bit in the scrollbars visibility code,
That doesn't even make sense. Computers can't address single bits.
From article:
Interestingly, the exploit requires modifying only a single bit of the Windows operating system.
That makes even less sense. If you can modify the OS, you don't need an exploit. You're done.
This entry starts by detailing the vulnerability. At first, it seemed to us impossible to exploit. After some hard word, however, we managed to produce a fully working exploit which we’ll describe.
I see they worded hard on their proofreading.
I note the article stops before it actually explains how any of this bullshit can actually result in privilege escalation.
Did these guys find a security hole? Possibly; from their write-up, I think they're just idiots who got lucky.
-
From the fourth paragraph of the article (emphasis mine):
At first, it seemed to us impossible to exploit. After some hard word, however, we managed to produce
@accalia approves of this tyop.
-
That doesn't even make sense. Computers can't address single bits.
So we're back to aggressive illiteracy today?
...we can use this to either Bitwise OR the first DWORD of the freed buffer with 0xC (if we disable the arrows) or to clear bit 3 and 4.
That makes even less sense. If you can modify the OS, you don't need an exploit. You're done.
Yes, clearly you've shown why there's no vulnerability and why there isn't a patch for it.
Our examination showed that the tagSBINFO pointer is used without any verification after the callback. Ultimately, this could lead to a Use-After-Free (UAF) vulnerability...
-
So we're back to aggressive illiteracy today?
Mostly I'm griping about the "very good" explanation on their site. The explanation is garbage. I hope the write-up they provided Microsoft was at least an order of magnitude better.
Yes, clearly you've shown why there's no vulnerability and why there isn't a patch for it.
THEY are the ones who wrote "modify the OS" when it's obviously not what they meant. Don't blame me.
-
THEY are the ones who wrote "modify the OS" when it's obviously not what they meant. Don't blame me.
I just know how you hate hate HATE pedantic dickweedery.
-
I just know how you hate hate HATE pedantic dickweedery.
That's not pedantic dickweedery. That's me reading what they actually typed.
I have no telepathic abilities available to know what they meant to type; I only have access to what they actually typed. Which is idiotic.
-
@blakeyrat beat you to it. It's glaring because it's the post exactly before yours.
-
That's not pedantic dickweedery. That's me reading what they actually typed.
They typed a lot of other stuff, too, but you got stuck on that one sentence.
I have no telepathic abilities available to know what they meant to type; I only have access to what they actually typed. Which is idiotic.
You could have read the other stuff in the article like other people did.
-
You could have read the other stuff in the article like other people did.
I read the entire article. At no point do they explain where they modify Windows.
-
@blakeyrat beat you to it. It's glaring because it's the post exactly before yours.
hanzo'd then....
i'l admit i had skimmed the topic earlier and then noticed that tyop when i clicked through a second time to send to out network admin.
Fair play to @blakeyrat for catching the tyop first and all credit shall accrue to him as is only right and proper.
-
At no point do they explain where they modify Windows.
My point, exactly. A less aggressively illiterate person would likely conclude that instead of "one bit in the Microsoft Windows operating system," they probably meant something like, "one bit in a program running on a Microsoft Windows operating system."
But you already think that it's impossible to change just one bit, so I'm not sure why we should be listening to you.
-
It's one bit in the data structures kept by the Windows operating system...so yes, it is one bit in Windows itself, just a bit of data, not a bit of code.
-
Saying "a single bit of Kernel memory" would have been more accurate.
Still, that doesn't make it much easier to turn this into an actual attack. I don't understand how they go from "we can now misreport the size of a heap-allocated structure by one 16-byte block" to "arbitrary code execution".
-
Still, that doesn't make it much easier to turn this into an actual attack. I don't understand how they go from "we can now misreport the size of a heap-allocated structure by one 16-byte block" to "arbitrary code execution".
The rest is a heap overflow of the type already known in the literature, so they don't spend time explaining what's already well-trodden ground for the security community.
-
I still think they're idiots.
-
You're right I guess.
I just have no idea how a heap buffer overflow can cause ACE (unlike stack buffer overflows which I understand without problem).Edit: Ah, just thought of something, such as messing with the next object's vtable pointer.
-
You just have sand in your vagina because we're showcasing a Windows bug instead of Linux, as usual.
-
I just have no idea how a heap buffer overflow can cause ACE (unlike stack buffer overflows which I understand without problem).
The classic (long countermeasured away) technique would overwrite the prev/next pointers of the following heap block so that when the allocator went to allocate that block it would write an attacker-controlled value at an attacker-controlled location (what's called a "write anything anywhere" gadget) which you could then use to overwrite a return address or whatever you please. Heap integrity checks make that exploit a lot harder now.For a concrete example of a modern heap overflow exploit that is actually explained pretty well, the GHOST vulnerability description (the recent overrun in glibc's
gethostname) contains an example exploit that uses a buffer overrun to overwrite the size field of the next heap block. That heap block is free, and the overwrite makes the block look larger than it is; a later allocation then gets that block and that results in two allocations overlapping. The contents of the later allocation are attacker-controlled, so that means they can overwrite the stuff in the original allocation of that space.
-
This reminds me of the method of jailbreaking Windows 8 RT, someone found a way to abuse a buffer overrun and modify a single bit in the Windows kernel that allowed it to execute unsigned code.
(Unfortunately, this was patched for 8.1 RT so I can't jailbreak my Surface. We think one person has figured it out but he/she/it is not releasing the new method so they can continue to use it without Microsoft patching it away.)
-
GODDAMNlT CARTMAN I DO NOT HAVE SAND IN MY VAGINA!
-
I just have no idea how a heap buffer overflow can cause ACE (unlike stack buffer overflows which I understand without problem).
No, no, no, it's privilege escalation, not code execution. You use this to get admin access on a computer you can already run code on.
I got the theme that it was adding a reserved property name to the window, probably something like "was this launched as admin?". But you'd need to see the list of reserved property names to figure out which one.
-
-
Thanks, EvanED and riking.
-
A less aggressively illiterate person would likely conclude that instead of "one bit in the Microsoft Windows operating system," they probably meant something like, "one bit in a program running on a Microsoft Windows operating system."
You really expected Drax to get that? His deduction engine seems to be broken.
-
My point, exactly. A less aggressively illiterate person would likely conclude that instead of "one bit in the Microsoft Windows operating system," they probably meant something like, "one bit in a program running on a Microsoft Windows operating system."
Maybe they're using "bit" in the informal, non-technical sense, to mean "a small amount'. When they say the "changed one bit of Windows", they mean they swapped out a device driver, or a DLL file, or something...
-
If you can swap out a system library, you already have access to the computer. You're on the wrong side of an air-tight trapdoor.
-
No. They mean they changed one bit (a literal bit, a binary digit) of a kernel data structure.
-
No. They mean they changed one bit (a literal bit, a binary digit) of a kernel data structure.
Exactly, it wasn't a huge change they made, they just changed the OS a little bit, but that was enough.
-
You really expected Drax to get that?
No. Like I said, "A less aggressively illiterate person..."
Maybe they're using "bit" in the informal, non-technical sense, to mean "a small amount'. When they say the "changed one bit of Windows", they mean they swapped out a device driver, or a DLL file, or something...
No, they're definitely talking about a single bit. At one point they say something like, "for simplicity, we'll talk here about changing two bits (by xoring 0x0C), but it can be done by changing a single bit." I assume that was to simplify something and also to obscure the actual exploit (which they explicitly said they wanted to do).
