News White House urges developers to avoid C and C++, use 'memory-safe' programming languages

[bit_user]

I'll never give up C. Malloc() and free() and I have been best buddies for decades... Stop blaming the language. It's the people that are the problem. KISS Principle rules!

The tool matters. It's more effort and more error-prone to manually ensure your malloc's and free's are always matched 1:1, that you always initialize your data before use, clear your stale pointers, and we haven't even gotten to bounds overruns.

In my opinion, the worst thing about C is the poor support it provides for writing generic, reusable data structures and algorithms. The result is programmers continually reinventing the wheel, but nearly always doing a substandard job of it. Due to laziness and/or ignorance, C programs often utilize inferior algorithms, inferior/buggy implementations, or (often) both. This makes it even harder & more laborious to use well - at least for anything serious.

Uh... C and C++ can be "memory safe" if you program like that.

No, C really isn't a memory-safe language. The only way C++ even gets close to being memory-safe is through of good style, which includes rigorous use of standard library facilities designed to improve memory safety.

 

[bit_user]

Even if there was a security vulnerability exploited it was there because someone didn't apply a patch.

But why was the patch even needed? If you can reduce the number of vulnerabilities (i.e. by improving software quality), you reduce the number of patches that might fail to get applied.

instead they are trying to solve the problem through engineering. I say -- good luck with that.

There's no silver bullet that can solve all security problems. What's needed is an "all of the above" approach.

 

[SunMaster]

MCSE - Must Consult Someone Experieenced - the influx of clueless consultants.

I'll dangle my pointer wherever i want 🙂

 

[bit_user]

Oh, delicious irony!

The forum just threw an error at me, in the form of a banner at the top of the window. Upon refreshing the page, I saw only:

"An unexpected database error occurred. Please try again later. "
​

Nice.

 

[SunMaster]

C had a good 55-year run, but I think the writing is on the wall. Many of the more serious C stalwarts are starting to embrace Rust. There are apparently few contexts Rust can't scale down to fit, including microcontrollers.

The death of C has been predicted "anytime soon" for the last 20 years. It's not happening in my lifetime. It's too fundamental, both as a tool and learning how computers actually work.

 

[SunMaster]

Rust. That's literally what they're saying without saying it. "Memory Safe", "Close(r) to the kernel". There's literally only one language that fits that description.

Pretty cool Rust itself is written in C.

 

[bit_user]

The death of C has been predicted "anytime soon" for the last 20 years. It's not happening in my lifetime. It's too fundamental, both as a tool and learning how computers actually work.

I don't think it'll die off, entirely. However, I do think it'll get pushed out of most major projects where it's still being used.

Pretty cool Rust itself is written in C.

This gets at an interesting philosophical discussion. At some level, you need to be able to bootstrap your development toolchain.

Anyway, that doesn't invalidate any claims about the merits of Rust over C. Nobody is saying it's impossible to use C correctly - just hard. Therefore, the more you can restrict its use, the less exposed you are to its many pitfalls and downsides.

Also, GCC now has a Rust frontend. GCC is written in C++, FWIW.

 

[bit_user]

Regardless of code used, it will access memory. I fail to see after reading the article, how one programming language could be more memory safe than another.

Good question. We should be clear about what constitutes memory safety.

Here are some bits I scraped off the wikipedia page:

Memory safety is the state of being protected from various software bugs and security vulnerabilities when dealing with memory access, such as buffer overflows and dangling pointers.
...
Many different types of memory errors can occur:

• Access errors: invalid read/write of a pointer
  • Buffer overflow – out-of-bound writes can corrupt the content of adjacent objects, or internal data (like bookkeeping information for the heap) or return addresses.
  • Buffer over-read – out-of-bound reads can reveal sensitive data or help attackers bypass address space layout randomization.
  • Race condition – concurrent reads/writes to shared memory
  • Invalid page fault – accessing a pointer outside the virtual memory space. A null pointer dereference will often cause an exception or program termination in most environments, but can cause corruption in operating system kernels or systems without memory protection, or when use of the null pointer involves a large or negative offset.
  • Use after free – dereferencing a dangling pointer storing the address of an object that has been deleted.
• Uninitialized variables– a variable that has not been assigned a value is used. It may contain an undesired or, in some languages, a corrupt value.
  • Null pointer dereference – dereferencing an invalid pointer or a pointer to memory that has not been allocated
  • Wild pointers arise when a pointer is used prior to initialization to some known state. They show the same erratic behaviour as dangling pointers, though they are less likely to stay undetected.
