nyh
commented
1 year ago I just noticed https://x41-dsec.de/news/missing-or-weak-mitigations-in-various-unikernels/ discusses the importance of stack canaries, and the fact it's not supported properly on OSv (and most other unikernels). They say the following about OSv - which I have to admit, I didn't quite understand:
The main Makefile of OSv uses the -fno-stack-protector flag, which explicitly disables stack smashing protections / stack canaries. When creating an application, one can enable stack canaries by using e.g.\ the -fstack-protector-all flag. While this advises the compiler to generate the necessary stack checking code, the OS is still in charge of generating a random value and placing it at the correct address so that it can be copied onto the stack. OSv ships the musl libc with its code, but does not use musl’s stack smashing protection code. Instead, OSv implements its own stack smashing protection in runtime.cc, defining a static canary value. There is a flaw in the canary value initialization process, leading to the canary value always being 0 when explicitly enabling stack smashing protection. Due to time constraints it was not possible to conduct a root cause analysis yet. Interestingly, the code being faulty might even make it more secure here, as many string based input function stop reading input when a 0 byte occurs. Thus, it might be harder for an attacker to include a 0 byte in the exploit string than to include a static canary not containing a 0 byte.
wkozaczuk
Some executables and libraries are compiled with -fstack-protector. These do not run correctly on OSv today: The code generated by the stack protector assumes that the C library puts in %fs:0x28 a random value ("SSP canary") and puts a copy of that value on the stack so it can be later tested (see explanation in, for example,http://www.drdobbs.com/security/anatomy-of-a-stack-smashing-attack-and-h/240001832).
%fs:0x28 means position 0x28 in the TCB, and our struct thread_control_block is too small, and doesn't have this position. We need to enlarge thread_control_block, and consider setting this canary to a random value in setup_tcb(). Would be good to take this oportunity to understand gcc's entire layout of the TCB, and if we might be missing another important thing.
Paweł Dziepak saw one example of such library - libgomp.so from his Linux distribution, and the attempt to read %fs:0x28 resulted in a crash in his test.