7 ms·

Do we need US gov advisory in order to be convinced? Microsoft and Chromium were telling this for years https://www.chromium.org/Home/chromium-security/memory-

Do we need US gov advisory in order to be convinced? Microsoft and Chromium were telling this for years https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet... >The Chromium project finds that around 70% of our serious security bugs are memory safety problems. Our next major project is to prevent such bugs at source. https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/ https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe... >As we’ve seen, roughly 70% of the security issues that the MSRC assigns a CVE to are memory safety issues. This means that if that software had been written in Rust, 70% of these security issues would most likely have been eliminated. And we’re not the only company to have reported such findings.

mannykannot 4y ago
This advisory will be about as effective as all the other prior attempts to get the message across.
euler_angles 4y ago
There are definitely organizations within the US government developing software that need to be convinced.
hvs 4y ago
It depends on who "we" is. This sort of endorsement will likely speed adoption in larger organizations.
woodruffw 4y ago
This is the wrong framing: there are different companies and business interests that listen to different advisories. A government advisory bears different weight for government contractors, for example.
- bluGill 4y ago
  This recommendation can be brought to court. If you suffer a security breech in a memory related area share holder or affected customers can sue for incompetent with this as evidence that you should have known. It may not mean much to you, but to a non technical CEO or board of directors it has meaning.
deleted 4y ago
[deleted]
Shish2k 4y ago
> Do we need US gov advisory in order to be convinced? Even HN still has a fair number of comments along the lines of “C++ is fine, you just need to do things the modern way and avoid making any mistakes”...
- langshame 4y ago
  Yes, disclaimer, or necessary predefense here? ;) Looking at rust, wanting to play with it, liking it very much from what I have seen, to some degree... still it also seems to develop some complexity problems, and is it fully stable in regard to language now? Can we take it to a certification body already? Or will it also become the next C++ with the later on-boltings? Anyway.. > “C++ is fine, you just need to do things the modern way and avoid making any mistakes” I know I will be burned now, but: Which is kind of true if you stick to modern C++ (>11) .. and if you do that (maybe enforced by a style checker or some new cpp standard setting?) you even strip out the "avoid making any mistakes". Again, fully admitted, C++ is kind of a grown and ugly language, with many holes that you could use if you don't systemically forbid them.. but if it just would make real step to enforce / deprecate with a safe-strict-standard all the bad old C/C++ heritage and there'd be something like an enforced safe-C++, I think it would not be too far away from Rust.. .. because I lately read a Rust paper "Safe Systems Programming in Rust" and what did I needed to read there?: "There are a number of data types whose implementations fundamentally depend on shared mutable state and thus cannot be type-checked according to Rust’s strict ownership discipline. To support such data types, Rust embraces the judicious use of unsafe code encapsulated within safe APIs." (and more schizophrene explanations how we still can do everything in Rust, but are safe follow..) If that is the case, then this is really not too far away from safe&modern-C++, where you only touch the unsafe parts for hard to find last bits of performance? Especially, and hear me out .. what I'm not getting is consider the typcal embedded/automotive and similar applications, which usually run single threaded and without any dynamic memory allocation and by that already exclude all of the data-race and other problems. You are basically left with bounds-checking on arrays and similar buffers, and you can really, no you will have that if you use modern C++? I'm really confused more than ever :) .. but the rust complexity curve does not seem to be only high for the devs, but also for the orgs who require standardization&certification. Hope that will follow now, and also some way to completely abandon unsafeness completely in Rust before we put it so high up the throne? and plea Haven't we seen any Rust security issues because there is so little software out with it? If some memory unsafeness in some Rust program happens, will we always hear then Rust is safe, this was just unsafe code (like today it was all every time the hacker's fault?? :D )
xphos 4y ago
Yes we do. The NSA publishes the future security standards that defense, aviation, banking, and government institute have to take into account. Once the NSA backs the technology it's generates the government push to get NIST to push a standards update for government contracts specs, which yields better security in the long run. It' silly but that's how change is implemented in government it's slow but eventually it forces adoption of better standards.
- rudolph9 4y ago
  This.
- alexfromapex 4y ago
  I might be the only one but I found it annoying that the NSA article seemingly chose to only omit Rust in the list of examples in the Path Forward section, after having mentioned it as an example of a memory-safe language earlier.
- wellareyousure 4y ago
  I don’t think the guys in India Japan and China who write the C++ code in the games and apps I use for the pay the offshorers want to pay are going to give a fuck.
- fragmede 4y ago
  As an example, it was NIST that recommended password rotation every X days (note: they no longer do), and from there every one else decided to implement that password requirement in so many corporate workplaces. It wasn't a requirement that came up out of thin air.
  - nintendo1889 4y ago
    Lol let's hear what Satoshi nakamoto has to say about this! (Bip39 phrases)
- le-mark 4y ago
  The curious thing is the DoD funded development of a memory safe language in the 80s which they then didn’t use. Ada has memory safety built in.
