34 ms·

NSA urges orgs to use memory-safe programming languages

220 points by AlexeyBrin 4y ago

justinsaccount 4y ago
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.
GnarfGnarf 4y ago
C++ is the new COBOL.
theandrewbailey 4y ago
> 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 https://en.wikipedia.org/wiki/Utah_Data_Center Edit: comprised -> compromised
- t-3 4y ago
  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?
  - kibwen 4y ago
    rustc has been successfully subjected to diverse-double-compilation (https://dwheeler.com/trusting-trust/ https://dwheeler.com/trusting-trust/) via mrustc at various points in its history, which plausibly rules out trusting-trust attacks for those versions.
  - drexlspivey 4y ago
    GNU successfully bootstrapped the Rust compiler https://guix.gnu.org/tr/blog/2018/bootstrapping-rust/ https://guix.gnu.org/tr/blog/2018/bootstrapping-rust/
- freilanzer 4y ago
  You mean 'compromised'?
  - Verdex 4y ago
    So, technically, they probably meant: "unauthorized modification of a security-related system, device or process in order to gain unauthorized access". This being the jargon definition for 'compromised'. You probably should have instead posted something like: "You probably should have instead posted something like: compromised instead of comprised". Now, I know what you're thinking: "Yeah, the definition of 'compromised' is what I meant when I said 'You mean "compromised"?'. Why do you have to be so pedantic?" Perhaps you are correct. Maybe it's better to not correct people on the internet when what they were saying is technically incorrect, but otherwise understandable.
    - theandrewbailey 4y ago
      I'm genuinely grateful that the previous comment asked if I meant 'compromised'. Short, simple, and to the point. I do not read any bad intent into that comment, and point-outs like those seem to be protocol for HN.
      - Verdex 4y ago
        Perhaps you are correct. Maybe it's better to not correct people on the internet when what they were saying is technically incorrect, but otherwise understandable.
        jaywalk 4y ago
        I think most people appreciate typos being pointed out to them politely. Maybe it's better to not tell people they shouldn't help others.
  - theandrewbailey 4y ago
    D'oh! Yes, I meant 'compromised'. Edited.
- tyingq 4y ago
  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_SOFTWARE_MEMORY_SAFETY.PDF https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...
  - MonkeyMalarky 4y ago
    I wouldn't put Python on that list because of how many packages are wrapped up C/C++ code. I know the same is done with Java and JNI but the pervasiveness of it is not at the same level.
    - tyingq 4y ago
      True, though Ruby made the list, and there's a fair amount of gems linked to native libraries and/or using their own C code.
      - MonkeyMalarky 4y ago
        Hah, I had no idea, I don't know anything about Ruby except it also suffers from a Gil? Maybe they're using the other golden rule: All languages starting with a P are old, crusty and should be avoided.
        krallja 4y ago
        That's why Raku was invented!
        tmtvl 4y ago
        Hey now, PureScript is not that old.
        pmontra 4y ago
- candiddevmike 4y ago
  How?
- chongli 4y ago
  It’s part of the NSA’s mission to secure American businesses, communications, and infrastructure against foreign attack.
  - peeters 4y ago
    It is, but they also have a competing mission to compromise the security of non-American businesses, communications, and infrastructure. Since for the most part, the same software is used by both, these missions often contradict each other. e.g. documents from Snowden revealed that the NSA had broken encryption recommended by NIST. It's difficult to know if NSA recommends something because it makes their defensive mandate easier, or their offensive mandate easier. For this reason, experts like Schneier [1] have long advocated that the NSA be broken up so that these two missions do not fall under the same agency. [1] https://www.schneier.com/blog/archives/2014/02/breaking_up_the.html https://www.schneier.com/blog/archives/2014/02/breaking_up_t...
  - kingaillas 4y ago
    No it is not. Responsibility (issue advisories) for unclassified, commercial, non-defense internet is a confusing mess split between Commerce (NIST, https://csrc.nist.gov/about https://csrc.nist.gov/about), DHS (CISA, https://www.cisa.gov/cybersecurity https://www.cisa.gov/cybersecurity), Energy (CESER, https://www.energy.gov/ceser/cybersecurity https://www.energy.gov/ceser/cybersecurity if it is related to energy infrastructure), etc. Throw in other agencies like DISA (https://disa.mil/About/Our-Work https://disa.mil/About/Our-Work) as appropriate. NSA's defensive mission is about securing National Security Systems. These have a fairly specific definition, and are not running in the average business.
- webmobdev 4y ago
  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?).
  - theandrewbailey 4y ago
    I'm pretty sure that in this context "memory safe" means more than that, like difficult to impossible to have a buffer overflow.
- blululu 4y ago
  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.
  - darksaints 4y ago
    That's how they're supposed to operate, not how they actually operate. They've been hoarding zero-days for years, and they have even worked surreptitiously to undermine encryption by endorsing algorithms that they had already compromised. They couldn't give a single fuck about protecting US infrastructure if it comes at the cost of their offensive weapons portfolio.
    - throwaway0x7E6 4y ago
      case in point https://en.wikipedia.org/wiki/EternalBlue https://en.wikipedia.org/wiki/EternalBlue and that's just a glimpse into how bad things really are
      - sitkack 4y ago
        There should have been a commission formed about the p0wn goal that was EternalBlue. Microsoft charging for security patches should get the execs thrown in jail. The NSA should be disclosing big RCEs like this to the vendor and figuring out how to ensure that everyone is patched. https://en.wikipedia.org/wiki/EternalBlue#Responsibility https://en.wikipedia.org/wiki/EternalBlue#Responsibility
        4y ago
- deleted 4y ago
  [deleted]
- marcosdumay 4y ago
  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.
- gw98 4y ago
  I wish that was the case. The biggest software risk to companies I have worked at are not the NSA or memory safety. It's their own product management and development staff competence. You can leave a whale sized implementation hole in the finest of Rust applications!
- some_random 4y ago
  That certainly is a conspiracy theory alright.
- cryptonector 4y ago
  That's hilarious. The reality is that just by not recommending C (or C++), they really are making things safer.
- Rochus 4y ago
  > 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.
- pjc50 4y ago
  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?
- deleted 4y ago
  [deleted]
- RadixDLT 4y ago
  better stick with D then ;)
