Live data from Hacker News

Pointer Authentication

github.com

21–30 of 45 posts

Re: Pointer Authentication

#21
post #14
post #13

If you don't use the standard library, and you don't need JIT, you can simply not use pointers to callbacks. You can still have something like qsort() but you need to have statically defined: typedef void*(*callback)(...);extern const callback callbacks[256]; and qsort() takes an index instead of a raw pointer to a callback. "Validating" a callback is cheap: Just make sure it's <256 (how many do you need anyway?). If…

Neat. But how do you make this modular and still safe? When the code invoking qsort() does not know about how many callbacks there are, can you still deal with it?

The idea is you have some struct that is in peril. Perhaps it will be overflowed, or used after free, etc. It has a function pointer.

    struct danger {
        sort_fn sorter;
        char data[16];
    };
    danger->sorter(danger); /* what if it's a bad pointer? */
You replace that with this.

    int add_sort_fn(sort_fn sorter) {
        sort_fns[num_sorts++] = sorter;
        return num_sorts;
    }
    struct lessdanger {
        int sortidx;
        char data[16];
    };
    danger->sortidx = add_sort_fn(sorter);
    /* could clean this up a bit more */
    sort_fns[danger->sortidx % num_sorts](danger);
There's still the possibility of calling the wrong function, but only one from a finite set of possibilities. There's no direct control over the pointer value.

You can make the sort_fns array resizeable, but in practice there's usually only so many targets.

Re: Pointer Authentication

#22
post #14
post #13

If you don't use the standard library, and you don't need JIT, you can simply not use pointers to callbacks. You can still have something like qsort() but you need to have statically defined: typedef void*(*callback)(...);extern const callback callbacks[256]; and qsort() takes an index instead of a raw pointer to a callback. "Validating" a callback is cheap: Just make sure it's <256 (how many do you need anyway?). If…

Neat. But how do you make this modular and still safe? When the code invoking qsort() does not know about how many callbacks there are, can you still deal with it?

Our qsort() caller is an application with at most 256 different comparators. Let us call that an ABI limit. The addresses are in read-only memory so they cannot be changed- new addresses simply cannot be introduced at run-time, so there is no risk of qsort being tricked into “jumping into the middle of a function”. The implementation of my qsort() does not need to know if there are fewer- the entry will be null and the program will crash.

Re: Pointer Authentication

#23
post #22
post #14

Earlier quoted context omitted.

Neat. But how do you make this modular and still safe? When the code invoking qsort() does not know about how many callbacks there are, can you still deal with it?

Our qsort() caller is an application with at most 256 different comparators. Let us call that an ABI limit. The addresses are in read-only memory so they cannot be changed- new addresses simply cannot be introduced at run-time, so there is no risk of qsort being tricked into “jumping into the middle of a function”. The implementation of my qsort() does not need to know if there are fewer- the entry will be null and t…

This is a whole-program transformation though, it doesn't seem to be possible to make it modular. Unless you manage to map some module-specific dispatch table whenever you're running code from that module - in a way that cannot easily be subverted by exploit code! Not sure how to do this however.

Re: Pointer Authentication

#25
post #15
post #12

Earlier quoted context omitted.

> AMD remains the only one to really offer hardware acceleration for SHA Intel added SHA with Goldmont, for smaller laptops. But it's only SHA1 and SHA2, which are already outdated. Good enough for ptrauth though.

SHA-2 isn't outdated if used correctly (e.g. combine with HMAC if length extension attacks are a threat to your protocol). SHA-3 is the "break glass in case of emergency" hash.

You are right, SHA2 is fine still, mostly.

But... Combining with HMAC isn’t exactly a seal of approval. HMAC with MD5 is still considered secure because even if you made a hash collision you didn’t have the key.

And yes, SHA3 would be overkill. Most people don’t understand the mechanics of hashing let alone the new keying that SHA3 brings.

Re: Pointer Authentication

#26
Although nice in theory, contemporary implementations of the same scheme leave a lot to be desired. Take Windows' control flow guard (CFG) as a practical example. The scope of valid indirect branch targets is so vast that even with CFG enabled it's almost always possible for an attacker to craft a ROP chain to achieve arbitrary code execution.

That doesn't invalidate the concept of pointer authentication as a whole, but does reduce the number of situations in which you should consider to apply it. If you have a large codebase 'bolting it on' will make pointer authentication much less effective. And when you're starting a new process, then why not start it in a language that offers stronger memory safety for a start, such as Rust?

Re: Pointer Authentication

#27
post #8

Earlier quoted context omitted.

that is exactly what an MMU is for.

MMUs work on much larger regions than what is useful for many classes of memory safety issues. Luckily, ARMv8.5 adds support for memory tagging at a more granular level.

Let's resurrect segments!

Re: Pointer Authentication

#28
post #26

Although nice in theory, contemporary implementations of the same scheme leave a lot to be desired. Take Windows' control flow guard (CFG) as a practical example. The scope of valid indirect branch targets is so vast that even with CFG enabled it's almost always possible for an attacker to craft a ROP chain to achieve arbitrary code execution. That doesn't invalidate the concept of pointer authentication as a whole,…

The point of PAC is that you can’t create an arbitrary return pointer - it’s not based on ahead of time knowledge of what they fill CFG state is. The return address is signed as a byproduct of making the call in the first place, so to return to a different location you need to be able to rop through a pointer with a forged signature.

Re: Pointer Authentication

#29
post #4

Does anyone here know how this compares to hwasan?

Hardware Address Sanitizer is intended to protect against memory corruption in general, while pointer authentication helps ensure code flow integrity. (And I think it's mutually incompatible with the implementation that iOS uses because they both use TBI).

They can be compatible. Memory tagging does use the TBI bits. Pointer authentication uses an arbitrary number of bits, and the kernel configures the width and whether the TBI bits are preserved. So you can use both, it just costs you 8 bits of signature.

Moreover, this can be configured independently for code and data pointers. iOS turns off TBI on code pointers to get 8 more bits of signature. That's not a problem for memory tagging because memory tagging isn't particularly useful for code pointers anyway.

Re: Pointer Authentication

#30
post #12

I’m guessing this was developed by or at the behest of Apple and ARM, based off the supported hardware and languages? Are any versions of the iOS or macOS kernel (or even user lands) utilizing this “across the board” now? I’d read papers and theory on strong pointer authentication to mitigate control flow attacks a very long time ago but I did not realize this was now “mainstream” in a consumer compiler (with support…

> AMD remains the only one to really offer hardware acceleration for SHA Intel added SHA with Goldmont, for smaller laptops. But it's only SHA1 and SHA2, which are already outdated. Good enough for ptrauth though.

Right. Pointer authentication depends on it not being easy to forge a signature given the desired pointer. Given that there's a secret key included in the signature, the requirements on the hash function aren't really very strong. Signatures just need to not leak information about the key that could be used to predict other signatures.
Post reply on HN