Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Binaries compiled with musl not having NX bit set #30824

Closed
aliclark opened this issue Jan 11, 2016 · 1 comment
Closed

Binaries compiled with musl not having NX bit set #30824

aliclark opened this issue Jan 11, 2016 · 1 comment

Comments

@aliclark
Copy link
Contributor

After following the Static Linking guide and creating binaries with rustc (https://doc.rust-lang.org/book/advanced-linking.html#static-linking), the compiled x86_64-unknown-linux-musl binaries currently do not have the NX set on the stack.

This can be checked using the following script: http://www.trapkit.de/tools/checksec.html

This seems to be a regression given that binaries compiled with the vanilla rustc do have NX set on the stack (it is also common practice for C programs these days).

I created a small demonstration project here, simulating exploitation after an ASLR bypass: aliclark/rust-musl-nx-issue@a5a37fe

with normal rustc:

cargo run
Running target/debug/snap
Calling out to buggy C code
An unknown error occurred

with musl rustc:

cargo run --target x86_64-unknown-linux-musl
Running target/x86_64-unknown-linux-musl/debug/snap
Calling out to buggy C code
sh-4.3$

bors added a commit that referenced this issue Jan 27, 2016
This explicitly adds an option telling the linker on these platforms to make the stack and heap non-executable (should already be the case for Windows, and likely OS X).

Without this option there is some risk of accidentally losing NX protection, as the linker will not enable NX if any of the binary's constituent objects don't contain the .note.GNU-stack header.

We're not aware of any users who would want a binary with executable stack or heap, but in future this could be made possible by passing a flag to disable the protection, which would also help document the fact to the crate's users.

Edit: older discussion of previous quickfix to add a .note.GNU-stack header to libunwind's assembly:

Short term solution for issue #30824 to ensure that object files generated from assembler contain the .note.GNU-stack header.

When this header is not present in any constituent object files, the linker refrains from making the stack NX in the final executable.

Further actions:

I'll try to get this change merged in with upstream too, and then update these instructions to just compile the fixed version.

It seems a good idea to use issue #30824 or some other issue to add a test that similar security regressions can be automatically caught in future.
@alexcrichton
Copy link
Member

I think this was fixed in #30859, so closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants