6 ms·

The first step would be to stop using C (and any other memory-unsafe language). The vast majority of these problems come about by memory corruption tricking the

The first step would be to stop using C (and any other memory-unsafe language). The vast majority of these problems come about by memory corruption tricking the computer into executing attacker-delivered code (or ROP gadgets). Yes there will be other security flaws like missing access checks, etc. But none are so pervasive nor so devastating as out-of-bounds read/write. If C arrays were bounds-checked by default then the majority (literally) of exploits would be rendered void immediately. The Rust borrow checker, Swift ARC, or GCs would eliminate use-after-free. Combined that would drastically reduce all available attack surface. The second step is to assign a separate identity to every piece of code, rather than running everything as the current user. Unless it has been initiated by a user action there is no reason for malware to even have write access to your files (or system files for that matter). The idea that any ol random bit of code that manages to execute should be just as trusted as the user is crazytown. IMHM macOS SIP is a good step in that direction, enforcing read-only access to /System and most of /usr. The third step is to have pervasive copy-on-write, including in all filesystems by default. If your system does get pwned it should be a trivial matter of booting to a read-only recovery mode and rolling back to a known-good state. The fourth step is to have more interlocks enforced by the system that cannot be overridden. For example there might be a legitimate reason to truncate shadow copies but why should anyone with admin rights be allowed to do so from a normal login session? That's just stupid. (For those unaware, malware now routinely disables Windows' volume shadow copy and nukes the existing copies to stop you from rolling your files back). Stuff like that should require rebooting into single-user mode or recovery mode. There's always a lot of resistance to the idea of dropping C. Before you go replying with a counter-argument I urge you to stop and think seriously. We've been pushing secure coding standards as an industry for many years now. Everyone is well aware of the risks. We have tools like Address Sanitizer and Undefined Behavior Sanitizer. We have lots of static analysis tools. We have tools like valgrind. And yet... the exploits keep on coming. Despite the thousands upon thousands of years of effort poured into fixing it, we still routinely have new out-of-bounds and use-after-free exploits in critical C code. Even experienced developers get bitten by signed integer overflow and other forms of undefined behavior... and most C code is not being written by experienced careful developers. Embedded code is even worse. If you read the source behind your car's ECU you'd probably never drive again. It is time to admit the truth: programming languages should be memory-safe by default. Period. Whatever the cost it is worth paying.

naasking 9y ago
> The first step would be to stop using C (and any other memory-unsafe language). The vast majority of these problems come about by memory corruption tricking the computer into executing attacker-delivered code (or ROP gadgets). Seriously. People have been saying this for decades now, and warning of future disasters in using memory unsafe languages. The warning signs were all there in early worms and viruses, but still we haven't changed the languages we use or the access control systems that leave gaping wide holes in our computer systems. The chickens are coming home to roost, and everyone will feel the economic impact of this short sightedness! Ada has been around long enough, but it was a little painful when I was using it a few years back despite all the great safety benefits. Thank god for Rust. I sincerely hope it, or something like Idris really takes off.
- rf15 9y ago
  Well, it's always a tradeof, isn't it? Manual memory management gives you greater freedom and performance, with added risks. That being said, performance is what you want when it comes to low level layers that other layers have to rely on - e.g. You don't want your net stack be dragged down by a slow TCP/IP implementation.
  - sametmax 9y ago
    Now you have rust. No excuses.
    - flukus 9y ago
      When all the rust libraries are in my package manager and when rust is as simple to write as C let me know, until then it's laughable that you think it's a replacement. To replace C rustc needs to be a drop in replacement for gcc, not a whole platform on it's own as it is now with cargo.
      - sametmax 9y ago
        > when rust is as simple to write as C let me know Good C is not simple to write, that's the whole point. > To replace C rustc needs to be a drop in replacement for gcc, not a whole platform on it's own as it is now with cargo. The argument here is about dropping C. You can't replace C without paying some kind of a price.

naasking 9y ago

> The first step would be to stop using C (and any other memory-unsafe language). The vast majority of these problems come about by memory corruption tricking the computer into executing attacker-delivered code (or ROP gadgets). Seriously. People have been saying this for decades now, and warning of future disasters in using memory unsafe languages. The warning signs were all there in early worms and viruses, but still we haven't changed the languages we use or the access control systems that leave gaping wide holes in our computer systems. The chickens are coming home to roost, and everyone will feel the economic impact of this short sightedness! Ada has been around long enough, but it was a little painful when I was using it a few years back despite all the great safety benefits. Thank god for Rust. I sincerely hope it, or something like Idris really takes off.

rf15 9y ago
Well, it's always a tradeof, isn't it? Manual memory management gives you greater freedom and performance, with added risks. That being said, performance is what you want when it comes to low level layers that other layers have to rely on - e.g. You don't want your net stack be dragged down by a slow TCP/IP implementation.
- sametmax 9y ago
  Now you have rust. No excuses.
  - flukus 9y ago
    When all the rust libraries are in my package manager and when rust is as simple to write as C let me know, until then it's laughable that you think it's a replacement. To replace C rustc needs to be a drop in replacement for gcc, not a whole platform on it's own as it is now with cargo.
    - sametmax 9y ago
      > when rust is as simple to write as C let me know Good C is not simple to write, that's the whole point. > To replace C rustc needs to be a drop in replacement for gcc, not a whole platform on it's own as it is now with cargo. The argument here is about dropping C. You can't replace C without paying some kind of a price.