The past few days have been busy if you’re trying to keep up with the pace of computer security news. Between a serious Chromium bug that’s actively being exploited on Windows 7 systems, the NSA releasing one of their tools as an open source project, and a new Spectre-like speculative execution flaw in Intel processors, there’s a lot to digest.
Intel’s Spoiler
To discuss “Spoiler” let’s do a quick refresher on how we got here. Speculative Execution is a staple of modern processors, allowing code to be executed out of order, and caching the results until needed. Instructions Per Cycle (IPC) has become an important metric as clock speed has stalled out at the 5 GHz barrier. Speculative Execution was dealt a blow when Spectre and Meltdown were announced. The essence of both attacks is that speculative execution has discernible effects. Try to access something you shouldn’t be allowed to see, and with some clever timing attacks against the cache, the protected data is leaked to another process.
Rowhammer is an attack against a machine’s physical memory. Modern memory only holds state for a limited period of time, and needs to be refreshed several times a second. It turns out that flipping nearby bits can cause that state to degrade more quickly. The Rowhammer exploit rapidly flips specific bits in order to affect neighboring ram, even if those memory addresses belong to different processes. It can change data in places that should be protected. One of the mitigations for Rowhammer is that the attacking process needs to understand the physical memory layout. There are various techniques that hide how a process’s memory is mapped to the physical layout, like Kernel Address Space Layout Randomization (KASLR).
Spoiler is a new abuse of speculative execution that leaks information about the physical memory layout, enabling much quicker Rowhammer attacks. The Register was the first to pick up on this story. Intel processors have a memory management system that allows speculative execution of memory load and store commands. The researchers realized that in certain cases, the delay in memory operations leaks enough information about the physical layout to perform a Rowhammer attack. They demonstrate a Rowhammer attack from an unprivileged user, and even from within a Javascript sandbox.
National Security and Ghidra
The National Security Agency (NSA) is no stranger to Open Source, as ironic as that thought may be. They developed and released Security Enhanced Linux (SELinux), as well as SEAndroid. Ghidra was first “announced” rather unintentionally, as it was repeatedly mentioned in the Vault 7 leak on Wikileaks. It’s a reverse engineering tool-kit, supporting many architectures and running on Linux, OSX, and Windows. The NSA officially announced Ghidra as a new open source project at the 2019 RSA conference.
The code has yet to be released, but the binaries are available and the full source code will be released as soon as possible. The NSA promises the binaries aren’t backdoored. On a totally unrelated note, running Ghidra in debug mode opens port 18001 to all network interfaces, allowing remote code execution. While suspicion and jokes have abounded, the quality of Ghidra seems quite high, and commercial reverse engineering tool-kits are priced out of the budget of many of us. We look forward to the release of the full source code, and taking advantage of this new tool.
Chromium, Windows 7, and Use-after-free
Use-after-free is a class of memory management vulnerability. When a program allocates memory for a data structure, that memory is reserved and the program uses a pointer to access what is stored there. Once the allocation is no longer needed, the memory is freed. What happens, then, if the program tries to access the memory after freeing it? Once the memory is released, any other process could be assigned that memory. An attacker can attempt to allocate the same physical memory location once it has been freed. When the vulnerable program tries to access the freed memory, it’s reading the attacker’s payload.
Chromium contained a Use-after-free bug in the file_reader_loader routines. Multiple references to a single data structure were unintentionally available, and not all those references were deleted when the data was freed. Google has fixed the issue in Chromium, and released a statement linking the Chromium vulnerability to a Windows kernel vulnerability. It seems that these two problems are actively being exploited in tandem to achieve remote code execution and privilege escalation.
Google took the unusual step of recommending that users of Windows 7 upgrade to Windows 10, as the security features of the newer Windows release seemed to prevent exploitation. As support for Windows 7 fully ends January of 2020, the hands of time are slowly ticking toward the inevitable demise of Windows 7.
See some exciting security news we should be covering? Head over to the tip line and let us know!
” An attacker can attempt to allocate the same physical memory location once it has been freed. When the vulnerable program tries to access the freed memory, it’s reading the attacker’s payload.”
Shame zeroing out memory costs so much.
Wouldn’t help; the problem is not a memory leak from Chrome to the attacker code, the issue is that Chrome re-uses a bit of memory that others have the ability to write to.
I maybe being dumb here, but isn’t this the kind of thing compilers warn about? Also, isn’t accessing freed memory normally enough to cause a segfault?
No and no: pointers can hang around in all sorts of places, and statically determining if a pointer is valid at any point is basically impossible. Also, segfaults only occur after memory is returned to the os (or otherwise marked as protected), which doesn’t necessarily happen when an object is freed.
What awesomeclaw said.
For this there are tools like valgrind [1] which, among other things, run your code with instrumented malloc/free interfaces and even can run your code under a virtual machine to watch memory accesses. But you gotta somehow “run” the code (and take the right branches, not always easy). Static analysis may help, sometimes, a bit.
[1] https://en.wikipedia.org/wiki/Valgrind
It’s quite common IME to have a debug mode where memory is marked (usually not zeroed as that’s a common payload) on free (and in some more paranoid cases checked to be zero on allocation). Makes catching these things a bit easier.
In this case it appears that the memory is reallocated and then accessed, which zeroing or otherwise marking wouldn’t detect.
That seems like the perfect way for Micro$oft to push the remaining users off of Win7.
Yes, I am paranoid, but that doesn’t mean someone isn’t out to get me…
Windows users are willing to be abused. If they weren’t then they would have fled to another OS. I’m not saying transitioning to another OS is easy, what I am saying is that they rather be abused than make the transition.
Ignoring the great cost at making that transition hence this not being the year of desktop Linux.
Paranoid: what’s crazy about this is that it’s Google telling you to update Windows to mitigate the impact of a (now fixed) bug in Chromium.
How deep does the rabbit hole go?!?!
(Hint: probably not that deep. It’s probably an honest assessment of security advances in 10 vs 7.)
They can pry win7 from my cold dead privacy violated hands.
It is 2019. You can quit using the dollar sign. Microsoft has been quite vocal about getting current users to move to 10 for security and there are many articles on the web. You aren’t paranoid, you are just hanging out in echo chambers.
It is not like people won’t be able to run Win 7 at their own risk, it is just end of life cycle to focus on improving a cohesive product. There are a lot of cool articles here on HaD you should check out about retro computing. There was a big one the other day about people making Commodore 64s.
It should go without saying that you shouldn’t buy any Intel chips in the future.
Similar techniques are used by all high performance CPUs. Intel CPUs are simply the biggest attack surface because of their popularity.
The use after free issue makes we wonder about ideas concerning using encryption built into the memory controller to protect process memory from being read by another process. I wonder how fine grained this could be so an attacker wouldn’t be able to make meaningful changes to a target buffer.
The release of Ghidra seems like it could be a big deal but it sounds like it should be run in a sandbox until the source is released and it’s checked for issues.
Encryption in the memory controller is only really useful against Cold Boot attacks (when black suit gentlemen knock on your door) and virtualisation.
Quickly looking at “AMD_Memory_Encryption_Whitepaper_v7-Public.pdf” there’s no mention of inter-process security.
This is proof positive that humans are insane and doomed as a species, they have been making this same error over and over again for decades and there is no sign of any improvement in the situation.
Feel free to design a computer and language that doesn’t have hairy memory management. So far, there still seems to be a class of problems that requires c-like languages and their memory models.
Someday, there’ll be a bug or exploit with a cutesy name like mittens, sparkles, or fuzzy ears…
Are you looking for Pixie Dust attack on WPS?
This Ghidra looks interesting (IDA is stupid expensive!!), but even with full source code released and inside a VM i will not run this. Call me paranoid but the NSA might have some super hard to spot backdoor somewhere. I don’t trust these guys…
Launching NSA’s binary? Without source? Geez really cool offer :D. They should also release “how to get yourself backdoored – for dummies” book, aren’t they? ????
gcc has both runtime and compiletime checks for all sorts of things
-fsanitize=leak -fsanitize=address -fno-omit-frame-pointer -fsanitize=bounds-strict -fsanitize=object-size -fsanitize=undefined -fsanitize=integer-divide-by-zero -fsanitize=shift -fstack-protector-all -fsanitize=builtin -fsanitize=pointer-overflow -fsanitize=enum -fsanitize=alignment -fsanitize=return -fsanitize=signed-integer-overflow -fsanitize=null -fsanitize=shift-base -fsanitize=shift-exponent -fsanitize-address-use-after-scope -fstack-check -fstack-clash-protection -fanalyzer