Determine the actual canary location

[clubby789]

Description/Motivation/Screenshots

This PR adds arch-specific methods to find the actual canary location, as stored in $fs_base+0x28 on x86_64.
This allows printing the in-use canary location, which can help with exploits that involve overwriting the canonical canary.

I wasn't able to find a way to read the gs segment on 32-bit, so currently this PR only adds functionality to x86_64.

Against which architecture was this tested ?

"Tested" indicates that the PR works and the unit test (see docs/testing.md) run passes without issue.

• x86-32
• x86-64
• ARM
• AARCH64
• MIPS
• POWERPC
• SPARC
• RISC-V

Checklist

• My PR was done against the dev branch, not main.
• My code follows the code style of this project.
• My change includes a change to the documentation, if required.
• If my change adds new code, adequate tests have been added.
• I have read and agree to the CONTRIBUTING document.

[clubby789]

Failure looks unrelated, but my other PR passed so I'm unsure

[clubby789]

A couple things I'm not sure how to deal with

• I believe it would be nice to inform the user when the canary is read from the non-canonical auxv. However, this information is a bit confusing in the general case where a user just wants to know the canary value, and seems to get spammed a bit on launch
• The cached ._canary property wasn't being used, and I've added a check that returns it if it's already been cached. However, if the canary location (e.g. spawning a thread) or the canary itself (e.g. via exploitation) changes, the cached value is now innacurate so it might be best not to cache this at all

[Grazfather]

The cached ._canary property wasn't being used, and I've added a check that returns it if it's already been cached. However, if the canary location (e.g. spawning a thread) or the canary itself (e.g. via exploitation) changes, the cached value is now innacurate so it might be best not to cache this at all

Yes, just noticed via your change, missed this comment. We also do this for a couple other things e.g. pagesize.

How often is this function called? We probably shouldn't cache.

[clubby789]

It might be worth only caching/checking cache in the exception case - the address of AT_RANDOM isn't going to change, and it's unlikely/irrelevant that it would be overwritten there - then again, it seems to be called a few times on startup, then only when canary is invoked by the user, so caching is probably unecessary in general here

[Grazfather]

Let's not cache, and figure out what to do in #919.

[clubby789]

Still no idea about the failing tests :/ It looks persistent, but dev seems to be passed fine

[Grazfather]

You're writing a 4 byte canary and testing for it, It'll fail if there is anything but 0s in the other 4 bytes.

[+] The canary of process 3439 is at 0x7ffff7fb8568, value is 0x7f00deadbeef"

[Grazfather]

The other test is failing because you very slightly lower the coverage score... @hugsy should probably fix it, it's way too stringent right now.

[hugsy]

Good idea, minor stuff to change before we can merge.

[hugsy]

LGTM