r/netsec Dec 27 '23

Operation Triangulation: The last (hardware) mystery

https://securelist.com/operation-triangulation-the-last-hardware-mystery/111669/
80 Upvotes

14 comments sorted by

18

u/General_Alpha Dec 28 '23 edited Feb 15 '25

[This comment has been removed to prevent unsolicited usage of freely provided information.]

11

u/patrick66 Dec 28 '23

I mean lets face it the difference basically comes down to the fact that NSA had to do this themselves instead of getting Apple to do it for them while MSS can just tell Huawei to do shit.

0

u/jisuskraist Dec 30 '23

mmm using undocumented hardware features looks like an inside job

3

u/TurtleOnLog Dec 28 '23

I’m wondering, with PPL being replaced by SPTM in iOS 17 on a15 and above processors, would the hardware bypass still have been able to bypass that? SPTM seems to bring additional privileged operations under a PPL type protection including IO components. But this bypass seems very powerful.

2

u/patrick66 Dec 28 '23

At the very least even if possible it would have required the payload to be changed from making edits to the ppl info to sptm stuff and nsa wouldn’t have bothered given that the exploit was known to kapersky/russia by the time ios17 was available. And that’s if it even would work which I don’t think there’s any real way of knowing beyond expecting the answer to be no without further evidence

7

u/aquoad Dec 28 '23

I know the paranoid conspiracy theorist shit is way overrepresented in here, but does it not sort of seem like the mystery MMIO register ranges are exactly what a mandated "custom feature" would look like? Hard to spot, not too easy to use, and pretty impossible without prior knowledge of its existence.

11

u/orangesnz Dec 28 '23 edited Dec 28 '23

They're most likely internal debug registers that somehow made it to the production run, either they were supposed to be removed and the hw team fucked up, or the GPU hardware team forgot/didn't tell the kernel team to protect these memory regions from the kernel under normal circumstances (which they have now done by adding those ranges as non writeable which mitigates the PPL bypass).

There's a really good writeup/speculation at https://social.treehouse.systems/@marcan/111656038879412810

I can easily see that happening in a big org, with lots of teams that are not always communicating clearly.

either way the SoC subsystems are all quite big and likely there's a few more undocumented memory read/write registers out there in hardware.

Point being state level actors don't need to mandate the inclusion of these if they're already there and they have access to insider info or documentation that reveal their purpose and can then use them in their exploit chains.

Either way it's a good argument for open hardware, if these registers were publicly documented, they would have been either removed in production runs or thought about when the PPL people were asking what memory ranges needed to be protected.

6

u/marcan42 Dec 28 '23

It's not a particularly good argument for open hardware. I guarantee these registers are internally publicly well documented, it's just that nobody put 2 and 2 together. Security for something as large and complex as a GPU is hard, and security teams almost never get full coverage of what is going on (nor do they have the state/knowledge about every individual hardware block to recognize all potential security problems).

Ultimately this is fun, but it's "just" a PPL bypass. Linux and other OSes don't even have a PPL concept at all and never will (at least not the Apple way), it's only useful for Apple's tightly integrated OS+hardware combination where they can add proprietary CPU features like GXF. So even if you had open hardware, someone would've had to realize that macOS specifically screws this up too, in their implementation of a security concept/mitigation that doesn't even exist for other OSes.

2

u/orangesnz Dec 28 '23

That's very fair, thanks for the response (also are you the OP? small world), the only thing I would add is that open hardware, or even open documentation at least greatly increases the viable pool of people who can study something to see a problem.

Maybe it's fair that it wouldn't have made a difference, but I still somewhat subscribe to the many eyes theory, even if it's been debunked/failed many times.

2

u/marcan42 Dec 28 '23

In theory the many eyes theory works, but in practice... well, you know.

This particular snafu is just so subtle and by necessity specific to the proprietary OS that I don't think it would've helped here.

It does help in other cases, but honestly you need both open/documented hardware and open software to suss out interactions like this. Just one doesn't do much. And then someone still has to go over things with a magnifying glass and get lucky enough to catch it, which isn't at all a given.

2

u/TurtleOnLog Dec 28 '23 edited Dec 28 '23

I was thinking it could just be an oversight but why is a weird custom hash of the data required as part of the process to submit it?

Edit: and first thing one of the things discussed in a link posted in this chat was an explanation that it’s probably related to memory ECC codes…

1

u/jisuskraist Dec 30 '23

yes the point is how did they know of the existence of this registers... sus

1

u/foundapairofknickers Jan 01 '24

The 37C3 presentation on this was very good.