Seth David Schoen <[email protected]> wrote:
> Theo de Raadt writes:
>
> > This is a bit different than polymorphism (which is interpreting
> > variable-sized instruction sequences at alternative offsets), but it is
> > worse (data tables placed into code without giving a shit about the
> > bytes in the data tables having meaning as instructions)
>
> Is there a ROP gadget scanner that could identify byte sequences that
> are useful to ROP attacks in general, beyond just the specific individual
> byte 0xc3? Then one could set a goal of reducing the extent to which
> any such byte sequence appears in code segments, both by not including
> them in data tables like this, and conceivably by having compilers try
> not to emit them in code.
Yes there are tools for that. google for "rop gadget scanner" and you'll
find the first few.
But that isn't the right approach.
If you find just one gadget, how do you react? You can't the constant table
to have different values.
You move the table to rodata. So why not skip the scanning approach, and
move them all to rodata?
Because that is exactly where the data belongs. The C versions of these
functions use 'const', and it goes to rodata.
Can you imagine a world where the C versions of these functions had tables
annotated with __attribute((".section text")) to ensure the data table is
'fast in the cache'? Come on, anyone who did that would be laughed straight
off a cliff.
