151–160 of 204 posts
Earlier quoted context omitted.
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.
The author is here and ought to make it all clear but if you google the title of the article you can download the paper already despite everyone being coy about it and the ACM not having published it yet. It's kind of ridiculous it's getting this kind of press before the paper is officially published and available. If the paper was published and security experts were allowed to analyze it before the tech press went n…
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 ter…
Earlier quoted context omitted.
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.
The author is here and ought to make it all clear but if you google the title of the article you can download the paper already despite everyone being coy about it and the ACM not having published it yet. It's kind of ridiculous it's getting this kind of press before the paper is officially published and available. If the paper was published and security experts were allowed to analyze it before the tech press went n…
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 us…
The author is here and ought to make it all clear but if you google the title of the article you can download the paper already despite everyone being coy about it and the ACM not having published it yet. It's kind of ridiculous it's getting this kind of press before the paper is officially published and available. If the paper was published and security experts were allowed to analyze it before the tech press went n…
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 us…
Earlier quoted context omitted.
This is a great question! What this means is that a software patch cannot fix the speculative execution behavior that causes the PACMAN issue since it is built directly into how the hardware operates.
So there is no possible set of instructions that could block the particular behavior in the exploit?
The author is here and ought to make it all clear but if you google the title of the article you can download the paper already despite everyone being coy about it and the ACM not having published it yet. It's kind of ridiculous it's getting this kind of press before the paper is officially published and available. If the paper was published and security experts were allowed to analyze it before the tech press went n…
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.
Earlier quoted context omitted.
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.
The growing pains of silicon development date back to the Intel line of Pentium FDIV bug issues. Not surprised it occurred, just surprised it took so long to come to fruition. I can only think its the lack of hardware engineers savvy enough to exploit such an issue, since the abstractions from hardware are so far removed from us general populous software developers. Any thoughts on the above?
For the uninitiated, are such ‘unpatchable’ hardware flaws prevalent and/or debilitating to a greater or lesser degree in other processors (Intel, AMD, Apple AX processors)? Or has Apple "dropped the ball" compared with other chip designers?
Such lists were initially published as "Errata Lists", but now many manufacturers use less honest names, e.g. Intel uses "Specification Update" and AMD uses "Revision Guide".
Some defects may become manifest only when the hardware is used in certain ways, which may be avoided by the motherboard manufacturers, maybe at the price of reduced performance.
Many uncorrected defects affect only various testing or performance monitoring features. Many other uncorrected defects affect only privileged programs, so the resolution "Won't Fix" is justified by saying that all the popular operating systems have been tested and they have not been seen to trigger the bug. (For someone who develops their own operating system it is mandatory to read all the errata lists, because obviously their OS will not be used by Intel and AMD for testing the new CPUs.)
When the defects can affect user programs, in many cases it is possible to implement workarounds with microcode updates included in BIOS or operating systems, possibly with the price of reduced performance. Only when no microcode workaround is possible and the bug can be triggered by user programs, leading to crashes or incorrect results, then the defect is scheduled for being corrected in a new revision of the CPU. Most of these defects that are corrected are discovered during the testing of the engineering samples, before the official launch of the CPU, which uses the latest revision, with only the known defects that either do not affect non-privileged programs or have microcode workarounds.
Earlier quoted context omitted.
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.
/s, though not entirely, moving more stuff to unprivileged contexts would be nice