• Memory leak– when memory usage is not tracked or is tracked incorrectly
  • Stack exhaustion – occurs when a program runs out of stack space, typically because of too deep recursion. A guard page typically halts the program, preventing memory corruption, but functions with large stack frames may bypass the page.
  • Heap exhaustion – the program tries to allocate more memory than the amount available. In some languages, this condition must be checked for manually after each allocation.
  • Double free – repeated calls to free may prematurely free a new object at the same address. If the exact address has not been reused, other corruption may occur, especially in allocators that use free lists.
  • Invalid free – passing an invalid address to free can corrupt the heap.
  • Mismatched free – when multiple allocators are in use, attempting to free memory with a deallocation function of a different allocator[26]
  • Unwanted aliasing – when the same memory location is allocated and modified twice for unrelated purposes.

The page also discusses various approaches to providing/improving memory safety, for those interested in the subject.

 

[baboma]

>Alternatively, you could just hire developers that are aware of and care about memory utilization. I'm aware those skills are very expensive and hard to find. They do exist in older workers.

Your comment gave me a chuckle. No offense. Yes, all businesses need to do is to hire experienced and expensive developers. That sounds nice in theory, but it's rooted in wish fulfillment fantasy. It's like saying that all we need to resolve conflicts is to learn to love thy neighbor.


>So the US government is considered responsible and their response is to offer a recommendation? Sounds like a slow news day for cybersecurity, government, and conspiracy theories. That is just about as run-of-the-mill as it gets.

For TomHW, most days are slow news days, since PC hardware news are far between. Clickbait pieces like this are sadly the norm, with the resident regulars only too eager to jump on and demonstrate their faux outrage, whether that's bad govt or greedy companies or whatever scapegoats being served up.

I mean, I understand the logic of the setup. THW needs clicks for its livelihood, and this is the best they can muster. I also get why forum venting is an online pasttime. It's a given that the noise level is always high.

 

[Rob1C]

So, they aren't recommending GNAT, Spark, or ADA.

I've written a lot of code in Assembly and C, back in the days when you saved your work on Cassette tape; you learn not to make mistakes, check your code, and check again; before running and testing.

The list sounds like it was made by a different (lazier) crowd; there's a dozen other great languages left off that list that offer more than just memory safety (and a short list of other benefits). Though there are also a few good suggestions there, it's too much of a mixed bag.

 

[35below0]

I mean, I understand the logic of the setup. THW needs clicks for its livelihood, and this is the best they can muster. I also get why forum venting is an online pasttime. It's a given that the noise level is always high.

I wasn't really knocking THW, just commenting that a fairly straightforward WH recommendation based on a think-tank report is dull news. Relevant and important just, you know. A "water still wet, experts find!" type of headline.

 

[qwertymac93]

Government-"you should use a memory safe language like Java to avoid vulnerabilities."
Also Government-"We bring this up because that Java exploit called log4shell was like, really bad mkay?"
🤔

Rust seems like a really good option, but it just isn't catching on all that quickly.

 

[baboma]

>I wasn't really knocking THW

I wasn't either. "Clickbait" has a negative connotation, but I understand the necessity of it for ad-supported sites. It's a necessary trade-off for free.

>just commenting that a fairly straightforward WH recommendation based on a think-tank report is dull news. Relevant and important just, you know. A "water still wet, experts find!" type of headline.

I don't think a lot of thought goes into the "relevant and important" criteria, but more of "what can get the most clicks with the least amount of effort (commensurate to the low payout)." Again, that's not a knock on THW personnel, but a realistic take of clickbait's goal.

Sure, I'd like to get more relevant tech news, like the impending release of Stable Diffusion 3 and how it fares against SD XL, etc. But I understand THW's constraints, and there are other outlets for tech news that I frequent.

Regardless, it's all good. THW gets the necessary revenue to stay afloat (hopefully), and people here get an excuse to rant at "The Man" or "Big Evil Company". It works out.

 

[coolestcarl]

I'm sorry "the NSA recommends C#" just makes me crack up. A language specifically designed for the "holey" Windows is hardly a ringing endorsement. It just makes me think they must have keys to the kingdom for closed source code on any Windows environment. Its not the first time that they have endorsed something they already have the keys for. Just ask the "neutral" Swiss and the whole cryptographic scam that enabled us to listen to the private conversations of the Soviets and our European allies for the better part of a decade. Any 3 letter agency is almost certainly serving its own interest first. Want good security? Follow good practice and hire people that have more than a 6 week certification. The certification industry is the biggest scam here.

 

[bit_user]

I'm sorry "the NSA recommends C#" just makes me crack up. A language specifically designed for the "holey" Windows is hardly a ringing endorsement.

