5 ms·
> Also, how is AV a (direct) impediment to a shipping a safe browser? It seems to me that a browser should be mostly agnostic toward AV. The main problem is th
by cesarb 10y ago
> Also, how is AV a (direct) impediment to a shipping a safe browser? It seems to me that a browser should be mostly agnostic toward AV.
The main problem is that AV (and some other Windows software) like to inject DLLs into every single process in the system.
The current trend in browser security is a heavy form of sandboxing, in which the sandboxed processes can only access a very limited set of system calls. For that to work, the set of system calls required by the sandboxed process must be known, which is only possible if all the code running within the sandbox comes from either the browser or the operating system itself.
However, if an arbitrary DLL is injected into the sandboxed process, running arbitrary code and attempting to call arbitrary system calls, the sandboxed process will crash, either because the sandbox mechanism kills the process when it attempts to call an unexpected system call, or because the call attempt returns an error value which the injected DLL didn't expect.
Therefore, browser vendors are unable to enable stronger forms of sandboxing, since they'll lead to crashes in the wild.
- petra 10y ago>> browser vendors are unable to enable stronger forms of sandboxing, Is it availble as a setting , for those of us without AV ?
- teaearlgraycold 10y agoI doubt they'd have code for that if only a small minority of users will use it. Hardening something takes a lot of effort, and it's probably not worth the work to have two different sandbox techniques just so that users without AV can have a better one.
- digi_owl 10y agoThe current trend in security seems to be heavy sandboxing, period. And anything that gets in the way of said sandboxing, however benign, is considered insecure, full stop...
- GauntletWizard 10y agoIt's the principle of least privilege. Give apps (and websites, and even parts of core services/infrastructure and kernel code) only what they absolutely need. Every syscall you can say shouldn't ever be called is one less avenue for attack. Benign isn't good enough. You need to actively justify every privilege, and leaving a few open for "benign" reasons is bad practice.
- colejohnson66 10y agoThat's the basis for BDD's `pledge(2)`[0] [0]: http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/pledge.2 http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/...
- tptacek 10y agoThe code we're talking about isn't benign. It's incredibly complicated and has one of the worst track records in all of software security.
- pjmlp 10y agoYou also get the same thing with LD_PRELOAD. We only way forward is proper sandboxing and not allowing any form of executables to run from $HOME, even if it means some coding patterns will no longer be as easy to implement.
- cesarb 10y agoNot only is LD_PRELOAD interpreted by code within the process itself (so it can easily be ignored), but also the parent process which forks the sandbox process can (and most probably does) clear all the environment variables. I believe it's not as easy on Windows for a process to protect itself against DLL injection.
- pjmlp 10y agoOn my UNIX days I used it as poor man's solution to track memory leaks, by overriding malloc()/free(), this was done at dynamic linker level, not the process. So I checked and apparently this no longer works since AT_SECURE exists, around 2.6.0 time frame. It has been a while since I cared to do this on GNU/Linux, maybe around 2002. So thanks for forcing me to update myself.
- majewsky 10y ago> On my UNIX days I used it as poor man's solution to track memory leaks, by overriding malloc()/free(), That's not a poor man's solution. That's how Valgrind's leak checker works (AFAIK).