Fragen? Antworten! Siehe auch: Alternativlos
PAC ist ein ARM-Feature und steht für Pointer Authentication Code.
Das Grundproblem ist, dass viele Exploits darauf basieren, einen Pointer zu überschreiben. Bei einem traditionellen Buffer Overflow auf dem Stack übernagelt man die Rücksprungadresse, die auch auf dem Stack liegt. Bei Heap-Overflows übernagelt man Zeiger in den Metadaten des Heapmanagers. Viele Kernel-Exploits basieren darauf, dass man dem Kernel einen Zeiger aus dem Userspace überhilft, wo der einen Kernel-Mode-Zeiger erwartet hat.
In der Intel-Welt sind die Gegenmaßnahmen ASLR (jeder Prozess landet an einer anderen virtuellen Adresse, damit der Angreifer die nicht vorhersagen kann und keinen funktionierenden Zeiger produziert kriegt) und dass man per CPU-Flag einschalten kann, dass User-Mode-Zeiger im Kernel generell beim Zugriff einen Fehler werfen.
In der ARM-Welt gibt es ein anderes Konzept, dass das Problem beheben soll, nämlich nutzt man "ungenutzte Bits" in Zeigern dafür, da eine Krypto-Checksumme unterzubringen. Nun sind Krypto-Checksummen normalerweise viel größer als man freie Bits in Zeigern hat, daher war meine erste Reaktion auf die Idee auch eher ablehnend, aber je mehr ich darüber nachgedacht habe, desto besser gefiel mir das. Bei ASLR hat man ja auch nicht mehr freie Bits in den Zeigern.
Es gibt zwei neue CPU-Instruktionen. Eine macht aus einem gültigen Zeiger einen "signierten", der dann nicht mehr dereferenziert werden kann. Dafür verwendet sie den Wert des Zeigers, ein Geheimnis, das vom Kernel in ein Spezialregister geladen wird dafür, und der pro Prozess anders ist, und einen dritten Wert, z.B. den aktuellen Stack Pointer. Dann gibt es eine Instruktion in die Gegenrichtung, die einen Zeiger in eine dereferenziere Form wandelt und eine Exception wirft, wenn die Signatur ungültig war.
Es gibt davon auch noch mehrere Formen für verschiedene Zeigerarten, damit man nicht einen gültigen Datenzeiger über eine Rücksprungadresse nageln kann.
Das ist jedenfalls eine eigentlich ziemlich schlaue Angelegenheit, die nur einen echten Nachteil hat: Man muss seinen Code dafür kompilieren, dass er das nutzt. Die Intel-Gegenmaßnahmen funktionieren auch ohne Neukompilieren der Programme.
Dieser PACMAN-Angriff hier behauptet, sie könnten das Geheimnis über spekulative execution herausfinden und "von außen" gültig signierte Zeiger erzeugen. Das wäre schon ziemlich doof, wenn das ginge.
Die Behauptung, als sei das M1-spezifisch, stimmt aber nicht. Das ist ein ARM-Feature, kein M1-Feature. Der Einschätzung, dass das "unpatchbar" ist, würde ich mich anschließen.