Comment by cesarb | Hacker News Reader

Comment by cesarb | Hacker News Reader

Parent Full thread

> 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.

The 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...

The 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.

Wait, are you talking about browsers or AV now :D

AV. Browsers, too, but browsers at least have a good excuse.

It'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.

That's the basis for BDD's `pledge(2)`[0]

[0]: http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/...

>> browser vendors are unable to enable stronger forms of sandboxing,

Is it availble as a setting , for those of us without AV ?

I 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.

You 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.

Not 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.

On 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.

> 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).

Valgrind's leak checker is far more complicated than a simple malloc replacement. It's a virtual machine that runs the program being debugged.

It is poor man's solution, because on the cases there was money to spare, we could use Purify.

Reply on news.ycombinator.com