R0b0t1 <r03...@gmail.com> wrote: > 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. > [...] you can't directly cause another process to start executing > your code directly [...] On Windows there exists CreateRemoteThread.
If you get your browser to do what you wish (e.g. calling CreateRemoteThread on windows) you can usually let it directly execute what you wish, anyway. So there is hardly a difference from the system. I agree that the number of possible exploits for the former was slightly decreased if you had a correspondingly configured hardened kernel (and provided, of course, that you have not other gapping security holes like polkit, systemd, nepomuk/baloo, ... which all suffer from the same problem than browsers due to the fact that they provide every user access to a much too complex software stack.) But my original text was arguing against the claim that the primary purpose of hardened kernels was to protect against untrusted users sitting in front of the keyboard.
