Dramatically Reducing Software Vulnerabilities [pdf]

http://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8151.pdf

by neiesc • 10 years ago

77 43 10 years ago

nvlpubs.nist.gov

gravypod2• 10 years ago

Some of these are great, some of these are OK, and some of these are horrible ideas. I wish instead of "studies" we did RFCs

throwaway729• 10 years ago

I wish instead of "studies" we did RFCs

This is not a study, it's just a report. It's mostly a summary of a lot of different sources, approaches, and opinions.

A proper study on this question would certainly include an RFC or other form of opinion polling. But a thorough study would go far beyond opinion polling/solification and also attempt to measure the accuracy of solicited opinions in an objective way.

shpat• 10 years ago

Out of curiosity, what do you think the horrible ideas are?

gravypod2• 10 years ago

There are a few things I noticed and I'll cover a few right now.

Firstly, they are talking about using microservices which would be ok (I've used a few microservices for specific applications that actualy make sense to service-ify) but I would by no means consider this a safer way of doing things. When you're talking about services run by our government, who isn't notorious for having their network-security done right, I'm very weary of them moving to a microservice architecture.

MTD is another thing that sounds concerning. This seems like the bottom of the barrel of security ideas and looks like it would be far more complicated then the other methods mentioned. If used this along would probably introduce more bugs.

"Education and Training" can basically be summed up as universities being stuck in the 70s and not teaching CS but teaching the Math that CS needs.

The "Liability" section is keeping me torn.

tyingq3• 10 years ago

Fairly in-depth. I'm surprised though, at the generally positive tone around containers/docker. No mention of the the current widespread practice of containers running as root. Nothing about the relative lack of protection against local kernel exploits escaping the container, etc.

Was expecting something a little more balanced on the topic.

hueving• 10 years ago

Note that it doesn't say that containers are secure. It just implies that they can be used to help with security practices like principle of least privilege for processes.

In other words, containers are better than running normal processes for security. Not better than running a VM.

tyingq3• 10 years ago

Agreed. But, seems odd to mention "principle of least privilege" when unprivileged containers aren't the default :)

(yes, I get those are two different scopes of the word privilege)

ctz• 10 years ago

I don't really understand why this doesn't cover memory safety.

tyingq3• 10 years ago

Overflow, memory randomization, and other related topics are sprinkled around the document, but yes, there's not a specific section.

naasking• 10 years ago

Seriously. Just switching to memory safe languages would be the single biggest reduction in software vulnerabilities you could achieve with one decision.

duneroadrunner• 10 years ago

Yes, after reading a draft[1] of this document, I suggested to them that they seemed to be insufficiently emphasizing remote execution vulnerabilities (due to invalid memory access). I also pointed out that they neglected to mention Rust and the Clang/LLVM sanitizers. (And SaferCPlusPlus[2] too.) They acknowledged my comments, but it doesn't seem to have had much effect on the document.

[1] https://news.ycombinator.com/item?id=12643463

[2] shamelss plug: https://github.com/duneroadrunner/SaferCPlusPlus

godmodus• 10 years ago

"A weakness is an undesired characteristic of a system’s requirements, design or implementation [Black11a]. This definition excludes:

* ...

* insider malfeasance, such as exfiltration by Edward Snowden"

Heh.

eutectic• 10 years ago

Fool me once...

PaulHoule2• 10 years ago

It seems like I am seeing something about SAT solvers almost every day now.

Animats3• 10 years ago

Those are the usual answers. But they're too broad.

A good way to look at the problem is that trusted software needs to be far less vulnerable, and untrusted software needs to be kept in a cage where it can't make trouble.

On the untrusted side, all games, for example, should be caged or sandboxed. (Yes, this breaks some intrusive anti-cheat mechanisms. Tough.) Applications on phone-type platforms should have far fewer privileges, (Yes, that breaks some ad networks. Tough.)

Until somebody with enough power to make it stick takes a hard-ass position and sets standards, there's not going to be progress. It would be progress if AT&T or Comcast or Verizon deployed secure routers, for example.

tptacek3• 10 years ago

I'm not sure what you mean by AT&T deploying secure routers. Do you mean routers as in the devices at the core of their networks? Or as in the customer prem devices? What's the role of sandboxing for either of those devices?

Two challenges with this least-privilege strategy for software security:

1. For single-function devices, like a customer prem device for a cable network, there may not be meaningful privilege boundaries to exploit.

2. As privilege models get more complicated, the risk that privileges may accidentally equate to each other increases. This was an observation Bernstein made of his qmail security model in his retrospective paper.

Animats3• 10 years ago

I meant secure routers on customer premises, ones that are resistant to attacks from at least the network side. That was the big problem with the latest round of DDOS attacks.

What would you sandbox in a consumer router? If there's a web server in there, it needs very limited access the rest of the router.

nickpsecurity7• 10 years ago

Here's an option:

1. Secure, automatic update process that keeps user config where possible.

2. Default configuration that's as secure as factory setting can get plus without unnecessary services running.

3. Running on a self-healing microkernel if possible.

4. Code for key functionality written in languages like Ada, SPARK, and/or Rust for reduced 0-days.

5. Embedded firewall with rate limiting from host network in event ISP detects DDOS.

6. Optionally, more secure way to connect to admin interface comes with installation CD or software.

Those seem like nice baseline for router that would increase its security and availibility at relatively, low cost. There used to even be a vendor selling switches and routers with INTEGRITY-178 separation kernel enforcing POLA down to the ports. Rockwell uses AAMP7G CPU to enforce it down to the thread or process level with mathematical proof of its correctness. So room to improve further to high-assurance for that end of the market, too, on top of what my list already gives.

EDIT to add what just showed up in another feed. Case in point about how much better baseline could be with small effort.

https://lobste.rs/c/wyyqc6

chubot5• 10 years ago

It's astonishing to me that I hit Ctrl-F and searched for "sandbox" and "software compartmentalization" and there are no hits in that doc.

Chrome-like sandboxing seems like the current state of the art, and it's complementary to all the techniques mentioned. There will be vulnerabilities, but making attackers chain vulnerabilities to get into the system will have the effect of "dramatically reducing them".

I don't see any numbers in that paper either, which seems like a big oversight.

Chrome has proven to be more difficult than other browsers to exploit, and this is with hundreds of thousands of dollars on the line. I think the Pwn2Own escape in 2016 required the attacker to chain 4 exploits. I don't think people hacking servers need 4 exploits today.

https://en.wikipedia.org/wiki/Pwn2Own

The browser is operating under a more extreme environment than a server: it contains tens of millions of lines of C++ code, and it exposed to attackers (web sites) by billions of people continuously throughout the day.

This is also the solution that doesn't require rewriting hundreds of millions of lines of code, which is an economic impossibility in the short term.

There is some current research on how to help programmers split programs into trusted and untrusted parts, e.g.:

http://dl.acm.org/citation.cfm?id=2813611

tptacek3• 10 years ago

People hacking servers don't need 4 exploits, but hacking servers is still difficult relative to hacking clientside code, because servers (a) have a more limited attack surface than clients and (b) are less performance-sensitive and thus can rely on memory-safe languages.

Docker and seccomp-bpf are techniques for sandboxing server applications, and they're useful, but they run into the same problem as sandboxing any complex system: the privilege to do many of the things the application ordinarily does --- writing a row in a database table, for instance, or creating a new queue entry --- can unpredictably result in privilege escalation.

The techniques you need to apply to make sure that basic application actions don't escalate privileges are largely the same as the ones you'd take to ensure the application doesn't have bugs.

Don't get me wrong: I think more and more applications will take advantage of serverside sandboxes, to good effect. But I don't think it's going to be a sea-change for security, and I don't think it's valid to compare the "4-exploit chain" needed for Chrome to the situation in a complicated web application.

Clubber3• 10 years ago

It's astonishing to me that I hit Ctrl-F and searched for "sandbox" and "software compartmentalization" and there are no hits in that doc.

They use the term container. It's a subheading:

2.2.1 Operating System Containers

"...Container-based isolation can clearly reduce the impact of software vulnerabilities if the isolation is strong enough."

nickpsecurity7• 10 years ago

The OP Secure Browser invented the process isolation w/ kernel model for browsers in 2008. It was based on what high-assurance security did since the 70's. Native Client watered down its security a bit in 2009 to make it faster and with unsafe language. Result + some regular stuff was Chrome sandbox. Far from cutting edge in high assurance security for browser architecture or isolation in 2016.

Lots of potential for improvement using tech developed since then that does way better or older tech that does job little better.

tornadoboy55• 10 years ago

Chrome-like sandboxing seems like the current state of the art

Where do you get that from? Ever heard of the macOS Seatbelt framework? Jails in BSD?

jwatte• 10 years ago

The problem is that anti-cheat and ad networks are requirements for the market that the current market forces have built. Saying we should be without them, without any kind of plan for how to reshape those market forces, is like wishing for a unicorn pony. When you're a subsistence farmer.

Animats3• 10 years ago

That's why I got out of security years ago. If you could have a completely secure smartphone, but it wouldn't run Pokemon Go, would you buy it? (I've been saying this for a while, with occasional changes to the frivolous application.)

How many people dumped Uber because Uber now insists on knowing your location at all times?

taeric• 10 years ago

This is appealing for the duality. Important stuff should be protected. Unimportant shouldn't be able to do anything.

The problem is soon everything will be important. Think we can classify ourselves out of this? Good luck.

So, we can make things less vulnerable at a software level. Or we can pick our data. For example, your personal information should be more resilient to problems.

The problem is this is as much societal as software. If someone "robs" you by buying tons of digital non goods, there should be cheap recourse. If they bought real goods, should be the same.

But then we get to physical things like cars. Nothing is as good as the sandbox that currently exists of isolated devices. As soon as they are fully networked, the concept of sandboxing is laughable. Desperately needed, but laughable.

Dramatically Reducing Software Vulnerabilities [pdf]

Related Stories