{"id":20309,"date":"2021-08-14T20:00:00","date_gmt":"2021-08-14T18:00:00","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=20309"},"modified":"2023-08-06T21:41:16","modified_gmt":"2023-08-06T19:41:16","slug":"unsafe-programming-languages","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2021\/08\/14\/unsafe-programming-languages\/","title":{"rendered":"Unsafe Languages, Inadequate Defense Mechanisms and Our Dangerous Addiction to Legacy Code"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">bugs, bugs everywhere<\/h2>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p>A recent study found that 60-70% of vulnerabilities in iOS and macOS are caused by memory unsafety. Microsoft estimates that 70% of all vulnerabilities in their products over the last decade have been caused by memory unsafety. Google estimated that 90% of Android vulnerabilities are memory unsafety. An analysis of 0-days that were discovered being exploited in the wild found that more than 80% of the exploited vulnerabilities were due to memory unsafety.<\/p>\n<cite>(<a href=\"#ref-Gaynor2019\">Gaynor, 2019<\/a>)<\/cite><\/blockquote>\n\n\n\n<p>Over the last 20 years, developing secure software has become increasingly important. To this day, we write a significant amount of code in languages with manual memory management. However, the Peter Parker principle states that \u201cgreat power comes with great responsibility\u201d. Many scoring systems classify, enumerate and rank prevalence of known vulnerabilities. In theory, developers should be aware of common programming mistakes leading to these bugs. Yet, the last 20 years are living proof that manual memory management is highly error-prone. Because most systems share memory between data and instructions, controlling small portions of memory can be enough to take over entire systems (<a href=\"#ref-Szekeres2013\">Szekeres et al., 2013<\/a>). The fight over attacking and defending the security measures on top of unsafe systems is often called the <em>eternal war in memory<\/em>.<\/p>\n\n\n\n<p>In this blog post, I want to examine what properties make programming languages like C\/C++ fundamentally <em>unsafe<\/em> to use. After that, I briefly discuss the inadequacies of our defense mechanisms. Last of all, I reflect on the sociopolitical implications arising from the continued use of unsafe languages.<\/p>\n\n\n\n<!--more-->\n\n\n\n<h2 class=\"wp-block-heading\" id=\"toc\">table of contents<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"#bugs-bugs-everywhere\">bugs, bugs everywhere<\/a><\/li>\n\n\n\n<li><a href=\"#memory-safety\">memory-safety<\/a>\n<ul class=\"wp-block-list\">\n<li><a href=\"#spatial-safety\">spatial safety<\/a><\/li>\n\n\n\n<li><a href=\"#temporal-safety\">temporal safety<\/a><\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><a href=\"#type-safety\">type-safety<\/a><\/li>\n\n\n\n<li><a href=\"#thread-safety\">thread-safety<\/a>\n<ul class=\"wp-block-list\">\n<li><a href=\"#concurrency-bugs\">concurrency bugs<\/a><\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><a href=\"#layers-of-defense\">layers of defense<\/a>\n<ul class=\"wp-block-list\">\n<li><a href=\"#language-design\">language design<\/a><\/li>\n\n\n\n<li><a href=\"#testing-for-security\">testing for security<\/a><\/li>\n\n\n\n<li><a href=\"#operating-systems\">operating systems<\/a><\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><a href=\"#conclusion\">conclusion<\/a><\/li>\n\n\n\n<li><a href=\"#bibliography\">bibliography<\/a><\/li>\n<\/ul>\n\n\n<h2 id=\"memory-safety\">memory-safety<\/h2>\n<p>First, one must distinguish between memory-safe programs and languages. A <em>program<\/em> is considered memory-safe if all of its possible executions over all possible inputs are memory-safe <span class=\"citation\" data-cites=\"Hicks2014\">(<a href=\"#ref-Hicks2014\" role=\"doc-biblioref\">Hicks, 2014<\/a>)<\/span>. While it is possible to write memory-safe programs using unsafe languages, it is the responsibility of the programmer to ensure that no memory corruptions occur. In contrast, a memory-safe <em>language<\/em> provides guarantees that all possible programs written it are memory-safe <span class=\"citation\" data-cites=\"Hicks2014\">(<a href=\"#ref-Hicks2014\" role=\"doc-biblioref\">Hicks, 2014<\/a>)<\/span>. It can be concluded, that memory-safety is mainly about shifting responsibilities from the developer to the compiler.<\/p>\n<h3 id=\"spatial-safety\">spatial safety<\/h3>\n<p>Fundamentally, spatial safety is about respecting a program\u2019s memory layout. It demands that pointer are only used to access memory that <em>belongs<\/em> to it. <span class=\"citation\" data-cites=\"Hicks2016\">(<a href=\"#ref-Hicks2016\" role=\"doc-biblioref\">Hicks, 2016<\/a>)<\/span> illustrates the concept of <em>belonging<\/em> by viewing pointers as triples (<span class=\"math inline\">\\(p\\)<\/span>, <span class=\"math inline\">\\(b\\)<\/span>, <span class=\"math inline\">\\(e\\)<\/span>). <span class=\"math inline\">\\(p\\)<\/span> is the memory address the pointer points to. It can be in-\/ decremented using pointer arithmetic. The <span class=\"math inline\">\\(b\\)<\/span> refers to the base address of the memory region associated with the pointer. The extent <span class=\"math inline\">\\(e\\)<\/span> marks the end address of the region we are allowed to access. It is determined from the arguments passed to <code class=\"\" data-line=\"\">malloc<\/code> or <code class=\"\" data-line=\"\">sizeof<\/code>. <span class=\"math display\">\\[b &lt;= p &lt;= e-sizeof(typeof(p))\\]<\/span> Dereferencing a pointer is spatially safe as long as <span class=\"math inline\">\\(p\\)<\/span> stays within the allotted memory region <span class=\"math inline\">\\(b\\)<\/span> to <span class=\"math inline\">\\(e\\)<\/span>. If the program violates this condition, we have an out-of-bounds read\/write.<\/p>\n<h4 id=\"example-null-pointer-dereference\">example: null pointer dereference<\/h4>\n<div class=\"sourceCode\" id=\"cb1\">\n<pre class=\"sourceCode c\"><code class=\"\" data-line=\"\">&lt;span id=&quot;cb1-1&quot;&gt;&lt;a href=&quot;#cb1-1&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;span class=&quot;dt&quot;&gt;int&lt;\/span&gt; &lt;span class=&quot;op&quot;&gt;*&lt;\/span&gt;ptr &lt;span class=&quot;op&quot;&gt;=&lt;\/span&gt; NULL&lt;span class=&quot;op&quot;&gt;;&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb1-2&quot;&gt;&lt;a href=&quot;#cb1-2&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;span class=&quot;op&quot;&gt;*&lt;\/span&gt;ptr &lt;span class=&quot;op&quot;&gt;=&lt;\/span&gt; &lt;span class=&quot;dv&quot;&gt;1&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;;&lt;\/span&gt;&lt;\/span&gt;<\/code><\/pre>\n<\/div>\n<p>A null pointer is a value to indicates that a pointer does not refer to a valid object <span class=\"citation\" data-cites=\"WikiNullptr2021\">(<a href=\"#ref-WikiNullptr2021\" role=\"doc-biblioref\">Wikipedia contributors, 2021b<\/a>)<\/span>. They are typically used to represent an \u201cexceptional\u201d state. Forgetting to check for invalid pointers may result in dereferencing a null pointer. Because these pointers do not refer to a meaningful object, the C standard specifies the resulting behaviour as undefined. To avoid arbitrary and potentially damaging behavior, most operating systems map the null pointer\u2019s address to an unmapped memory location. Thereby, read\/write access results in a segmentation fault that crashes the program. Although undesirable, crashes are often the best option, as they warn developer that something went wrong and prevent further exploitation.<\/p>\n<h4 id=\"example-buffer-overflow\">example: buffer overflow<\/h4>\n<figure align=\"center\">\n<img decoding=\"async\" src=\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/08\/buffer_overflow.png\" height=\"200\"><figcaption>\nbuffer overflow<br>\n<\/figcaption><\/figure>\n<p>Every time a function is called, the operating system allocates a new stack frame in RAM. Every stack frame consists of: &#8211; a <em>memory region<\/em> for allocation of local variables &#8211; a <em>saved frame pointer<\/em> that references the memory address of the previous stack frame &#8211; a <em>return address<\/em> that specifies points to the next instruction fetched by the CPU after exiting the current function.<\/p>\n<p>One example, could be a function that takes a user input and copies it into a character buffer. To achieve maximum performance, <code class=\"\" data-line=\"\">.strcopy()<\/code> evades the overhead of bounds checking, copying bytes until reaching a terminating null character. It <em>expects<\/em> the programmer to check that the input fits into the target buffer. Without it, the routine will continue to copy bytes beyond the memory region belonging to the destination pointer. Buffer overflow attacks are a classic example of exploiting missing spatial safety. If a malicious agent overwrites the return address at the end of the stack frame, he\/she might be able to hijack the control-flow and execute remote code. Additionally, out-of-bounds reads can be used to leak sensitive information from other memory regions.<\/p>\n<h3 id=\"temporal-safety\">temporal safety<\/h3>\n<p>So far, we considered the spatial component of memory-safety. With memory being limited, applications must free resources once they are no longer needed. Hence, memory is a construct evolving over time. With this new dimension comes a new class of vulnerabilities.<\/p>\n<p>The best way to explain the concept of temporal safety is to classify memory regions. <em>Undefined memory<\/em> are regions that have never been allocated, were previously allocated but have been freed or are uninitialized <span class=\"citation\" data-cites=\"Hicks2014\">(<a href=\"#ref-Hicks2014\" role=\"doc-biblioref\">Hicks, 2014<\/a>)<\/span>. Temporal memory-safety enforces that all memory dereferences are valid, thereby preventing access to undefined memory and use of dangling pointers <span class=\"citation\" data-cites=\"Payer2017\">(<a href=\"#ref-Payer2017\" role=\"doc-biblioref\">Payer, 2017<\/a>)<\/span>.<\/p>\n<h4 id=\"example-use-after-free\">example: use after free<\/h4>\n<div class=\"sourceCode\" id=\"cb2\">\n<pre class=\"sourceCode c\"><code class=\"\" data-line=\"\">&lt;span id=&quot;cb2-1&quot;&gt;&lt;a href=&quot;#cb2-1&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;span class=&quot;co&quot;&gt;\/\/ dereferencing a freed pointer&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb2-2&quot;&gt;&lt;a href=&quot;#cb2-2&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;span class=&quot;dt&quot;&gt;int&lt;\/span&gt; &lt;span class=&quot;op&quot;&gt;*&lt;\/span&gt;p &lt;span class=&quot;op&quot;&gt;=&lt;\/span&gt; malloc&lt;span class=&quot;op&quot;&gt;(&lt;\/span&gt;&lt;span class=&quot;kw&quot;&gt;sizeof&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;(&lt;\/span&gt;&lt;span class=&quot;dt&quot;&gt;int&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;));&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb2-3&quot;&gt;&lt;a href=&quot;#cb2-3&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;span class=&quot;op&quot;&gt;*&lt;\/span&gt;p &lt;span class=&quot;op&quot;&gt;=&lt;\/span&gt; &lt;span class=&quot;dv&quot;&gt;5&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;;&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb2-4&quot;&gt;&lt;a href=&quot;#cb2-4&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;free&lt;span class=&quot;op&quot;&gt;(&lt;\/span&gt;p&lt;span class=&quot;op&quot;&gt;);&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb2-5&quot;&gt;&lt;a href=&quot;#cb2-5&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;span class=&quot;co&quot;&gt;\/\/ ...&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb2-6&quot;&gt;&lt;a href=&quot;#cb2-6&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;doProcess&lt;span class=&quot;op&quot;&gt;(&lt;\/span&gt;p&lt;span class=&quot;op&quot;&gt;);&lt;\/span&gt; &lt;span class=&quot;co&quot;&gt;\/\/ dereferenced memory no longer belongs to p&lt;\/span&gt;&lt;\/span&gt;<\/code><\/pre>\n<\/div>\n<p>The most frequent exploitation of temporal unsafety are use-after-free (UAF) vulnerabilities. When an object is freed, the underlying memory is no longer associated to the object and the pointer is no longer valid <span class=\"citation\" data-cites=\"Payer2017\">(<a href=\"#ref-Payer2017\" role=\"doc-biblioref\">Payer, 2017<\/a>)<\/span>. Yet, deallocation does not change the value of the pointer variable. If the program continuous to use the reference after its memory has been freed, a number of security risks arise.<\/p>\n<p>The operating system may reallocate previously freed memory at any point in time. Therefore, read-access through a dangling pointer could leak sensitive data from unrelated objects. Writing to a dangling pointer can corrupt valid data structures, leading to undefined behavior <span class=\"citation\" data-cites=\"OWASP2021\">(<a href=\"#ref-OWASP2021\" role=\"doc-biblioref\">OWASP, 2021<\/a>)<\/span>.<\/p>\n<p>Another exploitation is <em>heap massaging<\/em>. Here, the attacker forces the program to allocate new data into the memory region of the dangling pointer. The mismatch between the expected and actual datatype causes the program to misbehave. This illustrates how memory-safety is tightly linked to the topic of type-safety (which we conver later).<\/p>\n<h4 id=\"example-double-free\">example: double free<\/h4>\n<div class=\"sourceCode\" id=\"cb3\">\n<pre class=\"sourceCode c\"><code class=\"\" data-line=\"\">&lt;span id=&quot;cb3-1&quot;&gt;&lt;a href=&quot;#cb3-1&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;span class=&quot;dt&quot;&gt;char&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;*&lt;\/span&gt; ptr &lt;span class=&quot;op&quot;&gt;=&lt;\/span&gt; &lt;span class=&quot;op&quot;&gt;(&lt;\/span&gt;&lt;span class=&quot;dt&quot;&gt;char&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;*)&lt;\/span&gt;malloc &lt;span class=&quot;op&quot;&gt;(&lt;\/span&gt;SIZE&lt;span class=&quot;op&quot;&gt;);&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb3-2&quot;&gt;&lt;a href=&quot;#cb3-2&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;span class=&quot;co&quot;&gt;\/\/ ...&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb3-3&quot;&gt;&lt;a href=&quot;#cb3-3&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;span class=&quot;cf&quot;&gt;if&lt;\/span&gt; &lt;span class=&quot;op&quot;&gt;(&lt;\/span&gt;abrt&lt;span class=&quot;op&quot;&gt;)&lt;\/span&gt; &lt;span class=&quot;op&quot;&gt;{&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb3-4&quot;&gt;&lt;a href=&quot;#cb3-4&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;free&lt;span class=&quot;op&quot;&gt;(&lt;\/span&gt;ptr&lt;span class=&quot;op&quot;&gt;);&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb3-5&quot;&gt;&lt;a href=&quot;#cb3-5&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;span class=&quot;op&quot;&gt;}&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb3-6&quot;&gt;&lt;a href=&quot;#cb3-6&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;span class=&quot;co&quot;&gt;\/\/ ...&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb3-7&quot;&gt;&lt;a href=&quot;#cb3-7&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;free&lt;span class=&quot;op&quot;&gt;(&lt;\/span&gt;ptr&lt;span class=&quot;op&quot;&gt;);&lt;\/span&gt;&lt;\/span&gt;<\/code><\/pre>\n<\/div>\n<p>A double free is a type of use-after-free vulnerability, where we deallocate memory that already has been freed. To understand why this is problematic, one must understand how heap memory is managed at runtime. To keep track of allocations inside a memory pool, a memory manager uses a data structure called free list. For example, a doubly linked list maintains a set of nodes representing unallocated memory regions. Calling <code class=\"\" data-line=\"\">malloc<\/code> searches the free list for a node that fits the requested allocation size. If the node has more space available than requested, it will be split, unlinked and the remaining chunk becomes a new node in the free list <span class=\"citation\" data-cites=\"Habeeb2020\">(<a href=\"#ref-Habeeb2020\" role=\"doc-biblioref\">Habeeb, 2020<\/a>)<\/span>. Calling <code class=\"\" data-line=\"\">free<\/code> deallocates the respective chunk in the heap, linking a new node into the free list. As this action is not idempotent, double frees corrupt a program\u2019s free list. If the free list contains multiple nodes refering to the same memory region, new allocations could easily corrupt valid memory regions, resulting in undefined behavior.<\/p>\n<h2 id=\"type-safety\">type-safety<\/h2>\n<div class=\"sourceCode\" id=\"cb4\">\n<pre class=\"sourceCode c\"><code class=\"\" data-line=\"\">&lt;span id=&quot;cb4-1&quot;&gt;&lt;a href=&quot;#cb4-1&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb4-2&quot;&gt;&lt;a href=&quot;#cb4-2&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;span class=&quot;co&quot;&gt;\/\/ no implementated semantic meaning for + operator between int and str &lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb4-3&quot;&gt;&lt;a href=&quot;#cb4-3&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;span class=&quot;dv&quot;&gt;1&lt;\/span&gt; &lt;span class=&quot;op&quot;&gt;+&lt;\/span&gt; \u201cfoo\u201d&lt;span class=&quot;op&quot;&gt;;&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb4-4&quot;&gt;&lt;a href=&quot;#cb4-4&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb4-5&quot;&gt;&lt;a href=&quot;#cb4-5&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;span class=&quot;co&quot;&gt;\/\/ calling function with wrong data type (int instead of float)&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb4-6&quot;&gt;&lt;a href=&quot;#cb4-6&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;scale&lt;span class=&quot;op&quot;&gt;(&lt;\/span&gt;circle&lt;span class=&quot;op&quot;&gt;,&lt;\/span&gt; &lt;span class=&quot;dv&quot;&gt;2&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;);&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb4-7&quot;&gt;&lt;a href=&quot;#cb4-7&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb4-8&quot;&gt;&lt;a href=&quot;#cb4-8&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;span class=&quot;co&quot;&gt;\/\/ undefined out of bounds access&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb4-9&quot;&gt;&lt;a href=&quot;#cb4-9&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;span class=&quot;dt&quot;&gt;char&lt;\/span&gt; buf&lt;span class=&quot;op&quot;&gt;[&lt;\/span&gt;&lt;span class=&quot;dv&quot;&gt;4&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;];&lt;\/span&gt; &lt;\/span&gt;\n&lt;span id=&quot;cb4-10&quot;&gt;&lt;a href=&quot;#cb4-10&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;buf&lt;span class=&quot;op&quot;&gt;[&lt;\/span&gt;&lt;span class=&quot;dv&quot;&gt;4&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;]&lt;\/span&gt; &lt;span class=&quot;op&quot;&gt;=&lt;\/span&gt; \u2018x\u2019&lt;span class=&quot;op&quot;&gt;;&lt;\/span&gt;&lt;\/span&gt;<\/code><\/pre>\n<\/div>\n<p>Programming languages are defined by <em>syntax<\/em> and <em>semantics<\/em>. <em>Syntax<\/em> is the specification of what constitutes a formally correct program. Developer learn syntax rules to combine symbols into valid language constructs (e.g.&nbsp;expressions, control structures, or statements). <em>Semantics<\/em> deal with the computational meaning of syntactically valid source code. At its core, type-safety tries to close the gap where source code is syntactically valid, but semantically flawed <span class=\"citation\" data-cites=\"Hicks2014\">(<a href=\"#ref-Hicks2014\" role=\"doc-biblioref\">Hicks, 2014<\/a>)<\/span>.<\/p>\n<p>A type-sytem is a part of the compiler or interpreter to ensure that programs do not \u201cgo wrong\u201d <span class=\"citation\" data-cites=\"Milner1978\">(<a href=\"#ref-Milner1978\" role=\"doc-biblioref\">Milner, 1978<\/a>)<\/span>. A type-system is built on primitive, composite, and abstract data types that abstract memory storage. The type of a variable determines how to store and interpret its binary representation in memory. Additionally, types are used to attach semantics to a piece of data. The process of <em>type-checking<\/em> verifies that all operations are compatible with its type. If the type-system detects a violation, it throws a <em>type-error<\/em> to prevent undefined program behavior. What constitutes a type error depends on the strictness of the particular type-system. Some type-systems require explicit type declarations and conversions, while others are more liberal (e.g.&nbsp;type inference, implicit type casts, etc.). Different type-systems provide different guarantees, but all are integral in validating the correctness of programs.<\/p>\n<blockquote>\n<p>Please note: Complex type systems can do much more than data abstraction and preventing illegal operations. For example, Rust uses the type system to enforce memory and thread-safety guarantees.<\/p>\n<\/blockquote>\n<h2 id=\"thread-safety\">thread-safety<\/h2>\n<h3 id=\"concurrency-bugs\">concurrency bugs<\/h3>\n<figure align=\"center\">\n<img decoding=\"async\" src=\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/08\/con_parallel.png\" height=\"150\"><p><\/p>\n<figcaption>\ndifference between concurrency and parallelism<br>\n<\/figcaption>\n<\/figure>\n<p>To leverage the computational power of modern multi-core systems, developers often turn to <em>concurrency<\/em> and <em>parallelism<\/em>. Parallelism is about the <em>simultaneous execution<\/em> of multiple things <span class=\"citation\" data-cites=\"Pike2012\">(<a href=\"#ref-Pike2012\" role=\"doc-biblioref\">Pike, 2012<\/a>)<\/span>. Examples range from multi-threading on a single machine, to multi-processing and distributed systems. Concurrency <em>structures<\/em> a bigger computation by slicing it into independently executing things <span class=\"citation\" data-cites=\"Pike2012\">(<a href=\"#ref-Pike2012\" role=\"doc-biblioref\">Pike, 2012<\/a>)<\/span>. If successful, concurrency enables us to <em>deal with a lot of things at once<\/em> <span class=\"citation\" data-cites=\"Pike2012\">(<a href=\"#ref-Pike2012\" role=\"doc-biblioref\">Pike, 2012<\/a>)<\/span>.<\/p>\n<figure align=\"center\">\n<img decoding=\"async\" src=\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/08\/con_communication.png\" height=\"150\"><p><\/p>\n<figcaption>\nways of communication<br>\n<\/figcaption>\n<\/figure>\n<p>Composing concurrent modules back together requires some form of communication, such as reading\/writing to shared memory or by passing messages <span class=\"citation\" data-cites=\"MITConcurrency2021\">(<a href=\"#ref-MITConcurrency2021\" role=\"doc-biblioref\">MIT, 2021<\/a>)<\/span>. Uncoordinated access to shared resources is dangerous, as unexpected and unwanted interactions between threads can affect program correctness <span class=\"citation\" data-cites=\"Hosfelt2019a\">(<a href=\"#ref-Hosfelt2019a\" role=\"doc-biblioref\">Hosfelt, 2019<\/a>)<\/span>.<\/p>\n<figure align=\"center\">\n<img decoding=\"async\" src=\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/08\/deadlock.gif\" height=\"150\"><p><\/p>\n<figcaption>\ndeadlock<br>\n<\/figcaption>\n<\/figure>\n<p>A <em>deadlock<\/em> is circular dependency between processes that hold locks to resources while waiting for others to release theirs. If the system is not able to detect and release these state, adversaries could deliberately trigger deadlocks to attack the availability of systems.<\/p>\n<blockquote>\n<p>Your hardware is racy, your OS is racy, the other programs on your computer are racy, and the world this all runs in is racy. <span class=\"citation\" data-cites=\"Rustonomicon2021\">(<a href=\"#ref-Rustonomicon2021\" role=\"doc-biblioref\">Rustonomicon, 2021<\/a>)<\/span><\/p>\n<\/blockquote>\n<p><em>Race conditions<\/em> are a fundamental part of computing and not necessarily malicious. Yet, the term mostly describes situations where non-deterministic timing causes a interlacing of operations, affecting the correctness of a program <span class=\"citation\" data-cites=\"Hosfelt2019a\">(<a href=\"#ref-Hosfelt2019a\" role=\"doc-biblioref\">Hosfelt, 2019<\/a>)<\/span>. <em>Data races<\/em> arise when multiple parallel timelines (such as threads, processes, async callback chains) interfere with another by accessing the same memory location (and if at least one of them is a write) <span class=\"citation\" data-cites=\"Normand2019\">(<a href=\"#ref-Normand2019\" role=\"doc-biblioref\">Normand, 2019<\/a>)<\/span>.<\/p>\n<table>\n<thead>\n<tr class=\"header\">\n<th>Thread 1<\/th>\n<th>Thread 2<\/th>\n<th><\/th>\n<th>Integer value<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr class=\"odd\">\n<td><\/td>\n<td><\/td>\n<td><\/td>\n<td>0<\/td>\n<\/tr>\n<tr class=\"even\">\n<td>read value<\/td>\n<td><\/td>\n<td>\u2190<\/td>\n<td>0<\/td>\n<\/tr>\n<tr class=\"odd\">\n<td><\/td>\n<td>read value<\/td>\n<td>\u2190<\/td>\n<td>0<\/td>\n<\/tr>\n<tr class=\"even\">\n<td>increase value<\/td>\n<td><\/td>\n<td><\/td>\n<td>0<\/td>\n<\/tr>\n<tr class=\"odd\">\n<td><\/td>\n<td>increase value<\/td>\n<td><\/td>\n<td>0<\/td>\n<\/tr>\n<tr class=\"even\">\n<td>write back<\/td>\n<td><\/td>\n<td>\u2192<\/td>\n<td>1<\/td>\n<\/tr>\n<tr class=\"odd\">\n<td><\/td>\n<td>write back<\/td>\n<td>\u2192<\/td>\n<td>1<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Both are independent concepts, but there is considerable overlap in practice. The table shows how a combination of race condition and data race causes a lost update. Thereby we can infer that thread unsafety could be used to attack the integrity of systems <span class=\"citation\" data-cites=\"Hosfelt2019a\">(<a href=\"#ref-Hosfelt2019a\" role=\"doc-biblioref\">Hosfelt, 2019<\/a>)<\/span>.<\/p>\n<p>Thread-safe code coordinates the manipulation of shared data structures by synchronization via locks, semaphores or mutexes to prevent such unintended interaction. Unfortunately, developing concurrent code is hard, because humans think sequentially and read\/write source code in a top to bottom flow <span class=\"citation\" data-cites=\"Frey2016\">(<a href=\"#ref-Frey2016\" role=\"doc-biblioref\">Frey et al., 2016<\/a>)<\/span>. These natural biases lead to fallacy, that code is executed sequentially and independent of external influences. Besides being hard to reason about, concurrency bugs are notoriously hard to debug. By being a product of interaction, it is difficult to trace behavior back to its root cause in source code. Due to their time sensitive nature, the behavior of bugs tends to be nondeterministic, making them very difficult to reproduce. Running in debug mode, adding extra logging, or attaching a debugger affect relative timing between interfering threads, which may cause bugs to disappear.<\/p>\n<h4 id=\"example-time-of-check-to-time-of-use-toctou\">example: time of check to time of use (TOCTOU)<\/h4>\n<div class=\"sourceCode\" id=\"cb5\">\n<pre class=\"sourceCode c\"><code class=\"\" data-line=\"\">&lt;span id=&quot;cb5-1&quot;&gt;&lt;a href=&quot;#cb5-1&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;span class=&quot;co&quot;&gt;\/\/ pass filepath as argument &lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-2&quot;&gt;&lt;a href=&quot;#cb5-2&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;span class=&quot;dt&quot;&gt;int&lt;\/span&gt; main&lt;span class=&quot;op&quot;&gt;(&lt;\/span&gt;&lt;span class=&quot;dt&quot;&gt;int&lt;\/span&gt; argc&lt;span class=&quot;op&quot;&gt;,&lt;\/span&gt; &lt;span class=&quot;dt&quot;&gt;char&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;*&lt;\/span&gt; argv&lt;span class=&quot;op&quot;&gt;[])&lt;\/span&gt; &lt;span class=&quot;op&quot;&gt;{&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-3&quot;&gt;&lt;a href=&quot;#cb5-3&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;    &lt;span class=&quot;dt&quot;&gt;int&lt;\/span&gt; fd&lt;span class=&quot;op&quot;&gt;;&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-4&quot;&gt;&lt;a href=&quot;#cb5-4&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;    &lt;span class=&quot;dt&quot;&gt;int&lt;\/span&gt; size &lt;span class=&quot;op&quot;&gt;=&lt;\/span&gt; &lt;span class=&quot;dv&quot;&gt;0&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;;&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-5&quot;&gt;&lt;a href=&quot;#cb5-5&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;    &lt;span class=&quot;dt&quot;&gt;char&lt;\/span&gt; buf&lt;span class=&quot;op&quot;&gt;[&lt;\/span&gt;&lt;span class=&quot;dv&quot;&gt;256&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;];&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-6&quot;&gt;&lt;a href=&quot;#cb5-6&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-7&quot;&gt;&lt;a href=&quot;#cb5-7&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;    &lt;span class=&quot;cf&quot;&gt;if&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;(&lt;\/span&gt;argc &lt;span class=&quot;op&quot;&gt;!=&lt;\/span&gt; &lt;span class=&quot;dv&quot;&gt;2&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;)&lt;\/span&gt; &lt;span class=&quot;op&quot;&gt;{&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-8&quot;&gt;&lt;a href=&quot;#cb5-8&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;        printf&lt;span class=&quot;op&quot;&gt;(&lt;\/span&gt;&lt;span class=&quot;st&quot;&gt;&quot;usage: %s &lt;file&gt;&lt;\/span&gt;&lt;span class=&quot;sc&quot;&gt;\\n&lt;\/span&gt;&lt;span class=&quot;st&quot;&gt;&quot;&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;,&lt;\/span&gt; argv&lt;span class=&quot;op&quot;&gt;[&lt;\/span&gt;&lt;span class=&quot;dv&quot;&gt;0&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;]);&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-9&quot;&gt;&lt;a href=&quot;#cb5-9&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;        exit&lt;span class=&quot;op&quot;&gt;(&lt;\/span&gt;&lt;span class=&quot;dv&quot;&gt;1&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;);&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-10&quot;&gt;&lt;a href=&quot;#cb5-10&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;    &lt;span class=&quot;op&quot;&gt;}&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-11&quot;&gt;&lt;a href=&quot;#cb5-11&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-12&quot;&gt;&lt;a href=&quot;#cb5-12&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;    &lt;span class=&quot;co&quot;&gt;\/\/ use syscall stat() to get information about this file&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-13&quot;&gt;&lt;a href=&quot;#cb5-13&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;    &lt;span class=&quot;kw&quot;&gt;struct&lt;\/span&gt; stat stat_data&lt;span class=&quot;op&quot;&gt;;&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-14&quot;&gt;&lt;a href=&quot;#cb5-14&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;    &lt;span class=&quot;cf&quot;&gt;if&lt;\/span&gt; &lt;span class=&quot;op&quot;&gt;(&lt;\/span&gt;stat&lt;span class=&quot;op&quot;&gt;(&lt;\/span&gt;argv&lt;span class=&quot;op&quot;&gt;[&lt;\/span&gt;&lt;span class=&quot;dv&quot;&gt;1&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;],&lt;\/span&gt; &lt;span class=&quot;op&quot;&gt;&amp;&lt;\/span&gt;stat_data&lt;span class=&quot;op&quot;&gt;)&lt;\/span&gt; &lt;span class=&quot;op&quot;&gt;&lt;&lt;\/span&gt; &lt;span class=&quot;dv&quot;&gt;0&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;)&lt;\/span&gt; &lt;span class=&quot;op&quot;&gt;{&lt;\/span&gt; &lt;span class=&quot;co&quot;&gt;\/\/ &lt;-- time of check&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-15&quot;&gt;&lt;a href=&quot;#cb5-15&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;        fprintf&lt;span class=&quot;op&quot;&gt;(&lt;\/span&gt;stderr&lt;span class=&quot;op&quot;&gt;,&lt;\/span&gt; &lt;span class=&quot;st&quot;&gt;&quot;Failed to stat %s: %s&lt;\/span&gt;&lt;span class=&quot;sc&quot;&gt;\\n&lt;\/span&gt;&lt;span class=&quot;st&quot;&gt;&quot;&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;,&lt;\/span&gt; argv&lt;span class=&quot;op&quot;&gt;[&lt;\/span&gt;&lt;span class=&quot;dv&quot;&gt;1&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;],&lt;\/span&gt; strerror&lt;span class=&quot;op&quot;&gt;(&lt;\/span&gt;errno&lt;span class=&quot;op&quot;&gt;));&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-16&quot;&gt;&lt;a href=&quot;#cb5-16&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;        exit&lt;span class=&quot;op&quot;&gt;(&lt;\/span&gt;&lt;span class=&quot;dv&quot;&gt;1&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;);&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-17&quot;&gt;&lt;a href=&quot;#cb5-17&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;    &lt;span class=&quot;op&quot;&gt;}&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-18&quot;&gt;&lt;a href=&quot;#cb5-18&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;    &lt;\/span&gt;\n&lt;span id=&quot;cb5-19&quot;&gt;&lt;a href=&quot;#cb5-19&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;    &lt;span class=&quot;co&quot;&gt;\/\/ check if the file is owned by root, if yes print error&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-20&quot;&gt;&lt;a href=&quot;#cb5-20&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;    &lt;span class=&quot;cf&quot;&gt;if&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;(&lt;\/span&gt;stat_data&lt;span class=&quot;op&quot;&gt;.&lt;\/span&gt;st_uid &lt;span class=&quot;op&quot;&gt;==&lt;\/span&gt; &lt;span class=&quot;dv&quot;&gt;0&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;)&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-21&quot;&gt;&lt;a href=&quot;#cb5-21&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;    &lt;span class=&quot;op&quot;&gt;{&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-22&quot;&gt;&lt;a href=&quot;#cb5-22&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;        fprintf&lt;span class=&quot;op&quot;&gt;(&lt;\/span&gt;stderr&lt;span class=&quot;op&quot;&gt;,&lt;\/span&gt; &lt;span class=&quot;st&quot;&gt;&quot;File %s is owned by root&lt;\/span&gt;&lt;span class=&quot;sc&quot;&gt;\\n&lt;\/span&gt;&lt;span class=&quot;st&quot;&gt;&quot;&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;,&lt;\/span&gt; argv&lt;span class=&quot;op&quot;&gt;[&lt;\/span&gt;&lt;span class=&quot;dv&quot;&gt;1&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;]);&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-23&quot;&gt;&lt;a href=&quot;#cb5-23&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;        exit&lt;span class=&quot;op&quot;&gt;(&lt;\/span&gt;&lt;span class=&quot;dv&quot;&gt;1&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;);&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-24&quot;&gt;&lt;a href=&quot;#cb5-24&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;    &lt;span class=&quot;op&quot;&gt;}&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-25&quot;&gt;&lt;a href=&quot;#cb5-25&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-26&quot;&gt;&lt;a href=&quot;#cb5-26&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;    &lt;span class=&quot;co&quot;&gt;\/\/ if not, open the file in readonly mode and do stuff&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-27&quot;&gt;&lt;a href=&quot;#cb5-27&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;    fd &lt;span class=&quot;op&quot;&gt;=&lt;\/span&gt; open&lt;span class=&quot;op&quot;&gt;(&lt;\/span&gt;argv&lt;span class=&quot;op&quot;&gt;[&lt;\/span&gt;&lt;span class=&quot;dv&quot;&gt;1&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;],&lt;\/span&gt; O_RDONLY&lt;span class=&quot;op&quot;&gt;);&lt;\/span&gt;  &lt;span class=&quot;co&quot;&gt;\/\/ &lt;-- time of use&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-28&quot;&gt;&lt;a href=&quot;#cb5-28&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-29&quot;&gt;&lt;a href=&quot;#cb5-29&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;    &lt;span class=&quot;co&quot;&gt;\/\/ ...&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb5-30&quot;&gt;&lt;a href=&quot;#cb5-30&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;span class=&quot;op&quot;&gt;}&lt;\/span&gt;&lt;\/span&gt;<\/code><\/pre>\n<\/div>\n<p>To an untrained eye, the implementation above looks plausible. However, the snippet <span class=\"citation\" data-cites=\"LiveOverflow2019\">(<a href=\"#ref-LiveOverflow2019\" role=\"doc-biblioref\">LiveOverflow, 2019<\/a>)<\/span> contains a race condition vulnerability, commonly called time of check to time of use (TOCTOU). Assuming isolated sequential code execution, the programmer <em>expects<\/em> that the file doesn\u2019t change between checking for the ownership and opening it.<\/p>\n<div class=\"sourceCode\" id=\"cb6\">\n<pre class=\"sourceCode c\"><code class=\"\" data-line=\"\">&lt;span id=&quot;cb6-1&quot;&gt;&lt;a href=&quot;#cb6-1&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;span class=&quot;co&quot;&gt;\/\/ winning the race&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb6-2&quot;&gt;&lt;a href=&quot;#cb6-2&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;span class=&quot;co&quot;&gt;\/\/ syscall SYS_renameat2 to swap two file paths&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb6-3&quot;&gt;&lt;a href=&quot;#cb6-3&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;span class=&quot;cf&quot;&gt;while&lt;\/span&gt; &lt;span class=&quot;op&quot;&gt;(&lt;\/span&gt;&lt;span class=&quot;dv&quot;&gt;1&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;)&lt;\/span&gt; &lt;span class=&quot;op&quot;&gt;{&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb6-4&quot;&gt;&lt;a href=&quot;#cb6-4&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;  syscall&lt;span class=&quot;op&quot;&gt;(&lt;\/span&gt;SYS_renameat2&lt;span class=&quot;op&quot;&gt;,&lt;\/span&gt; AT_FDCWD&lt;span class=&quot;op&quot;&gt;,&lt;\/span&gt; argv&lt;span class=&quot;op&quot;&gt;[&lt;\/span&gt;&lt;span class=&quot;dv&quot;&gt;1&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;],&lt;\/span&gt; AT_FDCWD&lt;span class=&quot;op&quot;&gt;,&lt;\/span&gt; argv&lt;span class=&quot;op&quot;&gt;[&lt;\/span&gt;&lt;span class=&quot;dv&quot;&gt;2&lt;\/span&gt;&lt;span class=&quot;op&quot;&gt;],&lt;\/span&gt; RENAME_EXCHANGE&lt;span class=&quot;op&quot;&gt;);&lt;\/span&gt;&lt;\/span&gt;\n&lt;span id=&quot;cb6-5&quot;&gt;&lt;a href=&quot;#cb6-5&quot; aria-hidden=&quot;true&quot;&gt;&lt;\/a&gt;&lt;span class=&quot;op&quot;&gt;}&lt;\/span&gt;&lt;\/span&gt;<\/code><\/pre>\n<\/div>\n<p>Unfortunately for developers, hackers are in the business of identifying and violating expectations. The code snippet above is executed in parallel to the first code example. Using the <code class=\"\" data-line=\"\">SYS_renameat2<\/code> syscall, the attacker continuously swaps the file paths of two files, passing one of them to the program. If the timing is just right, the program calls stat() when the path refers to a file that passes the program\u2019s security checks. If the adversary wins to race to swaps out file paths before time of use, he\/she can inject any file-on-disk into the application.<\/p>\n<h2 id=\"layers-of-defense\">layers of defense<\/h2>\n<p>After introducing memory-, type-, and thread-safety, it should be clear that developing secure code in unsafe languages is not trivial. Currently, there are three layers of defense.<\/p>\n<h3 id=\"language-design\">language design<\/h3>\n<p>The first layer of defense is at the language level. One common approach is to address risks by <em>limitation<\/em>. Usually, modern safe programming languages rely on garbage collection (GC) to ditch the risks of manual memory management all together. For a majority of programming nowadays, this seems to be a reasonable choice. However, fields such as systems programming require low-level memory access, cannot afford performance overhead and nondeterministic runtime behavior <span class=\"citation\" data-cites=\"Szekeres2013\">(<a href=\"#ref-Szekeres2013\" role=\"doc-biblioref\">Szekeres et al., 2013<\/a>)<\/span>. Another approach is are <em>concepts<\/em> like <em>ownership<\/em> to prove safety gurantees at compile time, avoiding many runtime costs.<\/p>\n<blockquote>\n<p>C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off.<\/p>\n<\/blockquote>\n<p>Due to the vicious cycle of designing programming languages, C++ chose to <em>extend<\/em> an unsafe language. In <span class=\"citation\" data-cites=\"Stroustrup2020\">(<a href=\"#ref-Stroustrup2020\" role=\"doc-biblioref\">Stroustrup and Regehr, 2020<\/a>)<\/span> Bjrane Stoustup mentions, that once a programming language gains adoption, this results in a responsibility not to break code. Just think about the repercussions of breaking compatibility with billions lines of existing C\/C++ code. This means that if you don\u2019t get core language features right on the first try, you may have to live with suboptimal decisions for decades. The only option to rectify mistakes is to <em>add<\/em> a better version (e.g.&nbsp;smart pointers) to the language. However, without deprecation, you lose the mechanism to enforce these concepts. Now, language safety morphs from a technical into a communication issue. Millions of programmers must attend conferences and read guideline documents <span class=\"citation\" data-cites=\"Sutter2021\">(<a href=\"#ref-Sutter2021\" role=\"doc-biblioref\">Sutter and Stroustrup, 2021<\/a>)<\/span> to adopt the \u201cmodern\u201d reincarnation of the language.<\/p>\n<h3 id=\"testing-for-security\">testing for security<\/h3>\n<p>The topic of language safety also affects the way we test software for security. Testing is an indispensable cornerstone in modern software development. With countless ways to test your software, it is important to choose strategies that deliver a high ROI, but also be aware of anti-patterns and blind spots.<\/p>\n<h4 id=\"peer-review\">peer review<\/h4>\n<p>Manual static testing is usually some variation of peer review. They are a great tool to combat developer tunnel vision and discuss abstract design decisions early in development. Following the motto \u201cyour strength is your weakness\u201d, this social setting is fairly ineffective in uncovering language unsafety vulnerabilities. By nature, these bugs tend to be fairly complex, require security experience, time and high degrees of mental focus.<\/p>\n<h4 id=\"dynamic-testing\">dynamic testing<\/h4>\n<p>With dynamic testing, we try to identify bugs by executing code and observing its behavior. A developer defines test cases, writes scripts and analyzes the test results. As most vulnerabilities result from bugs with error handling, unit testing is only informative with a sufficiently high degree of code coverage. A common mistake is to optimize for these quantifiable metrics, while misinterpreting their meaning <span class=\"citation\" data-cites=\"Leitner2017\">(<a href=\"#ref-Leitner2017\" role=\"doc-biblioref\">Leitner, 2017<\/a>)<\/span>. Pointlessly testing for every edge in the control-flow-graph is tedious labor and provides a false sense of security. Code coverage helps to discover untested code, but is not a measurement of code quality <span class=\"citation\" data-cites=\"Fowler2012\">(<a href=\"#ref-Fowler2012\" role=\"doc-biblioref\">Fowler, 2012<\/a>)<\/span>. To exclude a specific bug, you have to explicitly test for their absence. Therefore, language unsafty force developers to write <em>more<\/em> tests, which doesn\u2019t scale well with the size of the codebase. Another strategy to alleviate some manual work and developer biases from the process of testing is <em>fuzzing<\/em>. Fuzz testing is a type of automated test that sends a wide range of inputs variants to all data interfaces of a program. The inputs are generated from known-to-be-dangerous values and random data. During execution, the program is monitored to see whether inputs are caught by error-handling or trigger unwanted behavior.<\/p>\n<figure align=\"center\">\n<img decoding=\"async\" src=\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/08\/address_sanitizer.png\" height=\"200\"><p><\/p>\n<figcaption>\naddress sanitizer<br>\n<\/figcaption>\n<\/figure>\n<p>A program crash constitutes a clear indicator that a particular input has not been dealt with properly. Other vulnerabilities however are <em>silent<\/em>, making it difficult to distinguish from regular program behavior. To detect these cases, C\/C++ compilers support instrumentation in the form of <em>sanitizers<\/em>. Sanitizers inject assertions into the application, track execution at runtime and report errors by deliberately crashing the program <span class=\"citation\" data-cites=\"WikiFuzz2021\">(<a href=\"#ref-WikiFuzz2021\" role=\"doc-biblioref\">Wikipedia contributors, 2021a<\/a>)<\/span>. Sanitization should only be used during testing and debugging, as it comes with a considerable compute and memory overhead. <span class=\"citation\" data-cites=\"WikiFuzz2021\">(<a href=\"#ref-WikiFuzz2021\" role=\"doc-biblioref\">Wikipedia contributors, 2021a<\/a>)<\/span> list a series of sanitizers for different types of bugs:<\/p>\n<blockquote>\n<ul>\n<li>to detect memory related errors, such as buffer overflows and use-after-free (using memory debuggers such as AddressSanitizer),<\/li>\n<li>to detect race conditions and deadlocks (ThreadSanitizer),<\/li>\n<li>to detect undefined behavior (UndefinedBehaviorSanitizer),<\/li>\n<li>to detect memory leaks (LeakSanitizer), or<\/li>\n<li>to check control-flow integrity (CFISanitizer).<\/li>\n<\/ul>\n<\/blockquote>\n<p><span class=\"citation\" data-cites=\"Lemire2019\">(<a href=\"#ref-Lemire2019\" role=\"doc-biblioref\">Lemire, 2019<\/a>)<\/span> calls sanitizers a game changer and integral part in writing modern c++. Although fuzzing can be shockingly effective at discovering vulnerabilities, it can be a double-edged sword. It provides no guarantee that our software is safe, because \u201cdemonstrates the presence of bugs rather than their absence\u201d <span class=\"citation\" data-cites=\"WikiFuzz2021\">(<a href=\"#ref-WikiFuzz2021\" role=\"doc-biblioref\">Wikipedia contributors, 2021a<\/a>)<\/span>. Even with a capable fuzzing farm, fuzzing may take hours or days to complete. Additionally, the report provides little information on the cause of the detected bugs. Another downside with being \u201cshockingly effective\u201d is that as a dual-use tool, fuzzing can be utilized by adversaries as well.<\/p>\n<h3 id=\"operating-systems\">operating systems<\/h3>\n<p>Language unsafety also affects the design of our operating systems. Post-hoc security mechanisms are often the last layer of defense. Prominent examples are Address space layout randomization (ASLR), Stack smashing protection (SSP) and Non-eXecutable (NX) to \u201cprotect\u201d against buffer overflows.<\/p>\n<p>ASLR mitigates buffer overflow attacks that overwrite the EIP register to a fixed memory address by adding randomizing the process\u2019s memory layout.<\/p>\n<p>SSP injects a secret value into every stack frame. If a malicious agent overwrites a routine\u2019s return address, he\/she will also alter the secret. Upon leaving a function, the current value is compared against the initial secret.<\/p>\n<p>NX attempts to revoke the missing barrier between code and data. Memory pages containing code are tagged as executable and read-only, areas containing data as read\/write and non-executable <span class=\"citation\" data-cites=\"Gisbert2014\">(<a href=\"#ref-Gisbert2014\" role=\"doc-biblioref\">Gisbert and Ripoll, 2014<\/a>)<\/span>. The hardware is responsible for enforcing these policies when fetching instructions from memory.<\/p>\n<figure align=\"center\">\n<img decoding=\"async\" src=\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/08\/buf_overflow_stats.png\" height=\"200\"><p><\/p>\n<figcaption>\nprevalence of buffer overflow vulnerabilities<br>\n<\/figcaption>\n<\/figure>\n<p>Post-hoc techniques merely increase the difficulty of exploitation rather than addressing the underlying issue of memory unsafety <span class=\"citation\" data-cites=\"Gisbert2014\">(<a href=\"#ref-Gisbert2014\" role=\"doc-biblioref\">Gisbert and Ripoll, 2014<\/a>)<\/span>. According to <span class=\"citation\" data-cites=\"Gisbert2014\">(<a href=\"#ref-Gisbert2014\" role=\"doc-biblioref\">Gisbert and Ripoll, 2014<\/a>)<\/span>, slight variations in the attack and weak implementations are the Achilles heel of these types of defense mechanisms. The CVE shows no reduction in the prevalence of overflow attacks, proving this strategy ineffective. The ongoing mentality to fix security issues inside the kernel is not sustainable in the long run <span class=\"citation\" data-cites=\"Lunduke2021\">(<a href=\"#ref-Lunduke2021\" role=\"doc-biblioref\">Lunduke, 2021<\/a>)<\/span>. I believe these tools are symptomatic for optimizing around an issue that shouldn\u2019t exist in the first place.<\/p>\n<h2 id=\"conclusion\">conclusion<\/h2>\n<blockquote>\n<p>[\u2026] we\u2019re in the midst of the greatest crisis of computer security in computer history. <span class=\"citation\" data-cites=\"Snowden2021\">(<a href=\"#ref-Snowden2021\" role=\"doc-biblioref\">Snowden, 2021<\/a>)<\/span><\/p>\n<\/blockquote>\n<p>In this article, we examined why producing safe programs using unsafe languages is hard. Bugs are highly prevalent even in the most professional code bases. However, most projects start as small internal or hobby projects. At early stages of development, resources are often highly constrained and primarily invested in adding functionality or address bug reports. Writing secure C\/C++ absolutely <em>requires<\/em> a professional build pipeline to compensate for its lack of memory-, type-, and thread-safety. Without it, the project grows into a pile of insufficiently tested code. Treating security as an afterthought is a deadly fallacy. Finding vulnerabilities due to language unsafety is not an easy task, and many pull request were merged without proper review and discussion. The sheer scale of code makes it unlikely to combat the issue by manually writing tests. As a last resort, automated techniques like fuzzing are deployed and reveal a sea of bugs. Now it\u2019s difficult to prioritize and there are usually not enough capable developers to cover all potential memory-, type-, and thread-safety vulnerabilities. If remaining vulnerabilities make it into production, post-hoc security mechanism have proven to be insufficient at catching and preventing their exploitation. Unfortunately, functional value is often the primary factor that drives adoption, as there are no metrics to measure the risks introduced by a dependency <span class=\"citation\" data-cites=\"Leitner2019\">(<a href=\"#ref-Leitner2019\" role=\"doc-biblioref\">Leitner, 2019<\/a>)<\/span>. Most software nowadays is build on top of other software. If security is hard to get right, bugs may spread easily between software projects. This makes us highly vulnerable to supply chain attacks targeting the weakest link.<\/p>\n<p>On top of that, technical weaknesses are amplified by bad organizational practices. Open-source contributions and use of dedicated security teams have the tendency to separate the entity that introduces a vulnerability from the one that fixes it. Without skin in fixing vulnerabilities, developer are desensitized to security issues, won\u2019t be able to learn from their mistakes and repeat them in other projects <span class=\"citation\" data-cites=\"Leitner2017\">(<a href=\"#ref-Leitner2017\" role=\"doc-biblioref\">Leitner, 2017<\/a>)<\/span>. Security must be an integral part of the development process. The only way to enforce this is if security issues prevent compilation. Another area for improvement is static analysis to inform developers about potential security hazards.<\/p>\n<figure align=\"center\">\n<img decoding=\"async\" src=\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/08\/itsfine.jpeg\" height=\"200\"><p><\/p>\n<figcaption>\nit\u2019s not<br>\n<\/figcaption>\n<\/figure>\n<p>However, I fully acknowledge that the decision to develop in unsafe languages is most often a <em>practical<\/em> and <em>economic<\/em> choice. Regarding practicality, C\/C++ has clear advantage of battle-tested libraries and interoperability with legacy systems. Still, every new line written in unsafe languages today, eventually becomes the legacy of tomorrow <span class=\"citation\" data-cites=\"Leitner2017\">(<a href=\"#ref-Leitner2017\" role=\"doc-biblioref\">Leitner, 2017<\/a>)<\/span>. This ongoing mentality is what fuels our addiction for the last twenty years.<\/p>\n<blockquote>\n<p>[\u2026] are all happy to write code in programming languages that we know are unsafe, because, well, that\u2019s what they\u2019ve always done, and modernization requires a significant effort, not to mention significant expenditures. <span class=\"citation\" data-cites=\"Snowden2021\">(<a href=\"#ref-Snowden2021\" role=\"doc-biblioref\">Snowden, 2021<\/a>)<\/span><\/p>\n<\/blockquote>\n<p>I think Snowden hits the nail on the head. It is economically irrational to choose any other language, because it likely demands an investment on your part, rather than profiting from the work of others. Another problem is the vicious circle of adoption. Companies won\u2019t invest in a technology unless there are enough trained developers to hire. Most companies cannot justify the cost of retraining on the job. On the other hand, most developers won\u2019t learn a new language, if it doesn\u2019t further their career. This stalemate significantly slows down the speed at which the ecosystems of emerging technologies mature.<\/p>\n<p>Dennis Ritchie and Bjarne Stoustrup developed C\/C++ at a time when digital warfare (government funded APTs) and a growing \u201cinsecurity industry\u201d (legal and illegal for-profit hacking) were still science fiction rather than daily reality. Continuing the path of the last 20 years is nothing but an act of negligence. Unsafe programming languages are overwhelmingly used in critical infrastructure, industrial\/financial applications and embedded devices. Moreover, the recent Pegasus scandal reveals how unsecure software affects journalists, human rights defenders and ultimately our democracy. They are a weapon in the hands of enemies that directly threatens our physical well-being. Therefore, they should be widespread interest in avoiding unsafe languages as much as possible. As much as we like to deny it, the choice of programming comes with a political responsibility.<\/p>\n<figure align=\"center\">\n<img decoding=\"async\" src=\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/08\/risk_matrix_shift.png\" height=\"200\"><p><\/p>\n<figcaption>\ncausing a shift in the risk matrix<br>\n<\/figcaption>\n<\/figure>\n<blockquote>\n<p>If you want to see change, you need to incentivize change. For example, if you want to see Microsoft have a heart attack, talk about the idea of defining legal liability for bad code in a commercial product. Where there is no liability, there is no accountability. <span class=\"citation\" data-cites=\"Snowden2021\">(<a href=\"#ref-Snowden2021\" role=\"doc-biblioref\">Snowden, 2021<\/a>)<\/span><\/p>\n<\/blockquote>\n<p>Personally, I believe that the only way to increase the traction of technical solutions is by causing a shift in the risk matrix. The software industries lack of liability for damages caused by its malformed products makes risks economically tolerable. To match the enormous risks carried by society, we must increase the industries skin in the game. I fully acknowledge that addressing technical issues with legal tools is always a slippery slope. Yet, to do it right, the push for regulation must come from within the developer community. Nobody likes to make his\/her own job more difficult, but I strongly believe it\u2019s a small price to pay.<\/p>\n<h2 class=\"unnumbered\" id=\"bibliography\">bibliography<\/h2>\n<div id=\"refs\" class=\"references csl-bib-body\" role=\"doc-bibliography\">\n<div id=\"ref-Fowler2012\" class=\"csl-entry\" role=\"doc-biblioentry\">\nFowler, M., 2012. <em>TestCoverage<\/em>. [online] Available at: &lt;<a href=\"https:\/\/martinfowler.com\/bliki\/TestCoverage.html\">https:\/\/martinfowler.com\/bliki\/TestCoverage.html<\/a>&gt;.\n<\/div>\n<div id=\"ref-Frey2016\" class=\"csl-entry\" role=\"doc-biblioentry\">\nFrey, J., Buchwald, H., Soller, S., Kriha, W. and Binder, B., 2016. <em>Why is parallel programming so hard to express?<\/em> [online] Available at: &lt;<a href=\"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2016\/10\/24\/why-is-parallel-programming-so-hard-to-express\/\">https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2016\/10\/24\/why-is-parallel-programming-so-hard-to-express\/<\/a>&gt;.\n<\/div>\n<div id=\"ref-Gaynor2019\" class=\"csl-entry\" role=\"doc-biblioentry\">\nGaynor, A., 2019. <em>Introduction to memory unsafety for VPs of engineering<\/em>. [online] Available at: &lt;<a href=\"https:\/\/alexgaynor.net\/2019\/aug\/12\/introduction-to-memory-unsafety-for-vps-of-engineering\/\">https:\/\/alexgaynor.net\/2019\/aug\/12\/introduction-to-memory-unsafety-for-vps-of-engineering\/<\/a>&gt;.\n<\/div>\n<div id=\"ref-Gisbert2014\" class=\"csl-entry\" role=\"doc-biblioentry\">\nGisbert, H.M. and Ripoll, I., 2014. On the effectiveness of NX, SSP, RenewSSP, and ASLR against stack buffer overflows. In: <em>2014 IEEE 13th international symposium on network computing and applications<\/em>. pp.145\u2013152. <a href=\"https:\/\/doi.org\/10.1109\/NCA.2014.28\">https:\/\/doi.org\/10.1109\/NCA.2014.28<\/a>.\n<\/div>\n<div id=\"ref-Habeeb2020\" class=\"csl-entry\" role=\"doc-biblioentry\">\nHabeeb, R., 2020. <em>Free-list malloc explained<\/em>. [online] Available at: &lt;<a href=\"https:\/\/www.youtube.com\/watch?v=b1vv-z_Otr4\">https:\/\/www.youtube.com\/watch?v=b1vv-z_Otr4<\/a>&gt;.\n<\/div>\n<div id=\"ref-Hicks2014\" class=\"csl-entry\" role=\"doc-biblioentry\">\nHicks, M., 2014. <em>What is memory safety?<\/em> [online] Available at: &lt;<a href=\"http:\/\/www.pl-enthusiast.net\/2014\/07\/21\/memory-safety\/\">http:\/\/www.pl-enthusiast.net\/2014\/07\/21\/memory-safety\/<\/a>&gt;.\n<\/div>\n<div id=\"ref-Hicks2016\" class=\"csl-entry\" role=\"doc-biblioentry\">\nHicks, M., 2016. <em>Software security &#8211; memory safety<\/em>. [online] Available at: &lt;<a href=\"https:\/\/www.youtube.com\/watch?v=CqaEDK9HjRM\">https:\/\/www.youtube.com\/watch?v=CqaEDK9HjRM<\/a>&gt;.\n<\/div>\n<div id=\"ref-Hosfelt2019a\" class=\"csl-entry\" role=\"doc-biblioentry\">\nHosfelt, D., 2019. <em>Fearless security: Thread safety<\/em>. [online] Available at: &lt;<a href=\"https:\/\/hacks.mozilla.org\/2019\/02\/fearless-security-thread-safety\/\">https:\/\/hacks.mozilla.org\/2019\/02\/fearless-security-thread-safety\/<\/a>&gt;.\n<\/div>\n<div id=\"ref-Leitner2017\" class=\"csl-entry\" role=\"doc-biblioentry\">\nLeitner, F. von, 2017. <em>34C3 &#8211; antipatterns und missverst\u00e4ndnisse in der softwareentwicklung<\/em>. [online] Available at: &lt;<a href=\"https:\/\/www.youtube.com\/watch?v=E0_Y53ci9cw\">https:\/\/www.youtube.com\/watch?v=E0_Y53ci9cw<\/a>&gt;.\n<\/div>\n<div id=\"ref-Leitner2019\" class=\"csl-entry\" role=\"doc-biblioentry\">\nLeitner, F. von, 2019. <em>36C3 &#8211; das n\u00fctzlich-unbedenklich spektrum<\/em>. [online] Available at: &lt;<a href=\"https:\/\/www.youtube.com\/watch?v=31xA9p3pYE4&amp;t=2123s\">https:\/\/www.youtube.com\/watch?v=31xA9p3pYE4&amp;t=2123s<\/a>&gt;.\n<\/div>\n<div id=\"ref-Lemire2019\" class=\"csl-entry\" role=\"doc-biblioentry\">\nLemire, D., 2019. <em>Building better software with better tools: Sanitizers versus valgrind<\/em>. [online] Available at: &lt;<a href=\"https:\/\/lemire.me\/blog\/2019\/05\/16\/building-better-software-with-better-tools-sanitizers-versus-valgrind\/\">https:\/\/lemire.me\/blog\/2019\/05\/16\/building-better-software-with-better-tools-sanitizers-versus-valgrind\/<\/a>&gt;.\n<\/div>\n<div id=\"ref-LiveOverflow2019\" class=\"csl-entry\" role=\"doc-biblioentry\">\nLiveOverflow, 2019. <em>File path race condition &amp; how to prevent it &#8211; bin 0x31<\/em>. [online] Available at: &lt;<a href=\"https:\/\/www.youtube.com\/watch?v=5g137gsB9Wk\">https:\/\/www.youtube.com\/watch?v=5g137gsB9Wk<\/a>&gt;.\n<\/div>\n<div id=\"ref-Lunduke2021\" class=\"csl-entry\" role=\"doc-biblioentry\">\nLunduke, B., 2021. <em>Linux sucks 2021<\/em>. [online] Available at: &lt;<a href=\"https:\/\/www.youtube.com\/watch?v=WtJ9T_IJOPE\">https:\/\/www.youtube.com\/watch?v=WtJ9T_IJOPE<\/a>&gt;.\n<\/div>\n<div id=\"ref-Milner1978\" class=\"csl-entry\" role=\"doc-biblioentry\">\nMilner, R., 1978. A theory of type polymorphism in programming. <em>Journal of Computer and System Sciences<\/em>, 17(3), pp.348\u2013375. <a href=\"https:\/\/doi.org\/10.1016\/0022-0000(78)90014-4\">https:\/\/doi.org\/10.1016\/0022-0000(78)90014-4<\/a>.\n<\/div>\n<div id=\"ref-MITConcurrency2021\" class=\"csl-entry\" role=\"doc-biblioentry\">\nMIT, 2021. <em>Two models for concurrent programming<\/em>. [online] Available at: &lt;<a href=\"http:\/\/web.mit.edu\/6.031\/www\/fa17\/classes\/19-concurrency\/\">http:\/\/web.mit.edu\/6.031\/www\/fa17\/classes\/19-concurrency\/<\/a>&gt;.\n<\/div>\n<div id=\"ref-Normand2019\" class=\"csl-entry\" role=\"doc-biblioentry\">\nNormand, E., 2019. <em>What are race conditions?<\/em> [online] Available at: &lt;<a href=\"https:\/\/www.youtube.com\/watch?v=i_eJzLRN0xc\">https:\/\/www.youtube.com\/watch?v=i_eJzLRN0xc<\/a>&gt;.\n<\/div>\n<div id=\"ref-OWASP2021\" class=\"csl-entry\" role=\"doc-biblioentry\">\nOWASP, 2021. <em>Using freed memory<\/em>. [online] Available at: &lt;<a href=\"https:\/\/owasp.org\/www-community\/vulnerabilities\/Using_freed_memory\">https:\/\/owasp.org\/www-community\/vulnerabilities\/Using_freed_memory<\/a>&gt;.\n<\/div>\n<div id=\"ref-Payer2017\" class=\"csl-entry\" role=\"doc-biblioentry\">\nPayer, M., 2017. <em>CS-527 software security memory safety<\/em>. [online] Available at: &lt;<a href=\"https:\/\/nebelwelt.net\/teaching\/17-527-SoftSec\/slides\/02-memory_safety.pdf\">https:\/\/nebelwelt.net\/teaching\/17-527-SoftSec\/slides\/02-memory_safety.pdf<\/a>&gt;.\n<\/div>\n<div id=\"ref-Pike2012\" class=\"csl-entry\" role=\"doc-biblioentry\">\nPike, R., 2012. <em>Concurrency is not parallelism<\/em>. [online] Available at: &lt;<a href=\"https:\/\/vimeo.com\/49718712\">https:\/\/vimeo.com\/49718712<\/a>&gt;.\n<\/div>\n<div id=\"ref-Rustonomicon2021\" class=\"csl-entry\" role=\"doc-biblioentry\">\nRustonomicon, 2021. <em>Data races and race conditions<\/em>. [online] Available at: &lt;<a href=\"https:\/\/doc.rust-lang.org\/nomicon\/races.html\">https:\/\/doc.rust-lang.org\/nomicon\/races.html<\/a>&gt;.\n<\/div>\n<div id=\"ref-Snowden2021\" class=\"csl-entry\" role=\"doc-biblioentry\">\nSnowden, E., 2021. <em>The insecurity industry<\/em>. [online] Available at: &lt;<a href=\"https:\/\/edwardsnowden.substack.com\/p\/ns-oh-god-how-is-this-legal\">https:\/\/edwardsnowden.substack.com\/p\/ns-oh-god-how-is-this-legal<\/a>&gt;.\n<\/div>\n<div id=\"ref-Stroustrup2020\" class=\"csl-entry\" role=\"doc-biblioentry\">\nStroustrup, B. and Regehr, J., 2020. <em>Ask me anything with bjarne stroustrup<\/em>. [online] Available at: &lt;<a href=\"https:\/\/www.youtube.com\/watch?v=Bycec3UQxOc\">https:\/\/www.youtube.com\/watch?v=Bycec3UQxOc<\/a>&gt;.\n<\/div>\n<div id=\"ref-Sutter2021\" class=\"csl-entry\" role=\"doc-biblioentry\">\nSutter, H. and Stroustrup, B., 2021. <em>C++ core guidelines<\/em>. [online] Available at: &lt;<a href=\"https:\/\/github.com\/isocpp\/CppCoreGuidelines\/blob\/master\/CppCoreGuidelines.md\">https:\/\/github.com\/isocpp\/CppCoreGuidelines\/blob\/master\/CppCoreGuidelines.md<\/a>&gt;.\n<\/div>\n<div id=\"ref-Szekeres2013\" class=\"csl-entry\" role=\"doc-biblioentry\">\nSzekeres, L., Payer, M., Wei, T. and Song, D., 2013. <span>SoK<\/span>: Eternal war in memory. In: <em>2013 <span>IEEE<\/span> symposium on security and privacy<\/em>. <span>IEEE<\/span>. <a href=\"https:\/\/doi.org\/10.1109\/sp.2013.13\">https:\/\/doi.org\/10.1109\/sp.2013.13<\/a>.\n<\/div>\n<div id=\"ref-WikiFuzz2021\" class=\"csl-entry\" role=\"doc-biblioentry\">\nWikipedia contributors, 2021a. <em>Fuzzing<\/em>. Available at: &lt;<a href=\"https:\/\/en.wikipedia.org\/wiki\/Fuzzing\">https:\/\/en.wikipedia.org\/wiki\/Fuzzing<\/a>&gt;.\n<\/div>\n<div id=\"ref-WikiNullptr2021\" class=\"csl-entry\" role=\"doc-biblioentry\">\nWikipedia contributors, 2021b. <em>Null pointer<\/em>. Available at: &lt;<a href=\"https:\/\/en.wikipedia.org\/w\/index.php?title=Null_pointer&amp;  oldid=1027733642\">https:\/\/en.wikipedia.org\/w\/index.php?title=Null_pointer&amp;  oldid=1027733642<\/a>&gt;.\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Over the last 20 years, developing secure software has become increasingly important. To this day, we write a significant amount of code in languages with manual memory management. However, the Peter Parker principle states that \u201cgreat power comes with great responsibility\u201d. Many scoring systems classify, enumerate and rank prevalence of known vulnerabilities. In theory, developers should be aware of common programming mistakes leading to these bugs. Yet, the last 20 years are living proof that manual memory management is highly error-prone. Because most systems share memory between data and instructions, controlling small portions of memory can be enough to take over entire systems (Szekeres et al., 2013). The fight over attacking and defending the security measures on top of unsafe systems is often called the eternal war in memory.<\/p>\n<p>In this blog post, I want to examine what properties make programming languages like C\/C++ fundamentally unsafe to use. After that, I briefly discuss the inadequacies of our defense mechanisms. Last of all, I reflect on the sociopolitical implications arising from the continued use of unsafe languagues.<\/p>\n","protected":false},"author":1045,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1,26],"tags":[],"ppma_author":[853],"class_list":["post-20309","post","type-post","status-publish","format-standard","hentry","category-allgemein","category-secure-systems"],"aioseo_notices":[],"jetpack_featured_media_url":"","jetpack-related-posts":[{"id":3084,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2017\/09\/05\/cloud-security-part-2-the-vulnerabilities-and-threats-of-the-cloud-current-scientific-work-on-cloud-security-conclusion-and-outlook\/","url_meta":{"origin":20309,"position":0},"title":"Cloud Security \u2013 Part 2: The vulnerabilities and threats of the cloud, current scientific work on cloud security, conclusion and outlook","author":"Andreas Fliehr","date":"5. September 2017","format":false,"excerpt":"The second of two blog posts about cloud security. This post covers the vulnerabilities and threats of the cloud, the current scientific work on cloud security and a conclusion and an outlook.","rel":"","context":"In &quot;Cloud Technologies&quot;","block_context":{"text":"Cloud Technologies","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/scalable-systems\/cloud-technologies\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2017\/09\/Structure-of-Nexen.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2017\/09\/Structure-of-Nexen.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2017\/09\/Structure-of-Nexen.png?resize=525%2C300&ssl=1 1.5x"},"classes":[]},{"id":25613,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2023\/08\/15\/the-hardest-boss-in-dark-souls-a-secure-multiplayer\/","url_meta":{"origin":20309,"position":1},"title":"The hardest boss in Dark Souls: A secure multiplayer","author":"Fabian Rei\u00dfer","date":"15. August 2023","format":false,"excerpt":"Over the course of the last decades, video games have continuously risen in popularity. Today, hundrets of thousands of people play video games every day. Many of these games have multiplayer, where an enormous amount of people play together at the same time. When thinking about 'hacking' in multiplayer games,\u2026","rel":"","context":"In &quot;Allgemein&quot;","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/08\/DS3.jpg?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/08\/DS3.jpg?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/08\/DS3.jpg?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/08\/DS3.jpg?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/08\/DS3.jpg?resize=1050%2C600&ssl=1 3x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/08\/DS3.jpg?resize=1400%2C800&ssl=1 4x"},"classes":[]},{"id":20850,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2021\/08\/30\/hafnium-exchange-server-attacks-what-happened-and-how-to-protect-yourself\/","url_meta":{"origin":20309,"position":2},"title":"HAFNIUM EXCHANGE SERVER ATTACKS &#8211; What happened and how to protect yourself","author":"Jannik Smidt","date":"30. August 2021","format":false,"excerpt":"an article by Carina Szkudlarek, Niklas Schildhauer and Jannik Smidt This post is going to review the zero day exploit of the Microsoft Exchange Servers starting in January 2021.It will look into the methods of SSRF and the exploitation of mistakes in the deserialization of input values to procure privileged\u2026","rel":"","context":"In &quot;Secure Systems&quot;","block_context":{"text":"Secure Systems","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/system-designs\/secure-systems\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/08\/5.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/08\/5.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/08\/5.png?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/08\/5.png?resize=700%2C400&ssl=1 2x"},"classes":[]},{"id":10939,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2020\/09\/11\/how-are-vulnerabilities-exploited-to-compromise-a-system\/","url_meta":{"origin":20309,"position":3},"title":"How are vulnerabilities exploited to compromise a system?","author":"Joel Beiter","date":"11. September 2020","format":false,"excerpt":"This article is a recap of the \"Live Hack\" presentation, held in the lecture \"Sichere Systeme\" in SS 2020. It will introduce different vulnerabilities like XSS and SQL-Injection and shows how passwords can be cracked under certain circumstances. The last step explains how a SUID binary was exploited to gain\u2026","rel":"","context":"In &quot;Secure Systems&quot;","block_context":{"text":"Secure Systems","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/system-designs\/secure-systems\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":5576,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2019\/03\/04\/improved-vulnerability-detection-using-deep-representation-learning\/","url_meta":{"origin":20309,"position":4},"title":"Improved Vulnerability Detection using Deep Representation Learning","author":"Daniel Bruckner","date":"4. March 2019","format":false,"excerpt":"Today's software is more vulnerable to cyber attacks than ever before. The number of recorded vulnerabilities has almost constantly increased since the early 90s. The advantage of Deep Learning algorithms is that they can learn vulnerability patterns on their own and achieve a much better vulnerability detection performance. In this\u2026","rel":"","context":"In &quot;Allgemein&quot;","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/03\/luca-bravo-217276-unsplash.jpg?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/03\/luca-bravo-217276-unsplash.jpg?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/03\/luca-bravo-217276-unsplash.jpg?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/03\/luca-bravo-217276-unsplash.jpg?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/03\/luca-bravo-217276-unsplash.jpg?resize=1050%2C600&ssl=1 3x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/03\/luca-bravo-217276-unsplash.jpg?resize=1400%2C800&ssl=1 4x"},"classes":[]},{"id":24936,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2023\/07\/17\/security-knockout-how-capcoms-street-fighter-5-punched-a-hole-in-intels-security-system\/","url_meta":{"origin":20309,"position":5},"title":"Security Knockout: How Capcom&#8217;s Street Fighter 5 punched a hole in Intel&#8217;s security system","author":"Frederik Omlor","date":"17. July 2023","format":false,"excerpt":"Games are usually built in order to optimize performance, not security. Nevertheless, they can be responsible for security vulnerabilities as well. This article shows how anti-cheat software, cheaters themselves and finally also game developers can cause harm to users systems.","rel":"","context":"In &quot;Secure Systems&quot;","block_context":{"text":"Secure Systems","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/system-designs\/secure-systems\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/07\/StreetFighterV-1.jpg?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/07\/StreetFighterV-1.jpg?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/07\/StreetFighterV-1.jpg?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/07\/StreetFighterV-1.jpg?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/07\/StreetFighterV-1.jpg?resize=1050%2C600&ssl=1 3x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/07\/StreetFighterV-1.jpg?resize=1400%2C800&ssl=1 4x"},"classes":[]}],"jetpack_sharing_enabled":true,"authors":[{"term_id":853,"user_id":1045,"is_guest":0,"slug":"jt057","display_name":"Jan-Niklas Tille","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/2ca4de938764d277f1783af679af106f5921a06844c984306259dcb4faed713b?s=96&d=mm&r=g","0":null,"1":"","2":"","3":"","4":"","5":"","6":"","7":"","8":""}],"_links":{"self":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/20309","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/users\/1045"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/comments?post=20309"}],"version-history":[{"count":92,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/20309\/revisions"}],"predecessor-version":[{"id":25363,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/20309\/revisions\/25363"}],"wp:attachment":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/media?parent=20309"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/categories?post=20309"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/tags?post=20309"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/ppma_author?post=20309"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}