Our goal is to demonstrate that we can learn the PAC for a kernel pointer from userspace. Just demonstrating that this is even possible is a big step in understanding of how mitigations like pointer authentication can be thought of in the spectre era.
We do not aim to be a zero day, but instead aim to be a way of thinking about attacks/ an attack methodology.
The timer used in the attack does not require a kext (we just use the kext for doing reverse engineering) but the attack itself never uses the kext timer. All of the attack logic lives in userspace.
Provided the attacker finds a suitable PACMAN Gadget in the kernel (and the requisite memory corruption bug), they can conduct our entire attack from userspace with our multithread timer. You are correct that the PACMAN Gadget we demonstrate in the paper does live in a kext we created, however, we believe PACMAN Gadgets are readily available for a determined attacker (our static analysis tool found 55,159 potential spots that could be turned into PACMAN Gadgets inside the 12.2.1 kernel).
Our paper is available at our website: https://pacmanattack.com/paper.pdf
Most of the mainstream articles make it seem like they a) did not read the paper b) are incapable of understanding the paper c) were not provided any guidance about what any of this actually means in the real world.
Which is all scary as the paper is well written and very accessible IMO.
> Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.
But what can you do about it?
This seems pretty par for the course in terms of science/tech journalism to be honest.
> Something definitely went wrong here though
Both of these have the same reason: it's about Apple. I know someone that avoids telling people that they work at Apple, to avoid similar drama.
Yeah, that's a given. Journalists do not have time for optional tasks.
b) are incapable of understanding the paper
That's a safe bet.
c) were not provided any guidance
Asking for guidance or clarifications is another one of those optional tasks.
The article is pretty good and shows good understanding of what the attack is.
It’s a very diplomatic choice. Moreso than I’d have gone with. I admire your restraint!
I don't see anything wrong with that, because all opinions are not equal.
I think there is some level of pressure to get one's word in quickly, otherwise the nebulous cloud of commenters moves on to the next story, and your well-thought-out comment that took hours to write is seen by no-one. If you're responding to someone hoping to get into a nice conversation, you're out of luck since they have no idea you just responded to them.
I would take anything Matthew Green blogs about with a grain of salt. It's not clear how much of what he says is just cheap amplification of what others claim.
"Apple is DOOMED!"
"Turn off your iPhone, Apple's security BUSTED!"
The headline is pretty reasonable too. Apple can't patch this, and as other commentators point out subsequent attack techniques are only going to make this flaw worse.
But reading your comment does sort of put a smile on my face though. The what others would called a non-cynical world view.
So ultimately, right now, it's just downgrading a very new protection to as if it didn't exist, which is exactly how 98% of ARM chips in the world operate right now. Not great, not terrible, A for effort, was worth a shot, speculative execution breaks everything.
This is attacking a memory safety exploitation mitigation tech, there needs to be a memory safety bug. Otherwise there's no need for PAC in the first place.
reading the "official" site of the Researchers gives more clues than the headline of the article.
Or do they have strong limits as well?
The full fix will require a complete recompile of the full kernel/toolchain, if they can do any kind of microcode update (I have not checked) that allows for mitigation.
^ This is not the case, you can trigger these from userspace in valid syscalls. The same behaviour was in spectre.
Really? Usually malicious stuff is installed by the user themselves being unaware of it.
Then the extension needs to be allowed in System Preferences > Security (this step has been required on Intel Macs too)
/s, though not entirely, moving more stuff to unprivileged contexts would be nice
But yes, there was a time when editing even /etc/sudoers required disabling SIP. That time is long gone.
right, ok? as Snowden thankfully heroically warned us, the NSA already has root-level access to most devices.
“ Remember the Spectre vulnerability. Now we have more than 7 variants of Spectre. No one guarantees that new, more destructive versions of this vulnerability will not be discovered in the future.”
> If someone can find a way to do this without installing kexts then it becomes way more serious.
right, yeah, you’re onto the right trail now.
This is interesting theoretically but the amount of access required is pretty high, this is hardly an exploitable zero day.
Having read the paper, in a nutshell it requires:
- Login to the Mac in question
- Ability to install a custom kext to make the PACMAN Gadget work. The exploit requires access to undocumented registers on the M1 that are apparently not accessible from user space, but this is a bit unclear.
- Also need an exploitable kernel buffer overflow against Mac OS (they made a custom kext with a buffer overflow)
- Run the bufferflow + Pacman Gadget together to do the final elevation
If someone can find a way to do this without installing kexts then it becomes way more serious. As is it certainly is a super interesting paper and presents a bunch of work for chip designers.