This Week In Security: IOS, OpenSSL, And SQLite

Earlier this week, a new release of iOS rolled out, fixing a handful of security issues. One in particular noted it “may have been actively exploited”, and was reported anonymously. This usually means that a vulnerability was discovered in the wild, being used as part of an active campaign. The anonymous credit is interesting, too. An educated guess says that this was a rather targeted attack, and the security company that found it doesn’t want to give away too much information.

Of other interest is the GPU-related fix, credited to [Asahi Lina], the VTuber doing work on porting Linux to the Apple M1/M2 platform, and particularly focusing on GPU drivers. She’s an interesting case, and doing some very impressive work. There does remain the unanswered question of how the Linux Kernel will deal with a pull request coming from a pseudonym. Regardless, get your iOS devices updated.

The Coming OpenSSL Apocalypse

OK, probably not. But still, the folks behind OpenSSL have announced version 3.0.7 coming November 1st, and have already warned that it will contain a fix for a CRITICAL vulnerability. For those keeping track, this is the second vulnerability fixed in the OpenSSL project to get the CRITICAL rating, going back to 2014 when they started rating flaws. This problem only affects the 3.x release series, so distros like Red Hat Enterprise Linux and clones are safe, as they’re still on the 1.1.1k release.

It is interesting that OpenSSL announces the presence of a serious flaw, and a bit of information about when it was introduced, a week before release. You might think that you can just go find the latest security fix in their git repository, but it seems that fix is being held til just before the version release. Approaching the problem from the other end could work, you’d just have to look for the commit that introduced the vulnerability. We even get a hint, it’s only in the 3.x series of releases. It seems the previous version was forked for maintenance back in 2018, so any commits to the master branch since then are fair game. That’s a bunch of commits to wade through, though I’m confident multiple researchers are attempting it. This happens to land at the perfect time to trigger a Fedora 37 release date slip. Last minute update, Fedora delayed the release of 37 for this bug.

Word To Ring Zero

This one is mainly for fun — or a testament to the power of Visual Basic embedded in Word documents. Either way, a vulnerable antivirus driver can be used to elevate a user process up to kernel-level execution. As a fun challenge, [DISREL] decided to port the exploit to VBA, and run it from a word document. Keep in mind there’s some setup here, like turning off some features that prevent running VBA automatically, and having the vulnerable driver installed. Still, It’s fun. Enjoy.

Give Out Processor Time, People Mine Crypto

Freejacking is all about taking advantage of free trials and free tiers of compute services. Digital Ocean offers a 60 day free trial? Time to mine! If you’ve ever been annoyed at how hard it is to get set up on a free trial, that’s part of why. Researchers at Sysdig have identified a previously unknown ring of scammers, and have dubbed them PURPLEURCHIN. The scheme is impressive, starting with many docker images that include miners and a Command & Control node. The mining happens on free GitHub accounts, as GitHub actions. Carefully kept just under the limits for free accounts. In fact, one of the themes of this whole operation is carefully flying under the radar. That may be why the mining isn’t for any of the big coins, but the likes of Tidecoin and Onyx. Clever.

Stranger Strings in SQLite

The SQLite project is one of the most secure, boasting a code test suite that manages 100% coverage. It’s pretty much as close to bulletproof as code can get. Which is why [Andreas Kellas] was particularly surprised when he managed to make it crash. So here’s the lowdown. SQLite has a 1 GB internal limit. By definition, you can’t feed it more data than that at once. Except, you can call SQLite’s API from a C program, and it’s pretty easy on a modern system to allocate way more memory than that. Feed it a 2 GB string to process, and you’re outside test coverage, even when the test suite boasts 100% code coverage.

The exact API call is sqlite3_snprintf(), a string formatting function, specifically written to handle some special characters like quotation marks in the input. The code uses an int internally to keep track of the extra output size, and grows the size as special characters are encountered and escaped. If that length exceeds 2,147,483,647; then two’s complement math kicks in and it rolls over to a negative number. A negative number is smaller than the stack buffer size, so the whole string gets written to the stack, smashing things and causing the crash.

A crash is interesting, but with a crack discovered in SQLite’s armor, is there a way to exploit? The problem is that the gigabytes-long string needed to trigger the exploit is way too much data to copy onto the stack. There’s another integer, i, that keeps track of the number of input bytes, as well as controlling exactly how many bytes are copied to the destination buffer. As a for loop process the input buffer, a special case involving Unicode characters will increment i without affecting the other counters. Trigger that case enough times, and i also overflows. Now remember earlier when we just assumed that overflowing an int results in a negative number? It’s not so simple.

