The Joke on Someone in Nebraska

This joke is part of xkcd, a webcomic created by the American cartoonist, engineer, and writer Randall Munroe. What the author is trying to show here is the dependency between elements in an overall digital system or architecture represented as a tower of blocks —like a Jenga— that symbolize software components. Thus, as we move up from the tower's bottom, the higher-level components depend on more and more lower-level components.

Actually, it's not that our systems depend on what a specific individual in Nebraska is doing. What this joke —at the same time alarm— seems to be aiming at is to give an example of a general reality that we have been experiencing for many years: various programs or software components, some of them small, maintained mainly due to personal reasons by one or a few non-famous or unsung people, anywhere in the world, support a lot of our current digital infrastructure.

While Randall's cartoon depicts the aforementioned reality, when we review its caption, we can read the following: "Someday ImageMagick will finally break for good and we'll have a long period of scrambling as we try to reassemble civilization from the rubble." This is a specific example, perhaps exaggerated but illustrative. ImageMagick is a free and open-source software for processing, creating, displaying, editing and converting raster images, created back in 1987 by John Cristy, which has been and is widely used in various applications, especially those intended for web services, and to which communities of engineers and developers have contributed over time.

Although many other libraries and APIs can perform ImageMagick's tasks, this one seems to have become the default package. The problem with this library is that, back in 2016, five vulnerabilities were discovered in it (which ended up carrying the name "ImageTragick"), one of which, when exploited, would allow remote code execution (RCE). This finding set off alarm bells among engineers and developers, signifying a high potential risk since if ImageMagick were to break down, lots of programs depending on it would fail, at least temporarily, showing an imbalance and collapse in "the tower."

Nowadays, many of us know, although many more are probably unaware of it, that the smallest and largest companies and organizations around the world are using open-source software components from third parties. Almost all existing software depends on such products developed and maintained by individuals and communities of developers. But why?

One of the main reasons is the now typical proverb, "Don't reinvent the wheel." That is, if that human work was already functional enough, don't waste your time and go on to build something new. In the software universe, many people create and share code publicly and for free, which fulfills specific functions, some of which are very basic. So, others don't have to build their applications from scratch; they don't need to develop all the components of their products. They simply resort to what has already been created and shared by the community, which allows for cheaper, simpler and more efficient technological development.

In other words, here we are talking about reuse and modularity, principles that have been used for a long time but are fundamental today in software engineering. So, when a group of developers aims to create an application, they end up building a chain or dependency tree with multiple open-source software components previously developed separately by other engineers, some of them only a few lines of code that fulfill specific functions.

The problem, as Randall illustrated, is that many of these open-source software component projects that are fundamental to large-scale projects are often maintained by very few people. Unlike large enterprises like Linux, for example, many other projects don't get enough attention. Those who preserve them are usually experts in them who often work too much and for little or no money, mainly as a hobby, and on whom all the responsibility falls. However, for reasons such as weariness or finding better opportunities, some of these projects may be abandoned. This drawback, together with the security vulnerabilities that may be present, often means a considerable risk to the integrity and security of "the whole system."

In addition to the ImageMagick case, other illustrative cases of this worrying problem have been, for example, those of Heartbleed and left-pad. Heartbleed is a bug discovered in 2014 in OpenSSL, a library that enables encrypted communications over the Internet, for instance, for e-commerce. This one, unlike others, is a relatively large software component since, by that time, it had around 500 thousand lines of code. As reported on a simple website dedicated to this vulnerability, it allowed "stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet."

Apparently, this case qualified as irresponsibility on the part of the OpenSSL team because they had previously known a latent problem that they didn't pay enough attention to. It took about two years to detect Heartbleed. The worst thing is that, seemingly, the maintenance of the affected component depended only on two guys, both volunteers and overworked. It is said that, despite what happened, donations for this project grew very little, from around $2,000 to $9,000 a year. (This underfunding is something prevalent in open-source software development history and something we wish to emphasize in a future blog post).

For a similar, more recent case, see Log4j, an Apache's open-source library in which a vulnerability was discovered that allowed remote attackers to execute arbitrary code on exposed systems.

Regarding left-pad, it turns out that a young man named Azer Koçulu had been developing code for npm, a well-known and widely used web development service for finding and installing open-source software packages written in JavaScript. When npm, in an imbroglio not worth mentioning here, apparently acted against the basic principles of open-source culture regarding a package Koçulu had been working on, he chose to abandon it, specifically delete it, back in 2016, which led to a meltdown among many projects and websites dependent on it.

Everyone working on all components of their own software products? That's not viable. What seems more feasible at the moment is to keep the open-source culture intact but contribute to its maintenance and security to a greater extent. As many have already said, why don't the big companies of the capitalist system that depend on these public and free projects contribute to their financing or in some other way? Where is the institutional and governmental support? All this is still insufficient.

Apart from raising awareness of this situation, seeking to minimize ignorance about it, and looking for funding for projects on which we all depend, many companies from different industrial sectors can also contribute to the security of our digital infrastructure. Attention! The fact that we don't have to reinvent the wheel doesn't mean we should overlook it. Can we not learn about it? While we don't have to develop the third-party software components we use in our products, we should know about them, review them, update them, improve them.

Here's where the much-talked-about software bill of materials (SBOM) comes into play. Employ it as an organized inventory of all third-party components used by your application. From there, discard those packages that are unnecessary, request a security vulnerability assessment on the rest, and, if possible, contribute with review, code or funds, especially to those software components that perform a critical role in keeping your company alive.

If you want to learn how Fluid Attacks can help you with SBOM, software composition analysis (SCA), and more security testing, feel free to contact us.