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