tester756 4y ago
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.
ok123456 4y ago
Holy C is the only CIA safe language.
- slackware_linux 4y ago
  How so?
  - bombcar 4y ago
    https://en.wikipedia.org/wiki/TempleOS https://en.wikipedia.org/wiki/TempleOS for those not in the know. Dig deeper if you dare.
  - arein3 4y ago
    Information directly from the horse mouth If there is someone that knows how to protect yourself from the glowies, it's the creator of Holy C
  - arecurrence 4y ago
    HolyC is TempleOS's primary language. Previous to its creation the author had a mental breakdown... this should explain everything quite clearly https://en.wikipedia.org/wiki/TempleOS https://en.wikipedia.org/wiki/TempleOS
  - qzx_pierri 4y ago
    TempleOS was an OS created by a genius programmer named Terry. Also, I very rarely use the word genius, but he was a genius by definition. He was extremely mentally ill, but his brilliance lives on through TempleOS (and HolyC). Check out this Down the Rabbit Hole video about him. https://www.youtube.com/watch?v=UCgoxQCf5Jg https://www.youtube.com/watch?v=UCgoxQCf5Jg
  - rightbyte 4y ago
    God revealed him self and said so. Maybe a burning bush was involved I don't remember the details.
- arein3 4y ago
  Agree
ngneer 4y ago
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?
- pjmlp 4y ago
  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.
- vitiral 4y ago
  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.
- anthomtb 4y ago
  If that were the case, wouldn't the recommendation have been to use modern hardware rather than memory safe languages?
- ylk 4y ago
  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/ 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 https://news.ycombinator.com/item?id=30007474
beeforpork 4y ago
Shoot, no Perl!
- sigzero 4y ago
  Yeah, it's a weird list. If Ruby is there, Perl should be. I've seen lists with Python on it as well.
  - bogwog 4y ago
    That list of languages gave you the choice between dependence on Microsoft, Google, Apple, and Oracle. So maybe they just added Ruby in there to have a neutral option?
    - sigzero 4y ago
      Maybe, you never know.
  - tgv 4y ago
    Perl may have managed memory, but it is a great language for introducing bugs.
    - beeforpork 4y ago
      But its definitely memory safe. :-)
  - lvass 4y ago
    Doesn't ruby have mark-and-sweep GC while Perl only has ARC with no circular reference cleaning?
josevalerio 4y ago
What about programming in immoral languages ?
- vitiral 4y ago
  So anything except Holy C?
