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.
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