This attack relies on being able to overwrite code generated by the JIT during the period in which the memory protection bits have not yet transition to r-x (i.e. they are still rw-). One approach to foiling this type of attack would be to compute a CRC value as instructions are written to the page, making the page r-x and then recomputing the CRC (based on page contents) to ensure that it has not deviated. Another defense against this type of attack is to shrink the time that the code is vulnerable, so setting page protections as each page is processed might be a valid approach.
Related and not discussed in the iSEC report, is bug 506693, which proposes that jit code pages be dual-mapped in the address space, with one mapping RW and the other mapping RX.
Created attachment 473881 [details] [diff] [review] wip - includes other mitigation techniques work-in-progress patch that computes a CRC checksum for each method that has previously been generated and is on a executable page. Prior to switching the pages to rw- we gather up these CRCs and later use them to re-validate the contents of each method on the page. see code bordered by the define NJ_HARDENING_CODE_CRC
Assignee: nobody → rreitmai
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → flash10.1.x-Salt
Related is bug 506693; dual mapping of code pages.
Can we fold this bug into 506693?
(In reply to comment #4) > Can we fold this bug into 506693? Different techniques and the bugs are cross-listed so I don't see value in doing so.
Rick, following your recent comments on hardening, please re-assign this bug to a doable target release. Removing Andre blocker.
No longer depends on: 641055
I don't believe this should be assigned as its not yet proven this is a worthwhile deterrent. Target is future and its unassigned.
Assignee: rreitmai → nobody
Target Milestone: Q1 12 - Brannan → Future
You need to log in before you can comment on or make changes to this bug.