6 ms·

Dramatically Reducing Software Vulnerabilities [pdf]

77 points by neiesc 10y ago

gravypod 10y 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 10y 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 10y ago
  Out of curiosity, what do you think the horrible ideas are?
  - gravypod 10y 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.
    - PaulHoule 10y ago
      Two examples of MTD at work are: (i) address space layout randomization: this is by no means impervious but it is worth doing (ii) there being several "official" Etherium clients such that if somebody hacked just one client they could not take over the whole network.
    - Clubber 10y ago
      I think the idea of using micro services is that lessens the surface area of what you need to harden. In other words, it's easier to harden a simple service that just does one or a few things versus hardening a complex monolithic application. I'd liken it to OOP encapsulation or the idea behind linux executables.
    - nickpsecurity 10y ago
      Moving Target, aka obfuscation, is one of best things you can do against serious attackers on top of solid baseline. Just obfuscating CPU as a non-Intel CPU masquerading as one protected many deployments of mine and others for years on end. The idea is the extra effort they put in on a per-client or per-site basis either breaks their attack entirely or makes you more likely to notice it.
tyingq 10y 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 10y 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.
  - tyingq 10y 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 10y ago
I don't really understand why this doesn't cover memory safety.
- tyingq 10y ago
  Overflow, memory randomization, and other related topics are sprinkled around the document, but yes, there's not a specific section.
- naasking 10y ago
  Seriously. Just switching to memory safe languages would be the single biggest reduction in software vulnerabilities you could achieve with one decision.
- duneroadrunner 10y 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 https://news.ycombinator.com/item?id=12643463 [2] shamelss plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus
godmodus 10y 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 10y ago
  Fool me once...
PaulHoule 10y ago
It seems like I am seeing something about SAT solvers almost every day now.
Animats 10y 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.
- tptacek 10y 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.
  - Animats 10y 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.
    - tptacek 10y ago
      The web server in a consumer router exists mostly for the purpose of providing an admin interface --- in fact, most attacks on customer prem devices target that web server. Many of the admin functions on the router are game-over for security. It's a good example of something that seems like it should be straightforward to sandbox, but isn't.

77 points by neiesc 10y 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 10y 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 10y ago
Out of curiosity, what do you think the horrible ideas are?
- gravypod 10y 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.
  - PaulHoule 10y ago
    Two examples of MTD at work are: (i) address space layout randomization: this is by no means impervious but it is worth doing (ii) there being several "official" Etherium clients such that if somebody hacked just one client they could not take over the whole network.
  - Clubber 10y ago
    I think the idea of using micro services is that lessens the surface area of what you need to harden. In other words, it's easier to harden a simple service that just does one or a few things versus hardening a complex monolithic application. I'd liken it to OOP encapsulation or the idea behind linux executables.
  - nickpsecurity 10y ago
    Moving Target, aka obfuscation, is one of best things you can do against serious attackers on top of solid baseline. Just obfuscating CPU as a non-Intel CPU masquerading as one protected many deployments of mine and others for years on end. The idea is the extra effort they put in on a per-client or per-site basis either breaks their attack entirely or makes you more likely to notice it.

tyingq 10y 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 10y 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.
- tyingq 10y 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 10y ago

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

tyingq 10y ago
Overflow, memory randomization, and other related topics are sprinkled around the document, but yes, there's not a specific section.
naasking 10y ago
Seriously. Just switching to memory safe languages would be the single biggest reduction in software vulnerabilities you could achieve with one decision.
duneroadrunner 10y 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 https://news.ycombinator.com/item?id=12643463 [2] shamelss plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus

godmodus 10y 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 10y ago
Fool me once...

PaulHoule 10y ago

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

Animats 10y 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.

tptacek 10y 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.
- Animats 10y 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.
  - tptacek 10y ago
    The web server in a consumer router exists mostly for the purpose of providing an admin interface --- in fact, most attacks on customer prem devices target that web server. Many of the admin functions on the router are game-over for security. It's a good example of something that seems like it should be straightforward to sandbox, but isn't.