VikingCoder 4y ago
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-systems-programming-language/ https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-s...
- woodruffw 4y ago
  I’m a big fan of Rust, and I think it’s reasonable for those languages to be listed: with the exception of a few niches, most of the code written in those languages will be spatially and temporally memory safe. They’re also popular languages with large ecosystems, so listing them “grounds” the guidance.
- brightball 4y ago
  I've actually heard claims of memory safety in Ruby for the last few years and I was always skeptical...but this gives those claims a lot more merit for sure. And worst case, there's always jRuby.
- feukreust 4y ago
  What do you mean just barely? They're exactly as safe as Rust. Perhaps they're not making it a selling point because it's been obvious for a few decades that automatic memory management tends to be memory safe. In fact some languages are even safer (e.g. Scheme and various Lisp implementations don't have integer overflows due to having bignums by default).
  - VikingCoder 4y ago
    I guess I'm using "memory safety" very broadly and not literally, which I admit is not good. But, the borrow-checker seems to be significantly safer than anything else I've read about. Having no null pointer sounds very smart...
    - andai 4y ago
tmtvl 4y ago
I think we should all switch to programming in SPARK. It won't solve all bugs, but it'll solve the avoidable ones.
- Rochus 4y ago
  Good luck with that.
Maximus9000 4y ago
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?
- msgilligan 4y ago
  My understanding is that Rust provides memory safety with less overhead than languages that provide memory-safety via garbage collection. This comes at the price of some extra cognitive load for developers, but is appropriate for many applications where the added performance is needed. (Not necessarily "better" overall, but a better choice for certain applications.)
- ok123456 4y ago
  It's not. Garbage collection is fine. Rust just imposes constraints on references using the type system, so the compiler knows to emit the free in the right spot. For regular application code there's no real benefit. It's not really a systems language because of all the hidden memory allocations and lack of a stable ABI. It's garbage for embedded because of all the gratuitous copies you have to make to appease the borrow checker. It blows up your memory budget.
  - zRedShift 4y ago
    > For regular application code there's no real benefit Can't disagree, naive garbage collected code would outperform naive Rust code that allocates Strings and Vecs up the wazoo. And performance isn't a real issue with simple CRUD/ORM-type services. Wrapping business logic in newtypes and enforcing specific invariants for them and serde style "parse don't validate", can do wonders for business logic, but then again you can probably just use a garbage collected functional language with dependent typing and a bunch of other tricks in its hat, and get more mileage out of it, if that's the code you write. > It's not really a systems language because of all the hidden memory allocations C and C++(especially) can hide memory allocation just fine themselves. Allocations are pretty explicit in Rust, but layers of libraries can hide those (if you don't use no_std and the like), just like in C or C++. > lack of a stable ABI there is the C ABI, a stable Rust ABI at any stage would just be an optimization killer and a massive PITA, ask C++. Stable ABI, international standard, and multiple implementations of the compiler, are not a requirement for a systems language. For a language that relies on compile-time monomorphization, a stable ABI beyond what C already provides gives precious little. Swift ABI forgoes monomorphization, but it's not really a trade-off a systems language should embrace. The template header issue in C++, I won't even touch. There are also crates in the ecosystem that can generate 2-way FFI glue code to provide a stable ABI for Rust based on extern "C". > It's garbage for embedded because of all the gratuitous copies you have to make to appease the borrow checker. It blows up your memory budget. We use embedded Rust on a memory constrained MCU and besides slightly increasing the maximum stack size (because less is allocated on the heap), memory budget is not an issue we have. And in LLVM 16, Rust's stack usage will decrease even more, due to recent optimizations. You don't need to use "gratuitous copies", you can statically allocate just fine, and if your value is ephemeral and is read/mutated by multiple threads, heap allocating with reference counting is just fine.
