| 1 |
On Thu, Jul 6, 2017 at 1:33 AM, Martin Vaeth <martin@×××××.de> wrote: |
| 2 |
> Peter Humphrey <peter@××××××××××××.uk> wrote: |
| 3 |
>> On Tuesday 04 Jul 2017 10:14:23 Martin Vaeth wrote: |
| 4 |
>>> |
| 5 |
>>> With modern browsers and their complexity, you can expect that any |
| 6 |
>>> website (or the one who has hacked it) can do anything which the |
| 7 |
>>> user of that browser can do if he is sitting on your seat. |
| 8 |
>> |
| 9 |
>> Have you seen any reports of that kind of thing? |
| 10 |
> |
| 11 |
> Are you joking? Every CVE of the browser (or of any of its dependencies) |
| 12 |
> which eventually allows an "execution of arbitrary code" exploit is |
| 13 |
> such an example. |
| 14 |
> |
| 15 |
>> but I'd expect Linux to be less vulnerable. |
| 16 |
> |
| 17 |
> This has nothing to do with linux. It is the complexity of the |
| 18 |
> browser which is the problem. |
| 19 |
> |
| 20 |
|
| 21 |
To be fair it is a bit more circuitous on Linux than it is on Windows. |
| 22 |
Even if you use (or abuse?) /proc as I outlined in my blurb on |
| 23 |
GRsecurity you can't directly cause another process to start executing |
| 24 |
your code directly, but you can edit its memory, debug it, and mess |
| 25 |
with it in almost every other imaginable way - or you can just find a |
| 26 |
way to get the user to execute some other executable you created on |
| 27 |
disk. |
| 28 |
|
| 29 |
On Windows there exists CreateRemoteThread.[1] You can force a |
| 30 |
currently loaded process to run whatever code you want. |
| 31 |
|
| 32 |
You can solve both of these problems with Role Based Access Controls, |
| 33 |
if you want to bother setting them up. Otherwise process sandboxing |
| 34 |
only applies to resources, not security. |
| 35 |
|
| 36 |
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms682437(v=vs.85).aspx |
Archives