Perhaps I'm old and cynical, but I can't help but feel that: "it'll take decades before we clean up this mess" should really be: "it'll take decades before we replace this mess with a different mess"...

I take it you use a horse carriage instead of these newfangled explosion-engine carriages ? Too dangerous !

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,

So you are posting from Kandahar ?

I suggest an explosion engine bicycle from Yamaha. Your warriors use them to great effect.

I am but a humble SQL consultant who 'does a bit' in C# & Java (history of all sorts going back to Fortran, Pascal etc).

Is there any reason why memory safe can't be enforced in the C/C++ compilers?

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

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.

Which mythical-magical C compiler did this "30 years ago". What you describe cannot be done with LLVM or GCC TODAY.

I call Male Cow Excrement.

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

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/

or Boost.

Boost cannot enforce type safety and especially does nothing to ensure MT memory safety.

“… no multithreading race condition safety assurance in C++, whatsoever.”

Not true. At all. Not in the least little bit

how ?

There’s a whole lump of the standard library dedicated to providing all the stuff you need to handle multithreaded code and the synchronisation mechanisms that operate between them

Sappeur ENFORCES that multithreaded data structures are protected by Mutexes. In C++ you can easily create a thread-shared variable and forget the mutex to protect this variable. Nasty heap errors will likely result.

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 ?

So it can never achieve the efficiency and realtime capabiities of an imperative language ?

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.

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

...for this reasonable and kind comment.

Use these languages: trust us they're safe.

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.

..Unix was the wrong turn, we should have gone the Algol Mainframe way instead !

As far as I know there are only two kinds of checks and you've listed them in your post. Are you advocating for no checks at all or some top secret unknown check no-one else knows about?

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.

You confuse Memory Leaks with Memory Safety. Please educate yourself. It is about stopping memory corruption and Virus Injection.

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

..always helps to stay in the darkness of ignorance. You use it with an additional tinfoil hat.

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.

[1]https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html

So yes, "Crap unsafe software can be written in any language"

[1] https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html

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

{

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;

}

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

My browser will not navigate to that because it is insecure.

Oh yeah, unsafe because not using 400Kloc of OpenSSL niceness ?

Larry worked for NASA, not the NSA. there's a bigger difference than the single letter would imply.

Apparently, he worked for BOTH NSA and NASA

https://blog.techno-z.at/larry-wall-i-can-do-better-i-know-how-to-write-a-computer-language/

Perl clearly is an NSA thing (agile extraction of needles from a haystack) as opposed to NASA (numerics).

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.

But how does memory safety reduce phishing attacks, DDOS or plain old hard-coded passwords?

Can we get our priorities right?

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.

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

"You can negotiate with a terrorist, but not with a computer guy".

Seriously, you should discover that there is more than just black and white. Real technology progress is about gradual change as opposed to ideological purity.

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