1 |
On Fri, Oct 21, 2016 at 2:02 PM, Mick <michaelkintzios@×××××.com> wrote: |
2 |
> |
3 |
> I haven't looked into exploits for this. At a practical level, what will it |
4 |
> take to compromise a PC? |
5 |
> |
6 |
|
7 |
You need to be able to run arbitrary code as a non-privileged user |
8 |
that has read-access to a file whose modification would allow |
9 |
elevation of privileges, on a read-write mounted filesystem. |
10 |
|
11 |
For example, somebody with shell access to your system could edit a |
12 |
SUID binary to obtain a root shell. Or they could edit any number of |
13 |
config files in /etc to cause code to be run as root, and so on. |
14 |
|
15 |
In general it is pretty easy to exploit in any multi-user scenario. |
16 |
It is a privilege escalation vulnerability, so somebody needs to |
17 |
already be running non-privileged code on your host. On some more |
18 |
"exotic" configurations like android where all the suid and |
19 |
configuration stuff is mounted read-only and even read access tends to |
20 |
be limited cross-user the opportunity for attacks is much smaller. |
21 |
|
22 |
I'm not sure how hardening like SELinux interacts with this. I'm not |
23 |
sure if it would prevent modification of the files. It could limit |
24 |
some of the impact of execution of those files, since you'd probably |
25 |
be running as root in a more limited security context. I suspect that |
26 |
containers wouldn't help a great deal, since you could get root inside |
27 |
the container, and if you have root inside the container then you can |
28 |
probably get whatever user that is equivalent to outside the |
29 |
container, and if that isn't root on the host you could use the same |
30 |
attack to obtain root on the host. |
31 |
|
32 |
Note, I'm not an expert on such matters, but this is probably not far |
33 |
off the mark. |
34 |
|
35 |
-- |
36 |
Rich |