You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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.
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$
The text was updated successfully, but these errors were encountered: