5 ms·

To quote the article: ``` Furthermore, as Microsoft has patched most of the basic memory safety bugs, attackers and bug hunters have also stepped up their gam

To quote the article: ``` Furthermore, as Microsoft has patched most of the basic memory safety bugs, attackers and bug hunters have also stepped up their game, moving from basic memory errors that spew code into adjacent memory to more complex exploits that run code at desired memory addresses, ideal for targeting others apps and processes running on the system. ``` Is all we can hope for in the security game a series of mitigations? As soon as we add layers of security (Stack cookies, ASLR, memory "safe" languages with exploitable runtimes, etc.) it seems like new methods are invented to bypass them and those methods gradually become widespread (ROP chains, runtime fuzzing, rowhammer, speculative execution exploits). What is the next "70 percent" of security bugs? Is there an end to this race? I think the only thing in the future that can ever be as secure as in-person conversation and paper records is devices using zero-intermediary communication, in the style of an ansible https://en.wikipedia.org/wiki/Ansible https://en.wikipedia.org/wiki/Ansible, and extremely restricted storage which can only store data and not arbitrary application state.

ip26 8y ago
Security is an arms race, in a quite literal sense of the term. Arms races don't really ever end, except for truces/treaties or total victory.
- raymond_goo 8y ago
  No, just use Rust...
  - swsieber 8y ago
    Well, that wouldn't eliminate everything (row-hammer, speculative execution), but it would probably get rid of the most common culprits - buffer overflows and use after free.
    - phkahler 8y ago
      Things like row hammer will not get attention until they are commonly used. Rust does eliminate the most common vulnerabilities and should be seriously considered for any new project that would otherwise be written in C.
      - swsieber 8y ago
        Oh, I completely agree. It's just easy to overstate Rust's guarantees, which doesn't do anybody any good.
  - rurban 8y ago
    Nonsense. Rust safeties are massively overhyped. Not enough memory safety (comparable to Java, which is similarily memory unsafe), no type safety (unsafe keyword), not enough concurrency safety (not deadlock free, need to manually set mutexes). While there do exist safe and fast languages, Rust is not one of them.
    - pcwalton 8y ago
      If we all wrote in languages as memory-safe as Java, almost all these security bugs would go away. Is Rust guaranteed to be 100% memory-safe? No, there could always be bugs in the compiler and/or unsafe code. (Aside: it annoys me how people consider the presence of an unsafe keyword inherently less trustworthy than a non-verified compiler/runtime system, when there is really little difference between them.) Is it a huge improvement? Yes.
      - sanxiyn 8y ago
        Full agreement, but I think unsafe-phobia is mostly about user-extensible nature of it. unsafe in standard library is okay, because as you said it's no more dangerous than doing it in runtime. unsafe in "your" library is not okay, because I don't trust you to modify runtime either.
        rurban 8y ago
        unsafe memory and unsafe types are not okay if you widely claim to be memory safe. Thousands of people actually believe these lies, and companies do makes decisions on these claims. It's much more memory unsafe than Java in fact. Java recently removed the unsafe tricks, whilst rust was once safe and went more and more unsafe since.
    - phkahler 8y ago
      >> Nonsense. Rust safeties are massively overhyped. No. They are not. You obviously have not done your homework on the subject.
      - 8y ago
21 8y ago
It's about increasing the costs to the attacker. Now a Windows/browser zero-day requires months of research and can be sold for $100k+.
- est31 8y ago
  Yes, the goal is to increase the costs to the attacker as much as possible while having minimal added costs during development and runtime of the software. Statically proven programs are great security wise but they are expensive to produce, while adding ASLR is not perfect but comparatively easy to pull off.
monocasa 8y ago
sel4 shows that an endgame is possible wrt to memory safety, it's formally verfied to be memory safe. It's sitting at ~25 to 1, proof code to implementation code. I think you could probably get that down to 5 to 1 or so by treating a lot of the work they did as a library. The proof covers a full equivalence from abstract spec to machine code, and you could reuse a lot of that. Sort of how it's not fair to include the LOC of your compiler even though you need that for your program ultimately.
- chillacy 8y ago
  But does formal verification even help when you're up against side channel attacks on the hardware? Like the branch predictor or DRAM memory access timing.
  - monocasa 8y ago
    With a model of the full system, quite possibly. That's one of the things that makes me so excited for RISC-V.
    - sempron64 8y ago
      I don't know of any technique to model or avoid timing attacks that wouldn't drastically slow down execution to the point of being impractical.
  - deleted 8y ago
    [deleted]
- xiphias2 8y ago
  Reinforcement learning can be used to improve theorem proving, but it probably needs more research: https://arxiv.org/abs/1805.07563 https://arxiv.org/abs/1805.07563
- rurban 8y ago
  Nope, sel4 is unsafe against modern Spectre/Meltdown attacks. Only Fiasco was recently made safe against these. Secondly, Microsoft's own SecureMemZero is insecure against those attacks. It only applies a trivial compiler barrier, but no memory barrier, so you cannot use it to securely delete sensitive memory.
james_s_tayler 8y ago
Computer security is a fundamentally asymmetric game. Your entire stack needs to contain zero mistakes and an attacker only needs to find one. Also the resources you would expend trying to find and patch every last hole would break the economics. It is what it is.
- AgentME 8y ago
  >Also the resources you would expend trying to find and patch every last hole would break the economics. If people built with things that weren't made of holes (ie. using memory safe languages), then there wouldn't need to be much effort in the "find and patch" side of things.
  - james_s_tayler 8y ago
    Are you absolutely certain of that conclusion? I'll agree with the sentiment that memory safe languages are less prone to security holes because by nature they entirely remove a whole class of issues related to managing memory... but I can't help but think that it still stands to be the case that finding and patching the remaining holes that aren't related to memory management would still break the economics. Perhaps the one thing I could imagine that might make a difference is regulations coming into force that mandated pentests / fuzzing for companies producing software doing a certain amount in revenue. It's been my experience that that stuff gets done but it's once in a blue moon. And stuff is always turned up. I'm yet to work anywhere where it is part of a regular process. Even if it were I'm always blown away by security researchers who spend months and months attacking something and finally crack it then give a presentation about how they did it. There can't even be that many people on Earth with the level of skillset required. I dunno... the economics of it seem to play out like "let's just deal with the fallout of an incident when it happens because that's cheaper than investing in security" The asymmetric nature of finding holes vs not creating them combined with the asymmetric nature of the business value of investing in security is just a mildly awful combination.
zrm 8y ago
> Is there an end to this race? If there is, it'll be a combination of two things. One is you make things simple enough that finding the bugs is more realistic. WireGuard, not OpenSSL. The other is that you make things modular, and once you have one of the modules right, you mostly leave it alone. Many people still use djbdns and qmail for a reason, and it's not the pace of new feature support. These are trade offs. They do have costs. But it has proven to be more effective.

ip26 8y ago

Security is an arms race, in a quite literal sense of the term. Arms races don't really ever end, except for truces/treaties or total victory.

raymond_goo 8y ago
No, just use Rust...
- swsieber 8y ago
  Well, that wouldn't eliminate everything (row-hammer, speculative execution), but it would probably get rid of the most common culprits - buffer overflows and use after free.
  - phkahler 8y ago
    Things like row hammer will not get attention until they are commonly used. Rust does eliminate the most common vulnerabilities and should be seriously considered for any new project that would otherwise be written in C.
    - swsieber 8y ago
      Oh, I completely agree. It's just easy to overstate Rust's guarantees, which doesn't do anybody any good.
- rurban 8y ago
  Nonsense. Rust safeties are massively overhyped. Not enough memory safety (comparable to Java, which is similarily memory unsafe), no type safety (unsafe keyword), not enough concurrency safety (not deadlock free, need to manually set mutexes). While there do exist safe and fast languages, Rust is not one of them.
  - pcwalton 8y ago
    If we all wrote in languages as memory-safe as Java, almost all these security bugs would go away. Is Rust guaranteed to be 100% memory-safe? No, there could always be bugs in the compiler and/or unsafe code. (Aside: it annoys me how people consider the presence of an unsafe keyword inherently less trustworthy than a non-verified compiler/runtime system, when there is really little difference between them.) Is it a huge improvement? Yes.
    - sanxiyn 8y ago
      Full agreement, but I think unsafe-phobia is mostly about user-extensible nature of it. unsafe in standard library is okay, because as you said it's no more dangerous than doing it in runtime. unsafe in "your" library is not okay, because I don't trust you to modify runtime either.
      - rurban 8y ago
        unsafe memory and unsafe types are not okay if you widely claim to be memory safe. Thousands of people actually believe these lies, and companies do makes decisions on these claims. It's much more memory unsafe than Java in fact. Java recently removed the unsafe tricks, whilst rust was once safe and went more and more unsafe since.
  - phkahler 8y ago
    >> Nonsense. Rust safeties are massively overhyped. No. They are not. You obviously have not done your homework on the subject.
    - 8y ago

21 8y ago

It's about increasing the costs to the attacker. Now a Windows/browser zero-day requires months of research and can be sold for $100k+.

est31 8y ago
Yes, the goal is to increase the costs to the attacker as much as possible while having minimal added costs during development and runtime of the software. Statically proven programs are great security wise but they are expensive to produce, while adding ASLR is not perfect but comparatively easy to pull off.

monocasa 8y ago

sel4 shows that an endgame is possible wrt to memory safety, it's formally verfied to be memory safe. It's sitting at ~25 to 1, proof code to implementation code. I think you could probably get that down to 5 to 1 or so by treating a lot of the work they did as a library. The proof covers a full equivalence from abstract spec to machine code, and you could reuse a lot of that. Sort of how it's not fair to include the LOC of your compiler even though you need that for your program ultimately.

chillacy 8y ago
But does formal verification even help when you're up against side channel attacks on the hardware? Like the branch predictor or DRAM memory access timing.
- monocasa 8y ago
  With a model of the full system, quite possibly. That's one of the things that makes me so excited for RISC-V.
  - sempron64 8y ago
    I don't know of any technique to model or avoid timing attacks that wouldn't drastically slow down execution to the point of being impractical.
- deleted 8y ago
  [deleted]
xiphias2 8y ago
Reinforcement learning can be used to improve theorem proving, but it probably needs more research: https://arxiv.org/abs/1805.07563 https://arxiv.org/abs/1805.07563
rurban 8y ago
Nope, sel4 is unsafe against modern Spectre/Meltdown attacks. Only Fiasco was recently made safe against these. Secondly, Microsoft's own SecureMemZero is insecure against those attacks. It only applies a trivial compiler barrier, but no memory barrier, so you cannot use it to securely delete sensitive memory.

james_s_tayler 8y ago

Computer security is a fundamentally asymmetric game. Your entire stack needs to contain zero mistakes and an attacker only needs to find one. Also the resources you would expend trying to find and patch every last hole would break the economics. It is what it is.

AgentME 8y ago
>Also the resources you would expend trying to find and patch every last hole would break the economics. If people built with things that weren't made of holes (ie. using memory safe languages), then there wouldn't need to be much effort in the "find and patch" side of things.
- james_s_tayler 8y ago
  Are you absolutely certain of that conclusion? I'll agree with the sentiment that memory safe languages are less prone to security holes because by nature they entirely remove a whole class of issues related to managing memory... but I can't help but think that it still stands to be the case that finding and patching the remaining holes that aren't related to memory management would still break the economics. Perhaps the one thing I could imagine that might make a difference is regulations coming into force that mandated pentests / fuzzing for companies producing software doing a certain amount in revenue. It's been my experience that that stuff gets done but it's once in a blue moon. And stuff is always turned up. I'm yet to work anywhere where it is part of a regular process. Even if it were I'm always blown away by security researchers who spend months and months attacking something and finally crack it then give a presentation about how they did it. There can't even be that many people on Earth with the level of skillset required. I dunno... the economics of it seem to play out like "let's just deal with the fallout of an incident when it happens because that's cheaper than investing in security" The asymmetric nature of finding holes vs not creating them combined with the asymmetric nature of the business value of investing in security is just a mildly awful combination.

zrm 8y ago

> Is there an end to this race? If there is, it'll be a combination of two things. One is you make things simple enough that finding the bugs is more realistic. WireGuard, not OpenSSL. The other is that you make things modular, and once you have one of the modules right, you mostly leave it alone. Many people still use djbdns and qmail for a reason, and it's not the pace of new feature support. These are trade offs. They do have costs. But it has proven to be more effective.