Secure Design – Opinion – Page 3 – Secure Software doesn't develop itself.

Please stop anthropomorphising Algorithms

On August 18, 2023

If you read the news, the articles are full of hype for the new Large Language Models (LLMs). People do amazing and stupid things by chatting with these algorithms. The problem is that LLMs are just algorithms. They have been „trained“ with large amounts of data, hence the first „L“. There is no personality or cognitive process involved. Keep the following properties in mind when using these algorithms.

LLMs stem from the field of artificial intelligence, which is a field of computer science.
LLMs perform no cognitive work. The algorithms do not think, they just remix, filter, and repeat. They can’t create anything new better than a random generator and a Markov chain of sufficiently high order.
LLMs have no opinion.
LLMs feature in-built hallucinations. This means the algorithms can lie. Any of the current (and possibly future models of the same kind) will generate nonsense at some point.
LLMs can be manipulated by conversation (by using variations of prompts).
LLMs are highly biased, because their training data lacks different perspectives (given their size and cultural background of the data, especially languages used for training).
LLMs can’t be debugged reliably. Most fixes to problems comprise input or output filters. Essentially, these filters are allow or block lists. This is the weakest form of using filters for protection.

So there are a lot of arguments for not treating LLMs as something with a opinion, personality, or intelligence. These models can mimick language. When training, they always learn language patterns. Yes, LLMs belong to the research field of artificial intelligence, but there is no thinking going on. The label „AI“ doesn’t describe what the algorithm is doing. This is not news. Emily Bender published an article titled „Look behind the curtain: Don’t be dazzled by claims of ‘artificial intelligence’“ in the Seattle Times in May 2022. Furthermore, there is a publication from Emily Bender, Timnit Gebru, Angelina McMillan-Major, and Shmargaret Shmitchell. Its title is „On the Dangers of Stochastic Parrots: Can Language Models Be Too Big?“. The publication date is March 2021. They published both articles way before the „new“ chat algorithms and LLM-powered „search engines“ hit the marketing departments. You have been warned.

So, this article is not meant to discourage anyone from exploring LLMs. You just need to be careful. Remember that algorithms are seldom a silver bullet that can solve all your problems or make them go away. This is especially true if you want to use LLMs for your software development cycle.

Update: If you really want to explore the uses of synthetic text generation, please watch the presentation “ChatGP-why: When, if ever, is synthetic text safe, appropriate, and desirable?” by Emily Bender.

Continuous Integration is no excuse for a complex Build System

By René Pfeiffer

On May 25, 2023

In Development, Testing

Continuous Integration (CI) is a standard in software development. A lot of companies use it for their development process. It basically means using automation tools to test new code more frequently. Instead of continuous, you can also use the word automated, because CI can’t work manually. Modern build systems comprise scripts and descriptive configurations that invoke components of the toolchain in order to produce executable code. Applications build with different programming languages can invoke a lot of tools with individual configurations. The build system is also a part of the code development process. What does this mean for CI in terms of secure coding?

First, if you use CI methods in your development cycle, then make sure you understand the build system. When working with external consultants that audit your code, the review must be possible without the CI pipeline. In theory, this is always the case, but I have seen code collections that cannot be built easily, because of the many configuration parameters hidden in hundreds of directories. Some configuration is old and use environment variables to control how the toolchain has to translate the source. Especially cross-platform code is difficult to analyse because of the mixture of tools. Often it is only possible to study the source. This is a problem, because a code review also needs to rebuild the code with changing parameters (for example, changing compiler flags, replacing compilers, adding analyzers, etc.). If the build process doesn’t allow this, then you have a problem. This makes switching to different tools impossible, which is also necessary when you need to test new versions of your programming language or need to migrate old parts of your code to a newer standard.

Furthermore, if your code cannot be built outside your CI pipeline, then reviews are basically impossible. Just reading the source means that a lot of testing cannot be done. Ensure that your build systems do not grow into a complex creation no one wants to touch any more. The rules of secure and clean coding also apply to your CI pipeline. Create individual packages. Divide the build into modules, so that you can assemble the final application from independent building blocks. Also, refactor your build configuration. Make is simpler and remove all workarounds. Once the review gets stuck and auditors have to read your code like the newspaper, it is too late.

Using AI Language Models for Code Creation

By René Pfeiffer

On May 15, 2023

In Development

