Hacker News Reader

Hi! I think I can clear a few things up here.

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

Something definitely went wrong here though that more guidance was not provided to the tech journalists.

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.

Based on the article, I think the journalist basically understands the situation (and if they don't, they should investigate further, that's the job). The headline is just intentionally over-dramatic to get clicks. This shouldn't be treated as a good-faith error, more guidance isn't required and wouldn't help.

It's sad that we reached a point where assuming bad faith from public informers is acceptable and, worse, reasonable.

Worth noting that someone else usually writes the headline for the articles, not the journalist / the author of an article.

OK, but that doesn't excuse things. There's a problem with journalism and its mostly about how they are incentivized and compensated. I don't know what the fix is but its clear that trust is so low, and rightfully so that journalism has largely failed as an industry at its job.

Journalism is paid for by ads, mostly. For online journalism, unless people click there is no money to pay the producers. Hence clickbait. This is a problem but there are worse problems.

In my opinion the requirement that HN submissions match the article's title is quite absurd because of this phenomenon.

Uh, that isn't the rule, for exactly that reason.

> Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.

https://news.ycombinator.com/newsguidelines.html

I've seen many cases where mods revert an informative title in favor of a less informative one. Also, the idea that the title of a submission should match the title of the resulting article is quite silly, since often the article is written for a different audience and the informed HN submitter can sometimes craft a title that better summarizes to HN readers why the story is interesting / worth reading / controversial.

Expected, yes. Reasonable or acceptable, no.

But what can you do about it?

>Most of the mainstream articles make it seem like they a) did not read the paper b) are incapable of understanding the paper

This seems pretty par for the course in terms of science/tech journalism to be honest.

> It's kind of ridiculous it's getting this kind of press

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

I mean, it's been like months of random press about the M1 despite there being anything special other than , _Apple_ so that's basically what you get when your marketing is super effective.

a) did not read the paper

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.

Clearly "did not read the article" applies to some internet commentators.

The article is pretty good and shows good understanding of what the attack is.

Welcome to tech journalism.

Just tech journalism? :) https://en.wikipedia.org/wiki/Michael_Crichton#GellMannAmnes...

Welcome to journalism.

It’s not just a problem with journalism but with humans in general. People are more imprecise with their comprehension of things than they are willing to admit.

How many synonyms did you try before you landed on “imprecise”?

It’s a very diplomatic choice. Moreso than I’d have gone with. I admire your restraint!

Thank you. Even here on HN, plenty of folks will comment on all kinds of research they know little about.

> Even here on HN, plenty of folks will comment on all kinds of research they know little about.

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.

Any thread about nutrition is so painful here.

Anything related to medicine/biochemistry can get cringe-y pretty quickly here. I think the problem is that the crowd here is generally pretty intelligent, but they know it and it's a coefficient > 1 on the Dunning-Kruger effect

Welcome to advertising driven journalism.

If the information was given solely to public security experts with blog presence (Matthew Green, Bruce Schneier, and a plethora of others) we could've linked to them and either ignore the 'clickbait middleman' or do most of the work for them allowing them an easier time to write up something half decent.

Matthew Green once publicly criticized something I created by simply parroting what someone else had said without bothering to do his own investigation. The original criticism turned out to be hogwash, and Matthew failed to recognize an obvious real crypto problem with the first version of my feature because he was too busy trying to just quickly stick his name into someone else's feature announcement while it was still "hot off the press."

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.

MG shows here that even a small dose of fame can ruin the biggest of nerds.

I can imagine some of the Tech YouTube channel headlines this week:

"Apple is DOOMED!"

"Turn off your iPhone, Apple's security BUSTED!"

Youtube titles with CAPITALIZED words make me sad. I don't want to click on any video with a title like that, but creators are incentivized to use those titles because they get more views. Some fine videos end up with those titles and I would miss out on some good stuff if I refuse to click on clickbait titles.

The Techcrunch article is well written and I thought summarises this rather well.

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.

Everything you listed are at the very end of the list of things that matter to modern day Journalist. If they even make the list.

But reading your comment does sort of put a smile on my face though. The what others would called a non-cynical world view.

d) were given about 90 minutes to write the article

