Comment by capitalsigma | Hacker News Reader

Comment by capitalsigma | Hacker News Reader

Parent Full thread

> Somewhere between base arithmetic and x86 is a sandbox people can’t just walk in and out of....Efficiently microsandboxing individual codepaths is a thing we should start exploring.

wat

The turtles need to end somewhere --- at the end of the day, you are writing something that becomes machine code, and you've lost the benefit of your high-level abstractions. The glibc bug is a perfect example --- glibc is an abstraction layer to make life safer that virtually all (excluding Debian and some other distros, but near enough) Linux code links against.

No matter where you put it, your stack is going to have a layer like that in it somewhere, and sometimes you're going to find bugs in that layer. Maybe next time it's a bug in your C-to-JS compiler that emits insecure code, or a bug in your `microsandboxing framework` that allows RCE. Shit, maybe there's a bug in your CPU architecture that allows RCE.

The glibc bug is an example of the sort of incredibly rare screwup you can't escape no matter how hard you try, and we're fortunate that 'the good guys' caught it before it had a chance to develop in the wild.

What I'm saying is that a lot of energy has gone into "Assuming an attacker has gotten us into an undefined state, let's try to prevent them from pushing us into a chosen redefined state." And what I'm saying is, maybe we can create an environment where we don't end up in undefined states, or at least, there are bounds to how undefined they can be.

For example, I'm exploring ending use after free bugs by just not freeing memory. This sounds ridiculous until you realize that on 64 bit, leaking virtual memory (and therefore never recycling pointers) is actually not an insane idea, particularly for browsers that get to kill processes outright because they feel like it. Also, lots of UaF in there.

When you indict things like ASLR as being little more than bait for exploit developers, and later suggest that part of the solution might be a hack involving free() create zombie addresses, you give the impression of having said "exploit mitigations aren't working, unless they're my exploit mitigations".

(I also don't think yours is a good plan, but I'll wait for you to publish more details before criticizing it further).

Very specifically, I'm interested in exploit mitigations that eliminate undefined states, rather than just hope an attacker doesn't know enough to redefine them. One can show "zombie pointers" (fine, we've got lots of space in 64 bit land) will never allow an attacker to exploit a UaF much easier than we can show memory is randomized enough.

At the end of the day hard bounds checking (however slow it might be) also falls into this category of "approaches that do not try to survive falling into undefined states". I'm not saying ASLR et al isn't useful, just that we should put more energy intostaying within well defined states.

That's ultimately what "better" languages promise, after all. I'm curious if there are approaches that don't require rewrites, and very interested in actually measuring what does and doesn't absolutely suppress vulnerability, at what performance cost. We're not doing enough of that.

> And what I'm saying is, maybe we can create an environment where we don't end up in undefined states

That environment is not going to be programmable in C, unless you want a huge performance hit.

You might be right, you might not be, in the general case. In the specific case getaddrinfo is not performance sensitive (to say the least) and that entire block could be specially compiled 10x slower or run inside of a trivially available sandbox.

We have options we're not exploring.

But there is a big difference between using a language that requires you to be explicit about doing unsafe stuff (here be dragons kind of thing) and one that every single code line is a possible exploit, relying on programmer's skill to make it perfect.

Debian uses glibc now and eglibc is just a fork of glibc.

Reply on news.ycombinator.com