Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory safety absolutists

itsallaboutthebit.com

Post reply on HN
Print view View original

251–260 of 272 posts

Re: Memory safety absolutists

#251

Post by dblohm7 »

bpavuk wrote: post #16
inigyou wrote: post #12

I don't think you need to be an absolutist or only use memory safe languages but it's very obvious that we need to do a whole lot better than we actually do. Rewriting in Rust or any other language is one way to do that, but not a perfect one. I'll accept C++ when most C++ software has 1 in 50 chance of an RCE and not just a 1 in 50 chance of a known RCE. I think we can get there but we are not currently there. Coreu…

ffmpeg is actually asm and for a good reason - it has to go fucking fast or else media playback will take too much resources

There are projects such as Halide[1] that actually allow you to achieve performance without needing to resort to asm.

[1] https://halide-lang.org/

Re: Memory safety absolutists

#253

Post by fmajid »

himata4113 wrote: post #229
Brian_K_White wrote: post #89

Earlier quoted context omitted.

There will always be one, so "it only takes one" is meaningless and invalid. That leaves less is better than more, and any form of less is as good as any other form of less.

This is pretty hard to argue since for example: WireGuard is a finished piece of software. It gets: no feature updates, was designed in-full before a single line of code was written and has stood the test of time. You cannot compare that to some desktop application that has a thousand features with 100's more added every year.

And its transition to post-quantum cryptography is going to be a migration challenge.

Re: Memory safety absolutists

#254

Post by noelwelsh »

debugnik wrote: post #217
noelwelsh wrote: post #6

Good article. Not much to add to it, other than I think more people should look at modal type systems like found in Scala 3 and OxCaml. If you want safe arena allocation they are a lot more ergonomic than Rust's approach.

I'm familiar with OxCaml, but in what sense does Scala have modalities?

Scala's capture checking [1] is a modal type system.

[1]: https://docs.scala-lang.org/scala3/reference/experimental/cc...

Re: Memory safety absolutists

#255

Post by uecker »

Pooge wrote: post #209
uecker wrote: post #178

Earlier quoted context omitted.

Most people I know that had security incidents did not have this because of memory safety issues. But it does not matter, even without memory safety issues out of the picture, you would need to update your software and be wary of supply chain attacks. (Actually, I can't remember a single incident where somebody I knew was directly affected by a memory safety issue)

> I can't remember a single incident where somebody I knew was directly affected by a memory safety issue That doesn't mean the issue is nonexistent. See this article by Microsoft that shows the percentages of fixed CVEs that are related to memory safety.[1] [1]: https://www.microsoft.com/en-us/msrc/blog/2019/07/we-need-a-...

The percentage of fixed CVE at Microsoft is an irrelevant number. It is heavily biased by 1) what gets assigned a CVE in the first place (a usability issue or a weak supply chain usually does not even though far more relevant for users), 2) what gets found and fixed (memory safety issues are relatively easy to find and verify), 3) and also by how Microsoft operates (e.g. certainly not using any modern C).

So I think looking at this with regard to what actually matters for users is completely misleading. Rust fans running around touting memory safety as the most critical thing that overrides all other considerations, but having several hundred of dependencies in statically compiled software and teaching users to do "curl | bash" is actually a disaster for security. I am not saying that memory safety is not a good thing, but this distortion of reality is harmful.

Re: Memory safety absolutists

#256

Post by uecker »

inigyou wrote: post #222
uecker wrote: post #178

Earlier quoted context omitted.

Most people I know that had security incidents did not have this because of memory safety issues. But it does not matter, even without memory safety issues out of the picture, you would need to update your software and be wary of supply chain attacks. (Actually, I can't remember a single incident where somebody I knew was directly affected by a memory safety issue)

Memory corruption is among the hardest things to exploit but also the most powerful. It used to be easier before things like ASLR and NX-stack.

And 99% of the problem for memory safety and also any other issue goes away for the regular user if software is obtained from trusted sources that provide security support, because the window of opportunity for the attacker gets smaller. Anything that makes this harder (and this includes free software written in Rust) is a practical real-word downside for security.

Re: Memory safety absolutists

#257

Post by Pooge »

uecker wrote: post #255
Pooge wrote: post #209

Earlier quoted context omitted.

> I can't remember a single incident where somebody I knew was directly affected by a memory safety issue That doesn't mean the issue is nonexistent. See this article by Microsoft that shows the percentages of fixed CVEs that are related to memory safety.[1] [1]: https://www.microsoft.com/en-us/msrc/blog/2019/07/we-need-a-...

The percentage of fixed CVE at Microsoft is an irrelevant number. It is heavily biased by 1) what gets assigned a CVE in the first place (a usability issue or a weak supply chain usually does not even though far more relevant for users), 2) what gets found and fixed (memory safety issues are relatively easy to find and verify), 3) and also by how Microsoft operates (e.g. certainly not using any modern C). So I think…

You can appreciate Rust and hate `curl | bash` at the same time. Plenty of binaries that are just download and execute.

Re: Memory safety absolutists

#258

Post by uecker »

Pooge wrote: post #257
uecker wrote: post #255

Earlier quoted context omitted.

The percentage of fixed CVE at Microsoft is an irrelevant number. It is heavily biased by 1) what gets assigned a CVE in the first place (a usability issue or a weak supply chain usually does not even though far more relevant for users), 2) what gets found and fixed (memory safety issues are relatively easy to find and verify), 3) and also by how Microsoft operates (e.g. certainly not using any modern C). So I think…

You can appreciate Rust and hate `curl | bash` at the same time. Plenty of binaries that are just download and execute.

Of course, I just wished enough Rust enthusiast cared also about other real-word security issues enough to get this fixed: https://rustup.rs/

Re: Memory safety absolutists

#259

Post by naasking »

uecker wrote: post #255
Pooge wrote: post #209

Earlier quoted context omitted.

> I can't remember a single incident where somebody I knew was directly affected by a memory safety issue That doesn't mean the issue is nonexistent. See this article by Microsoft that shows the percentages of fixed CVEs that are related to memory safety.[1] [1]: https://www.microsoft.com/en-us/msrc/blog/2019/07/we-need-a-...

The percentage of fixed CVE at Microsoft is an irrelevant number. It is heavily biased by 1) what gets assigned a CVE in the first place (a usability issue or a weak supply chain usually does not even though far more relevant for users), 2) what gets found and fixed (memory safety issues are relatively easy to find and verify), 3) and also by how Microsoft operates (e.g. certainly not using any modern C). So I think…

> 3) and also by how Microsoft operates (e.g. certainly not using any modern C).

Are you suggesting "modern C" is less prone to memory safety issues, and that if MS used "modern C" then that would meaningfully reduce the 70% of security vulnerabilities it claims are caused by memory safety violations?

Re: Memory safety absolutists

#260

Post by uecker »

naasking wrote: post #259
uecker wrote: post #255

Earlier quoted context omitted.

The percentage of fixed CVE at Microsoft is an irrelevant number. It is heavily biased by 1) what gets assigned a CVE in the first place (a usability issue or a weak supply chain usually does not even though far more relevant for users), 2) what gets found and fixed (memory safety issues are relatively easy to find and verify), 3) and also by how Microsoft operates (e.g. certainly not using any modern C). So I think…

> 3) and also by how Microsoft operates (e.g. certainly not using any modern C). Are you suggesting "modern C" is less prone to memory safety issues, and that if MS used "modern C" then that would meaningfully reduce the 70% of security vulnerabilities it claims are caused by memory safety violations?

I would say a modern style of C using proper abstractions and modern tooling is less prone to memory safety issues than C written in the style of C89.
Post reply on HN