back
222 comments
Recent and related:

NSA guidance on how to protect against software memory safety issues [pdf] - https://news.ycombinator.com/item?id=33553668 - Nov 2022 (90 comments)

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-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...

>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.

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.
> 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”...

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.
"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.

This advisory will be about as effective as all the other prior attempts to get the message across.
There are definitely organizations within the US government developing software that need to be convinced.
> 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.

It depends on who "we" is. This sort of endorsement will likely speed adoption in larger organizations.
Yes, many orgs and developers will only change habits when law comes into play.
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.

Yes, these types of recommendations go a long way toward influencing decisions in companies.
I predicted maybe 5 years ago that C was going to reach end-of-life due to memory unsafety issues.

D has been making steady progress towards being 100% memory safe when not using the GC (it's already memory safe if you stick to the GC).

The biggest memory safe feature is array overflow checking, and D has had that since its inception.

yes I agree D should have been on that list, bummer
Anything that hardware can do to improve the situation? How about pointer authentication or memory tagging? Do these measures also fall into the band-aid category?
There is CHERI, which seems pretty cool:

“CHERI extends conventional hardware Instruction-Set Architectures (ISAs) with new architectural features to enable fine-grained memory protection and highly scalable software compartmentalization. The CHERI memory-protection features allow historically memory-unsafe programming languages such as C and C++ to be adapted to provide strong, compatible, and efficient protection against many currently widely exploited vulnerabilities.”

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

I forgot the details but iirc it’s not too much work to recompile programs for the architecture.

It was discussed on HN before, e.g. https://news.ycombinator.com/item?id=30007474

Most probably yes. If it was an actual viable fix you can be almost guaranteed that it would have been implemented long ago. Engineers would love to have their cake and eat it too.
It can, but they are like trying to solve memory corruption issues with the ultimate weapon, because all other mitigation efforts from the last 50 years have failed.
If that were the case, wouldn't the recommendation have been to use modern hardware rather than memory safe languages?
I think we should all switch to programming in SPARK. It won't solve all bugs, but it'll solve the avoidable ones.
Good luck with that.
Cool, maybe they could get the rest of the government agencies to stop requiring bullshit FIPS certified crypto implementations that are all written in memory-unsafe programming languages.
>around 70% of our serious security bugs are memory safety problems

Is there any information available to assess what portion of that 70% was, or could have been, identified through static code analysis, sanitizers and other memory-safety techniques that can be applied in a bulk / automated manner?

C++ is the new COBOL.
What about programming in immoral languages ?
So anything except Holy C?
Any chance this would become a FedRAMP requirement based on this guidance?
So… no Linux in FedRAMP?
Shoot, no Perl!
Yeah, it's a weird list. If Ruby is there, Perl should be. I've seen lists with Python on it as well.
> C#, Rust, Go, Java, Ruby or Swift

Conspiracy: The NSA has compromised all those languages' runtimes to spy on whatever is being run and passed through them. After all, that Utah datacenter[0] isn't going to fill itself.

[0] https://en.wikipedia.org/wiki/Utah_Data_Center

Edit: comprised -> compromised

If you're concerned that Rust has been compromised you should consider where that leaves Python. The NSA is both offensive and defensive. Part of their mandate is to protect American infrastructure for foreign attacks. A switch like this is one of the easier ways to protect against foreign threats and it is something that is routinely advocated for by most large tech companies and cloud providers.

As for that Datacenter in Utah - it is a large Government project. The idea that the US Government is efficient with its resources or that its operatives are trying to maximize the use of their resources is not well supported by historical precedent. If the project is written off as yet another make-work job project for a reliably red state then I am sure we can all sleep well knowing that our tax dollars have been well spent.

I thought at first that specific list of languages might have just been theregister.com's editorialized list. But it's in the actual document[1].

"These inherent language features protect the programmer from introducing memory management mistakes unintentionally. Examples of memory safe language include C#, Go, Java®, Ruby™, Rust®, and Swift®."

I don't think there's any conspiracy, but it is interesting they don't mention JS or Python.

[1]https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...

Is there any standard to meet the requirements of being "memory safe" or is it enough for the language to just feature GC and automatic memory management? I thought only Rust and Ada (which is surprisingly not mentioned in the list) were stringent about memory safety as a language feature ... (perhaps Go too?).
It’s part of the NSA’s mission to secure American businesses, communications, and infrastructure against foreign attack.
It's definitely more work than it should be to bootstrap Rust, but we should be able to rule out most "trusting trust" scenarios with a fully bootstrapped compiler, right?
This is an extremely paranoid view that relies on nobody else outside the US spotting it or any of the network traffic that it would have to generate to be useful.

I think the only instance of this kind of thing for which there is evidence is the elliptic curve debacle?

That's hilarious. The reality is that just by not recommending C (or C++), they really are making things safer.
Reads like a "the people making this document have experience with those languages" list.

But this is the NSA, some amount of suspicion is always healthy.

> The NSA has compromised all those languages' runtimes

honi soit qui mal y pense, but I spontaneously had the same thought when I read that.

Holy C is the only CIA safe language.
What’s kinda annoying about comment sections on these articles is it shows how many people have opinions on this topic that they know only a bit about.

Rust is safer than C++ because it does “opt-out” of memory safety, rather than modern C++ which is more “opt-in”

But Rust (other than for threads) is definitely not more memory safe than Go/Java etc. Safe rust code can still memory leak. Unsafe rust code can have memory errors (and does frequently) that those others would stop.

Dumb question, it always seems like people say Rust is the gold standard for memory safety. Why is Rust better at memory safety than C#, Go, Java, Ruby or Swift?
# Infosec Memory Safety

## Hardware

- Memory protection: https://en.wikipedia.org/wiki/Memory_protection

- NX Bit: https://en.wikipedia.org/wiki/NX_bit

- Can non-compiled languages (e.g. those with mutable code objects like Python) utilize the NX bit that the processor supports?

- Can TLA+ find side-channels (which bypass all software memory protection features other than encryption-in-RAM)?

- How do DMA and IOMMU hardware features impact software memory safety controls? https://news.ycombinator.com/item?id=23993763

- DMA: Direct Memory Access

- DMA attack > Mitigations: https://en.wikipedia.org/wiki/DMA_attack

- IOMMU: I-O Memory Management Unit; GPUs, Virtualization, https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_ma...

- Kernel IOMMU parameters: Ctrl-F "iommu": https://www.kernel.org/doc/html/latest/admin-guide/kernel-pa...

- RDMA: Remote direct memory access https://en.wikipedia.org/wiki/Remote_direct_memory_access

## Software

- Type safety > Memory management and type safety: https://en.wikipedia.org/wiki/Type_safety#Memory_management_...

- Memory safety > Types of memory errors: https://en.wikipedia.org/wiki/Memory_safety#Types_of_memory_...

- Template:Memory management https://en.wikipedia.org/wiki/Template:Memory_management

- Category:Memory_management https://en.wikipedia.org/wiki/Category:Memory_management

- Reference (computerscience) https://en.wikipedia.org/wiki/Reference_(computer_science)

- Pointer (computer programming) https://en.wikipedia.org/wiki/Pointer_(computer_programming)

- Smart pointer (computer programming) in C++: unique_ptr, shared_ptr and weak_ptr; Python: weakref, Arrow Plasma IPC, https://en.wikipedia.org/wiki/Smart_pointer

- Manual Memory Management > Resource Acquisition Is Initialization https://en.wikipedia.org/wiki/Manual_memory_management#Resou...

- Resource acquisition is initialization (C++ (1980s), D, Ada, Vala, Rust), #Reference_counting (Perl, Python (CPython,), PHP,) https://en.wikipedia.org/wiki/Resource_acquisition_is_initia...

- Ada > Language constructs > Concurrency https://en.wikipedia.org/wiki/Ada_(programming_language)#Con...

- C_dynamic_memory_allocation#Common_errors: https://en.wikipedia.org/wiki/C_dynamic_memory_allocation#Co...

- Python 3 > C-API > Memory Managment: https://docs.python.org/3/c-api/memory.html

- The Rust Programming Language > 4. Understanding Ownership > 4.1. What is Ownership? https://doc.rust-lang.org/book/ch04-00-understanding-ownersh...

- The Rust Programming Language > 6. Fearless Concurrency > Using Message Passing to Transfer Data Between Threads https://doc.rust-lang.org/book/ch16-02-message-passing.html#...

> One increasingly popular approach to ensuring safe concurrency is message passing, where threads or actors communicate by sending each other messages containing data. Here’s the idea in a slogan from the Go language documentation: “Do not communicate by sharing memory; instead, share memory by communicating.”

> To accomplish message-sending concurrency, Rust's standard library provides an implementation of channels. A channel is a general programming concept by which data is sent from one thread to another.

> You can imagine a channel in programming as being like a directional channel of water, such as a stream or a river. If you put something like a rubber duck into a river, it will travel downstream to the end of the waterway.

- The Rust Programming Language > 15. Smart Pointers > Smart Pointers: https://doc.rust-lang.org/book/ch15-00-smart-pointers.html

- The Rust Programming Language > 19. Advanced Features > Unsafe Rust: https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html

- Secure Rust Guidelines > Memory management, > Checklist > Memory management: https://anssi-fr.github.io/rust-guide/05_memory.html

- Go 101 > "Type-Unsafe Pointers" https://go101.org/article/unsafe.html https://pkg.go.dev/unsafe

- https://github.com/rust-secure-code/projects#side-channel-vu...

- Segmentation fault > Causes, Examples, : https://en.wikipedia.org/wiki/Segmentation_fault

- "CWE CATEGORY: Pointer Issues" https://cwe.mitre.org/data/definitions/465.html

- "CWE CATEGORY: Memory Buffer Errors" https://cwe.mitre.org/data/definitions/1218.html

- "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer" https://cwe.mitre.org/data/definitions/119.html

- "CWE CATEGORY: SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)" https://cwe.mitre.org/data/definitions/1162.html

- "CWE CATEGORY: CERT C++ Secure Coding Section 08 - Memory Management (MEM)" https://cwe.mitre.org/data/definitions/876.html

- SEI CERT C Coding Standard > "Rule 08. Memory Management (MEM)" https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pa...

- SEI CERT C Coding Standard > "Rec. 08. Memory Management (MEM)" https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pa...

- Invariance (computer science) https://en.wikipedia.org/wiki/Invariant_(mathematics)#Invari...

- TLA+ Model checker https://en.wikipedia.org/wiki/TLA%2B#Model_checker > The TLC model checker builds a finite state model of TLA+ specifications for checking invariance properties.

- Data remnance; after the process fails or is ended, RAM is not zeroed: https://en.wikipedia.org/wiki/Data_remanence

- Memory debugger; valgrind, https://en.wikipedia.org/wiki/Memory_debugger

- awesome-safety-critical https://awesome-safety-critical.readthedocs.io/en/latest/#so... ; Software Safety Standards, Handbooks; Formal Verification; backup/ https://github.com/stanislaw/awesome-safety-critical/tree/ma...

- > Additional lists of static analysis, dynamic analysis, SAST, DAST, and other source code analysis tools: https://news.ycombinator.com/item?id=24511280

Every time I hear people bashing C++ for not being memory safe, I somehow get reminded of the teens that were eating Tide Pods a few years ago. So let's put a big warning and lock away the Tide Pods because people might eat them. Well FFS, I just want to do my laundry and I know what I'm doing.

Sure, I introduced my share of memory bugs in C++ code early in my career when the standard was older and the (static analysis) tools were missing, but working with the modern C++ ecosystem now is a pleasure, and I don't want to have a hand tied behind my back and locked into the playpen with the Tide Pod gourmands for "safety". </rant>

I guess I'm starting a language war, but...

I see how Rust is on that list.

I don't get how the other languages are on that list. I mean, yes, I guess they're marginally better than C and C++ at memory-safety, but... just barely...?

Like... this report?

https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-s...