westurner 4y ago
# Infosec Memory Safety ## Hardware - Memory protection: https://en.wikipedia.org/wiki/Memory_protection https://en.wikipedia.org/wiki/Memory_protection - NX Bit: https://en.wikipedia.org/wiki/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 https://news.ycombinator.com/item?id=23993763 - DMA: Direct Memory Access - DMA attack > Mitigations: https://en.wikipedia.org/wiki/DMA_attack 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_management_unit 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-parameters.html?highlight=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 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_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_errors https://en.wikipedia.org/wiki/Memory_safety#Types_of_memory_... - Template:Memory management https://en.wikipedia.org/wiki/Template:Memory_management https://en.wikipedia.org/wiki/Template:Memory_management - Category:Memory_management https://en.wikipedia.org/wiki/Category:Memory_management https://en.wikipedia.org/wiki/Category:Memory_management - Reference (computerscience) https://en.wikipedia.org/wiki/Reference_(computer_science) https://en.wikipedia.org/wiki/Reference_(computer_science) - Pointer (computer programming) https://en.wikipedia.org/wiki/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 https://en.wikipedia.org/wiki/Smart_pointer - Manual Memory Management > Resource Acquisition Is Initialization https://en.wikipedia.org/wiki/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_initialization https://en.wikipedia.org/wiki/Resource_acquisition_is_initia... - Ada > Language constructs > Concurrency https://en.wikipedia.org/wiki/Ada_(programming_language)#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#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 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-ownership.html 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#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 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 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 https://anssi-fr.github.io/rust-guide/05_memory.html - Go 101 > "Type-Unsafe Pointers" https://go101.org/article/unsafe.html https://go101.org/article/unsafe.html https://pkg.go.dev/unsafe https://pkg.go.dev/unsafe - https://github.com/rust-secure-code/projects#side-channel-vulnerability-checking https://github.com/rust-secure-code/projects#side-channel-vu... - Segmentation fault > Causes, Examples, : https://en.wikipedia.org/wiki/Segmentation_fault https://en.wikipedia.org/wiki/Segmentation_fault - "CWE CATEGORY: Pointer Issues" https://cwe.mitre.org/data/definitions/465.html https://cwe.mitre.org/data/definitions/465.html - "CWE CATEGORY: Memory Buffer Errors" https://cwe.mitre.org/data/definitions/1218.html 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 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 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 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?pageId=87152142 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?pageId=87151930 https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pa... - Invariance (computer science) https://en.wikipedia.org/wiki/Invariant_(mathematics)#Invariants_in_computer_science https://en.wikipedia.org/wiki/Invariant_(mathematics)#Invari... - TLA+ Model checker https://en.wikipedia.org/wiki/TLA%2B#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 https://en.wikipedia.org/wiki/Data_remanence - Memory debugger; valgrind, https://en.wikipedia.org/wiki/Memory_debugger https://en.wikipedia.org/wiki/Memory_debugger - awesome-safety-critical https://awesome-safety-critical.readthedocs.io/en/latest/#software-safety-standards https://awesome-safety-critical.readthedocs.io/en/latest/#so... ; Software Safety Standards, Handbooks; Formal Verification; backup/ https://github.com/stanislaw/awesome-safety-critical/tree/master/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 https://news.ycombinator.com/item?id=24511280
3a2d29 4y ago
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.
- LecroJS 4y ago
  I have only dabbled in Rust and have no experience with C++/Java/Go. Can you help me understand how those languages would be more memory safe than Rust? My understanding was that safe code was a solution to memory leaks. What’s the benefit to safe rust code if it isn’t getting rid of memory leaks?
  - 3a2d29 4y ago
    Memory leaks are not memory safety. Memory leaks in all languages are safe, they just slow performance and cause crashes. Rust still memory leaks.
    - LecroJS 4y ago
      Thanks. So what does it mean for a program to be memory safe if it can still memory leak? An example or pointing to a resource for further reading would be much appreciated.
      - Vecr 4y ago
        It prevents data races, use-after-free, double-free, buffer overflow, invalid type punning, etc. You can still do all those things in unsafe code though, and you could in safe code if the unsafe code you depend on (including the kernel) behave/are programmed incorrectly. You can also have hardware issues and stochastic bit flips that Rust and SPARK can't deal with.
      - Jtsummers 4y ago
WalterBright 4y ago
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.
- RadixDLT 4y ago
  yes I agree D should have been on that list, bummer
Jupe 4y ago
Any chance this would become a FedRAMP requirement based on this guidance?
- oxley 4y ago
  So… no Linux in FedRAMP?
gigel82 4y ago
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>
- dtech 4y ago
  If large groups of people and especially large groups of experts keep making the same mistakes with a tool, it's not the users that's the problem, it's the tool.
- deleted 4y ago
  [deleted]
- Hemospectrum 4y ago
  The problem isn't novices stubbing their toes in their own homes. The problem is professional programmers beneath your skill level who are making those same old mistakes in government offices and major corporations.
