About the security content of iOS 15.4.1 and iPadOS 15.4.1 | Hacker News Reader

About the security content of iOS 15.4.1 and iPadOS 15.4.1

support.apple.com

131 pointsShank25 comments

NSO is currently crumbling due to an internal all out war between the owners (in a war between themselves) and the debt owners (who have sided with 1 of the smaller shareholders)

The majority shareholder is trying to kill off the Pegasus branch via keeping all of the leveraged debt they took on on their side, I have to wonder if this "anonymous researcher" has anything to do with that

https://en.globes.co.il/en/article-squabbling-threatens-15b-...

If this was one of Pegasus' main 0days post "FORCEDENTRY" patch, this would make this fight quiet down very quickly

Same bug on macOS, along with an Intel graphics driver issue: https://support.apple.com/en-gb/HT213220

This update also happens to include a bug fix for an actual instruction selection bug in the compiler that miscompiled the Swift runtime libraries for certain devices. So if the security benefits didn’t convince you, consider making some mobile release engineers happy :)

Could provide a link with some info? I tried to look around to confirm but didn’t find anything. This sounds like it could be really useful.

Someone's reported this as https://bugs.swift.org/browse/SR-16047. The bug is that A11 and older processors don't have a CAS instruction, and LLVM's lowering accidentally added xzr to the set of "valid registers" for the replacement instruction sequence. So if you're seeing crashes in MetadataAllocator in iOS 15.4, this is probably going to fix it for you.

Also probably interesting: https://twitter.com/patch1t/status/1509767175946792966

What is AppleAVD? Audio video decode?

It's a kext for decoding HEVC, H.264, and VP9.

Sounds to me like a terrible OS design, to have such arbitrary things as video decoding, require a kernel extension. Microsoft move drivers, such as GPU, to user space, to escape exactly issues like these. This is likely done for the sake of DRM, which is even worse.

But SiDeLoADiNg is what is threatening users’ security.

This is how macOS is designed. macOS has over 100 kexts in a fresh install (IIRC) to keep the main kernel as small and error-free as reasonably possible without being a full microkernel and taking the performance hit that causes. This makes it a Hybrid kernel, neither a full microkernel (safety at cost of performance) or monolithic kernel (performance at cost of safety).

Other hybrid kernels include Windows and BeOS, though on Windows the kernel/extension separation is less clearly defined.

https://en.wikipedia.org/wiki/Hybrid_kernel

> "Microsoft move drivers, such as GPU, to user space, to escape exactly issues like these. This is likely done for the sake of DRM, which is even worse."

Heck... NO. Drivers are still in kernel space like ever. I don't know where you got that impression. Windows isn't a microkernel, it's got plenty of kernel drivers for everything. Only UMDF Drivers are userspace, and while there are many of them, none of them are as complex as a GPU. A GPU Driver in userspace on Windows would be massively performance bottlenecked. Microsoft even states in their documentation "File system drivers, display drivers (for full display devices, not display-only display devices), and print drivers cannot be UMDF drivers."

https://docs.microsoft.com/en-us/windows-hardware/drivers/wd...

Yes, and display drivers are in large part in user mode too:

https://docs.microsoft.com/en-us/windows-hardware/drivers/di...

This has been the case since Windows Vista WDDM.

So they are on Linux, macOS and other platforms. In fact the DirectX in kernel model used by Windows XP and earlier was the anomaly by modern terms.

I don’t understand why you argue with me. Moving the user-space is good. My point is that the direction should be moving to user-space, not tacking more and more on the kernel, especially for silly things such as DRM.

You realize it's common for PCs to have entire dedicated hardware circuitry for this, right? The HEVC support for Windows 10 depends on hardware support, for instance. And the decoding for 4K Blu-rays is actually being dropped by Intel chips, which means desktop platforms are losing the ability to decide their encryption.

Which OS kernel doesn't provide video decoding capabilities nowadays? At least Linux does, and most likely Windows too.

> This is likely done for the sake of DRM

The reason is hardware acceleration. No sane OS vendor is going to place every single piece of code in the kernel where DRM is involved.

> But SiDeLoADiNg

Not disagreeing, but do you have to bring it up on every single issue? I don't see the connection here.

> Sounds to me like a terrible OS design, to have such arbitrary things as video decoding, require a kernel extension

Why?

For exactly the reason they have to patch it. For exactly the same reason they are now disallowing custom kernel extensions. Apple engineers are not perfect machines, writing perfect code without issues. And so, here we are. Years in the wild exploit in a kernel extension for decoding h264. Ridiculous.

It's a kernel extension for audio and video decoding. /System/Library/Extensions/AppleAVD.kext/

Thanks for answering the question bobabob.

This is a shot in the dark, but could it be Azure Virtual Desktop for iOS?

More info on the exploit that was patched found here: https://cwe.mitre.org/data/definitions/787.html.

An application may be able to execute arbitrary code with kernel privileges.

Did you mean to link to a CWE page? This isn't about a specific bug.

Isn’t it? The patch is specifically to address:

> An out-of-bounds write issue was addressed with improved bounds checking. (CVE-2022-22675)

Which sounds exactly like a CWE-787 candidate.

gzer0's comment is a bit confusing. It could either be interpreted as saying "here's more info about this exact vulnerability" or "here's more info about this category of vulnerabilities". EE84M3i interpreted the comment as the first, but then saw the link is actually the second, and thought maybe EE84M3i made a mistake with the comment.

I read it as the second as well just due to the link, but

> More info on the <type of> exploit that was patched found here

might have inferred the category of vulnerabilities more.

Reply on news.ycombinator.com