The trend of large language models (LLMs) continues. Many people are doing experiments and explore how these algorithms can help them when developing software. Most integrated development environments have features that help you while writing code. Access to documentation, function call parameters, static checks, and suggestions are standard tools to help you. LLMs are the new kid on the block. Some articles describe how questions (or prompts) to chat engines were used to create code samples. The output depends a lot on the prompt. Changing words or rephrasing the prompt can lead to different results. This differs from the way other tools work. Getting useful results means to play with the prompt and engage in trial-and-error cycles. Algorithms such as ChatGPT are not sentient. They cannot think. The algorithm just remixes and repeats part of its training data. Asking for code examples is probably most useful for getting templates or single functions. This use case is disappointingly close to browsing tutorials or Stackoverflow.

Designing prompts is a new skill artificially created by LLMs algorithms. This is another problem, because you now need to collect prompts for creating the most useful code. The work shifts to another domain, but you don’t actually save time unless you have a compendium of prompts. Creating useful and well-tested templates is a better use of resources. The correct of of patterns governs code creating with or without LLMs.

The security questions have not been addressed yet. There are studies that analyse how the code quality of tool- and human-generated code looks like. According to the Open Source Security and Risk Analysis (OSSRA) report from 2022, the code created by assistant features contained vulnerabilities 40% of the time. An examination of code created by Github’s Copilot shows that autogenerated code contains bugs that belong to specific software weaknesses. The code created by humans has a distinct pattern of weaknesses. A more detailed analysis can only be done by larger statistical samples, because Copilot’s training data is proprietary and not accessible. There is room for more research, but it is safe to say that LLMs also make mistakes. Output from these algorithms must be included in the quality assurance cycle, with no exceptions. Code generators cannot work magic.

If you are interested in using LLMs for code creation, make sure that you understand the implications. Developing safe and useful templates is a better way than to engineer prompts for the best code output. Furthermore, the output can change whenever the LLM changes its version or training data. Using algorithms to create code is not a novel approach. Your toolchains most probably already contain code generators. In either case, you absolutely have to understand how they work. This is not something an AI algorithm can replace. The best approach is to study the code suggested by the algorithm, transfer it into pseudo-code, and write the actual code yourself. Avoid cut & paste, otherwise your introduce more bugs to fix later.

Presentation Supply Chain Attacks and Software Manifests

By René Pfeiffer

On April 22, 2023

In Development, Security

Today I held a presentation about supply chain attacks and software manifests. The content covers my experience with exploring standards for Software Bill of Materials (SBOMs). While most build systems support creating the manifests, the first step is to identify what components you use and where they come from. Typical software projects will use a mixture of sources such as packet managers from programming languages, operating systems, and direct downloads from software repositories. It is important to focus on the components your code directly relies on. Supporting applications that manage a database or host application programming interfaces (APIs) are a requirement, but usually not part of your software.

The presentation can be found by using this link. The slides are in German, but you will find plenty of links to sources in English.

Error message “undefined reference to `Mcuda_compiled’ in nvhpc”

By René Pfeiffer

On April 3, 2023

In C/C++

Using different compilers for either production or testing purposes can be challenging. While the GNU Compiler Collection is the standard on GNU/Linux system, using more than one compiler toolchain helps to identify bugs in the code. The project I am working on uses the Clang compiler. I added command-line options for NVIDIA’s nvc and nvc++ from the high-performance compiler collection. The first compilations runs yielded the error message “undefined reference to `Mcuda_compiled'” during the linker phase. Inspecting the object files and the libraries did not help. Several libraries define the Mcuda_compiled symbol. The key is to use consistent -M options across compiler and linker. The compiler uses the optimizer flags -Mcuda -Mvect. Adding the same options to the linker phase solves the problem. Inspecting the output of ldd shows that the library libcudanvhpc.so contains the symbol.

Creating Software Bill of Materials (SBOM) for your Code

By René Pfeiffer

On March 21, 2023

In Development

All software comprises components. Given the prevalence of supply chain attacks against modules and libraries, it is important to know what parts your code uses. This is where the Software Bill of Materials (SBOM) comes into play. A SBOM is a list of all components your code relies on. So much for the theory, because what is a component? Do you count all the header files of C/C++ as individual components or just as parts of the library? Is it just the run-time environment or do you also list the moving parts you used to create the final application? The latter includes all tools working in intermediate processes. A good choice is to focus on the application in its deployment state.

