Open Bug 504195 Opened 15 years ago Updated 2 years ago

Investigate CFI enforcement through segregating code and data

Categories

(Core :: General, defect)

x86
macOS
defect

Tracking

()

People

(Reporter: gal, Unassigned)

Details

On a number of platforms the OS allocates our heap as executable memory, despite our pleas to give us read/write pages only. On x86, the NX bit is coupled to using PAE, which isn't enabled on older versions of Windows (XP prior to some service pack, for example).

While not all OS+CPU combinations offer non-executable pages, all x86 processor have segment-granularity execution disabling-enabling. We could use this to limit addresses that are allowed to execute to the bottom Nth of the address space by shrinking the code segment length. All code must be placed below that address, and the JIT code cache also must reside below that limit. All data must be placed above the limit.

Things to investigate:

- Do Win32 and MacOSX allow shrinking the length of the code segment, and is this maintained across context switches. I have played tricks like this with Linux, so I am pretty sure it works there.

- Does the loader respect shorter code segment limits? (in all likelihood, not)

- Can we trick the loader into only loading below a certain limit? (probably yes, i.e. allocate/free a large hole and let the loader find those pages to allocate from)

- Does ASLR respect shorter code segments? (probably not)

- Is there a better way to make ASLR not interfere with this than disabling it (at least Windows allows disabling ASLR, but would we take that hit? ASLR helps with return-to-libc type attacks)
Recommended reading about ASLR: http://benpfaff.org/papers/asrandom.pdf
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.