1 |
On Fri, 29 Jan 2016 18:13:23 +0100 |
2 |
"PaX Team" <pageexec@××××××××.hu> wrote: |
3 |
|
4 |
> On 29 Jan 2016 at 16:44, Alessandro Di Federico wrote: |
5 |
> |
6 |
> > On Thu, 28 Jan 2016 02:49:46 +0100 |
7 |
> > "PaX Team" <pageexec@××××××××.hu> wrote: |
8 |
> > > nobody has ever shown that there exists such a bug (or set of |
9 |
> > > bugs) and in fact there's ample evidence that already executable |
10 |
> > > code contains all the necessary gadgets an exploit would need. |
11 |
|
12 |
Could you please detail better this "ample evidence"? Being so vague |
13 |
while requiring so much burden of proof on my side is a bit unfair :) |
14 |
|
15 |
I understand, and partly like, your practical approach, but security is |
16 |
not just preventing a certain bug to from being exploitable. |
17 |
Nowadays exploits, as you know, often use multiple vulnerabilities, |
18 |
while in the past a single one was enough. This makes attacker's life |
19 |
harder, that's why we ASLR: it doesn't prevent an exploit, it just makes |
20 |
it harder to exploit (e.g. you need an additional vulnerability). That's |
21 |
also why we have RELRO. |
22 |
|
23 |
A common principle when designing a secure system is trying to reduce |
24 |
the attack surface as much as possible, to decrease the chances that |
25 |
an attack is feasible. And that's exactly what the countermeasure I'm |
26 |
suggesting aims to do. |
27 |
|
28 |
I don't like to cite my own work, but take for instance the "leakless" |
29 |
attack [1,2]: finding the various gadgets required to perform the attack |
30 |
is not a straightforward task. The lesser the executable code, the |
31 |
harder it gets. |
32 |
|
33 |
Also, there are a couple of tools which require a set of gadgets to |
34 |
automatically build ROP chains (so called "ROP compilers", e.g. [3]). |
35 |
Reducing the amount of binaries on which they work increases the |
36 |
security of your system. Same argument on more versatile tools such as |
37 |
nROP [4], which don't require a fixed set of gadget but try to play with |
38 |
what they have. In this case we might make their life harder, and make |
39 |
them produce longer ROP chains, which is a critical factor in the |
40 |
evaluation of the feasibility of an exploit. Try a run of |
41 |
|
42 |
find -name "*.rb" -exec grep "'Space'" {} \; |
43 |
|
44 |
in your metasploit directory to get an idea of the average space |
45 |
available for exploits. |
46 |
|
47 |
Also, quite often, developers try to isolate Internet-facing deamons in |
48 |
small programs (take a look at DJB's qmail), making them even smaller by |
49 |
reducing the amount executable code sounds like a good idea to me. |
50 |
|
51 |
Not to talk about works trying to remove gadgets at compile-time *on |
52 |
the actual code* [5], ignoring `.rodata` and the like. But Gentoo will |
53 |
probably never use those, so it's less of an argument :) |
54 |
|
55 |
> > and there are 0x410 wasted bytes of memory due to `--rosegment` |
56 |
> > (the second `PT_LOAD` is mapped at 0x401410), in addition to the |
57 |
> > 0x728 which are wasted due to the RW segment. |
58 |
> |
59 |
> there's nothing wasted here, quite the opposite in fact, the linker |
60 |
> was smart enough to pull 3 segments into one physical page which |
61 |
> minimizes page cache waste on the kernel side and disk block usage on |
62 |
> the filesystem side. |
63 |
|
64 |
You're partly right. The kernel should be smart enough to use a single |
65 |
physical page for both the 0x400000 and 0x401000 pages, despite having |
66 |
different permissions, but for sure the last PT_LOAD needs a distinct |
67 |
page, so its first 0x728 bytes are effectively wasted. But this is an |
68 |
unrelated issue. |
69 |
|
70 |
> you have yet to demonstrate that it's a countermeasure against |
71 |
> anything ;). |
72 |
|
73 |
First I have to convince myself that the countermeasure I'm suggesting |
74 |
is fully effective! Which is not the case for how `--rosegment` |
75 |
currently works. :) |
76 |
|
77 |
-- |
78 |
Alessandro Di Federico |
79 |
|
80 |
[1] https://clearmind.me/leakless.pdf |
81 |
[2] https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/di-frederico |
82 |
[3] https://github.com/pakt/ropc |
83 |
[4] http://aurelien.wail.ly/nrop/ |
84 |
[5] https://www.acsac.org/2010/openconf/modules/request.php?module=oc_program&action=view.php&a=&id=121&type=2 |