DeepSec 2024 Press Release: Choice of programming language does not determine IT security. NSA warns of memory errors while ignoring the majority of other security vulnerabilities
Memory image of a compressed programme (Image: 2024, DeepSec GmbH)
There are over 900 clearly classified defects in software applications. Some of these are because of memory errors, where code accesses memory areas incorrectly and subsequent errors can lead to crashes or other effects. In 2022, the US National Security Agency (NSA) warned against using the programming languages C and C++ to avoid memory errors. The recommendation is to use other programming languages that prevent these errors. This recommendation ignores reality, as these problems can no longer occur in modern, correct C++ code because of the language specification. Furthermore, the NSA’s proposal ignores existing code that is well tested and ready for production, and much more dangerous defects that are still possible in all programming languages.
Modern C++
Bjarne Stroustrup published the C++ programming language back in 1978, and it has continued to evolve ever since. Beginning in 2011, language specifications have been defined every three years. The C++11 standard from 2011 also marks the beginning of modern C++, as gaps in the language definition have been eliminated. If all elements of the C++14 and later standards are used, correct C++ code has neither memory errors nor indeterminate behaviour. This may sound arrogant, but all programming languages have a language definition that defines how the code behaves. The only difference between C++ and other languages are the minimal checks in the runtime environment, because the compilers do not build in any implicit, and therefore invisible, mechanisms. However, some of the programming languages proposed by the NSA have a special unsafe mode that can prevent checks during execution. Such methods are often used for special problems or system programming.
Code with security vulnerabilities rarely adheres to specifications. The reasons for this may be the age of the code or a lack of knowledge of the programming language in relation to security. Old code in particular usually has to be adapted to modern language standards. If this is not done, defects are dragged along hidden. This problem can be found in all applications of a certain size and gets worse over time. Software development must always take these weaknesses into account.
Many other error classes as a danger
Insecure code can be implemented in any programming language. The Open Web Application Security Project (OWASP) compiles a list of the most common errors in web applications irregularly. This list does not include the memory errors invoked by the NSA. Instead, missing access restrictions and injection attacks are the greatest dangers. The underlying error classifications are often associated with missing or incorrect checks of data that a client sends to the web server. In contrast to faulty memory accesses, these defects are in line with the specifications of the programming languages used. Switching to other programming languages, therefore, does not bring the hoped-for benefits in terms of security. Ultimately, a lack of basic understanding of secure programming concepts and carelessness will bring down an application. If improvements are to be made here, a much more fundamental approach must be taken.
The concepts of secure coding and secure design can be applied equally to all programming languages. There are no development tools that can reliably and completely detect and point out programming errors. The cause is always a lack of cognitive processes, because tools do not think. This applies in particular to the algorithms currently marketed as ‘artificial intelligence’. Simulations and tests can help, but ultimately they are also devised by developers and do not think like attackers. Secure coding and secure design also specify principles that need to be implemented in the respective ecosystem of the development environment. Not all of this can be automated.
Old code is not necessarily unsafe
In media that write about software development, you often read about the ‘programming language of the week’. It is advertised very much like a seasonal cooking recipe. Depending on your mood and the time of year, you are supposed to learn a specific language and write all your code in it from then on. This approach completely misses the point, as software development generally tries to avoid constantly rewriting code. Once problems have been solved, they are collected in libraries or modules so that you can fall back on well-tested code. Therefore, old code is not automatically unsafe. It depends on how it was developed or tested and whether support and security updates are still available. Code that is frequently changed or rewritten poses a major risk.
This statement also applies to standard libraries that are part of a programming language. With young languages in particular, you can see from the published security defects that existing solutions are being re-implemented and thus start again at the beginning of development. This effect can even be seen in programming languages that are advertised as secure, such as Rust. Switching to a new development environment must therefore be carefully considered.
Secure coding and design
At this year’s DeepSec conference, sematicon AG and DeepSec will jointly illustrate how to start, improve and continuously implement secure design and secure coding in your own software development process. There will be presentations and discussions giving examples from productive environments. IT and OT systems will be covered in terms of technology. sematicon AG will also contribute specialised knowledge from the development of embedded systems. These contributions will take place in the technical lecture series, which is not available as a stream and will not be recorded.
Programme and booking
The DeepSec 2024 conference days are on 21 and 22 November. The DeepSec training sessions will take place on the two preceding days, 19 and 20 November. All training sessions (with announced exceptions) and presentations are intended as face-to-face events, but can be held partially or completely virtually if necessary. For registered participants there will be a stream of the presentations on our internet platform.
The DeepINTEL Security Intelligence Conference will take place on 20 November. As this is a closed event, please send direct enquiries about the programme to our contact addresses. We provide strong end-to-end encryption for communication: https://deepsec.net/contact.html
Tickets for the DeepSec conference and training sessions can be ordered online at any time via the link https://deepsec.net/register.html. Discount codes from sponsors are available. If you are interested, please contact deepsec@deepsec.net. Please note that we depend on timely ticket orders because of planning security.