1 |
On 29 Jan 2016 at 20:23, Alessandro Di Federico wrote: |
2 |
|
3 |
> On Fri, 29 Jan 2016 18:13:23 +0100 |
4 |
> "PaX Team" <pageexec@××××××××.hu> wrote: |
5 |
> |
6 |
> > On 29 Jan 2016 at 16:44, Alessandro Di Federico wrote: |
7 |
> > |
8 |
> > > On Thu, 28 Jan 2016 02:49:46 +0100 |
9 |
> > > "PaX Team" <pageexec@××××××××.hu> wrote: |
10 |
> > > > nobody has ever shown that there exists such a bug (or set of |
11 |
> > > > bugs) and in fact there's ample evidence that already executable |
12 |
> > > > code contains all the necessary gadgets an exploit would need. |
13 |
> |
14 |
> Could you please detail better this "ample evidence"? Being so vague |
15 |
> while requiring so much burden of proof on my side is a bit unfair :) |
16 |
|
17 |
the fact that the real life ROP exploits i've seen out there all make |
18 |
use of gadgets exclusively from (intended) code and not some data that |
19 |
happened to be mapped executable. note that i'm not claiming to have |
20 |
seen all the exploits out there but even if some exploits happen to |
21 |
use gadgets from non-code pages, it doesn't prove the value of --rosegment |
22 |
until one also proves that it is impossible to write the same exploits |
23 |
with gadgets from code pages only. add to this academic work like [1] |
24 |
and i believe you'll find yourself up against a rather high hill if you |
25 |
still want to prove the benefit of --rosegment ;). |
26 |
|
27 |
[1] Q: Exploit Hardening Made Easy |
28 |
https://www.usenix.org/legacy/event/sec11/tech/full_papers/Schwartz.pdf |
29 |
https://www.usenix.org/legacy/event/sec11/tech/slides/schwartz.pdf |
30 |
|
31 |
> I understand, and partly like, your practical approach, but security is |
32 |
> not just preventing a certain bug to from being exploitable. |
33 |
|
34 |
my approach is as much practical as theoretical, it is all based on a |
35 |
very generic and strong threat model, a full categorization of exploit |
36 |
techniques and corresponding defense mechanisms. i evaluate other defense |
37 |
mechanisms based on the same threat model and/or just plain common sense |
38 |
like in this case. |
39 |
|
40 |
> Nowadays exploits, as you know, often use multiple vulnerabilities, |
41 |
> while in the past a single one was enough. This makes attacker's life |
42 |
> harder, that's why we ASLR: it doesn't prevent an exploit, it just makes |
43 |
> it harder to exploit (e.g. you need an additional vulnerability). |
44 |
|
45 |
actually ASLR does prevent exploitation with a bounded probability |
46 |
absent of information leaks. if you're thinking of weak imitations |
47 |
then sure, you can brute force your way, but that won't work under |
48 |
grsecurity (you realize this is the gentoo hardened list, right? ;). |
49 |
|
50 |
> That's also why we have RELRO. |
51 |
|
52 |
yes, RELRO serves a quantifiable and useful purpose, which i have yet |
53 |
to see about --rosegment. |
54 |
|
55 |
> A common principle when designing a secure system is trying to reduce |
56 |
> the attack surface as much as possible, to decrease the chances that |
57 |
> an attack is feasible. And that's exactly what the countermeasure I'm |
58 |
> suggesting aims to do. |
59 |
|
60 |
the number of overall gadgets is not an attack surface. the number of |
61 |
any particular kind of gadget is one in that if it's 0 then the particular |
62 |
kind of gadget is unavailable for an exploit (which may or may not prevent |
63 |
exploitation). you haven't shown that --rosegment can achieve it for |
64 |
any particular gadget class on any particular binary, let alone all |
65 |
binaries mapped into a particular process (good luck with glibc btw ;). |
66 |
|
67 |
> I don't like to cite my own work, but take for instance the "leakless" |
68 |
> attack [1,2]: finding the various gadgets required to perform the attack |
69 |
> is not a straightforward task. The lesser the executable code, the |
70 |
> harder it gets. |
71 |
|
72 |
yes i know your work and i think you chose the very wrong choir to |
73 |
preach it to :P. for one, your attack assumes a setup without PIEs |
74 |
and BIND_NOW/RELRO which is kinda the anti-thesis of hardened gentoo. |
75 |
|
76 |
second, your attack assumes the ability to hijack control flow for |
77 |
which we also know the solution (various forms of CFI, i guess i'll |
78 |
stop at not citing my own work on it to be fair ;). |
79 |
|
80 |
last but not least, you haven't proved the 'harder' part in any |
81 |
quantifiable way i can see. like i said at the beginning, just |
82 |
show me *one* bug which is exploitable when .rodata is executable |
83 |
and isn't exploitable when .rodata is non-executable. |
84 |
|
85 |
> > there's nothing wasted here, quite the opposite in fact, the linker |
86 |
> > was smart enough to pull 3 segments into one physical page which |
87 |
> > minimizes page cache waste on the kernel side and disk block usage on |
88 |
> > the filesystem side. |
89 |
> |
90 |
> You're partly right. The kernel should be smart enough to use a single |
91 |
> physical page for both the 0x400000 and 0x401000 pages, despite having |
92 |
> different permissions, but for sure the last PT_LOAD needs a distinct |
93 |
> page, |
94 |
|
95 |
only when a copy-on-write fault hits it, which i'm not sure happens for |
96 |
a simple thing like hello world (i could certainly write one that would |
97 |
not need to write there since it's basically a write/exit sequence). |