1 |
On 25 Mar 2013 at 22:35, Kfir Lavi wrote: |
2 |
|
3 |
> Thanks for sharing this talk. I didn't know that the program image in |
4 |
> Linux is not randomize by ASLR. |
5 |
|
6 |
well, that's not quite true these days, even vanilla has logic to |
7 |
randomize the main executable - provided it's a PIE. it of course |
8 |
depends on the distros to provide PIEs for some/most of the programs |
9 |
they distribute, which is where the main difference is between say |
10 |
hardened gentoo and regular mainstream distros (the other difference |
11 |
is the amount of randomization due to PaX). |
12 |
|
13 |
> What i understand from this talk: I can probably take a lot of code |
14 |
> out of glibc, but it will never be less then 20K, which lets attacker |
15 |
> that is able to jump to glibc, to construct his ROP program. |
16 |
|
17 |
exactly. |
18 |
|
19 |
> As I don't have much experience in security, my question would be: Can |
20 |
> we deploy another mechanism to fight this ROP program building from |
21 |
> the program image? |
22 |
|
23 |
as i said above, PIE is one approach if we ignore infoleaking bugs |
24 |
that make all randomization based solutions fail. the real solution |
25 |
is some form of control flow enforcement but as far as i know, |
26 |
nobody proposed (let alone produced) a sufficiently well performing |
27 |
and easy-to-deploy idea so far. this is a very hot research topic, |
28 |
both in academia and industry, just look up microsoft's bluehat prize |
29 |
a year or so ago. |