pmoriarty 4y ago
"Microsoft and Chromium were telling this for years" The advantages of memory safe languages have been discussed to death in programming circles for many decades. This is absolutely nothing new, and it should surprise absolutely no one that both industry and government are behind the curve, as usual.
- muffles 4y ago
  What is the implication of this to embedded software platforms like Xilinx VITIS or TI's Code Composer Studio? Both tools are based on C/C++ so why would these platforms not have switched to C# or Rust earlier? Sorry for the simple question as Im a simple hardware guy but do you see a scenario where future platforms of these tools are based on Rust?
  - nicoburns 4y ago
    I think embedded software will likely switch to Rust (or other non-C/C++ languages) eventually. But that transition will be behind the transition for PC/server software by probably 10 years, partly because these indeustries are just slower to change, partly because support for these kind of environments in languages like Rust isn't as mature as support for more "full OS" environments, partly because these environments are often dependent on proprietary compilers provided by vendors and getting these vendors to ship Rust compilers is going to be a slow uphill battle. In some ways Rust is (or will be) particularly well suited to these environments. They're hard to debug so the compile-time constraints are particularly helpful. Features like async/await are perfect for modelling interactions with hardware peripherals, etc. But there are still a lot of rough edges. Most embedded development with Rust is still relying on unstable nightly features (particularly more advanced const evaluation). Although the recent stabilisation of GATs helps a lot.
    - qsort 4y ago
      Sic rebus stantibus, neither transition is realistic without enormous and painful investments. Basically every single piece of software that matters is a C library or is exposed through a C API, because that's what other languages hook into, including Rust. Heck, right this second I'm working on a piece of software that needs to talk to Java and Python simultaneously, so C++ with extern C it is. Using memory safe languages when you can is good advice, but it's kind of complicated to get to a point where everything is guaranteed safe.
pjmlp 4y ago
Yes, many orgs and developers will only change habits when law comes into play.
brightball 4y ago
Yes, these types of recommendations go a long way toward influencing decisions in companies.
PaulHoule 4y ago
Never hurts to add voices to the choir. It was funny, I went to see my optometrist the other day and found out he's gotten into Arduino programming but he hates C/C++, particularly the way pointers work. I told him I liked AVR8 assembly a lot better. It's not safe, but I really get to enjoy the large register file and don't have my CPU doing meaningless activities to maintain C calling conventions.
godelski 4y ago
> Microsoft and Chromium were telling this for years But have they written their browsers with memory safe languages? I thought Firefox was the only one.
- giaour 4y ago
  Isn’t Firefox still mostly C++? Cf https://firefox-source-docs.mozilla.org/contributing/contributing_to_mozilla.html#what-skills-do-i-need https://firefox-source-docs.mozilla.org/contributing/contrib...
  - pencilguin 4y ago
    Firefox is mostly old (i.e. pre-modern) C++. And even relies on a great deal of C code. Like Chromium.
  - godelski 4y ago
    I was under the impression that a substantial amount of it was being rewritten in Rust, which was part of the reason for the speedups (rewrite, not language)

mannykannot 4y ago

This advisory will be about as effective as all the other prior attempts to get the message across.

euler_angles 4y ago

There are definitely organizations within the US government developing software that need to be convinced.

hvs 4y ago

It depends on who "we" is. This sort of endorsement will likely speed adoption in larger organizations.

woodruffw 4y ago

This is the wrong framing: there are different companies and business interests that listen to different advisories. A government advisory bears different weight for government contractors, for example.

bluGill 4y ago
This recommendation can be brought to court. If you suffer a security breech in a memory related area share holder or affected customers can sue for incompetent with this as evidence that you should have known. It may not mean much to you, but to a non technical CEO or board of directors it has meaning.

deleted 4y ago

[deleted]

Shish2k 4y ago

> Do we need US gov advisory in order to be convinced? Even HN still has a fair number of comments along the lines of “C++ is fine, you just need to do things the modern way and avoid making any mistakes”...

langshame 4y ago
Yes, disclaimer, or necessary predefense here? ;) Looking at rust, wanting to play with it, liking it very much from what I have seen, to some degree... still it also seems to develop some complexity problems, and is it fully stable in regard to language now? Can we take it to a certification body already? Or will it also become the next C++ with the later on-boltings? Anyway.. > “C++ is fine, you just need to do things the modern way and avoid making any mistakes” I know I will be burned now, but: Which is kind of true if you stick to modern C++ (>11) .. and if you do that (maybe enforced by a style checker or some new cpp standard setting?) you even strip out the "avoid making any mistakes". Again, fully admitted, C++ is kind of a grown and ugly language, with many holes that you could use if you don't systemically forbid them.. but if it just would make real step to enforce / deprecate with a safe-strict-standard all the bad old C/C++ heritage and there'd be something like an enforced safe-C++, I think it would not be too far away from Rust.. .. because I lately read a Rust paper "Safe Systems Programming in Rust" and what did I needed to read there?: "There are a number of data types whose implementations fundamentally depend on shared mutable state and thus cannot be type-checked according to Rust’s strict ownership discipline. To support such data types, Rust embraces the judicious use of unsafe code encapsulated within safe APIs." (and more schizophrene explanations how we still can do everything in Rust, but are safe follow..) If that is the case, then this is really not too far away from safe&modern-C++, where you only touch the unsafe parts for hard to find last bits of performance? Especially, and hear me out .. what I'm not getting is consider the typcal embedded/automotive and similar applications, which usually run single threaded and without any dynamic memory allocation and by that already exclude all of the data-race and other problems. You are basically left with bounds-checking on arrays and similar buffers, and you can really, no you will have that if you use modern C++? I'm really confused more than ever :) .. but the rust complexity curve does not seem to be only high for the devs, but also for the orgs who require standardization&certification. Hope that will follow now, and also some way to completely abandon unsafeness completely in Rust before we put it so high up the throne? and plea Haven't we seen any Rust security issues because there is so little software out with it? If some memory unsafeness in some Rust program happens, will we always hear then Rust is safe, this was just unsafe code (like today it was all every time the hacker's fault?? :D )

