Researchers at the NCCGroup have been working on a 5-part explanation of a Windows kernel vulnerability, targeting the Kernel Transaction Manager (KTM). The vulnerability, CVE-2018-8611, is a local privilege escalation bug. There doesn’t seem to be a way to exploit this remotely, but it is an interesting bug, and NCCGroup’s work on it is outstanding.
They start with a bit of background on what the KTM is, and why one might want to use it. Next is a handy guide to reverse engineering Microsoft patches. From there, they describe the race condition and how to actually exploit it. They cover a wide swath in the series, so go check it out.
Just a reminder that bugs show up where you least expect them, [Hunter Stanton] shares his story of finding a code execution bug in the popular Valve game, Left4Dead 2. Since the game’s code isn’t available to look at, he decided to go the route of fuzzing. The specific approach he took was to fuzz the navigation mesh data, part of the data contained in each game map. Letting the Basic Fuzzing Framework (BFF) run for three days turned up a few possible crashes, and the most promising turned out to have code execution potential. [Hunter] submitted the find through Valve’s HackerOne bug bounty program, and landed a cool $10k bounty for his trouble.
While it isn’t directly an RCE, [Hunter] does point out that malicious mesh data could be distributed with downloadable maps on the Steam workshop. Alternatively, it should be possible to set up a fake game server that distributes the trapped map.
Big Brother Apple?
There is a constant tension between security and privacy. We’re used to governments making arguments about giving up privacy for the sake of security, but the same trade-off can show up in computer security, too. In this case, Apple has implemented an online check for every executable run by a macOS Catalina system. If you’re running macOS 10.15, you might have noticed your system is a bit slower than it should be. It seems that when connected to the internet, a modern Mac will upload a hash of each binary to Apple, assumably to check it against a blacklist of known malware.
The Reddit thread discussing this issue had a few more interesting observations. First off, one user pointed out that he had observed this issue while flying and connected to the terrible in-flight wifi. A second poster observed that a Mac will take an inordinate amount of time to reboot when connected to a network without internet access.
While there is likely an upside, this approach is terrible for performance and user privacy, and a breach of trust between Apple and their users. If they wanted to monetize the data, Apple now has a record of which binaries are run by which users and when. This sort of behavior should be documented at the very least, and come with an off switch for those who don’t wish to participate. The fact that it was discovered by internet sleuths is a black eye for Apple.
An interesting attack on certain ECDSA schemes was published on the 25th (PDF). This attack was specifically developed against OpenSSL, and uses a Flush+Reload cache attack to leak information from the elliptic curve operation as it is calculated. At some point we’ll do an in-depth look at elliptic curve cryptography, but for now it’s sufficient to understand that a mathematical operation is performed repeatedly in order to do key exchanges.
For each iteration, the researching team were able to extract approximately one bit of information about the internal state of the key. (Technically less than one bit, since it is a statistical attack.) After the data collection was carried out, a rather intensive CPU process is required to calculate the key. It’s not an attack that is particularly practical at this point, but it’s still important for the affected projects to mitigate against.
The math required to fully appreciate their work is pretty intense, but if that’s your thing, it’s there to be appreciated. For the rest of us, it’s just good to know that our algorithms are under such scrutiny from the good guys. We all win as a result.
The iOS security landscape has been in a tizzy over the last few weeks. It wasn’t long ago that an iOS exploit was the holy grail of security research, but just recently Zerodium, a zero-day vendor, has stopped accepting iOS zero-days because they have too many.
We will NOT be acquiring any new Apple iOS LPE, Safari RCE, or sandbox escapes for the next 2 to 3 months due to a high number of submissions related to these vectors.
Prices for iOS one-click chains (e.g. via Safari) without persistence will likely drop in the near future.
— Zerodium (@Zerodium) May 13, 2020
There’s been a new development, a jailbreak for any device running iOS 11 or newer. This jailbreak, named unc0ver, requires an unlocked phone and a computer. It’s quite a boon to researchers and end users alike.
COVID-19 Contact Tracing — What Could Go Wrong?
The Australian government has developed an Android and iOS app to track the spread of COVID-19, and it seems that it went wrong in all the predictable ways. For starters, it seems that once a device has the app installed, that device can be tracked even after it’s been uninstalled. A few of the issues have been fixed,
but as the app is closed source, it’s impossible to fully verify that it’s well behaved. Update: The source is available, but under a bizarre license. We suspect that there are other bugs. The link above is the working document maintained by a handful of researchers working to audit the app.