How do you get all the components used in the run-time version of your application? The build process is the first source you need to query. The details depend on the build tool you use. You need to extract the version, the source of the packaged component (this can be a link on the download source or a package URL), the name of of component, and hashes of either the files or the component itself. If you inspect the CycloneDX or SPDX specifications, then you will find that there are a lot more data fields specified. You can group components, name authors, add a description, complex distributions processes, generic properties, and more details. The build systems and package managers do not provide easy access to all information. The complete view requires using the original source for the component, the operating system, and external data sources (for example, the CPE or links to published vulnerabilities). Don’t get distracted by the sheer amount of information that can be included in your manifest. Focus on the relevant and easy to get data about your components.

Hashes of your components are important. When focussing on the run-time of your application, make sure you identify all parts of it. To give an example of C/C++ code, you can identify all libraries your applications load dynamically. Then calculate the hashes of the libraries on the target platform. SBOMs can be different for various target platforms. If you use containers, then you can fix the components. Linking dynamically against libraries means that your code will use different incarnations on different systems. Make sure that you calculate more than one hash for your manifest. MD5 and SHA-1 are legacy algorithms. Do not use them. Instead, use SHA-2 with 256 bit or more and one hash of the SHA-3 family. This guards against hash collisions, because SHA-3 is not prone to content appending attacks.

Recommendations for using Exceptions in Code

By René Pfeiffer

On February 22, 2023

In C/C++

Exceptions can be useful for handling error conditions. They are suited for better structuring code and avoiding if/else cascades. However, exceptions can disturb the control flow and can make your program skip sections of your code. Cleaning up after errors and the management of resources can be affected by this. Another downside is the performance if exceptions are triggered often. If you need to catch errors, you have to be careful when to use exceptions and when to use error flags. The article Exception dangers and downsides in the C++ tutorial has some hints how to use exceptions:

Use exceptions for errors that trigger infrequently.
Use exceptions for errors that are critical for the code execution (i.e. error conditions that make subsequent operations impossible).
Use exceptions when the errors cannot be handled right at the point where it occurs.
Use exceptions when returning an error code is not possible or not an option.

The actual cost for exceptions is influenced by the compiler, the hardware, and the operating system. There is a sign that the exception handling is improved on the x86_64 platform. Having multiple cores can pose a problem, because unwinding exceptions is a single-thread problem. This can be a problem for locked resources and similar synchronisation techniques. The proposal P2544R0 describes the background of these problems, and it proposes some alternatives for error handling by exceptions. The article also has some measurements that show the impact of exceptions. My recommendation is to investigate how frequent errors are and to explore handling non-critical errors by using flags or return codes. When in doubt, use the instrumentation of your compiler and measure the actual cost of exceptions.

Software Bill of Materials (SBOM)

By René Pfeiffer

On January 20, 2023

In Development

No software projects can do without components. Software libraries are the most common ingredient. Some programming languages use the concept of modules or plugins. Then there are frameworks typically used in web applications. All of these parts can feature different versions, because some requirement fixed the version to a major release. If one component exhibits a security vulnerability, then the code in question must be updated. Given the size of modern applications, this can be a challenge. Remember the Log4j vulnerability from last year. Many teams didn’t even know that they were running applications containing Log4j. Attackers know about this and target the supply chain of the code. Finding a critical bug in components can open up a wide variety of code for attacks. This is where the Software Bill of Materials (SBOM) comes into play.

SBOM is simply a list of components that your applications contains. Most teams using build tools have this already implicitly. Basically, SBOM is a standard for the manifest of components your software brings with it. The National Telecommunications and Information Administration (NTIA) has compiled a set of resources describing how to use the standard. The idea is not new. There already exists Software Package Data Exchange® (SPDX®), OWASP CycloneDX, and ISO/IEC 19770-2:2015. Everything boils down to a specification for a JSON document that contains all relevant metadata of all components. The key is to catch all the dependencies. Some libraries depend on others, so package managers can resolve these links and install additional components. Build systems do this automatically, but the SBOM needs to be complete. Another problem is the categorisation. Some parts of the code belong to the runtime, some are managed by the operating system, and others are shipped within the application itself. A full SBOM needs to combine these sources. Your toolchain can help you there. C/C++ compiler can create a list of all headers used during compilation (the Clang/GCC flags -MD and -MF name.out.d take care of it). This is just a part of the development environment. You have to create a manifest for container images and other deployment methods as well. Be as accurate as possible, and make sure that SBOM creating is an automated part of your build pipeline.

Go, Go Carbon, Go++, Carbon++, C++, or Go Rust?

By René Pfeiffer

On July 29, 2022

In Programming, Secure Coding