dang 4y ago
Recent and related: NSA guidance on how to protect against software memory safety issues [pdf] - https://news.ycombinator.com/item?id=33553668 https://news.ycombinator.com/item?id=33553668 - Nov 2022 (90 comments)
deleted 4y ago
[deleted]
mattewong 4y ago
>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?

220 points by AlexeyBrin 4y ago

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.

GnarfGnarf 4y ago

C++ is the new COBOL.

theandrewbailey 4y ago

> 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 https://en.wikipedia.org/wiki/Utah_Data_Center Edit: comprised -> compromised

t-3 4y ago
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?
- kibwen 4y ago
  rustc has been successfully subjected to diverse-double-compilation (https://dwheeler.com/trusting-trust/ https://dwheeler.com/trusting-trust/) via mrustc at various points in its history, which plausibly rules out trusting-trust attacks for those versions.
- drexlspivey 4y ago
  GNU successfully bootstrapped the Rust compiler https://guix.gnu.org/tr/blog/2018/bootstrapping-rust/ https://guix.gnu.org/tr/blog/2018/bootstrapping-rust/
freilanzer 4y ago
You mean 'compromised'?
- Verdex 4y ago
  So, technically, they probably meant: "unauthorized modification of a security-related system, device or process in order to gain unauthorized access". This being the jargon definition for 'compromised'. You probably should have instead posted something like: "You probably should have instead posted something like: compromised instead of comprised". Now, I know what you're thinking: "Yeah, the definition of 'compromised' is what I meant when I said 'You mean "compromised"?'. Why do you have to be so pedantic?" Perhaps you are correct. Maybe it's better to not correct people on the internet when what they were saying is technically incorrect, but otherwise understandable.
  - theandrewbailey 4y ago
    I'm genuinely grateful that the previous comment asked if I meant 'compromised'. Short, simple, and to the point. I do not read any bad intent into that comment, and point-outs like those seem to be protocol for HN.
    - Verdex 4y ago
      Perhaps you are correct. Maybe it's better to not correct people on the internet when what they were saying is technically incorrect, but otherwise understandable.
      - jaywalk 4y ago
        I think most people appreciate typos being pointed out to them politely. Maybe it's better to not tell people they shouldn't help others.
- theandrewbailey 4y ago
  D'oh! Yes, I meant 'compromised'. Edited.
tyingq 4y ago
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_SOFTWARE_MEMORY_SAFETY.PDF https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...
- MonkeyMalarky 4y ago
  I wouldn't put Python on that list because of how many packages are wrapped up C/C++ code. I know the same is done with Java and JNI but the pervasiveness of it is not at the same level.
  - tyingq 4y ago
    True, though Ruby made the list, and there's a fair amount of gems linked to native libraries and/or using their own C code.
    - MonkeyMalarky 4y ago
      Hah, I had no idea, I don't know anything about Ruby except it also suffers from a Gil? Maybe they're using the other golden rule: All languages starting with a P are old, crusty and should be avoided.
      - krallja 4y ago
        That's why Raku was invented!
      - tmtvl 4y ago
        Hey now, PureScript is not that old.
      - pmontra 4y ago
candiddevmike 4y ago
How?
chongli 4y ago
It’s part of the NSA’s mission to secure American businesses, communications, and infrastructure against foreign attack.
- peeters 4y ago
  It is, but they also have a competing mission to compromise the security of non-American businesses, communications, and infrastructure. Since for the most part, the same software is used by both, these missions often contradict each other. e.g. documents from Snowden revealed that the NSA had broken encryption recommended by NIST. It's difficult to know if NSA recommends something because it makes their defensive mandate easier, or their offensive mandate easier. For this reason, experts like Schneier [1] have long advocated that the NSA be broken up so that these two missions do not fall under the same agency. [1] https://www.schneier.com/blog/archives/2014/02/breaking_up_the.html https://www.schneier.com/blog/archives/2014/02/breaking_up_t...
- kingaillas 4y ago
  No it is not. Responsibility (issue advisories) for unclassified, commercial, non-defense internet is a confusing mess split between Commerce (NIST, https://csrc.nist.gov/about https://csrc.nist.gov/about), DHS (CISA, https://www.cisa.gov/cybersecurity https://www.cisa.gov/cybersecurity), Energy (CESER, https://www.energy.gov/ceser/cybersecurity https://www.energy.gov/ceser/cybersecurity if it is related to energy infrastructure), etc. Throw in other agencies like DISA (https://disa.mil/About/Our-Work https://disa.mil/About/Our-Work) as appropriate. NSA's defensive mission is about securing National Security Systems. These have a fairly specific definition, and are not running in the average business.
webmobdev 4y ago
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?).
- theandrewbailey 4y ago
  I'm pretty sure that in this context "memory safe" means more than that, like difficult to impossible to have a buffer overflow.
blululu 4y ago
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.
- darksaints 4y ago
  That's how they're supposed to operate, not how they actually operate. They've been hoarding zero-days for years, and they have even worked surreptitiously to undermine encryption by endorsing algorithms that they had already compromised. They couldn't give a single fuck about protecting US infrastructure if it comes at the cost of their offensive weapons portfolio.
  - throwaway0x7E6 4y ago
    case in point https://en.wikipedia.org/wiki/EternalBlue https://en.wikipedia.org/wiki/EternalBlue and that's just a glimpse into how bad things really are
    - sitkack 4y ago
      There should have been a commission formed about the p0wn goal that was EternalBlue. Microsoft charging for security patches should get the execs thrown in jail. The NSA should be disclosing big RCEs like this to the vendor and figuring out how to ensure that everyone is patched. https://en.wikipedia.org/wiki/EternalBlue#Responsibility https://en.wikipedia.org/wiki/EternalBlue#Responsibility
      - 4y ago
deleted 4y ago
[deleted]
marcosdumay 4y ago
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.
gw98 4y ago
I wish that was the case. The biggest software risk to companies I have worked at are not the NSA or memory safety. It's their own product management and development staff competence. You can leave a whale sized implementation hole in the finest of Rust applications!
some_random 4y ago
That certainly is a conspiracy theory alright.
cryptonector 4y ago
That's hilarious. The reality is that just by not recommending C (or C++), they really are making things safer.
Rochus 4y ago
> 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.
pjc50 4y ago
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?
deleted 4y ago
[deleted]
RadixDLT 4y ago
better stick with D then ;)

