Ask HN: What happened to Apples “rapid response” security updates | Hacker News Reader

Ask HN: What happened to Apples “rapid response” security updates

During the past two days, Apple has released updates 16.5.1a to iOS and macos, ostensibly fixing zero-days that have been exploited and/or observed in the wild. [1]

Then they pulled them, referencing "breaking changes" to Safari, as rumors say, because of the User agent string.

So if the problem really was the version number string, that should be easy to fix by increasing the version number instead of appending "a" to it.

However, this might not be the full story...?

Currently there seems to be no simple way to obtain the updates. But when announced, they were ostensibly fixing serious zero-click RCE vulnerabilites.

I couldn't find any official communication regarding this, so..?

[1] https://support.apple.com/en-us/HT201224

View on HN

The current CVE-2023-37450 seems to be related to the InjectedBundle API, which also allows IndexedDB access.

Back in 2021 there was the "history leaking" bug where you could write a little JS code to access the devtools whose window shared the IndexedDB with the rest of all tabs (and cookies, and userdata etc).

If you take a look at the recent WebKit commits, it seems like there were a bunch of bugs related to the InjectedBundle, that's why I am assuming it might be a critical RCE that results in yet another use after free in the IndexedDB or related code.

Back when I forked off RetroKit as a WebKit fork, I also decided to reduce the attack surface in terms of what is shared across the web contexts. I decided to remove a lot of APIs that I thought were too unsafe, both in terms of tracking and exploitation. [3]

[1] https://googleprojectzero.github.io/0days-in-the-wild/0day-R...

[2] https://github.com/WebKit/WebKit/commits

(see also the other release versions, not only main branch)

[3] https://github.com/tholian-network/retrokit/blob/main/SECURI...

Thanks for the thorough explanation! IIRC, IndexedDB or WebSQL has spectacularly failed, sadly, as it was meant to fill a real need. I'm sure there are many legitimate apps and sites using it, especially for PWA offline functonality... but I've only seen one of them in my career as a web dev so far.

And to be honest, the only reason they used it was because the developer probably wanted to.

So thinking twice, no, it wasn't a legitimate use, the 2KB of unstructured data they stored were easy to fit into localStorage...

But thinking about more complex apps, I'm now curious to find out if my assumption is correct. More complex apps probably extensively use it for offline functionality and state management... or don't they?

Back in those days there were also the Filesystem API in discussion (and stage0/1 iirc).

From a web app devs perspective there was a huge need for file processing in the client, where the Blob API wasn't enough. The use case was e.g. batch processing or opening/uploading a folder with a bunch of files in them.

Sadly the limitations for web contexts were easily exploited by using dozens of subdomains, so you could DDoS the filesystem of the client with it and break out of the 80/100MB limit for each context in all browsers.

I am very sad to see the html5 manifest gone, because it was a superb way to describe online/offline assets that can/should/must be cached.

The combination of the removal of all those APIs basically pushed native apps again, because web apps are pretty useless as file selectors and all the hacks around input fields (even with WebKit's custom file picker). Even electron started at some point to offer custom APIs for file handling (and database handling) because of it, so I'd argue that the overall offline initiative was a huge disaster.

Now we have 10+ years outdated code in the devtools in browsers which use APIs that are not even available in web contexts anymore, and they are nothing more than a pointless maintenance burden.

I wish there was a smarter way to describe C ABIs inside C/C++ code, but sadly there isn't. The outdated headers and the data types serialization/deserialization from web context to web context is usually what results in use after free bugs in the C code that doesn't expect it. Add the casual heap spraying bugs and you've got a factory for RCEs that are easy to implement.

Servo and its idea of "how to program a browser that interacts with other embedded languages" could have changed so much about this state of program bugs and issues.

C ABIs are not enough anymore, yet they are the only way programs can interact with each other.

And I'd argue it's a huge fail of the software industry, and it has to change if we ever don't want to think about this anymore.

It has to do with the parenthesis around the security response letter and how websites parsed it looking for the contents of said parenthesis. It went from expected values to just “a” with the initial security response update.

There’s only a certain subset of things a security response update can address and I don’t think they wanted to increase the version number just for this.

A small mitigation: disable JS in Safari.

Reply on news.ycombinator.com