xphos 4y ago

Yes we do. The NSA publishes the future security standards that defense, aviation, banking, and government institute have to take into account. Once the NSA backs the technology it's generates the government push to get NIST to push a standards update for government contracts specs, which yields better security in the long run. It' silly but that's how change is implemented in government it's slow but eventually it forces adoption of better standards.

rudolph9 4y ago
This.
alexfromapex 4y ago
I might be the only one but I found it annoying that the NSA article seemingly chose to only omit Rust in the list of examples in the Path Forward section, after having mentioned it as an example of a memory-safe language earlier.
wellareyousure 4y ago
I don’t think the guys in India Japan and China who write the C++ code in the games and apps I use for the pay the offshorers want to pay are going to give a fuck.
fragmede 4y ago
As an example, it was NIST that recommended password rotation every X days (note: they no longer do), and from there every one else decided to implement that password requirement in so many corporate workplaces. It wasn't a requirement that came up out of thin air.
- nintendo1889 4y ago
  Lol let's hear what Satoshi nakamoto has to say about this! (Bip39 phrases)
le-mark 4y ago
The curious thing is the DoD funded development of a memory safe language in the 80s which they then didn’t use. Ada has memory safety built in.

pmoriarty 4y ago

"Microsoft and Chromium were telling this for years" The advantages of memory safe languages have been discussed to death in programming circles for many decades. This is absolutely nothing new, and it should surprise absolutely no one that both industry and government are behind the curve, as usual.

muffles 4y ago
What is the implication of this to embedded software platforms like Xilinx VITIS or TI's Code Composer Studio? Both tools are based on C/C++ so why would these platforms not have switched to C# or Rust earlier? Sorry for the simple question as Im a simple hardware guy but do you see a scenario where future platforms of these tools are based on Rust?
- nicoburns 4y ago
  I think embedded software will likely switch to Rust (or other non-C/C++ languages) eventually. But that transition will be behind the transition for PC/server software by probably 10 years, partly because these indeustries are just slower to change, partly because support for these kind of environments in languages like Rust isn't as mature as support for more "full OS" environments, partly because these environments are often dependent on proprietary compilers provided by vendors and getting these vendors to ship Rust compilers is going to be a slow uphill battle. In some ways Rust is (or will be) particularly well suited to these environments. They're hard to debug so the compile-time constraints are particularly helpful. Features like async/await are perfect for modelling interactions with hardware peripherals, etc. But there are still a lot of rough edges. Most embedded development with Rust is still relying on unstable nightly features (particularly more advanced const evaluation). Although the recent stabilisation of GATs helps a lot.
  - qsort 4y ago
    Sic rebus stantibus, neither transition is realistic without enormous and painful investments. Basically every single piece of software that matters is a C library or is exposed through a C API, because that's what other languages hook into, including Rust. Heck, right this second I'm working on a piece of software that needs to talk to Java and Python simultaneously, so C++ with extern C it is. Using memory safe languages when you can is good advice, but it's kind of complicated to get to a point where everything is guaranteed safe.

pjmlp 4y ago

Yes, many orgs and developers will only change habits when law comes into play.

brightball 4y ago

Yes, these types of recommendations go a long way toward influencing decisions in companies.

PaulHoule 4y ago

Never hurts to add voices to the choir. It was funny, I went to see my optometrist the other day and found out he's gotten into Arduino programming but he hates C/C++, particularly the way pointers work. I told him I liked AVR8 assembly a lot better. It's not safe, but I really get to enjoy the large register file and don't have my CPU doing meaningless activities to maintain C calling conventions.

godelski 4y ago

> Microsoft and Chromium were telling this for years But have they written their browsers with memory safe languages? I thought Firefox was the only one.

giaour 4y ago
Isn’t Firefox still mostly C++? Cf https://firefox-source-docs.mozilla.org/contributing/contributing_to_mozilla.html#what-skills-do-i-need https://firefox-source-docs.mozilla.org/contributing/contrib...
- pencilguin 4y ago
  Firefox is mostly old (i.e. pre-modern) C++. And even relies on a great deal of C code. Like Chromium.
- godelski 4y ago
  I was under the impression that a substantial amount of it was being rewritten in Rust, which was part of the reason for the speedups (rewrite, not language)