Integer overflow is actually undefined behavior. Did the compiler opt to make this int 32, or 64 bits? The exact CPU instruction may temporarily handle the value as a 64-bit integer. It may or may not see it as a signed integer, for that instruction. And most interestingly, a single program can contain different combinations of these options at different points. And in the version of SQLite [Andreas] was working with, this was the observed behavior. In one calculation, the 32-bit integer overflowed into negative, and was “sign extended” to cast into a 64-bit value — still negative. In another instruction, the value was incremented by one, as a 64-bit value. For that memory access, no overflow happened, as it was treated as a normal 64-bit integer. Call it a “Divergent Representation”, where two different values can be read from the same source variable. Trippy.

Careful management of these variables and tricks allows for near-arbitrary writing to the stack. If an attacker could supply the string that was sent to the vulnerable function, and that function is called with a format string that makes it possible, then it could allow for arbitrary code execution. The good news is that not every application that uses SQLite is vulnerable. As ubiquitous as the SQLite library has become, there are like a handful of vulnerable uses out there. Version 3.39.2 fixes the vulnerability.

Bits and Bytes

DEF CON 30 talks are finally available for all, and there appear to be some goodies in there. Like the kid that Rickrolled his entire school district as a senior prank. And of course [Sick Codes] and his infamous Tractor Doom mod on a John Deere.

The password is dead, long live the passkey. You may have heard of Passkey, the new standard from Microsoft, Apple, and Google. It’s the death of the password that we’ve been promised for so long. So how does it work? Instead of passwords, your device automatically generates a private key per service. When you need to log on, the device prompts for a biometric or PIN, and then uses the private key to authenticate. For more technical information, check out the FIDO multi-device credentials white-paper.

Want to try your hand at browser exploitation, but not sure how to start? [Jack Halon] is starting a series on the deep internals of web browsers. It quickly gets into memory layouts, and how the underlying language manages JS objects. Good stuff.

And to cap the week, the reference implementation of SHA-3 has a buffer overflow. It’s essentially an integer overflow. It remains to be seen how big of a deal this is, though I can imagine many projects have simply copied and pasted this code. That’ll take a while.

13 thoughts on “This Week In Security: IOS, OpenSSL, And SQLite

  1. “The password is dead, long live the passkey. You may have heard of Passkey, the new standard from Microsoft, Apple, and Google. It’s the death of the password that we’ve been promised for so long. So how does it work? Instead of passwords, your device automatically generates a private key per service. When you need to log on, the device prompts for a biometric or PIN, and then uses the private key to authenticate. For more technical information, check out the FIDO multi-device credentials white-paper.”

    So, just another 2FA?

    1. Yes and no. The primary authentication is done via the key stored in the device. The key is in your key store/keychain which requires user authentication locally. So yes, two factors are used but only single factor to the service.

    1. It’s new because it doesn’t use passwords anymore. So even server breaches won’t result in breached passwords anymore. It’s a fundamental change which makes authentication easier on the user and much safer as a total.

    2. “Passkeys just trade WebAuthn cryptographic keys with the website directly. There’s no need for a human to tell a password manager to generate, store, and recall a secret—that will all happen automatically, with way better secrets than what the old text box supported, and with uniqueness enforced.”

      Please show me the existing password manager who can do this.

    3. From one of the promoted comments on the linked Arstechnica article:
      “Q: How is this different than a long password in a password manager?
      A: No more phishing! […] Passkeys are a) asymmetric, so if you accidentally authenticate with a fake page, they don’t get any sensitive info, and b) include hostname validation as part of the protocol, so making sure you’re on the right page is a first-class concern and not a super fragile layer on top.”

  2. The relevant info on that new FIDO thing:
    “The proposed additions to the FIDO/WebAuthn specs define a protocol that uses
    Bluetooth to communicate between the user’s phone (which becomes the FIDO authenticator) and
    the device from which the user is trying to authenticate.”

    So it needs a smartphone.. And no doubt nicely works two ways also positively identifying WHO is authenticating and so nicely kills anonymous accounts.. purely coincidentally of course, on this system pushed by MS/Google/Apple..

  3. Circular discussion. It’s always a matter of 1’s and 0’s that can be replicated and replayed, layer by layer, in many ways to fool an authentication system. All the proposed techniques exist to make the fraud a little more fatidious. But at the end, the reality is that all doors have always being open.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.