tester756 4y ago

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.

ok123456 4y ago

Holy C is the only CIA safe language.

slackware_linux 4y ago
How so?
- bombcar 4y ago
  https://en.wikipedia.org/wiki/TempleOS https://en.wikipedia.org/wiki/TempleOS for those not in the know. Dig deeper if you dare.
- arein3 4y ago
  Information directly from the horse mouth If there is someone that knows how to protect yourself from the glowies, it's the creator of Holy C
- arecurrence 4y ago
  HolyC is TempleOS's primary language. Previous to its creation the author had a mental breakdown... this should explain everything quite clearly https://en.wikipedia.org/wiki/TempleOS https://en.wikipedia.org/wiki/TempleOS
- qzx_pierri 4y ago
  TempleOS was an OS created by a genius programmer named Terry. Also, I very rarely use the word genius, but he was a genius by definition. He was extremely mentally ill, but his brilliance lives on through TempleOS (and HolyC). Check out this Down the Rabbit Hole video about him. https://www.youtube.com/watch?v=UCgoxQCf5Jg https://www.youtube.com/watch?v=UCgoxQCf5Jg
- rightbyte 4y ago
  God revealed him self and said so. Maybe a burning bush was involved I don't remember the details.
arein3 4y ago
Agree

ngneer 4y ago

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?

pjmlp 4y ago
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.
vitiral 4y ago
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.
anthomtb 4y ago
If that were the case, wouldn't the recommendation have been to use modern hardware rather than memory safe languages?
ylk 4y ago
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/ 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 https://news.ycombinator.com/item?id=30007474

beeforpork 4y ago

Shoot, no Perl!

sigzero 4y ago
Yeah, it's a weird list. If Ruby is there, Perl should be. I've seen lists with Python on it as well.
- bogwog 4y ago
  That list of languages gave you the choice between dependence on Microsoft, Google, Apple, and Oracle. So maybe they just added Ruby in there to have a neutral option?
  - sigzero 4y ago
    Maybe, you never know.
- tgv 4y ago
  Perl may have managed memory, but it is a great language for introducing bugs.
  - beeforpork 4y ago
    But its definitely memory safe. :-)
- lvass 4y ago
  Doesn't ruby have mark-and-sweep GC while Perl only has ARC with no circular reference cleaning?

josevalerio 4y ago

What about programming in immoral languages ?

vitiral 4y ago
So anything except Holy C?