C# on Linux, Android, and iOS is a thing. Simply recommending C# doesn't imply recommending Windows.

 

[digitalgriffin]

Biden administration urges developers to use memory-safe programming languages to safeguard against future cybersecurity incidents

White House urges developers to avoid C and C++, use 'memory-safe' programming languages : Read more

I can crash a system with Rust, Java, and .NET almost as fast. And they are less performance in memory intense apps.

 

[digitalgriffin]

I agree on the cloud skepticism. I am not a cloud guy.

Cloud is good if you need

24/7 world wide redudancy
Instant scaling with more instances (kubernetes)
Guaranteed backups

But I always said that once they find a way to compromise ring 0 on a cloud machine, you are compromised. Nothing is safe. And as it is today you can compromise ring 0 with a number of exploits that exploit hardware design flaws.

And Microsoft just had a breach with their tenant id system (oauth). That's keys to the kingdom.

 

[bit_user]

I can crash a system with Rust, Java, and .NET almost as fast. And they are less performance in memory intense apps.

There are big differences between Rust and the others. For one thing, Rust is not garbage-collected. Also, Rust is designed to maximize the amount of safety guarantees that take place at compile-time (i.e. don't incur runtime overhead). Consequently, Rust can approach C in runtime performance.

This is perhaps why it ultimately won over the Linux kernel developers. Rust is now used in select Linux device drivers, with ongoing exploration into using it in the kernel, more broadly.

 

[Maxonone]

This isssue is a non-starter. Jensen Huang spoke and we now know we won't be doing any coding anyways, memory-safe or otherwise.
That said, I am really looking forward to more coding recommendations from people with a lot of experience in the area such as no doubt the White House. Avoid infinite while loops. Do not run out of memory in your program. Do not use pointers.
I advise COBOL. Safest language ever ;-)

 

[digitalgriffin]

This isssue is a non-starter. Jensen Huang spoke and we now know we won't be doing any coding anyways, memory-safe or otherwise.
That said, I am really looking forward to more coding recommendations from people with a lot of experience in the area such as no doubt the White House. Avoid infinite while loops. Do not run out of memory in your program. Do not use pointers.
I advise COBOL. Safest language ever ;-)

I banish thee to the land of Mainframe FORTRAN 66 and punch cards. May you forever drop your box.

 

[Atom Symbol]

Regardless of code used, it will access memory. I fail to see after reading the article, how one programming language could be more memory safe than another.

Turing-completeness of a programming language (PL) is unrelated to memory safety of the PL. In other words: memory safety is an extra feature on top of Turing-completeness.

 

[snemarch]

I grew up with assembly, C and C++. I still have a soft spot for C++, even if my relationship with the language is Stockholm Syndrome'ish.

But we really should stop using C/C++ for new development – both of them are too hard to use correctly; memory safety is one issue, the big bunch of unsafe standard library functionality another, and the truckload of undefined behaviour (which compilers depend heavily on in order to generated optimized output) is yet another.

I probably wouldn't want to work with a person who feels confident they write 100% safe C/C++ code.

Rust is probably the best bet for low-level code. For applications/services/whatever higher-level code there's several choices – where memory safety is just one parameter, performance characteristics and ecosystem quality are other balancing factors. But we really ought to stop doing any new development work in C/C++.

(We're not going to escape the legacy/heritage anytime soon, though – there's heaps of existing code that's too costly to rewrite, and works fairly well by now... and C is the lowest common denominator for glueing different languages together).

 

[Atom Symbol]

The problem isn't the language, it's the skills of the coders.

Don't hire crap coders who can't manage memory properly and who care about secure programming fundamentals.

The fact is that many software projects use 3rd party libraries. If a 3rd party library is written in a memory-safe programming language (without using any unsafe {} blocks of code) then it is guaranteed that all calls to any of the library's functions (1) won't crash the main application (SEGFAULT) and (2) won't make the main application vulnerable to memory safety exploits.

 

[Atom Symbol]

Avoid infinite while loops. Do not run out of memory in your program. Do not use pointers.

It is mathematically impossible not to have some form of pointers: Any Turing-complete programming language has at least 1 pointer because the Turing machine has a read/write head and that read/write head is a pointer. The question therefore isn't "How to completely get rid of pointers?" but is "How to make sure that dereferencing a pointer is a valid operation with well-defined semantics?".

 

[Rabohinf]

TL;DR -- As long as there are gullible people (and there will be until everyone has access to good education) humans will be the weakest link in security.

Don't deceive yourself. Even the best education will have no effect on the gullible.