95% of journalism is at this level of understanding for anything non liberal arts that is commonly offered as a 4 year degree, and has been for as long as journalism has existed.

I really sympathise how your research is being misunderstood based on the reporting and responses to the press stuff missing the main point. And everyone equating modern ARM with "M1".. Anyway, awesome work! Let's hope pointer authentication gets a thorough treatment from the research community and you and other people can build further exciting results on your work!

Given there are "55,159 potential spots that could be turned into PACMAN Gadgets" do you think it is highly probably this attack is now part of a zero-day kill-chain?

100% chance.

Yep, 100% chance. (Despite the above downvotes, and this is coming from a JavaScript engine researcher).

Yeah, I work on Linux security for a big Red I mean Blue, company. Wrote poc for spectre/meltdown and more, but what do I know. ;)

You didn't clear up anything about publicizing this heavily in mainstream press before it's been reviewed by your peers.

It has been reviewed by the author’s peers — it was accepted to ISCA ‘22.

What are you hoping for here? Look at the facts as written.

Also important to mention that PAC is a new ARMv8.2 feature and previous versions of ARM have no PAC system at all. The only ARM chips with PAC are from Apple and AWS Graviton3 - any other chip has no hardware protections against this.

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.

Besides the Apple CPUs and Graviton 3 (Armv8.4-A), the cores introduced by ARM in 2021 and present in some 2022 smartphones (Cortex-X2, Cortex-A710, Cortex-A510), which implement Armv9.0-A, also support PAC.

The doc in the kernel tree is dated 2017, so it's percolated to products quite slowly: https://www.kernel.org/doc/html/latest/arm64/pointer-authent...

Ah thanks, this finally makes sense in context

Edit: Correction, ARMv8.3, not ARMv8.2.

From the home page: " For our demo, we add our own bug to the kernel using a kext. In a real world attack, you would just find an existing kernel bug."

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.

> "PACMAN is an exploitation technique- on its own it cannot compromise your system. While the hardware mechanisms used by PACMAN cannot be patched with software features, memory corruption bugs can be."

reading the "official" site of the Researchers gives more clues than the headline of the article.

Once you can get someone to install your kext aren’t you basically at game over anyway?

Or do they have strong limits as well?

This was just to expose the gadget easier, there are other gadgets in kernel that you can abuse too.

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.

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

^ This is not the case, you can trigger these from userspace in valid syscalls. The same behaviour was in spectre.

Yeah, the tech news just runs with it because fear sells. This is the “intel backdoor” all over again.

> - Login to the Mac in question

Really? Usually malicious stuff is installed by the user themselves being unaware of it.

Installing a kext is a password prompt away, I believe, so all that's needed technically seems to be "install something not reviewed by Apple, fill in a genuine OS password prompt when asked, and run it" which strikes me as a very common scenario.

Enabling 3rd-party extensions is much more involved on AS Macs: https://support.apple.com/guide/mac-help/change-security-set...

Then the extension needs to be allowed in System Preferences > Security (this step has been required on Intel Macs too)

Additionally, if can find a way to trick a user into installing a malicious kext, why even bother with PACMAN? You already have arbitrary kernel code execution!

Perhaps the kext with the overflow may not necessarily look malicious? It can serve as an actually useful kext and pass review.

These days all kexts look malicious.

Yeah. The bundled ones in the main OS image are the worst. Who the hell knows what nefarious acts lie behind IOPCIFamily.kext?!

/s, though not entirely, moving more stuff to unprivileged contexts would be nice

yeah but if you can trick the user to do that, you can already trick him to do more

First you need to trick Apple into signing that kext (which is getting more difficult by the day even for legitimate uses), or get the user to disable SIP first.

Didn't many tools require disabling SIP, like Homebrew? Is this no longer true?

This hasn't been true for at least 2 major macOS releases.

But yes, there was a time when editing even /etc/sudoers required disabling SIP. That time is long gone.

I downloaded Brave after googling it and got a .pkg instead of a .dmg because someone wanted to hack my new laptop, and didn't want to risk a hack that leveraged an exploit only nation states know about. They are sMArt. Like me! I still installed it because I am gullible and lazy.

> Login to the Mac in question

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.