mNo edit summary |
No edit summary |
||
| Line 2: | Line 2: | ||
A useful hardening feature is to have a page in the data segment which you can make read-only after initialization (using <code>mprotect</code>). Assuming the data is accessed using PC-relative instructions, there is no way that malicious code can patch it (without calling <code>mprotect</code> again first). For this to work, that data needs to be aligned on a page boundary, otherwise the <code>protect</code> call might make unrelated variables read-only. We currently do not encode the page size in the executable. There are some claims it is possible to guess it from the program header, but that seems to be a bit of a stretch. | A useful hardening feature is to have a page in the data segment which you can make read-only after initialization (using <code>mprotect</code>). Assuming the data is accessed using PC-relative instructions, there is no way that malicious code can patch it (without calling <code>mprotect</code> again first). For this to work, that data needs to be aligned on a page boundary, otherwise the <code>protect</code> call might make unrelated variables read-only. We currently do not encode the page size in the executable. There are some claims it is possible to guess it from the program header, but that seems to be a bit of a stretch. | ||
[[Toolchain/Watermark/HardeningStackCheck|Stack overflow checking]] depends on the page size, too. | |||
Similarly, for figuring out if a binary has indeed full RELRO, we need to know if the dynamic linker can actually make the GOT read-only because it does not overlap with data which has to be read-write. Without explicit page size information, it is not possible to tell whether lack of RELRO due to misalignment is a static linker bug or a missing linker flag. | Similarly, for figuring out if a binary has indeed full RELRO, we need to know if the dynamic linker can actually make the GOT read-only because it does not overlap with data which has to be read-write. Without explicit page size information, it is not possible to tell whether lack of RELRO due to misalignment is a static linker bug or a missing linker flag. | ||
[[Category:Toolchain/Watermark/Provisional]] | [[Category:Toolchain/Watermark/Provisional]] | ||
Revision as of 11:00, 24 October 2016
Page Size
A useful hardening feature is to have a page in the data segment which you can make read-only after initialization (using mprotect). Assuming the data is accessed using PC-relative instructions, there is no way that malicious code can patch it (without calling mprotect again first). For this to work, that data needs to be aligned on a page boundary, otherwise the protect call might make unrelated variables read-only. We currently do not encode the page size in the executable. There are some claims it is possible to guess it from the program header, but that seems to be a bit of a stretch.
Stack overflow checking depends on the page size, too.
Similarly, for figuring out if a binary has indeed full RELRO, we need to know if the dynamic linker can actually make the GOT read-only because it does not overlap with data which has to be read-write. Without explicit page size information, it is not possible to tell whether lack of RELRO due to misalignment is a static linker bug or a missing linker flag.