I break my rule of not writing titles with questions marks. The exemption is because of the new programming language, Carbon. I saw the announcement a couple of days ago. The article mentioned that Google engineers are working on a new programming language called Carbon. The author of the article added the tagline „A Hopeful Successor To C++“. The immediate question to the endeavor of creating a new programming language was: Why? There are a lot of programming languages and dialects around. All the languages have their own background. It is easy to bash a specific programming language, but if you take the history of creation into account, then it gets easier to understand why specific design choices were made. It is easy to recommend different choices in retrospect. Given the existence of Go and the periodic C++ standard updates, I wonder what the design goals of Carbon are. Luckily, the article mentioned them:

C++ performance
Seamless bidirectional interoperability with C++
Easier learning curve for C++ developers
Comparable expressivity
Scalable migration

If you read the actual Carbon language description from the repository, then there are some additional goals:

Safer fundamentals, and an incremental path towards a memory-safe subset
Language evolution (Carbon wants to be C++’s TypeScript/Kotlin)

This doesn’t look too bad. Clearly safer fundamentals and memory-safe features are a good idea. After checking some code examples, the syntax of Carbon looks a lot like Rust. For my taste, the easier learning curve is in the beholder’s eye. Personally, I dislike Rust’s syntax. Carbon adds some grammar and differences in special characters that will probably hinder anyone with C++ experience (well, at least myself). The interoperability claims that you can use your tried build system for your projects. The Carbon project clearly states that it is presenting a prototype for exploring the desired language features. Apparently, the designers want to use C++ as the foundation and add their own vision.

C++ has evolved a lot in the past decade. The new C++ standards have implemented a lot of the missing features that had to be supported by third-party libraries. Because a programming language needs time to create a stable version. Carbon will have to catch up with C++’s head start. Judging from the project vision, it seems to be yet another use case for LLVM. Let’s see if we find out the real reason why Google wants to replace C++.

Using C++ Threads or OpenMP for parallel Processing

By René Pfeiffer

On April 1, 2022

In C/C++

Having easy access to parallel processing is a pleasant feature in programming languages. The thread syscalls of operating systems have notoriously been difficult to access, especially in C. The Open Multi-Processing (OpenMP) library started in 1997 to make things easier. It helps to mark sections of parallel code and loop that can be parallelized. It works well for C, C++, and FORTRAN code. It is easy to implement. Plus, your code can be compiled with or without the OpenMP library present. The downside is that your code requires OpenMP on the target. I recently had a case where C++ code needs to be installed on different platforms (i.e. systems with different major version level). OpenMP is tied to the C/C++ standard library and the compiler. The code is compiled by Clang, so in this particular case you need different OpenMP libraries. In order to reduce the dependency on OpenMP, the code was refactored to use C++ threads.

C++11 threads are easy to use. When switching from OpenMP, you only have to convert your #pragma statements to function calls. When using member functions, you have to code around a peculiarity of std::async and std::thread. Member functions of dynamically allocated objects cannot be called directly. If you try to do this, then you will get an error message. Consider the following object:

class hash_list { private: kyotocabinet::HashDB HDB; kyotocabinet::HashDB::Cursor *pos; … public: bool walkthrough( string directory ) { … }The class is used to access different Tokyo Cabinet databases. The function walkthrough() does heavy I/O work and updates the database file. Calling the function directly with std::async will not work. I fought with many compiler errors and was tempted to convert the member function to static, but this would have required a full rewrite of the class. Static member variables and function change access to encapsuled data. Instead, you will need a wrapper function to call the members.

#ifndef USE_OPENMP bool wrap_walkthrough( hash_list *h, string d ) { return( h->walkthrough(d) ); } #endif

The function wrap_walkthrough() works fine, and it can be called with different dynamically allocated objects. The section calling the functions looks like this:

#ifndef USE_OPENMP future<bool> f_rc_path = std::async( std::launch::async, wrap_walkthrough, path_orig, opt_path ); future<bool> f_rc_prfx = std::async( std::launch::async, wrap_walkthrough, path_prefix, prefix_path ); const bool rc_path = f_rc_path.get(); const bool rc_prfx = f_rc_prfx.get(); if ( ! rc_path ) { cerr << "Walkthrough for " << opt_path << " failed!" << endl; rc += 23; } if ( ! rc_prfx ) { cerr << "Walkthrough for " << prefix_path << " failed!" << endl; rc += 23; } #endif

Remember to write wrapper functions when you encounter the error message “reference to non-static member function must be called”.