News for hackers. Stuff that matters.
Re:Spectre and the end of langsec by kibwen on Thursday January 11, 2018 @12:59PM (#16126024)
> All that pontification didn't actually work!

This is a bit silly. Security is a chain that is only as strong as its weakest link. For decades we believed that C was the weakest link, and now, with Spectre, we have discovered (drumroll, please!): nah, C is still the weakest link. For all the amazingly scary things that Spectre brings to the table, it's still less scary than Heartbleed and Cloudbleed were.

Don't get me wrong, hardware still sucks (and with Intel and AMD's growing body of management engine incompetence they may yet overtake C as the weakest link in the chain) but we will learn from this and get better. In the meantime, we need to be pushing forward on all fronts: hardware security, language security, kernel security, application security, network security... nobody gets to stand still.

Re:Spectre and the end of langsec by wahern on Thursday January 11, 2018 @03:54PM (#16127742)
Long before Heartbleed or Cloudbleed researchers (and presumably attackers) were using remote timing attacks to extract secret keys:

  https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf
And most big data breaches where information assets are actually stolen involve services written using "safe" languages, like Java or SQL.

And even if C is the weakest link, all that means is that you're totally screwed. No amount of Rust will save you when the Linux kernel, your relational database, and every router between you and the attacker are written using C or assembly.

At the end of the day, if you want strong security assurances you need to prove the correctness of all the semantics (of which memory bounds constraining is but one small aspect) of every piece of software in your stack, or at the very least all the most critical pieces. And the best tooling for that is for Ada and C.