VikingCoder 4y ago

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-systems-programming-language/ https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-s...

woodruffw 4y ago
I’m a big fan of Rust, and I think it’s reasonable for those languages to be listed: with the exception of a few niches, most of the code written in those languages will be spatially and temporally memory safe. They’re also popular languages with large ecosystems, so listing them “grounds” the guidance.
brightball 4y ago
I've actually heard claims of memory safety in Ruby for the last few years and I was always skeptical...but this gives those claims a lot more merit for sure. And worst case, there's always jRuby.
feukreust 4y ago
What do you mean just barely? They're exactly as safe as Rust. Perhaps they're not making it a selling point because it's been obvious for a few decades that automatic memory management tends to be memory safe. In fact some languages are even safer (e.g. Scheme and various Lisp implementations don't have integer overflows due to having bignums by default).
- VikingCoder 4y ago
  I guess I'm using "memory safety" very broadly and not literally, which I admit is not good. But, the borrow-checker seems to be significantly safer than anything else I've read about. Having no null pointer sounds very smart...
  - andai 4y ago

tmtvl 4y ago

I think we should all switch to programming in SPARK. It won't solve all bugs, but it'll solve the avoidable ones.

Rochus 4y ago
Good luck with that.

Maximus9000 4y ago

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?

msgilligan 4y ago
My understanding is that Rust provides memory safety with less overhead than languages that provide memory-safety via garbage collection. This comes at the price of some extra cognitive load for developers, but is appropriate for many applications where the added performance is needed. (Not necessarily "better" overall, but a better choice for certain applications.)
ok123456 4y ago
It's not. Garbage collection is fine. Rust just imposes constraints on references using the type system, so the compiler knows to emit the free in the right spot. For regular application code there's no real benefit. It's not really a systems language because of all the hidden memory allocations and lack of a stable ABI. It's garbage for embedded because of all the gratuitous copies you have to make to appease the borrow checker. It blows up your memory budget.
- zRedShift 4y ago
  > For regular application code there's no real benefit Can't disagree, naive garbage collected code would outperform naive Rust code that allocates Strings and Vecs up the wazoo. And performance isn't a real issue with simple CRUD/ORM-type services. Wrapping business logic in newtypes and enforcing specific invariants for them and serde style "parse don't validate", can do wonders for business logic, but then again you can probably just use a garbage collected functional language with dependent typing and a bunch of other tricks in its hat, and get more mileage out of it, if that's the code you write. > It's not really a systems language because of all the hidden memory allocations C and C++(especially) can hide memory allocation just fine themselves. Allocations are pretty explicit in Rust, but layers of libraries can hide those (if you don't use no_std and the like), just like in C or C++. > lack of a stable ABI there is the C ABI, a stable Rust ABI at any stage would just be an optimization killer and a massive PITA, ask C++. Stable ABI, international standard, and multiple implementations of the compiler, are not a requirement for a systems language. For a language that relies on compile-time monomorphization, a stable ABI beyond what C already provides gives precious little. Swift ABI forgoes monomorphization, but it's not really a trade-off a systems language should embrace. The template header issue in C++, I won't even touch. There are also crates in the ecosystem that can generate 2-way FFI glue code to provide a stable ABI for Rust based on extern "C". > It's garbage for embedded because of all the gratuitous copies you have to make to appease the borrow checker. It blows up your memory budget. We use embedded Rust on a memory constrained MCU and besides slightly increasing the maximum stack size (because less is allocated on the heap), memory budget is not an issue we have. And in LLVM 16, Rust's stack usage will decrease even more, due to recent optimizations. You don't need to use "gratuitous copies", you can statically allocate just fine, and if your value is ephemeral and is read/mutated by multiple threads, heap allocating with reference counting is just fine.

westurner 4y ago

