Stop Coding In C and C++, Feds Say
December 2, 2024 Alex Woodie
Two federal agencies asked the IT world last month to stop developing applications in memory unsafe languages like C and C++ and to come up with roadmaps to migrate existing apps. While the security alert is unlikely to have a major impact on IBM i application development, the C family of languages does have a presence on the IBM midrange server that will be very tough to remove.
Organizations should immediately stop developing new applications written in memory unsafe languages like C and C++, the Cybersecurity and Infrastructure Security Agency (CISA) and the Federal Bureau of Investigations (FBI) warned last month. They also gave a deadline of January 1, 2026, for organizations with existing C and C++ applications to develop a roadmap for mitigating security exposures.
“The development of new product lines for use in service of critical infrastructure or NCFs [national critical functions] in a memory-unsafe language (e.g., C or C++) where there are readily available alternative memory-safe languages that could be used is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety,” CISA wrote in an October 16 report, titled “Product Security Bad Practices.”
C and C++ are considered to be memory-unsafe languages because they require developers to manually manage memory, which can lead to mistakes.
This isn’t the first time that memory safety has come up in the federal government. In February, the White House Office of the National Cyber Director (ONCD) issued a report calling for programmers to abandon C and C++ and adopt memory safe languages and techniques. It said that upwards of 70 percent of security vulnerabilities assigned a CVE [Common Vulnerabilities and Exposures] number were due to memory safety issues.
“Many of the major cybersecurity vulnerabilities over the past several decades were facilitated by memory safety vulnerabilities, including the Morris Worm of 1988, the Slammer Worm denial-of-service attack in 2003, the Heartbleed vulnerability in 2014, and the BLASTPASS exploit chain of 2023,” the ONCD wrote.
The best practice going forward is for developers to work with memory safe languages such as C#, Go, Java, Python, Rust, and Swift, the feds says. These languages automatically handle memory for the developer, which avoids the bulk of the security issues concerning memory access.
CISA encourages all software developers to take security seriously by adopting Secure by Design principles. It’s particularly concerned with people developing software used in support of critical infrastructure and NCFs.
“Software manufacturers should build products in a manner that systematically prevents the introduction of memory safety vulnerabilities, such as by using a memory safe language or hardware capabilities that prevent memory safety vulnerabilities,” it writes.
The agency has set a deadline of January 1, 2026, for organizations to create and publish roadmaps that show how they’re going to “eliminate memory safety vulnerabilities in priority code components, e.g., network-facing code or code that handles sensitive functions like cryptographic operations.” The deadline doesn’t apply to products that have an end-of-support date before January 1, 2030.
While C/C++ is by no means widely used in the IBM i community, there is a consistent set of developers who use it. Nine percent of IBM i shops surveyed by Fortra for its 2024 IBM i Marketplace Survey say they use C++, compared to 11 percent in 2023 and 8 percent in 2022. For comparison’s sake, the inaugural 2016 Marketplace report had 15.6 percent of users saying they used C++.
It’s unclear if the memory safety issues of C and C++ impact IBM i like they do other platforms. IBM i and the system innards (SLIC) do not allow programmers to manipulate memory the way other platforms do. Memory and storage, of course, are treated as a single unit (single level storage), and allocations are handled automatically by the system, not the programmer. There are also protections in place to prevent unauthorized code from running.
One of the midrange adherents to C is Chris Hird, the owner of Shield Advanced Solutions, the developer of high availability, message monitoring, and other utilities for the IBM i server. Hird has been developing C/C++ on the IBM midrange server for more than 30 years, and he doesn’t plan to stop anytime soon.
One of the problems with the call to end C/C++ development is that, in many instances, there are no alternatives, Hird says. For instance, many operating systems, including the IBM i operating system and relational database, sport large amounts of C code. “That may be why it’s so good and fast (and safe?)” he asks.
However, Hird acknowledges that the power of C/C++ can be a double-edged sword. The capability to use pointers for memory management gives developers incredible power, but used incorrectly, they can also lead to unintended consequences, he says. The solution to that is to pay close attention and test thoroughly, he says.
“C is not an unsafe language. The programmers make it unsafe by coding badly ( mostly unintentionally,” he tells IT Jungle. “Coding is an art. We can all write unsafe code in any language but the hope is that testing and coding practices reduce that to a minimum.”
Hird doesn’t intend to stop developing Shield’s products in C, which he says is “the best tool for the job.” “We have looked at alternative languages and tested them against a C based solution,” he says. “But we have not found an alternative so far which provides the same performance and capabilities as C.”
The Feds warning will undoubtedly put a damper on C and C++ development, at least for user-facing applications. While the Microsoft languages are heralded by programmers for their unparalleled low-level access, it is exactly that capability to manipulate data access at a very low level that can create problems, when done poorly.
As far as the migration of the world’s existing C and C++ code into C#, Go, Java, Python, Rust, or Swift, it doesn’t seem likely that it will be done anytime soon. Organizations have been trying for decades to get out from under aging RPG and COBOL applications running on the IBM midrange and mainframe servers, and quite little progress has been made.
Perhaps this new call to modernize C and C++ apps will create a new appreciation and new tools and techniques that will also benefit the IBM i and System Z shops that are stuck with aged, undocumented, and unsupported code.
RELATED STORIES
What New Language Will IBM i Support Next?
