NSA urges orgs to use memory-safe programming languages The NSA has released guidance encouraging organizations to shift programming languages from the likes of C and C++ to memory-safe alternatives – namely C#, Rust, Go, Java, Ruby or Swift. "NSA recommends that organizations use memory safe languages when possible and bolster protection through code-hardening defenses such as …
A new fangled explosion carriage with several thousand new levers in different positions to learn over the single bridle and a couple of stirrups? While waiting for the roads to be widened so you can get to the new libraries that will probably never be re-written,
"...Is there any reason why memory safe can't be enforced in the C/C++ compilers?"
It doesn't have to be in the compilers.
I did it more than 30 years ago in C libraries for an accounts package that I wrote. For example I replaced malloc() with my own version, which did a bit more (and so admittedly sacrificed some performance) but made the use of memory allocation for the rest of the package entirely safe and guarded against any and all overflows. IMO it was the only way to tame what was otherwise an obvious footgun.
The package is still running, still sending invoices, now even making VAT returns. Never a crash that wasn't caused by the hardware or the underlying OS. When someone called one of the users about a credit note and said that there must be a bug in it, the user laughed out loud.
And what's all this about Java and JavaScript? Weren't some of the biggest recent disasters written in those languages (log4j, npm)?
You can demonstrate incompetence in ANY computer language.
>Weren't some of the biggest recent disasters written in those languages (log4j, npm)?
Yes, but in both cases those disasters could be fixed in config. Something like 70% of severe vulnerabilities stem back to memory safety, which are much more challenging to detect, more challenging to fix and much more challenging to limit the blast radius.
JavaScript is in some ways memory-safe, but certainly not in the spirit of Rust or Sappeur. For example, JS records don't have a type. Each instance of record can contain other members. Or same named members with different types.
Rust, Sappeur, Spark Ada - they are Strongly Typed
I have been the re-initiator* of the Memory Safe System Programming Idea at around 2009. Rust and Swift have been created after I showed Sappeur to Mozilla and Apple.
Now NSA agrees with me and I am happy. If you don not share my happiness, just go to a different discussion. Thanks.
*Standing on the shoulders of Hoare, Bauer, ICL, Burroughs, MIPM
30 years ago I was writing grep and other apps that prevented me even trying to compile C code with any possible memory leak and fuckup code I could identify. Some of this in GCC warning etc and I get the impression LLVM was designed with this is mind but seems people would rather redesign the wheel than ping a few spokes.
Keyphrase seems to be "that I could identify".
Also "memory leaks" rather than "memory corruption".
If we could identify them all then we wouldn't have this issue and need memory safe languages, but alas, we do.
No necessarily for every context but they should be the default and deviating from that default justified.
Use of unsafe languages should be a code smell by default, not necessarily forbidden, but called out for the risk it is.
There's far more to memory safety than a custom malloc implementation could ever resolve. This does very little to achieve anything resembling memory safety. It does not achieve aliasing XOR mutability, any form of thread safety, or even to ensure the correct usage of pointers and data which ownership and move semantics resolves. No amount of code written or used in production with C can invalidate that or the large body of work that proving it to be necessary.
For starters, search for "Region-based memory management in Cyclone, by D Grossman 2002". This results of this research are a primitive form of the lifetime annotation syntax that you see in Rust today. One of many features that combined make memory safety possible.
>Is there any reason why memory safe can't be enforced in the C/C++ compilers?
Yes. This has been tried before.
The challenges are twofold. First is that you can only go so far with compiler-side checks. True memory safety is really a combination of (at least) thread safety, null safety and type safety in addition to the raw bounds checking most people are thinking of. Unless you're going to head off into managed language land and bring in a GC, you need language-level constructs to allow the programmer to work within these new bounds effectively. In Rust this is the "ownership" system, for example.
The second is that you almost always end up restricting the language features to some limited, safer set or replacing core functionality (e.g. malloc or the compiler) with something custom. This restricts the libraries you can use to those using your feature set, and requires you to maintain that core functionality ad infinitum. And even then you won't get "true" safety because it depends on everyone being careful and not using the wrong combination of features or compiler or versions and you being super sure your core implementation is itself safe. You can see a good example of this in D's "Better C", which is a true C compiler with memory safety, but without classes or exceptions. Or there's an older project called Cyclone which ends up effectively prohibiting pointer arithmetic.
So if you go all in on this, you're at the point where you need a specific compiler, plus a different set of core language features, plus you need to make sure all your supporting libraries are compliant, plus now you probably need bespoke supporting tooling for your static analysis and compile toolchain; so you may as well make life easier with some new syntax and higher-level features... you've basically developed Rust.
The second is that you almost always end up restricting the language features to some limited, safer set or replacing core functionality (e.g. malloc or the compiler) with something custom.
This is an important point. You can't have completely memory-safe C at the translation ("compiler", though C does not, strictly speaking have to be compiled) level, because you'd have to violate the C standard in various ways. For example, the translator can't tell how large an object with dynamic lifetime might be, nor how large an object passed by an external caller might be.
If it's a hosted C implementation, as most are, you have to provide malloc and friends. That's required by the standard unless it's a freestanding implementation.
So you might create a language which is similar to C with additional memory safety, but you're stuck with an uneasy compromise: something that isn't C enough to correctly translate and execute all conforming C code, but doesn't achieve the degree of memory safety you can get in something like Rust.
D is probably as good an attempt at a safer C as anyone's going to produce. C++, used in a careful, Stroustroppian manner, can achieve a decent level of safety; but C++ is also, as a language, required to carry a great deal of baggage. It's also huge (the C standard is large but comprehensible; the C++ standard defies the understanding of mortals), which makes it hard to reason about in general, and the vast majority of the considerable quantity of C++ code I've seen is rubbish, which suggests that many C++ developers find it difficult to be vigilant about their use of it.
No programming language is perfect. I like LISP and Scheme; I like OCaml and F#; I like Rust. I'm not particularly fond of Go, but I don't think it's objectively bad. I've enjoyed writing OO COBOL for .NET (which is not very COBOLy, to be honest), of all things. I've done a couple of non-trivial things in Java, and I don't mind working with it once I get back in the habit. I wrote a couple of academic projects in Javascript (for Reasons) and that was fun, though I wouldn't want to do anything big in the language, and third-party Javascript libraries are a plague. But all these have their faults, too.
Most of my work is still in C, and will continue to be for the foreseeable future.
I can't believe I'm reading this! Are you suggesting that a C programmer sacrifice speed for safety? Such a thing is just not done.
I think C++ went a very long way to address the memory safety issues but it still offers rubbish programmers the facilities to write dangerous code if they so wish.
C++ does offer some mechanisms towards memory safety, such as smart pointers, operator[] overloading and RAII. BUT - all of this depends on software engineer self-discipline. AND - there is no multithreading race condition safety assurance in C++, whatsoever.
All of this can be achieved by a proper type system, runtime check code and (multithtreaded if needed) ARC.
http://sappeur.ddnss.de/
I've used boost for years and it's a really useful addition but neither boost nor the compiler will care if you remember to lock access to shared data. The usual way is to create a mutex and lock it from the block where the data is accessed, but nothing will complain if you don't.
By contrast in Rust you *can't* share data between threads unless you either send it to the other thread, or use reference counting and a mutex / rwlock. You can't even access the data without acquiring the lock first.
"but neither boost nor the compiler will care if you remember to lock access to shared data."
You describe a race condition which will likely damage heap integrity and secondly have uncontrollable follow-on effects.
In other words, MT safety is a key feature of Memory Safety. SAPPEUR solves this by reflecting thread-shared memory in the type system and automatially generating Mutex lock code. Also, the ARC will be MT safe in this case(which is more expensive than ST ARC).
ARC: automatic reference count
MT: multithreaded
ST: singlethreaded
Mutexes doesn't mean thread safe, and not using a mutex doesn't make it unsafe. There are a lot of lock-free multiprocessing schemes.
Just tossing mutexes about is often slower than need be, and can even result in livelocks and deadlocks unless you actually do know what you're doing.
It's rather common to pass a huge array of "stuff to do" to a big pile of worker threads, then do something else (eg spin a waiting indicator) until all those threads finish (joined or whatever the language calls it).
A language-enforced mutex would make that slow or extremely slow, depending on where it decided to out the lock.
simply using
static std::string sharedString;
and then write-accessing sharedString from two threads will prolly destroy your heap integrity. In Sappeur this will either not compile, or the sharedString will be a "multithreaded" object and protected a mutex. And yes, you still need to use your brain and know what to do to achieve good performance.
C++ went some way to help with safety. Smart pointers for example. But it's still incredibly easy to screw up in C++ and the compiler won't care. It's all very well to blame "rubbish programmers" but the world is filled with mediocre and crap programmers and the programming language isn't doing all it could to beat some sense into the code they write. This is why *everyone* is looking at safer alternatives these days. Rust would be a prime example but NVidia has SPARK, Google has Carbon plus there are other modern programming languages that will unwind in a graceful way rather than crash or be exploited by C++.
Because C (from which C++ is derived) is a Systems Programming Language, used to write operating system and low-level code in. You specifically don't want any run-time checking or behind the curtain behavior there.
I always say: C is high-level assembly language and as such you need to handle it with care. Using it as a Application Programming Language is foolish.
This isn't really correct. You don't need "run time checking" or "behind the curtain behaviour" to achieve memory safety. Rust does this with explicit memory ownership. The presence of these things does not preclude use as a systems language. OCaml is an example of a successful systems-oriented language that includes a bunch of "behind the curtain behaviour".
OCaml is a LISP variant, correct ?
No. OCaml is a member of the ML family, which also includes Standard ML and Haskell. The ML and LISP families are not closely related. Five seconds of research would have told you that.
So it can never achieve the efficiency and realtime capabiities of an imperative language ?
This is precisely the sort of handwaving bullshit that lets your readers know you have no real arguments to offer, and they can safely ignore you.
So OCaml is not LISP, but shares all the hallmarks of LISP: functional programming, immutable state, garbage collection. All of that translates into inefficiency and a lack of realtime capabilities.
For some problems, functional programming is definitely the right solution, but not for others such as realtime control, realtime signals processing, realtime GUIs and the like. Also, GC typically requires 2x the memory of an ARC-based equivalent program.
I always say: C is high-level assembly language and as such you need to handle it with care. Using it as a Application Programming Language is foolish.
That's been my view as well. Being unsafe is baked into the language. It was and is appropriate for what it was intended for but not in applications where no end of effort has been - and has to be - expended trying to mitigate its unsafe nature.
I can understand why people ended up using C for everything but it was foreseeably walking a path to the inevitable nightmare. "Don't use C for applications" has been said for decades but mostly ignored.
Mine's the one next to the growling lion holding a flick knife and a bottle of Novichok. No; it's perfectly safe if you approach it right.
Actually, C and Unix were made for educational purposes, and were never meant for production. The same applies to Pascal.
C is indeed meant as an assembler replacement, and you're very right with your remark that you should never use it as an Application Programming Language. Tell that to C programmers. High level languages will add checks in the code, C will not. Checks like you defined a variable as numeric, is the data you want to move to the variable indeed numeric? Or, you defined a table with 100 entries, is the value in the pointer in range, so that you can't read or write "entry" 200 ? Yes, it will make the application slower, but so what. I want reliable code.
I remember a programmer complaining about C on VMS. The C compiler was always complaining about errors in the source, Unix didn't have that problem. I understand why ..........
Ada was designed to produce error free applications. Someone once told me that if you wrote a 100 lines Ada source, you would most likely get 200 lines of errors after the first compilation.
With all the computing power we have these days, it is time to start using languages that can produce error free code by adding code for checks that the programmer will not add, and should not be required to add.
Complete memory safety cannot be enforced in C/C++ in any practical manner.
Good programming practice goes a long way, and there are guides for C programming for safety critical systems such as cars (see MISRA guidance), etc, available that go through the sub-set of syntax you should use and things to avoid doing as they commonly result in bugs.
However, you (and others) can go a long, long way to avoiding problems by turning on the highest warnings and using various analysis tools, both static (e.g. lint, coverty scan, etc) and dynamic testing (e.g. the electric fence library, valgrind). I would be willing to be a large portion of security faults come from not listening to and correcting warning (possibly as legacy code had so much that developers wound back on the checks).
Beyond that, and for all languages, you can also use tools such as AppArmor for mandatory access control so software once executing is limited in what it can do by rules designed around what it should do.
Sadly try that with many programs like web browsers and its a complete mess of rules and requests for stuff you really, REALLY wonder wtf the developers thought they needed to poke around all sorts of places in the OS just to play cat videos and brows the web.
Strongly typed, memory safe languages do what you say, in a strict fashion. The static checkers you mention are incomplete and heuristically driven.
AppArmor is a different approach; coarse-grained and treating the program as a black box. It makes sense to not mix up memory safety and sandboxing, for clarity of thinking.
The CVE database is an excellent place to highlight the stupidity of people defending C (or C++). Look at the Linux kernel CVEs and the majority are for things like double free, call after free, buffer overflow, data race etc. I think we can all agree that the kernel devs are at the top of their game, probably knowing more about C than anyone else and yet the majority of their bugs are caused by the language it is written in.
"...Sadly try that with many programs like web browsers and its a complete mess of rules and requests for stuff you really, REALLY wonder wtf the developers thought they needed to poke around all sorts of places in the OS just to play cat videos and brows the web."
I wish I could upvote that ten more times.
Which is why people are getting fed up and turning to the "just containerize the bleeping thing" route used by things like Flatpak and Snap.
Sure, you still need to grant far too much access, but that's inherent when your browser is taking over from X.org for "OS running on top of the OS" status and the API surface for XDG Portals (the Linux equivalent to Android Intents) is still getting built out.
(eg. It's got a file/directory chooser portal that Firefox will use, but support for "When I pick this .html file, also mount the adjacent _files directory into the sandbox" is an open bug.)
Two main reasons:
1. The C and C++ language syntaxes don't, by default, provide enough information to the compiler. Attempts have been made to extend them on various occasions, but they're ugly and people don't use them.
2. They have huge ecosystems that don't use such annotations. When you switch languages, the act of annotating the APIs to be verifiable for correct use gets rolled into "writing bindings to the C or C++ code".
the ISO C++ 20 already has everything for memory safety for general purpose programming.
But even Rust like C, C++, for low level allocator development has to be unsafe in that you operate on bytes, before framing them as objects.
https://www.theregister.com/2022/09/28/is_it_time_to_retire_c/
"And, as Bjarne Stroustrup, C++'s creator, told The Register recently: "We can now achieve guaranteed perfect type and memory safety in ISO C++."
""We can now achieve guaranteed perfect type and memory safety in ISO C++. That is, every object is used according to the type it was defined with. That implies that we eliminate uses of dangling pointers, catch range errors, and eliminate data races. Note that every 'safe' language, including Rust, has loopholes allowing unsafe code."
It is quite easy to enforce.
How will the compiler force you to not use pointer arithmetics ?
How will the compiler check for accidentally shared thread-global objects and stop compiling ?
How will the compiler stop you from obtaining a pointer to a stack-allocated object and store the pointer somewhere in the heap ?
I am genuinely interested. And I do think Mr Stroustrup is not totally honest.
Rust does this via ownership, as others have explained. To get a pointer as an int and do fun/weird/dangerous stuff, you have to explicitly wrap the code in an 'unsafe' declaration, or it will not compile. At that point, all bets are off. Rust's guarantees only apply when you write normal/safe rust. If the programmer says "I'm smart, let me fuck about with integers, trust me bro"... then I hope they use other methods to validate their logic but the compiler is not going to. That's the awesome thing about Rust, if you never write unsafe code you'll never have these (specific) problems, and most applications do not require unsafe code, so the libraries that do require it can be small, audited, and hopefully bug free. But nobody is saying rust won't allow bugs, just that they will hopefully be less prevalent and always found in bits of code that label themselves as potentially dodgy.
I maintain a very large piece of code and I have a total of THREE unsafe blocks. All three of them are small blocks of code to do with a padding function I am in OpenSSL where it does stuff to memory buffers.
That means if I suffer an NPE I know exactly where it is. The rest of the code which is tens of thousands of lines has no unsafe code at all although some of the crates undoubtedly do, mostly to wrap and call C and native OS APIs.
I was asking how a C++ Compiler would do this. I think it cannot, because C++ does not have a memory safety system bolted-on.
Something like a
g++ --memorysafe
switch. That switch would more or less turn the g++ into a SAPPEUR compiler. No more raw pointers, no more handing over arbirtrary pointers to thread functions, no more MT unsafe global data structures etc.
The simple reason it can't be enforced by C/C++ compilers is because not a single C/C++ file would ever compile if they did. Nor do the languages give the compiler the contextual information necessary to enforce safety. Compilers could certainly get stricter by default, or do some lite static analysis but it's not going to hold a candle to what the Rust compiler would do by way of example.
There are plenty of smart people on the C++ standards committee. Maybe they will add a Memory Safety System to C++25 or so. The MSS would of course disable plenty of dangerous things and it would require additional syntax in order to delineate ST from MT datastructures.
One could envision that MSS-enabled compilation units would even integrate with NonMSS compilation units. This would allow for incremental transformation of a code base towards memory safety. As I wrote many times, this is about incremental improvements, not Purity.
The aliasing XOR mutability concept in Rust requires syntax for assigning lifetimes to references, along with additional syntax for distinguishing between immutable and mutable references. It also requires that you are writing software using references instead of raw pointers. So in effect, no it is not possible and if you make the changes required to make it possible then you've just recreated Rust and most likely the duplicated effort is vastly inferior.
That's also just one component of the feature set in Rust that makes it trivial to write software free of memory vulnerabilities. The other is the fact that move semantics are built into the language by default, with syntax to influence the behavior. Or that there's a trait mechanism to enable generics, and through that system there's some built-in traits that are automatically derived for types based on the composition of types within that type. Traits such as Send and Sync, which are used for thread safety mechanisms to prevent moving data cross thread boundaries that does not allow it, or preventing something from being shared across thread boundaries when it does not support it.
"Mitigations like address space layout randomization (ASLR) and stack guard are kind of a band-aid, not a full solution; moving to a memory-safe language is a much better one," added Reed
No language is perfectly safe - each has it's own range of potential critical bugs -- they just differ between languages. So regardless of the language, the best protection of all is a combination of attention to detail and rigorous testing. Unfortunately both come expensive, so instead of allowing for that cost we've chosen to make successive languages more and more "de-skill proof", which just shifts the goalposts rather than making things inherently more secure.
Just for example, it's quite possible to exhaust memory catastrophically in Java, despite its inherent memory management.
Vulnerabilities comes in classes. One such class is memory corruption vulnerabilities. These are particularly nasty because then can often lead to remote code execution.
Some languages eliminate this class of security bugs completely. Garbage collected languages (e.g., C#, Java, Ruby) and borrow checking languages (e.g., Rust) are languages that eliminate memory corruption bugs.
The advice is sound. Given that memory corruption often allows RCE, it makes sense to use a language where memory corruption is simply not a concern.
Java's memory access is heavily nerfed, at least at the programmer side, but the java vm itself is a seemingly bottomless font of security issues. So I'd hesitate pulling it's corpse of the burn pile and building new code with it.
Yeah you can write insecure code in almost anything through your own mistakes or ignorance. The problem with Java is that the JVM can screw you over even if the code you wrote was rock solid. You can't build a strong castle on a cracked foundation. The JVM slowly turned into hot garbage over the years, succumbing to bitrot along with Flash.
(Java still plainly the better of the two, clearly, but also not good, just less bad)
Also at the end of the day, why suffer for it? Java's a dinosaur from anther time, the way it treats it's users is frankly insulting, and baked in insecurity is the reward you get for accepting handcuffs that make writing anything non-trivial in it a PITA. I'm all for shoveling dirt on it's smoking corpse. Any other takers?
The advice is sound. Given that memory corruption often allows RCE, it makes sense to use a language where memory corruption is simply not a concern.
But even rust grandfathers C/C++'s (what you might call) cargo cultism around order of execution (memory barriers and whatnot). The problem is that order of execution is a non-trivial (unsafe) problem where you're cribbing from C/C++, where your compiler can't check for non-compliance when it comes to translation of the standard, and the CPU can make up its own mind ...
But yeah, in general Rust is a whole lot better. Just not perfect.
Rust is open-source with a very public development process, so I doubt you'll find a better candidate for not getting backdoored by the NSA.
Someone else characterized this as "the NSA has realized that trying to win at cyberwarfare by pure offense is ultimately a losing battle and has shifted to defense" and that makes sense to me.
Remember that, at the end of the day, the NSA does believe itself to be acting in defense of the U.S.A., even if the road to hell can be paved with good intentions.
And that an explicit part of the NSA's mission is to improve the US position against foreign SIGINT. That part was famously de-emphasized for a while around the turn of the 21st century, but under subsequent NSA directors and other Executive Branch influences became a priority again.
The NSA considers itself pretty good at finding vulnerabilities and creating exploits. It doesn't mind raising the bar to make things harder for others.
Hmm, compiler and runtime checks on data and stack accesses, how very late 60s/early 70s. Of course they tended to be optional in those days due to hardware constraints (memory size, cpu speed) and you needed to add code to handle the runtime errors properly, so they were on the way out by the end of the 70s.
Butt C++ != C. Ok, so I don't write device drivers, or kernel code, or anything where a picosecond of performance loss will mean the demise of civilization. I'm pretty happy to use std::string and std::vector with iterators and the like for exactly the purpose of bypassing the memory manglement hell that C people have to live with, and having additionally have the opportunity to bask in some schadenfreude when I see it happen.
C# is most certainly not immune to memory leaks.
I'm surprised nobody used the opportunity to worship Python in this article. But then, that programming language was designed with the goal of making very bad programming mistakes built right in from V1.0.
..its always the programmers, never the language, that is the reason for insecure software. Totally locked down software can be easily written in asm. By a competent programmer.
And there have been tools to find exactly these kind of problems in C and C++ codebases for at least 30 plus years.
There again, the more secure the general software ecosystem the more valuable the NSA's hardware backdoors are. Its not just in certain CPU's you know..
Well if you have been reading the CPU hardware manuals since the late 1970's (some of us have to worry about instruction clock cycles, cache miss penalty, decode depth per IPU etc.etc) you would have noticed some very interesting "features" mentioned in the mid 1990's for a certain CPU that have since disappeared from those multi K page tomes. Wont go into details but if you have been reading motherboard schematic for all these decades (since the days of 74LS TTL's) and know exactly whats connected to what and why, and what those timing diagrams mean. and what every last bit in all those system registers means, well, there are some very interesting things to find in those very old CPU hardware manuals which explain some of the odder elisions in the newer ones.
To those of us who actually had to totally lock down and secure executable environments, software and hardware, for commercial products our interest tends to be piqued if we see a very odd several line paragraph tucked away among the several K pages of a CPU hardware manual. Especially if the paragraph disappears in the next and subsequent editions but the "feature footprint" does not.
In those secure execution environment products the hardware and the OS are the primary attack surface. Which is why you have the source code / disassembly and all the relevant hardware manuals. No matter how obscure the chip. Plus you keep a logic analyzer around. Just in case you need it. But I usually leave that to the triple E's.
I'm sure there was nothing to the MS Anti Trust settlement being essentially set aside in 2001 for "national security reasons". Or the mystery of why the network stack codebase was never part of the 3'rd party build set. Nothing to see here, move along...
You do know that your shiny new language compiler is just yet another attack surface? That compilers have bugs. Lots of them. I can verify and validate the output from a subset of C fed into any C (but not C++) compiler. I have yet to see a compiler for any language that with a little playing around with, and looking at the output disassembly, you cannot find a compiler bug that provides some nice juicy exploit hole.
Your shiny new language will not protect us from crap programmers writing crap code. Who usually work for Big Nasty Software Corp Inc. In my experience.
Full disclosure, I am not a Rust programmer or pretty much any sort of programmer anymore (JAPH).
However, in the documentation it does explain how to get around some of those pesky memory checks and gain "superpowers" when you know you are right and the compiler is wrong.
https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html
So yes, "Crap unsafe software can be written in any language"
As much as the fire brigade can break rules of the road under pressing circumstances, low level software components will need to be excepted from memory safety.
As with the blue lights and the siren, this must be done in a controlled and careful fashion. Just because you have the siren blaring, does not mean you can run over a crossing. You (as a fire brigade driver) better go slow, check the traffic and then do the crossing.
If this is done correctly, the risks are controllable and acceptable. It does not mean there should be no rules of the road, because the police, fire brigade, red cross must break them then and now.
int Socket::send(&char buffer[],int count)
{
var int ret;
if(count>buffer.sz)
{
return -2;
}
inline_cpp[[
ret=0;
while(ret<count)
{
int ret2;
if( tlsConnection == NULL )
{
ret2 = ::send(_handle,buffer._array+ret,count-ret,0);
}
else
{
ret2 = tls_write(tlsConnection,buffer._array+ret,count-ret);
}
if(ret2<=0)
{
return -1;
}
ret=ret+ret2;
}
]]
return ret;
}
Rust is safe by default. You'd have to be determinedly bad at programming to want to wrap everything in unsafe for no reason. The purpose of unsafe in the language is for interface boundaries with the operating system or other languages. e.g. to call a function in C, or to be called by C.
The difference is a crap programmers and crap software get a lot further in C or C++ than they should. If you write crap in Rust the compiler will kick your ass and then helpfully explain why it's not going to compile your code. In C/C++ the compiler won't care and that bug might go all the way to production which not only degrades the quality of the code, puts security at risk and makes it harder to identify and fix after the fact.
This is why the NSA and others are pushing hard on using a safe languages.
This post has been deleted by its author
I salute my computer science colleagues in Military Intelligence for supporting the trend towards Memory Safety.
Having invented a memory safe language
http://sappeur.ddnss.de/
myself, I am very pleased to be validated by this esteemed* computer science organization.
Memory Safety is the natural progression from firewalls to mandatory access control (SE Linux, AppArmor, sandboxing) to fine-grained Software Fault Isolation.
Applied computer science does have a big problem, which is a lack of practical security. Entire corporations have seen their computer networks destroyed by exploits which are based on a lack of C or C++ memory safety.
http://sappeur.ddnss.de/Sappeur_Cyber_Security.pdf
70% of CVE exploits are based on the lack of memory safety of real-world C and C++ programs. Let's plug this hole.
Let's rediscover the Algol Mainframes, Spark ADA, Modula-2, Oberon, MSFT's Singularity OS. Memory Safety is not a new idea, but it had been forgotten.
* see the Perl Language as an example of NSA inventions
To all the detractors, I would like to point out this:
A) Decades-old Unix tools have been run with valgrind and exposed memory errors. So they still had memory errors after 1000 incremental bug fixes.
B) Even in safety critical automotive embedded code, programmed by highly experienced (20 years or more of software engineering time) software engineers, we find index errors using tools such as PC Lint or PolySpace.
C) Working with memory safe languages results in less pain, less bad surprises in my work as a software engineer. I am developing software since 1993 and I have a degree in CS.
D) Tony HOARE points out that real-world, production(!) FORTRAN programs typically contain index errors. Turning on index checking "offended" the FORTRAN users, because it "broke" their "proven" programs.
Conclusion: Human software engineers are the best we have (artificial neural networks can't do it yet and prolly won't do for another 100 years) and they are NOT perfect. Claiming such perfection is equivalent to lying.
I.T. Security has many aspects, one of which is Software Fault Isolation a.k.a. Memory Safety.
A single programming error should not open up the castle for an attacker.
That does not mean other aspects can be ignored.
It is called Computer Science, because it is not a trivial thing.
You are right that those are important parts of the attack surface, but this isn't an either or proposition. Using programming tools that are more memory safe are a part of the solution that falls on most people writing code.
Those that work on parts of these systems that face the classes of attacks/problems you mention have additional things they need to address, but they will need to do both, not choose one or the other. (though not the passwords thing, anybody that does that is a monster and should be fed to a mob of angry village people)
Memory save languages make the job of consistently avoiding these errors easier, even if things like rust bring a little pain and learning curve. And as one of the other posters above implied, if you think you can do that every time on your own in C and never slip up, you are lying to yourself. The code profilers strongly suggest otherwise. So why, other than pride or routine,would I stick with using tools so prone to blowing my own feet off?
You must be an Englishman as you are embodying what Babbage railed against ...
"Propose to an Englishman any principle, or any instrument, however admirable, and you will observe that the whole effort of the English mind is directed to find a difficulty, a defect, or an impossibility in it. If you speak to him of a machine for peeling a potato, he will pronounce it impossible: if you peel a potato with it before his eyes, he will declare it useless, because it will not slice a pineapple."
:-)
It is worth keeping in mind the aphorism "Perfect is the enemy of good" - the suggestion from NSA does not address all problems, but it does address a recurring problem in "everyday" software.
Your question makes no sense. Safe languages are intended to stop exploits and instability caused by C/C++ like buffer over/underflows, race conditions etc. No language to my knowledge can stop code from making general application logic errors but neither the NSA or the safe languages themselves are even claiming they can.
But languages like Java and JavaScript (I use the term “language” loosely here) and probably (I admit I’ve not checked) Go etc etc are either written in C or use massive C libraries underneath
So, that knackers up the supposed memory security “guarantee” (yea - right!) straight away
I was just pointing out the folly of advocating a solution that has (by the advocate’s own argument) an underlying basic and catastrophic flaw.
Unless you can absolutely verify that the underlying implementation of the tools is flawless then you are building on sand.
Of course, we build on sand every day because very few people outside of academia and computer research bother to verify that the tool chains we use are flawless (or even close).
My Sappeur compiler(coded in C++, but could be self-hosted one day) is far from perfect, but it has found lots of programming errors for me. The resulting code is empirically much more robust than equivalent C++. Much less "inexplicable" behaviour.
That is my experience, believe it or not.
While the first versions of any language compilers are by necessity written in another tool (or assembly), many have been rebuilt on their own code after the language is feature complete and stable. Hence modern C compilers are compiled using other c compilers and not assembly or COBOL.
The flaw you are arguing is in your own logic unfortunately. You conflate the classes of problems that the compiler could cause with the classes of problems the language is prone to. You also imply that the tools must be "flawless", which is nonsense. Yes, the sum of the problems in the underlying tools and runtime(in runtime languages) and the problems in the code itself all end up in the output. But perfect code beyond specific or trivial cases is provably impossible. The eminently achievable goal is to REDUCE the number and severity of problems. That's not building on sand. More like bricks, and one cracked brick will rarely bring a building down, especially if the engineers are paying attention.
Verifiably "flawless" code is only possible under specific constraints, and is impossible in a general sense, and also once you factor modern hardware in. QA exists for a reason though, so even when you can't write a formal proof of correctness, you can still do a good job. And good programmers need to understand whats happening inside that box that represents the compiler to manage any problems that may impact their code.
I was just pointing out the folly of advocating a solution that has (by the advocate’s own argument) an underlying basic and catastrophic flaw.
And C [and other] compilers have code generation flaws, but that does not make using High Order Languages (for some value of High) a bad decision or reduce us to "building on sand" - though we need to remain cautious about the degree of trust we place in such things.
The key difference between writing software in a language that exposes a greater risk of errors, or using a language where some underlying part of the toolchain is still dependent on that riskier language, is that the former approach exposes the entirety of the new software to those risks (and there is a long and sad history of software writers continuing to make the same sorts of mistakes as has been happening for decades). The latter approach moves more towards the "Correctness by Design" model in which it is not possible (or at least diificult) to make these mistakes during the implementation process.
It remains a problem that tools such as compilers (or libraries) might introduce errors - which is why you need to remain careful about the degree of trust you place in them (e.g. by careful vetting and control of your choices, and the degree of testing of the final product).
Ah yes, the need for bootstrapping!
My solution to that issue has been to maintain compiler sources in *both* languages. For a lot of stuff, I write in my own language first, since it is higher-level than C, then translate to C (yes, manually) when the former first compiles.
Over time, significant chunks of the C code have been deleted, replaced with calls to my bytecode engine to execute the version in my own language. At some point, my system will be complete enough to fully compile itself.
I was pushing to have versions of the whole thing quite a while ago, but stopped. As the language changed, there was no good reason to keep redoing the parser, for example. I did do the lexical scanner, and have used it to good effect for other purposes.
Currently, I'm working on producing X86-64 code (mostly there now) and Elf files to run on Linux. All of that is *only* in my own language.
Will my compiler end up as "good" as gcc or llvm? No, of course not. One guy versus teams of people. However, having *all* of the needed tools written in a memory-safe language will, I believe, be of benefit for extremely critical situations.
...and then there's the so-called Ken Thomson hack (circa 1974):
- https://wiki.c2.com/?TheKenThompsonHack
Do you "trust" the C compiler you are using?
Or perhaps you have adjusted the C compiler to suit yourself?
I think we should be told!!
P.S. This isn't a theoretical attack.....the SolarWinds mess used something similar!
A little bit of assembly level inspection would expose this.
Plenty of embedded sw organizations look at generated assembly, some even line by line source+assembly. Life critical aerospace control, for example.
Plus, there exist automatic protocols to.expose this technique, IF you have a single untainted compiler+os+machine.
I usually hear it referred to as a "trusting trust attack" and one strategy for countering it is Diverse Double Compiling (https://dwheeler.com/trusting-trust/).
Since Rust doesn't yet have a second full compiler, their approach for countering that attack is:
1. Use DDC to get a trusted-to-be-clean C++ compiler
2. Use mrustc (https://github.com/thepowersgang/mrustc) to bootstrap whatever the newest version of rustc it supports is from C++. (Currently 1.54.0. mrustc is a C++-based Rust compiler meant specifically for re-bootstrapping rustc, which keeps its complexity down by just trusting that what it's compiling would pass borrow-checking under the full compiler.)
3. Use the resulting compiler to bootstrap-chain up to the current Rust compiler.
Every time it's been done so far, the hashes of the produced rustc binaries have matched the hashes of the rustc binaries that trace their lineage back to when rustc was originally written in Ocaml.
Its many decades since I ran into a buffer underflow / overflow bug in any code I have written. In fact Reagan was president at the time of the last bug, in my first really big commercial product codebase.
Dont want buffer / array bugs then follow a few very simple rules.
1) Dont allocate on the local stack or the globals space. Always in the malloc() memory heap.
2) Always as a struct where first fields are maxsize in bytes, max array element count, then the buffer, array data
3) Every read and write uses an accessor function to this struct which checks min, max, range values and only if everything is legal does it proceed.
Another rule that will save grief down the line, dont use for loops anywhere for accessing data in buffers / arrays. If the codebase is used enough the for loop will fail, somehow. Same goes for anything recursive. Where are those function call stack frames kept in memory. What happens when that OS stack frame partition for your process is full? That sort of stuff.
Plus if every third or fourth line of the source code is not an assert of some sort of other then the code will fail. If given enough time.
Thats what actual engineering looks like. A lot of error checking and a huge number of asserts and only continue if all correct code. If the code is not written on the assumption that something might fail, totally paranoid code, the code will fail. If used enough. Guaranteed.
Apparently you work in accounting, web programming or the like.
There exists software which is - for all practical purposes - perfect:
ABS Brakes
ASR
ESP
Airbus A320 and later Flight Control SW
JÄGER90 Flight Control SW
Space Shuttle Flight Control SW
If this software were not perfect, we would have seen spectacular crashes and dead people. We have seen that with GRIPEN, F22, V22, 737MAX, ARIANE V, but never with JÄGER90, A320, A330, A340, A380 or A400M.
And of course AIRBUS, BOSCH, Continental etc use much better software engineering processes than YOU have ever seen.
https://de.wikipedia.org/wiki/Eurofighter_Typhoon#Zwischenfälle
https://de.wikipedia.org/wiki/Lockheed_Martin_F-22#Zwischenfälle
"Im April 1992 stürzte der erste YF-22-Prototyp im Landeanflug auf „Edwards“ ab. Testpilot Tom Morgenfeld überstand den Absturz unverletzt. Untersuchungen ergaben, dass die Flugzeug-Software Pilot Induced Oscillations nicht oder nicht hinreichend entgegenwirkte.[133]"#
F22 control creates oscillations:
https://www.youtube.com/watch?v=mbQx89Eklm8
Gripen control algorithm issues:
https://www.youtube.com/watch?v=k6yVU_yYtEc
V22 has an own page for the 51 people it killed out of enemy action
https://en.wikipedia.org/wiki/Accidents_and_incidents_involving_the_V-22_Osprey
Let me guess. You have never actually shipped any meaningful software. To end users. Of worked with anyone who has. Maybe at best just a small time byte pusher on a very large bureaucratic dev team working on Big Corp / Big Gov projects.
I was shipping mass market software (100K's to 1M's+ users ) long before you were born by the sound of it. I was the guy who had to sign off on the Golden Master on very expensive production runs when thats how software was delivered. Get even simple stuff wrong, that's many $100K's of disks / carts straight to landfill. This was back when you could buy a very nice car for $15K.. Get it seriously wrong and you are out of business in 12 to 18 months..
The last product I shipped was download only, but 600K downloads in the first 3 days, over 3M in first 90 days. For a very big company whose products you own and who care very very much about quality and company reputation. Nothing like a few million users to show up low probability serious bugs very quickly. That final Release Master put up on the server had to be even higher quality than what we used to send out as GM for dup. As any failure would be more obvious, more quickly.
I've have also worked on teams with guys who wrote avionics software for Boeing (FAA certified commercial aircraft) , missile control software for Lockheed Martin (the stuff that makes very big bangs when it lands 8000 miles away), and worked on embedded software (lead) that has go through FDA certification. So I know exactly how that software is written, the methodologies involved, and heard the war stories from the trenches. Some real doozies. Also the heard war stories from the NASA guys. Both Shuttle and Deep Space probes. The real miracle with the Shuttle is they only lost two hulls.
Funnily enough I fitted right in with the Boeing and Lockheed Martin guys. In fact my code was safer than the stuff they wrote. I actually had worked through potential point of failures for all language elements. For a guaranteed full recovery / restart on fail soft real-time OS project a few decades ago.
I'm old enough to remember exactly why both provable ADA compilers and other provably software efforts failed. And why very strict code discipline enforced by the dev lead actually works. Unlike the purely box ticking exercises for the latest ISO xxxx bullsh*t. by PM's.
You should get out more. Or maybe stick to stuff you might actually have a clue about.
1.) I worked on automotive software which is successfully used in hundreds of thousands of cars, some of which is ASIL D at max (maybe you use it in the power steering in your BMW, Tesla or Mercedes, maybe you use it in the VW Camper)
2.) Your experience at US aerospace companies validates my point that US aerospace projects are dangerous affairs. The V22 is just the tip of the iceberg. Below we can see F22 and 737MAX.
3.) I suggest you guys on the other side of the pond learn what V-Model development REALLY means. First and foremost, it is about honesty and about "reaping the low hanging fruit first". Have realistic Unit Tests, don't do something fox box-ticking, have realistic HIL tests. I bet your managers are cheating on all of it in the name of "financial performance".
3.2) Having said that, I also know German+other European managers who like to cheat, but apparently on average it is not as bad as in the U.S.
> There exists software which is - for all practical purposes - perfect:
> ABS Brakes
You clearly never experienced the joy of the Subaru ABS software, which contained a bug known to owners as "Ice mode". Once it gets into that state, there is no braking at all and you don't stop until you hit something.
Of course, the brakes don't lock up, so technically it meets the specification.
There are some indications that they were seriously challenged in the past to do proper SW engineering in automotive. I would assume though, that all of that has been resolved by now.
We have excellent relations with both Japan and South Korea and they will understand that they must meet high standards for selling cars in the US and Europe. Just recently we sent 6 JÄGER90 to Japan in order to stiffen their defence against China. In Return they wil definitely listen to our concerns.
How many new projects are that could be written using a GC-enabled language, but will be written in C/C++ instead if it were not for security concerns?
None, maybe. All those GC-enabled languages are much easier and faster to work with, and easier to debug. But are not suitable for RT processing.
So it boils down to C/C++ vs Rust for those projects where a GC-enabled language is not suitable.
This coming from the org that used one password (total) for all it's staff to access all it's spyware toolsets?
Not to sound paranoid, but it is also a LOT easier to reverse engineer or snoop GC/Memory-Safe applications, particularly while they are running. A lot easier than native machine code etc.
Why would the largest spy and surveillance organization in the world, the 5-eyes mammoth, be pushing a thing called Rust ? Who controls Rust ? Does Rust have some nasty stuff embedded inside, which can trigger unsolvable exploits ? "New security update : install new build of Rust, fixes 26 security errors immediately." Is Rust adopting the Google Chrome model of peddling zero day exploits in new builds ? With C/C++ there's apparently no such market possible for the dark net dragons.
it's not C's fault people are using it for stuff it's not supposed to be used for
it's an ultra-low-level language designed for those applications, ie single core applications running at highly efficient speeds on highly limited resources, where you need to control the memory space and re-allocate it to get the required performance or capability from the limited hardware.
if you don't need to use C/C++ then don't use it, if you do, you make your trade-offs and know how to make it work for your situation.
All the programming languages listed, like "C#, Rust, Go, Java, Ruby or Swift", are terribly insecure, as well as being much slower and limited.
All of them require installing run time security breaches that can easily be exploited.
None of the secure facilities I have ever worked at would ever allow a Java interpreter engine be installed for example, because then it is easily controlled by anyone who knows the details of the built in vulnerabilities.
C and C++ are the MOST secure languages because they rely on loading the fewest run time leaks, and are totally self contained except for driver and OS calls.
This article should have known better, and any real programmer should know that C and C++ are by far the most secure programming languages.
About the only security weakness in C and C++ are buffer over runs, which should be caught by the OS calls.
I suggest you use this memory safe C++ variant:
http://sappeur.ddnss.de/
You can always check the generated C++ code for NSA backdoors. I have a secret contract with NSA and will only insert backdoors after you have used the compiler for more than 16 hours during the last 24 hours. Then I assume you are too tired to check and will insert the backdoors.
If you purchase my high performance tinfoil hat with the compiler(see below), I promise not to insert any backdoors.
Seriously, man, get yourself a bottle of beer and a serious touch from your girlfriend.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