# Infosec Memory Safety ## Hardware - Memory protection: https://en.wikipedia.org/wiki/Memory_protection https://en.wikipedia.org/wiki/Memory_protection - NX Bit: https://en.wikipedia.org/wiki/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 https://news.ycombinator.com/item?id=23993763 - DMA: Direct Memory Access - DMA attack > Mitigations: https://en.wikipedia.org/wiki/DMA_attack 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_management_unit 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-parameters.html?highlight=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 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_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_errors https://en.wikipedia.org/wiki/Memory_safety#Types_of_memory_... - Template:Memory management https://en.wikipedia.org/wiki/Template:Memory_management https://en.wikipedia.org/wiki/Template:Memory_management - Category:Memory_management https://en.wikipedia.org/wiki/Category:Memory_management https://en.wikipedia.org/wiki/Category:Memory_management - Reference (computerscience) https://en.wikipedia.org/wiki/Reference_(computer_science) https://en.wikipedia.org/wiki/Reference_(computer_science) - Pointer (computer programming) https://en.wikipedia.org/wiki/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 https://en.wikipedia.org/wiki/Smart_pointer - Manual Memory Management > Resource Acquisition Is Initialization https://en.wikipedia.org/wiki/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_initialization https://en.wikipedia.org/wiki/Resource_acquisition_is_initia... - Ada > Language constructs > Concurrency https://en.wikipedia.org/wiki/Ada_(programming_language)#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#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 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-ownership.html 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#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 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 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 https://anssi-fr.github.io/rust-guide/05_memory.html - Go 101 > "Type-Unsafe Pointers" https://go101.org/article/unsafe.html https://go101.org/article/unsafe.html https://pkg.go.dev/unsafe https://pkg.go.dev/unsafe - https://github.com/rust-secure-code/projects#side-channel-vulnerability-checking https://github.com/rust-secure-code/projects#side-channel-vu... - Segmentation fault > Causes, Examples, : https://en.wikipedia.org/wiki/Segmentation_fault https://en.wikipedia.org/wiki/Segmentation_fault - "CWE CATEGORY: Pointer Issues" https://cwe.mitre.org/data/definitions/465.html https://cwe.mitre.org/data/definitions/465.html - "CWE CATEGORY: Memory Buffer Errors" https://cwe.mitre.org/data/definitions/1218.html 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 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 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 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?pageId=87152142 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?pageId=87151930 https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pa... - Invariance (computer science) https://en.wikipedia.org/wiki/Invariant_(mathematics)#Invariants_in_computer_science https://en.wikipedia.org/wiki/Invariant_(mathematics)#Invari... - TLA+ Model checker https://en.wikipedia.org/wiki/TLA%2B#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 https://en.wikipedia.org/wiki/Data_remanence - Memory debugger; valgrind, https://en.wikipedia.org/wiki/Memory_debugger https://en.wikipedia.org/wiki/Memory_debugger - awesome-safety-critical https://awesome-safety-critical.readthedocs.io/en/latest/#software-safety-standards https://awesome-safety-critical.readthedocs.io/en/latest/#so... ; Software Safety Standards, Handbooks; Formal Verification; backup/ https://github.com/stanislaw/awesome-safety-critical/tree/master/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 https://news.ycombinator.com/item?id=24511280

3a2d29 4y ago

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.

LecroJS 4y ago
I have only dabbled in Rust and have no experience with C++/Java/Go. Can you help me understand how those languages would be more memory safe than Rust? My understanding was that safe code was a solution to memory leaks. What’s the benefit to safe rust code if it isn’t getting rid of memory leaks?
- 3a2d29 4y ago
  Memory leaks are not memory safety. Memory leaks in all languages are safe, they just slow performance and cause crashes. Rust still memory leaks.
  - LecroJS 4y ago
    Thanks. So what does it mean for a program to be memory safe if it can still memory leak? An example or pointing to a resource for further reading would be much appreciated.
    - Vecr 4y ago
      It prevents data races, use-after-free, double-free, buffer overflow, invalid type punning, etc. You can still do all those things in unsafe code though, and you could in safe code if the unsafe code you depend on (including the kernel) behave/are programmed incorrectly. You can also have hardware issues and stochastic bit flips that Rust and SPARK can't deal with.
    - Jtsummers 4y ago

WalterBright 4y ago

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.

RadixDLT 4y ago
yes I agree D should have been on that list, bummer

Jupe 4y ago

Any chance this would become a FedRAMP requirement based on this guidance?

oxley 4y ago
So… no Linux in FedRAMP?

gigel82 4y ago

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>

dtech 4y ago
If large groups of people and especially large groups of experts keep making the same mistakes with a tool, it's not the users that's the problem, it's the tool.
deleted 4y ago
[deleted]
Hemospectrum 4y ago
The problem isn't novices stubbing their toes in their own homes. The problem is professional programmers beneath your skill level who are making those same old mistakes in government offices and major corporations.

dang 4y ago

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

deleted 4y ago

[deleted]

mattewong 4y ago

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