Hacker News Reader

Comment by devit | Hacker News Reader

Yes, the problem is that this terrible code directly copies the untrusted "nl2e" variable from the VM into the extremely critical hardware page table, only doing a broken unclearly written check.

Instead, "nl2e" should have a data type preventing such a direct copy, and only allowing to test single bits.

The code should then be written to copy bits one by one (for bits where it is appropriate), with a comment for each bit stating why it is safe to copy them.

The fact that this is not the case means that none of the other code in Xen can really be trusted to be bug-free, and there is probably no way to fix that without starting over or doing an equivalent amount of rewriting work.

View on HN

Can you name one substantial software project with more than 10 developers that you expect to be bug free?

Space Shuttle embedded controllers firmware

... I'll say a bit more ... I think it's sad that it's not practical anymore to write really high quality code. And most computer security researchers aren't interested in that anymore either, because it's not possible to force all other developers to write high quality code (and if you do you're called "mean" "alienating" etc.) So all they/we try to do is find new layers to contain all the bad code that has been and will be written.

Can we really be surprised when those layers, particularly if they are popular because they came out first and have lots of features, are also low-quality code? Is there anywhere a foot can be put down?

Also, openbsd is another good example of a project with code with a very very low bug density.

> Space Shuttle embedded controllers firmware

Not the space shuttle, but if you think things that go to space (and land on the goddamned Moon) are free of bugs then you are very sorely mistaken.

https://www.netjeff.com/humor/item.cgi?file=ApolloComputer

The orbiter computer was also not bug free. Remarkably correct software, even so.

http://klabs.org/DEI/Processor/shuttle/

At $job-2 doing agricultural telemetry, our firmware engineer found that one ISP's satellite was randomly dropping the last character in routed traffic. Took a little while for them to believe us, and that satellite had been up there for 30 years...

The engineering behind the space shuttle software is a fun read [1].

[1] http://www.fastcompany.com/28121/they-write-right-stuff/

Not sure, such is the sad state of the world.

But it would be especially important to have SOMETHING that can run multiple applications while being 100% sure that it is enforcing security between them.

So far everything has been a total disaster, with browsers getting completely owned every year at Pwn2Own, conventional kernels being effectively expected to be locally exploitable at all times (which means all mobile sandboxes are broken as well), and hypervisors where Xen seems to be the most secure of the ones that are mature, and is still terrible.

> Can you name one substantial software project with more than 10 developers that you expect to be bug free?

No, not even if you're counting in binary.

seL4 microkernel.

Of course, the velocity of development is very low, but that's because they want developers who can wrap their head around formal proofs.

Perfect is the enemy of good. There are plenty of projects I expect to have 90% lower defect rates.

This story from last month comes to mind: https://news.ycombinator.com/item?id=10430862

I suspect hiring this company would make even a large budget wilt a bit. Just a bit :P

Are there static analysis tools which could have flagged this vulnerable coding style?

No. This is a subtle vulnerability that involves the flags in the x86 page table not matching the hypervisor's view of them - not a mere buffer overflow. Ordinary static analysis couldn't have fixed this. Safe languages couldn't have fixed this. Even a complete formal proof would have missed this without a good model.

I wonder which pen-testing techniques were used by Alibaba to find this vulnerability.

Disagree. If those flags were properly typed then whoever added superpages would have had to make a decision about whether that was something guests should be allowed to set. Sure, they could still have made the wrong choice, but having the mask for which bits are allowed defined separately makes it much easier for a programmer to simply forget.

Heck, even without a type system, the problem is that the check is backwards. There shouldn't be a mask of flags that the guest isn't allowed to set, the flags should have been &ed with a mask that says which flags they are allowed to set, that way any new flag would have been disallowed by default.

The mask of flags that the guest isn't allowed to set is created by taking a whitelist of flags that it is allowed to set and inverting it, so that every flag that's not explicitly allowed is denied. They're flags that the guest was intentionally granted the ability to change. The problem is that Xen subtly mishandled the consequences of a guest changing them in a way that wouldn't affect normal guests. I haven't seen a solution to this that doesn't, in the end, basically boil down to not making that mistake in the first place.

Reply on news.ycombinator.com