5 ms·

Sounds like it requires physical access to a device, is that right? At least less of a concern than software only, though still not good.

• TazeTSchnitzel 4y ago
  As the article puts it, it's a breach in “last line” security defences. Specifically, it's a mitigation that applies when you already have code execution. It's nothing for most people to worry about. PACs are a new mitigation that Intel Macs didn't have, so it's not like it puts the M1 in a worse position than what it replaced.
  • adrian_b 4y ago
    This is a new security feature, which few computers have, so the fact that it does not work obviously has little practical importance. At worst it makes the new computers with this feature only as secure as any old computer. Nevertheless, the article is very important, because it shows that this supposedly security-improving feature has been implemented in a way that makes it useless (like it has also happened with some Intel security features, e.g. Software Guard Extensions). Everybody must become aware that this "pointer authentication" feature is currently unreliable, so it must not be used, and the designers of future CPUs must take care to not repeat these mistakes.
    • Someone 4y ago
      What are you basing “so it must not be used” on? I would think it can’t harm, ever.
      • adrian_b 4y ago
        Like you say, it does not do much harm if used. Nevertheless, there is some small loss of performance, because instructions to compute the Pointer Authentication Code (PAC) must be inserted in the program, and possibly also instructions to authenticate the PAC, though the latter may be omitted if the function return instructions and the indirect jumps through pointers are replaced with instructions that combine the pointer authentication with the jump. I have no idea whether on the Apple CPUs the jumps/returns with authentication have the same speed with the simple jumps/returns. I suppose that the Apple compiler adds automatically the PAC computation and authentication instructions, so using this option does not increase the complexity of the source code. Nevertheless, even if the performance impact of using PAC might not be important, whenever a security feature that does not work is used, there is the danger that there will be some people who do not know that it does not work, so they will believe that exploits are impossible and there is no need to be careful to avoid the possibility that an adversary might be able to modify a pointer, e.g. by crafting a special input to the application. In general all the variants of pointer validation that have been recently introduced in all CPU architectures are just workarounds against the bugs introduced by programmers, because in a well written program there should be no way for an adversary to modify an internal pointer.
        • astrange 4y ago
          "All programs must be well written" with nothing in the ISA to help you write them properly isn't a good way to do software. PAC helps you reduce bugs because it checksums your pointers.
          • adrian_b 4y ago
            The most important helping feature of an ISA is to provide an efficient way to compare indices and pointers against limits, so that the poor performance of limits checking will not discourage the compiler writers and the compiler users to always make such checks. Any decent C/C++ compiler has compile options to check all array accesses against limits, which, coupled with the good programming practice of always using indices and not pointers for memory accesses, can catch all the programming errors of the buffer overflow type. However, neither the compilers enable this option by default nor most programmers take care to always enable it, because of usually baseless worries of degrading the performance. Checking accesses against limits catches any such bugs at their origin, not much later when a corrupt pointer is identified by PAC, without knowing how it became corrupt. Intel has made an attempt with Skylake to introduce some instructions for easier limits checking, but unfortunately the instructions conceived by them were just dumb and not helpful at all, so they have been eventually deprecated. Better support exists in the IBM POWER ISA, which has conditional trap instructions.
      • dreamcompiler 4y ago
        Security techniques that have known workarounds cause harm by engendering a false sense of security.
        • _kbh_ 4y ago
          nearly every security feature in existence has known (situation dependent) work arounds. That does not mean you should turn them off.
        • deleted 4y ago
          [deleted]
  • amelius 4y ago
    > it's a mitigation that applies when you already have code execution Sounds like a huge deal if you want to run untrusted code inside a sandbox.
    • tempay 4y ago
      You still need a sandbox escape before this mitigation kicks in.