Ende letzten Monats (Juli, 2021) hat die CWE (Common Weakness Enumeration) einen Bericht ver\u00f6ffentlicht, welcher die Top 25 der Software-Schwachstellen aufzeigt. Es handelt sich dabei um eine Auswertung von gefundenen Schwachstellen der letzten zwei Jahre in verschiedenen Software-Systemen. Der Bericht umfasst eine Liste der 40 schwerwiegensten Schwachstellen. Dabei handelt es sich um Schwachstellen, welche einfach zu finden oder auszunutzen sind, h\u00e4ufig vorkommen und \u00e4u\u00dferst wirkungsvoll und dementsprechend gef\u00e4hrlich sind. [1]<\/p>\n\n\n\n
Platz 1 der Liste wird von einer Speicher-Schwachstelle belegt, dem Out-Of-Bounds-Write dicht gefolgt vom Out-Of-Bounds-Read auf Platz 3. Insgesamt sind 7 der 40 vorgestellten Schwachstellen solche, welche aufgrund mangelnder Speicher-Sicherheit entstehen k\u00f6nnen. Andere gef\u00e4hrliche Schwachstellen entstehen aus Fehlern in der parallelen Programmierung sowie durch zu schwache Typ-Systeme in der verwendeten Programmier-Sprache. [1]<\/p>\n\n\n\n
Speicher-spezifische Software-Schwachstellen sind die mit am h\u00e4ufigsten vorkommenden Schwachstellen. Circa 70% der Schwachstellen in Systemen von Microsoft sind auf Speicher-Fehler zur\u00fcck zu f\u00fchren. [11]<\/p>\n\n\n\n
Andere Beispiele f\u00fcr die H\u00e4ufigkeit von Speicher-Fehlern sind der Exim-Mail-Server vergangenen Mai, bei dem 12 der 21 gefundenen Schwachstellen Speicher-spezifische Fehler waren. [12] Aber auch zwei schwerwiegende Sicherheits-L\u00fccken beim Samba-LDAP-Server vom M\u00e4rz diesen Jahres sind auf Speicher-Fehler in der Software zur\u00fcck zu f\u00fchren. [13] In der Webkit-Komponente von Apple’s MacOS wurde ebenfalls ein Speicher-Fehler in Form eines Puffer-\u00dcberlaufs entdeckt. [14]<\/p>\n\n\n\n\n\n\n\n
Code-Fehler im Programm f\u00fchren nicht nur zu sp\u00e4teren Sicherheits-L\u00fccken in der Anwendung, sondern erh\u00f6hen die Entwicklungs-Kosten, da ein gro\u00dfer Teil der Entwicklungs-Zeit f\u00fcr die Fehler-Behebung teils schwer zu findender Programm-Fehler investiert werden muss.<\/p>\n\n\n\n
Speicher-Fehler sowie Fehler in der parallelen Programmierung werden erm\u00f6glicht, wenn die verwendete Programmier-Sprache diesbez\u00fcglich zu schwache Restriktionen besitzt. In den weit verbreiteten alten System-Sprachen C und C++ wurde bewusst auf derartige Einschr\u00e4nkungen verzichtet, um eine m\u00f6glichst vollumf\u00e4ngliche Kontrolle \u00fcber die Anwendung und den verwendeten Speicher zu erhalten. Zudem soll damit auch die bestm\u00f6gliche Effizienz bez\u00fcglich dem Speicher-Verbrauch und der Laufzeit der Anwendung erm\u00f6glicht werden. Andere Programmier-Sprachen wie etwa Java besitzen eine gr\u00f6\u00dfere Sicherheit und vermeiden Speicher-Fehler zum gro\u00dfen Teil. Dadurch wird jedoch die Laufzeit beeintr\u00e4chtigt, aber vor allem der Speicher-Verbrauch durch Garbage-Collection stark erh\u00f6ht. Dies ist f\u00fcr den Gro\u00dfteil der heutigen Anwendungen au\u00dfreichend, vor allem, da die Hardware seit der Ver\u00f6ffentlichung von C schneller geworden ist und mehr Speicher zur Verf\u00fcgung stellt. F\u00fcr Performance-kritische Systeme wie beispielsweise Betriebssysteme, Firmware, Treiber oder eingebettete Systeme wird aber weiterhin C und C++ verwendet, da hier die komplette Kontrolle \u00fcber den Speicher sowie den Prozessor erm\u00f6glicht wird [38].<\/p>\n\n\n\n
Rust, eine weitere System-Sprache, welche seit 2010 existiert, versucht, die Schw\u00e4chen von C und C++ zu beseitigen und dennoch eine etwa gleichbleibende Performance zu C und C++ zu bieten. Dies ist jedoch im Kontrast zu der Annahme, dass Sicherheit, also zus\u00e4tzliche \u00dcberpr\u00fcfungen, nicht umsonst zu bekommen ist, also immer auch Nachteile wie etwa Performance-Reduzierung mit sich bringt.<\/p>\n\n\n\n
Daher ist das Ziel dieses Artikels, die Schwachstellen der Kategorien Memory-Safety, Thread-Safety sowie Type-Safety des Top 25-Artikels des CVE entsprechend zu analysieren. Es wird auf Nachteile aber auch die daraus resultierenden M\u00f6glichkeiten von C und C++ bez\u00fcglich der jeweiligen Schwachstelle eingegangen, aber auch ein L\u00f6sungs-Konzept in Rust f\u00fcr das entsprechende Problem beschrieben. Dabei wird unter anderem auf Performance und Speicher-Verbrauch geachtet, um herauszufinden, ob Rust die lang etablierten System-Sprachen in diesem Bereich in Zukunft ersetzen k\u00f6nnte.<\/p>\n\n\n\n
In folgender Tabelle ist eine \u00dcbersicht der f\u00fcr diesen Artikel relevanten Schwachstellen, sortiert nach den Sicherheits-Bereichen, gegeben. Die Schwachstellen ‘Out-Of-Bounds-Read<\/strong>‘ und ‘-Write’<\/strong> sowie ‘Improper Restriction of Operations within the Bounds of a Memory Buffer<\/strong>‘ werden zusammen in einem Kapitel behandelt, da diese gr\u00f6\u00dftenteils thematisch \u00fcbereinstimmen.<\/p>\n\n\n\n Im folgenden Kapitel wird zun\u00e4chst auf drei wichtige Konzepte in Rust eingegangen, auf welche in den darauffolgenden Kapiteln immer wieder Bezug genommen wird.<\/p>\n\n\n\n Um auf L\u00f6sungen seitens von Rust bez\u00fcglich der Schwachstellen Bezug zu nehmen, wird zun\u00e4chst ein wichtiges Konzept in Rust beschrieben. Dieses erm\u00f6glicht Memory-Safety ohne Garbage-Collection, was die Stabilit\u00e4t von Anwendungen mit gleichbleibender Performance bezogen auf C\/C++ erm\u00f6glicht. Dies wird durch eine Pr\u00fcfung zur Compile-Zeit erreicht.<\/p>\n\n\n\n Das Konzept dient als Zugangs-Kontrolle, um zu \u00fcberpr\u00fcfen, dass Code nicht auf beliebige Daten, sondern nur auf f\u00fcr ihn erlaubte Daten Zugriff hat. Das Ownership-Prinzip besagt, dass immer nur eine Variable gleichzeitig, eine bestimmte Ressource besitzen kann. Andere Variablen k\u00f6nnen diese Ressource ausleihen, um ebenfalls Zugriff zu erhalten. Dieses Prinzip wird Borrowing genannt. Wird eine Ressource neu erzeugt, so besitzt die Variable, der die Ressource zugewiesen wird, zun\u00e4chst die Verantwortung dar\u00fcber. Der Besitzer einer Ressource kann gewechselt werden, indem die Ressource \u00fcber eine Move-Operation, \u00e4hnlich wie in C++, einer anderen Variable, per Parameter zugewiesen oder als R\u00fcckgabe-Wert dem Aufrufer \u00fcbergeben wird [19].<\/p>\n\n\n\n Die Ressource ist an die verantwortliche Variable gebunden. Sollte die Variable zerst\u00f6rt werden, wird die Ressource automatisch mit zerst\u00f6rt beziehungsweise freigegeben. Zus\u00e4tzlich kann \u00fcber die besitzende Variable die Ressource ver\u00e4ndert werden [19].<\/p>\n\n\n\n Beim Borrowing wird eine Referenz auf die Ressource \u00fcbergeben, sodass eine andere Software-Komponente darauf zugreifen kann, ohne dass die Verantwortung \u00fcber die Ressource wechselt. Es wird dabei vom Compiler garantiert, dass die Referenz nicht \u00fcber die Lebenszeit der Ressource hinaus existiert. Sollten Referenz-Variablen l\u00e4nger existieren, wird ein Compiler-Fehler geworfen [19].<\/p>\n\n\n\n Es gibt zwei Arten von Referenzen, welche jeweils eigene Restriktionen und M\u00f6glichkeiten bieten. Immutable, also nicht ver\u00e4nderbare Referenzen auf eine Ressource k\u00f6nnen beliebig oft im Programm existieren, da hier keine der Zugriffe, die Ressource ver\u00e4ndern darf. Damit ist gew\u00e4hrleistet, dass alle Software-Komponenten mit der selben stabilen Version der Ressource arbeiten k\u00f6nnen, ohne dass sie sich zwischendurch ver\u00e4ndert. Solange eine immutable-Referenz existiert, darf die Ressource nicht ge\u00e4ndert werden [19].<\/p>\n\n\n\n Die andere Referenz-Art ist die ver\u00e4nderbare (mutable) Referenz. Existiert eine ver\u00e4nderbare Referenz, so darf es keine weitere mutable oder immutable Referenz geben. So wird garantiert, dass Software-Komponenten, welche eine unver\u00e4nderbare Referenz besitzen, davon aus gehen k\u00f6nnen, dass sich die Ressource w\u00e4hrend der Lebenszeit der Referenz nicht \u00e4ndert [19].<\/p>\n\n\n\n Rust f\u00fchrt die Move-Operation bei Zuweisungen oder Parameter-\u00dcbergaben automatisch aus, anders als in C++, wo das explizit geschrieben werden muss. Um jedoch einen Wert in Rust zu kopieren, muss eine spezielle Kopier-Funktion (.clone()) auf der Ressource aufgerufen werden [40][21].<\/p>\n\n\n\n Ein Beispiel, wie das Ownership-Modell m\u00f6gliche Speicher-Fehler verhindern kann, ist wie folgt gegeben.<\/p>\n\n\n\n Wenn die Main-Funktion ausgef\u00fchrt wird, wird zun\u00e4chst die ‘fct1<\/strong>‘-Funktion aufgerufen. Diese erzeugt ein Array und bef\u00fcllt es mit einem Element. Damit ist die Variable ‘vec’ zun\u00e4chst der Besitzer. Das Array wird am Schluss als R\u00fcckgabe-Wert zur\u00fcckgegeben. Da es sich um eine Move-Operation handelt, wird die Verantwortung \u00fcber das Array an die aufrufende Funktion \u00fcbergeben. In der Main-Funktion wird anschlie\u00dfend eine immutable Referenz an ‘fct2<\/strong>‘ \u00fcbergeben. Ist ‘fct2<\/strong>‘ fertig abgearbeitet, wird der Kontext aufger\u00e4umt und die Referenz auf die Ressource wieder zerst\u00f6rt. Am Schluss wird der dritten Funktion ‘fct3<\/strong>‘ das Array per Move-Operation als Parameter \u00fcbergeben, sodass nun der Besitzer der Ressource zu ‘fct3<\/strong>‘ wechselt. Kehrt ‘fct3<\/strong>‘ nun wieder zum Aufrufer zur\u00fcck, so wird das Array automatisch zerst\u00f6rt und beanspruchter Speicher wieder frei gegeben. Der Entwickler muss sich nun keine Gedanken mehr dar\u00fcber machen, welche Software-Komponente nun f\u00fcr das Freigeben von Speicher zust\u00e4ndig ist, oder ob noch Referenzen auf die Ressource existieren. All diese Pr\u00fcfungen werden zur Compilezeit durchgef\u00fchrt, sodass die Performance kaum betroffen ist. [19]<\/p>\n\n\n\n Folgendes Beispiel soll die Bedeutung von ‘clone()<\/strong>‘, also das Kopieren einer Ressource, verdeutlichen.<\/p>\n\n\n\n Zun\u00e4chst wird wieder ein Array erzeugt welches anschlie\u00dfend \u00fcber ‘clone()<\/strong>‘ kopiert wird. Dabei verbleibt die Verantwortung \u00fcber die alte Ressource bei ‘v1<\/strong>‘ und ‘v2<\/strong>‘ wird der Besitzer der neu erstellten Ressource. Danach wird jedoch die Verantwortung der zuerst erstellten Ressource per Move-Operation an ‘v3<\/strong>‘ \u00fcbergeben, wodurch ‘v1<\/strong>‘ invalide wird. Da ‘v1<\/strong>‘ invalide ist, gibt es auch keine Verantwortung mehr, welche der Variablen ‘v4<\/strong>‘ \u00fcbergeben werden k\u00f6nnte. Daher erzeugt der Rust-Compiler hier einen Fehler.<\/p>\n\n\n\n Pointer, wie sie in C oder C++ existieren, sind in Rust nur unter Einschr\u00e4nkungen nutzbar. Dies muss zus\u00e4tzlich dem Rust-Compiler explizit mitgeteilt werden, indem der unsichere Modus von Rust genutzt wird, was im folgenden Abschnitt n\u00e4her erl\u00e4utert wird.<\/p>\n\n\n\n F\u00fcr gew\u00f6hnlich werden aber Rust-Pointer wie Box<T><\/strong> verwendet, um eine Adresse auf eine Ressource zu verwalten. Hierbei dient Box<T><\/strong> als Wrapper-Objekt f\u00fcr die darunter liegende Speicher-Adresse. Wird der Pointer durch das Verlassen des Kontext zerst\u00f6rt, so wird die Ressource, auf die der Pointer zeigt, automatisch frei gegeben [25].<\/p>\n\n\n\n Rust besitzt einen sehr konservativen Compiler. Dies bedeutet, dass er auch funktionierenden Code nicht kompiliert, wenn dieser in einer anderen Anwendungs-Umgebung Fehler verursachen w\u00fcrde. Zus\u00e4tzlich ist der Entwickler an das Schreiben sicheren Codes gebunden, was bei Low-Level-Programmierung teilweise nicht m\u00f6glich ist, wenn mit der Hardware oder dem Betriebssystem kommuniziert werden soll, oder eigene Bibliothekserweiterungen geschrieben werden sollen [39].<\/p>\n\n\n\n Hierf\u00fcr bietet Rust eine M\u00f6glichkeit, unter gewissen Einschr\u00e4nkungen auch ausgew\u00e4hlte unsichere Aktionen wie C-\u00e4hnliche Pointer zu verwenden, um zum Beispiel mit C oder dem dem Betriebssystem zu kommunizieren. Diese M\u00f6glichkeit hei\u00dft Unsafe-Rust und muss bei Nutzung dem Rust-Compiler explizit mitgeteilt werden [39].<\/p>\n\n\n\n Memory-Safety ist die Eigenschaft einer Programmiersprache oder Anwendung, keine Sicherheits-Schwachstellen oder andere Programm-Fehler in Bezug auf Speicher-Zugriffe zu erm\u00f6glichen. [15]<\/p>\n\n\n\n C und C++ sind in diesem Fall klar Memory-Unsafe, da die Sprachen Pointer intern als ganz normale Integer behandeln. Dies bedeutet, dass als Speicher-Adresse ein beliebiger Wert angegeben werden kann, auf welchen versucht werden k\u00f6nnte, zuzugreifen. Zus\u00e4tzlich kann durch Pointer-Arithmetik beliebig mit den Adressen gerechnet werden. Das Objekt-Layout von Strukturen kann Byte f\u00fcr Byte gelesen und beschrieben werden, was beliebige M\u00f6glichkeiten der Programmierung mit sich bring, jedoch auch viel Platz f\u00fcr Speicher-Fehler bietet.<\/p>\n\n\n\n Eine auch als Buffer-Overflow oder Buffer-Overrun bzw. Buffer-Underflow bezeichnete Schwachstelle, bei der es m\u00f6glich ist, Speicher-Zugriffe au\u00dferhalb des im Kontext vorgesehenen Speicher-Bereichs zu t\u00e4tigen [1][2][3][7]. In Tabelle 2 ist ein Beispiel gegeben.<\/p>\n\n\n\n Die Variable ‘arr<\/strong>‘ ist dabei wie folgt definiert: int arr[7];<\/strong><\/p>\n\n\n\n In obigem Beispiel ist gut ersichtlich, dass C\/C++ bei Array-Operationen Pointer-Arithmetik zum Berechnen der Speicher-Adresse verwendet. Damit existiert keine \u00dcberpr\u00fcfung des Index zur Laufzeit. Da Adressen auch subtrahiert werden k\u00f6nnen, ist daher ein negativer Index in C\/C++ erlaubt.<\/p>\n\n\n\n Verhindert werden kann der Speicher-Fehler durch ‘Bounds-Checking<\/strong>‘, also dass \u00dcberpr\u00fcfen des Index bzw. der Position, an der im Speicher zugegriffen werden soll. Liegt die Position in einem validen Speicher-Bereich, kann im Programm-Code weiter fortgefahren werden, ansonsten sollte die Anwendung angehalten werden, um dem Entwickler die M\u00f6glichkeit zu geben, den Fehler schnellstm\u00f6glich zu finden, sowie weiteren Schaden f\u00fcr die Anwendung zu vermeiden [2][3][7].<\/p>\n\n\n\n Ein m\u00f6glicher ‘Bounds-Check<\/strong>‘ k\u00f6nnte dabei wie folgt aussehen:<\/p>\n\n\n\n Dies kann teilweise zur Compilezeit geschehen, wenn die gr\u00f6\u00dfe des Arrays bereits bekannt ist, teilweise aber auch erst zur Laufzeit durchgef\u00fchrt werden, wenn Speicher dynamisch zur Laufzeit allokiert wird. Um die Performance nicht allzu stark zu beeintr\u00e4chtigen, werden in der STL (Standard Template Library) von C++ oft zwei Varianten einer Funktion angeboten, eine mit und eine ohne ‘Bounds-Checking<\/strong>‘. Damit braucht nur dann getestet werden, wenn die Eingaben nicht vorher bestimmbar sind, wie die eines Benutzers. Ein Beispiel f\u00fcr verschiedene Funktions-Versionen sind hierbei ‘std::vector::at()’ f\u00fcr die sichere, sowie ‘std::vector::operator[]()’ f\u00fcr die unsichere Variante eines Array-Zugriffs [26]. Dies k\u00f6nnte aber weiterhin durch ein Makro erg\u00e4nzt werden, welches eine Typpr\u00fcfung ausschlie\u00dflich im Debug-Modus der Anwendung durchf\u00fchrt und im Release-Modus die \u00dcberpr\u00fcfung wegl\u00e4sst. Bei externen Eingaben muss aber nachwievor eine Eingabe-Validierung stattfinden.<\/p>\n\n\n\n Rust bietet im sicheren Modus mit Pointer-Wrappern wie ‘Box<T><\/strong>‘ keine M\u00f6glichkeit f\u00fcr Pointer-Arithmetik. Box<T><\/strong> verh\u00e4lt sich im Grunde \u00e4hnlich wie eine Referenz-Variable in Java, da die Speicher-Adresse fix ist [25]. Datenstrukturen wie der Vector der Standard-Bibliothek von Rust, welche Low-Level-Speicher-Verwaltung betreiben, f\u00fchren Bounds-Checking<\/strong> zur Laufzeit aus. Eine zweite Variante ohne Bounds-Checking<\/strong> existiert nicht, weil dies nicht sicher w\u00e4re [27].<\/p>\n\n\n\n Bei ‘Use-After-Free<\/strong>‘ handelt es sich um einen Speicher-Fehler, bei welchem versucht wird, auf einen bereits freigegebenen Speicher-Bereich zuzugreifen [4]. Dies kann sowohl auf dem Stack, als auch auf dem Heap passieren, wie folgendes Beispiel zeigt:<\/p>\n\n\n\n Vor allem in der manuellen Speicher-Verwaltung bez\u00fcglich dem Heap ist der Hauptgrund f\u00fcr diese Schwachstelle, dass es keine klare Rollenverteilung beziehungsweise Zust\u00e4ndigkeit gibt, die durch den Compiler gepr\u00fcft werden kann. Daher ist es die Aufgabe des Entwicklers, welche Komponenten f\u00fcr welchen Speicher-Bereich verantwortlich sind, diesen also freigeben d\u00fcrfen, was zu Speicher-Fehlern f\u00fchren kann.<\/p>\n\n\n\n Die Folgen belaufen sich bestenfalls auf einen Absturz der Anwendung durch eine Zugriffs-Verweigerung (Access-Violation) hin. Anderenfalls k\u00f6nnen sensible Daten wie Zugangs-Codes ausgelesen oder geschrieben werden, wenn sich die Daten an dieser Stelle noch im Speicher befinden, sowie Fremd-Code angesprungen und ausgef\u00fchrt werden. Das Manipulieren bereits freigegebener Speicher-Bereiche kann beliebige andere Software-Komponenten beeinflussen und f\u00fchrt daher zu undefiniertem Verhalten der Anwendung und daher auch teilweise zu Fehlern, welche nur schwer reproduzierbar sind [4].<\/p>\n\n\n\n Die einfachste L\u00f6sung f\u00fcr dieses Problem w\u00e4re, den Pointer nach der Freigabe auf Null zu setzen, um per Pr\u00fcfung zu erkennen, ob ein Pointer noch auf validen Speicher zeigt. Sollte ein Null-Pointer dereferenziert werden, wird eine Null-Pointer-Exception geworfen und die Anwendung beendet, was zu einer schnellen Erkennung des Fehler f\u00fchrt [4]. Diese L\u00f6sung liegt jedoch wieder in der Verantwortung des Entwicklers und kann daher vergessen werden. Desweiteren handelt es sich hier um eine weitere Zuweisung (p = nullptr;), welche evtl. auf manchen Systemen zu einer schlechteren Performance f\u00fchren k\u00f6nnte.<\/p>\n\n\n\n In obigem Beispiel wird der Variablen ‘str’ eine Referenz auf das erste Feld im Array zugewiesen. Dar\u00fcber wird am Schluss versucht, auf das erste Feld zuzugreifen, nachdem das Array ver\u00e4ndert wurde. Hierbei kann es passieren, dass die Referenz ung\u00fcltig wird und auf einen invaliden Speicher-Bereich zeigt. Dies ist dann der Fall, wenn im Array nicht gen\u00fcgent Speicher reserviert ist, um das nueue Element ‘world’ einzuf\u00fcgen. Dadurch muss ein neuer Speicher-Bereich allokiert werden, in welchen die alten Elemente und das Neue hinein kopiert werden. Der alte Speicher-Bereich wird anschlie\u00dfend frei gegeben. Die Referenz zeigt aber noch auf den frei gegebenen Speicher-Bereich. Wird die Referenz nun verwendet, besitzt diese Anwendung eine Use-After-Free-Schwachstelle mit den entsprechenden m\u00f6glichen Folgen. [21]<\/p>\n\n\n\n Rust kann durch das Ownership-Modell unter anderem Use-After-Free-Schwachstellen vermeiden, wie der Rust-Code im obigen Beispiel zeigt. Die Referenz ‘str<\/strong>‘ ist immutable. Wird die Ressource vom Inhaber der Ressource ver\u00e4ndert, darf auf die immutable Referenz nicht mehr zugegriffen werden. Dies wird zur Compilezeit gew\u00e4hrleistet. Dadurch verursacht obiger Code von Rust einen Compiler-Fehler, sodass ein m\u00f6glicher Speicher-Fehler von vornherein verhindert werden kann. Anzumerken ist noch, dass dieser Code in Rust generell nicht erlaubt ist, auch wenn der Entwickler garantieren kann, dass in dieser Situation gen\u00fcgend Speicher im Array vorhanden ist. Dadurch muss der Code an manchen Stellen evtl. umst\u00e4ndlicher geschrieben werden, verhindert aber Speicher-Fehler, ohne gro\u00dfartigen Performance-Verlust. [21]<\/p>\n\n\n\n Generell k\u00f6nnen die sicheren Rust-Pointer nicht auf invalide Speicher-Bereiche zeigen. Dar\u00fcber hinaus entspricht ‘Box<T><\/strong>‘ einem Pointer, welcher ausschlie\u00dflich auf Speicher im Heap zeigt. Daher sind im abgesicherten Modus von Rust, Pointer auf lokale Variablen nicht m\u00f6glich [25]. Eine m\u00f6gliche L\u00f6sung f\u00fcr Use-After-Free auf dem Stack ist daher wie folgt gegeben.<\/p>\n\n\n\n In obigem Beispiel wird im Heap speicher allokiert und mit dem Wert 4 der Variablen ‘x’ beschrieben. Anschlie\u00dfend wird der Pointer per Move-Operation der aufrufenden Routine \u00fcbergeben.<\/p>\n\n\n\n Hierbei handelt es sich um das Dereferenzieren eines Null-Pointers, was zum Absturz der Anwendung f\u00fchrt. Sollte der Prozess jedoch Rechte besitzen, auf die Speicher-Adresse 0 zuzugreifen, k\u00f6nnte auch hier externe Code-Ausf\u00fchrung m\u00f6glich sein. [6] Die Schwachstelle wird durch fehlende Abfragen beziehungsweise \u00dcberpr\u00fcfungen auf Null hervorgerufen, zum Beispiel, wenn Funktionen Null als R\u00fcckgabewert f\u00fcr einen Fehler zur\u00fcck geben. Null-Pointer-Dereferenzierung k\u00f6nnte aber auch durch konkurierende Threads entstehen. [6] Folgendes Beispiel, veranschaulicht die Schwachstelle:<\/p>\n\n\n\n Als L\u00f6sung in C\/C++ sollte der Pointer vor der Verwendung auf Null gepr\u00fcft werden und ggf. bei mehreren Threads der Zugriff zus\u00e4tzlich gelockt werden. Der Compiler kann den Programmierer hierbei auch verpflichten, uninitialisierte Pointer vor der ersten Verwendung zu initialisieren, jedoch nur wenn diese im selben Kontext definiert sind. [6]<\/p>\n\n\n\n Die sicheren Pointer von Rust wie ‘Box<T>’ k\u00f6nnen keinen Null-Wert besitzen. Eine Null-Pointer-Dereferenzierung ist dadurch ausgeschlossen. In Rust ist gew\u00e4hrleistet, das sichere Pointer auf einen validen Speicher-Bereich zeigen [25]. Ein Beispiel f\u00fcr Null-\u00e4hnliche Verarbeitung ist in der Rust-L\u00f6sung im nachsten Abschnitt gegeben.<\/p>\n\n\n\n Als Memory-Leak wird eine Schwachstelle bezeichnet, bei welcher eine Anwendung Speicher belegt, welcher f\u00fcr sie aber nicht erreichbar ist, da kein Pointer darauf zeigt. Dies kann bei der manuellen Speicherverwaltung im Heap passieren, wenn es vers\u00e4umt wurde den nicht mehr ben\u00f6tigten Speicher frei zu geben. Auch hier kann die unklare Zust\u00e4ndigkeit der Software-Komponenten f\u00fcr die jeweiligen Speicher-Bereiche eine Rolle spielen.[8] Folgendes Beispiel soll die Schwachstelle veranschaulichen:<\/p>\n\n\n\n Die Folgen dieser Schwachstelle sind das Verbrauchen von immer mehr Speicher. Dies f\u00fchrt irgendwann dazu, dass immer \u00f6ffters Speicher-Bereiche auf die Festplatte zur\u00fcck und neueSpeicher-Bereiche wieder herein geladen werden m\u00fcssen (Trashing). Hierbei erh\u00f6hen sich die Zugriffszeiten auf den Speicher, wobei die Anwendung auch einfrieren kann. Sollte nicht mehr gen\u00fcgen Speicher f\u00fcr die Anwendung verf\u00fcgbar sein, wird diese in der Regel vom Betriebssystem automatisch beendet. [8]<\/p>\n\n\n\n Das Verwenden einer automatischen Speicher-Verwaltung wie etwa Garbage-Collection ist eine m\u00f6gliche L\u00f6sung f\u00fcr das Problem. [8] Der gro\u00dfe Zusatz-Speicher, der dabei aber ben\u00f6tigt wird, ist f\u00fcr die System-Programmierung f\u00fcr SPeicher-sensible Anwendungen keine Option. Daher werden nur einzelne Bestandteile der automatischen Speicher-Verwaltung in C\/C++ verwendet, wie etwa dem Reference-Counting. [8]<\/p>\n\n\n\n Beim Reference-Counting werden die Referenzen auf Speicher-Bereiche gez\u00e4hlt, um zu erkennen, wann ein Speicher-Bereich nicht mehr referenziert wird und daher wieder frei gegeben werden kann. Dies wird normalerweise mit Objekten erreicht, welche sich nach au\u00dfen hin wie ein normaler Pointer verhalten, jedoch intern den Z\u00e4hler des referenzierten Objektes inkrementieren, wenn die Referenz zugewiesen wurde, und wieder dekrementieren, wenn die Referenz verloren geht. Dies erh\u00f6ht zwar auch den Speicher-Verbrauch und die Laufzeit, aber deutlich geringer, als bei der vollst\u00e4ndigen Garbage-Collection. Beispiele hierf\u00fcr sind die Smart-Pointer in C++ wie ‘std::shared_ptr’, und ‘std::unique_ptr’.<\/p>\n\n\n\n Aber auch Rust besitzt als m\u00f6gliche Technik, ‘Reference-Counting’ mittels Objekten wie ‘Rc<T><\/strong>‘ [22]. Sollte aber klar sein, dass einer Ressource immer nur eine verantwortliche Variable zugeteilt sein muss, kann auch ein einzelner Pointer wie ‘Box<T><\/strong>‘ verwendet werden, um Memory-Leaks zu verhindern. Rust kennt f\u00fcr sicheren Programmcode keine Null-Pointer. Um ein \u00e4hnliches Verhalten wie in C\/C++ zu erhalten, muss ‘Option<T><\/strong>‘ verwendet werden. ‘Option<T><\/strong>‘ ist ein Datentyp, welcher einen Wert von None, oder einen Wert von Some(x) annehmen kann. ‘x’ muss hierbei vom Typ T sein. Der Wert kann \u00fcber eine Switch-Kontrollstruktur abgefragt werden [24]. Folgendes Beispiel gibt eine L\u00f6sung f\u00fcr obigen C\/C++-Code in Rust mittels eines Box<T><\/strong>-Objekts sowie dem ‘Option<T><\/strong>‘-Wert.<\/p>\n\n\n\n In obigem Rust-Code wird die Funktion ‘fct<\/strong>‘ aufgerufen. Sollte in der Funktion ‘fct<\/strong>‘ der Wert ‘None<\/strong>‘ zur\u00fcckgegeben werden, wird durch das Ownership-Prinzip von Rust, der Pointer ‘Box<i8><\/strong>‘ automatisch zerst\u00f6rt, wodurch der Speicher-Bereich, auf den der Pointer zeigt, frei gegeben wird. Sollte jedoch ‘Some(x)<\/strong>‘ zur\u00fcck gegeben werden, wird die Verantwortung \u00fcber den ‘Box<i8><\/strong>‘-Wert an die aufrufende Funktion ‘main<\/strong>‘ \u00fcbergeben. Der R\u00fcckgabe-Wert kann dann \u00fcber ‘match<\/strong>‘, was in etwa einem ‘switch’ in C\/C++ entspricht, abgefragt werden. Bei ‘Some(x)<\/strong>‘ kann \u00fcber ‘x<\/strong>‘ auf den ‘Box<i8><\/strong>‘-Wert zugegriffen werden.<\/p>\n\n\n\n Bei bestimmten Datentypen wie zum Beispiel ‘Box<T><\/strong>‘ kann Rust eine Optimierung bez\u00fcglich der Speicher-Gr\u00f6\u00dfe des ‘Option<T><\/strong>‘-Wertes durchf\u00fchren. Hierbei wird garantiert, dass die Gr\u00f6\u00dfe von ‘Option<T><\/strong>‘ dem enthaltenen Datentyp ‘T’ entspricht. Damit gibt es bez\u00fcglich der Gr\u00f6\u00dfe keinen Overhead [24].<\/p>\n\n\n\n Beim Integer-\u00dcberlauf handelt es sich um einen normalen Zahlen-\u00dcberlauf aufgrund begrenzter Speicher-Kapazit\u00e4ten im Registern der CPU. Er entsteht, wenn der Ergebnisdatentyp zu klein f\u00fcr das Ergebnis der Berechnung oder einer Zuweisung ist und das Ergebnis somit abgeschnitten werden muss, um noch in den Speicher zu passen [28][5]. Der Integer-\u00dcberlauf ist in C\/C++ besonders gef\u00e4hrlich, da im Standard die genaue Gr\u00f6\u00dfe von Daten-Typen nicht festgelegt ist, also je nach eingesetztem Compiler unterschiedlich sein kann. [29] M\u00f6gliche Folgen k\u00f6nnen Out-Of-Bounds-Zugriffe sowie Endlosschleifen, aber auch unerwartetes System-Verhalten sein, bis hin zum Absturz der Anwendung [5]. Folgendes Beispiel soll das unbeabsichtigte Verf\u00e4lschen von Werten durch Code visualisieren:<\/p>\n\n\n\n Das auch solche Fehler zu schwerwiegenden Katastrophen f\u00fchren k\u00f6nnen, zeigt das Ungl\u00fcck der Ariane V88-Rakete, welche im Jahr 1996 kurz nach dem Start durch einen arithmetischen \u00dcberlauf in einem Steuermodul die Flugbahn verlie\u00df und zerst\u00f6rt werden musste. [16]<\/p>\n\n\n\n Zus\u00e4tzlich k\u00f6nnen Folge-Schwachstellen, wie etwa Out-Of-Bounds durch oben genannte Gegenma\u00dfnahmen entdeckt und somit R\u00fcckschl\u00fcsse auf die eigentliche Ursache, den Integer-Overflow, gezogen werden.<\/p>\n\n\n\n Microsoft bietet f\u00fcr C++ die SafeInt-Bibliothek an, mit welcher Ganzzahl-\u00dcberl\u00e4ufe bei arithmetischen Operationen oder Castings erkannt werden k\u00f6nnen. Hierbei k\u00f6nnen einzelne Funktionen, aber auch Objekte verwendet werden, welche die primitiven Datentypen kapseln. [17][5]<\/p>\n\n\n\n Rust verh\u00e4lt sich hier je nach Compiler-Einstellung anders. Wird das Projekt als Debug-Version erstellt, werden f\u00fcr die primitiven Datentypen zus\u00e4tzliche Pr\u00fcfungen bei arithmetischen Operationen eingebaut. Tritt ein arithmetischer \u00dcberlauf auf, so wird dies erkannt und die Anwendung mit einem Fehler beendet. Im Release-Modus werden keine zus\u00e4tzlichen Pr\u00fcfungen eingebaut, sodass Zahlen-\u00dcberl\u00e4ufe zur Laufzeit unbemerkt bleiben k\u00f6nnen, aber eine bessere Performance erzielt wird [23].<\/p>\n\n\n\n Sollten dennoch arithmetische Operationen auf Zahlen-\u00dcberl\u00e4ufe gepr\u00fcft werden, so existieren wie bei der SafeInt-Bibliothek auch, diverse Funktionen wie zum Beispiel ‘overflowing_add’, um f\u00fcr einzelne Berechnungen eine Pr\u00fcfung auf Integer-Overflows zu erm\u00f6glichen. Hierbei wird ein zus\u00e4tzlicher boolscher Wert zur\u00fcc gegeben, welcher angibt, ob es einen Overflow gab [23].<\/p>\n\n\n\n Rust ist daher sehr \u00e4hnlich zu den herk\u00f6mmlichen Sprachen und ignoriert standardm\u00e4\u00dfig das \u00dcberlaufen von Zahlen-Werten zur Laufzeit im Release-Modus.<\/p>\n\n\n\n Eine Programm-Komponente oder ein Programm werden als Thread-Safe bezeichnet, wenn diese von mehreren Threads parallel ausgef\u00fchrt werden k\u00f6nnen, ohne das erwartete Laufzeit-Verhalten der Anwendung zu ver\u00e4ndern, also keine Race-Condition besitzen. Unter anderem soll die Anwendung auch keine Deadlocks enthalten, was teilweise durch Callback-Funktionen aber nicht ganz auszuschlie\u00dfen ist. [18]<\/p>\n\n\n\n Hierbei handelt es sich um die typische Race-Condition. Eine Race-Condition liegt vor, wenn mehrere Threads einen nicht synchronisierten geteilten Speicher-Bereich beschreiben wollen. Dies f\u00fchrt zu unerwartetem und vor allem undefiniertem Verhalten, dessen Fehlerquelle teilweise sehr schwer zu finden ist, da der Fehler schlecht reproduzierbar ist. Weitere Folgen k\u00f6nnen das mehrfache Allokieren von Speicher sein, was zu Folgen des Memory-Leaks weiter oben im Artikel f\u00fchren w\u00fcrde. [9]<\/p>\n\n\n\n Eine einfache Race Condition k\u00f6nnte das Inkrementieren einer globalen Variable x sein, da es sich hierbei um keine atomare Operation handelt, also aus einzelnen Teilschritten besteht, welche unterbrochen werden k\u00f6nnen, wie in folgendem Beispiel gezeigt [30].<\/p>\n\n\n\n Der Ablauf einer m\u00f6glichen Race-Condition mit dieser Operation ist wie folgt gegeben. T1 und T2 sind zwei Threads. Die Aktion T1-1 bedeutet, dass Therad 1 die Aktion 1 ausf\u00fchrt, bezogen auf die drei Assembly-Befehle in obiger Tabelle.<\/p>\n\n\n\n In obigem Beispiel ist zu sehen, dass die letzte Zeile der Tabelle keine Wirkung hat, da der erste Thread noch auf einem veralteten Zustand der globalen Variablen gearbeitet hat.<\/p>\n\n\n\n C und C++ sowie Java und andere Sprachen unterst\u00fctzen verschiedene Synchronisations-Mechanismen, um einen exklusiven Zugriff auf geteilte Ressourcen in einer parallel ausf\u00fchrbaren Umgebung zu erm\u00f6glichen. Atomare Operationen sind hierbei die kleinste Synchronisations-Primitive, da es sich hierbei um Synchronisation auf Instruktions-Level handelt [30]. Aus atomaren Instruktionen k\u00f6nnen Locking-Mechanismen gebaut werden, welche gr\u00f6\u00dfere Code-Bereiche f\u00fcr nur einen Thread parallel ausf\u00fchrbar machen k\u00f6nnen, um den Synchronisations-Aufwand zu reduzieren [31]. Mutexes [32] und Semaphoren [33] bieten als Synchronisations-Objekte eine angenehme Anwendung diverser Patterns aus der parallelen Programmierung wie etwa ‘Producer\/Consumer’ [34].<\/p>\n\n\n\n Aber keine der Sprachen bis auf Rust hatte bisher Mechanismen in der Sprache eingebunden, um eine Thread-sichere Entwicklung zu gew\u00e4hrleisten. Das korrekte Locking beziehungsweise Synchronisieren in C\/C++ oder Java ist Aufgabe des Entwicklers. Zum Beispiel ist nicht gew\u00e4hrleistet, dass die geteilte Ressource nicht von einer anderen Stelle der Anwendung manipuliert werden kann.<\/p>\n\n\n\n Dem Versucht Rust entgegenzuwirken, indem in Rust ein Mutex immer an die zu sch\u00fctzende Ressource gekoppelt ist. Wird versucht, auf die Ressource zuzugreifen, muss die Ressource \u00fcber das Mutex angefragt werden. Es wird also garantiert, dass diese Ressource nie von zwei Threads parallel zugegriffen werden kann [19].<\/p>\n\n\n\n Ein weiterer Mechanismus von Rust ist das MutexGuard<T><\/strong>-Objekt, welches bei der Anfrage des Mutex nach dem Lock zur\u00fcck gegeben wird. Hierbei handelt es sich um ein Wrapper-Objekt \u00e4hnlich einem Scoped-Lock. Wenn das Objekt zerst\u00f6rt, also der Kontext oder die Funktion verlassen wird, wird die Ressource wieder \u00fcber das Mutex frei gegeben. Damit werden Deadlocks durch ein fehlendes unlock() vermieden. \u00dcber das MutexGuard-Objekt kann schlie\u00dflich auf die Ressource zugegriffen werden, wobei vom Compiler zur Compile-Zeit garantiert wird, dass die Referenz auf die Ressource nicht \u00fcber die Lebenszeit des MutexGuard hinaus \u00fcberlebt. Dadurch werden zum Beispiel Fehler wie der Zugriff auf die Ressource ohne Locking \u00fcber die Referenz vermieden [19]. Folgende Tabelle zeigt die daf\u00fcr n\u00f6tigen Funktionen in Rust, um eine Ressource \u00fcber das Mutex anzufragen.<\/p>\n\n\n\n Ein entsprechender Beispielcode f\u00fcr die Abfrage einer Ressource \u00fcber das Mutex-Objekt ist wie folgt gegeben:<\/p>\n\n\n\n Beim Erstellen von Threads bietet Rust weitere Sicherheiten, wie etwa den JoinGuard<T><\/strong>. Dieses Objekt verh\u00e4lt sich \u00e4hnlich wie der Scoped-Lock, ruft aber join(), anstatt unlock() im Destruktor auf, und auch nur wenn join() nicht bereits aufgerufen wurde. Damit k\u00f6nnen Referenzen auf Speicher-Inhalte des Stacks, welche den entsprechenden Threads bei der Erzeugung mitgegeben wurden, valide gehalten werden. Beim Verlassen des Kontext wird zun\u00e4chst auf alle erstellten Threads des Kontext gewartet und anschlie\u00dfend der Stack-Speicher frei gegeben. [19]<\/p>\n\n\n\n In folgendem Beispiel wird ein dynamisches Array (Vector) auf dem Stack erzeugt und bei der Erzeugung des Threads eine Referenz darauf \u00fcbergeben.<\/p>\n\n\n\n Soll nicht auf erzeugte Threads gewartet, also die Funktion direkt beendet werden, kann auch eine statische Pr\u00fcfung zur Compile-Zeit stattfinden. Hier ist es nun nicht mehr erlaubt, Referenzen auf dem Stack-Speicher dem Thread bei der Erzeugung mitzugeben [19].<\/p>\n\n\n\n Folgendes Beispiel w\u00fcrde nicht kompilieren und entspricht obigem Beispiel mit einer anderen Erzeugungs-Funktion ‘spawn’, welche die statische Pr\u00fcfung erm\u00f6glicht.<\/p>\n\n\n\nBereich<\/th> Platzierung<\/th> Schwachstelle<\/th> Name<\/th><\/tr><\/thead> Memory-Safety<\/td> 1<\/td> CWE-787<\/td> Out-of-Bounds Write<\/td><\/tr> Memory-Safety <\/td> 3<\/td> CWE-125<\/td> Out-of-bounds Read<\/td><\/tr> Memory-Safety <\/td> 17<\/td> CWE-119<\/td> Improper Restriction of Operations within the Bounds of a Memory Buffer<\/td><\/tr> Memory-Safety <\/td> 7<\/td> CWE-416<\/td> Use After Free (Dangling Pointer)<\/td><\/tr> Memory-Safety <\/td> 15<\/td> CWE-476<\/td> Null-Pointer Dereferenzierung<\/td><\/tr> Memory-Safety <\/td> 32<\/td> CWE-401<\/td> Missing Release of Memory after Effective Lifetime (Memory Leak)<\/td><\/tr> Memory-Safety <\/td> 12<\/td> CWE-190<\/td> Integer Overflow or Wraparound<\/td><\/tr> Thread-Safety<\/td> 33<\/td> CWE-362<\/td> Concurrent Execution using Shared Resource with Improper Synchronization (‘Race Condition’)<\/td><\/tr> Type-Safety<\/td> 36<\/td> CWE-843<\/td> Access of Resource Using Incompatible Type (‘Type Confusion’)<\/td><\/tr><\/tbody><\/table> Rust<\/h2>\n\n\n\n
Ownership-Modell<\/h3>\n\n\n\n
Borrowing (Referenzen)<\/h4>\n\n\n\n
Clone \/ Copy<\/h4>\n\n\n\n
Beispiele<\/h4>\n\n\n\n
fn fct1() -> Vec<i32>{<br> let mut vec = Vec::new();<br> vec.push(0);<br> vec \/\/ return with move<br>}<br>fc fct2(vec: &Vec<i32>){<br> \/\/ destroy reference<br>}<br>fc fct3(vec: Vec<i32>){<br> \/\/ destroy vec<br>}<br>fc main(){<br> let vec = fct1();<br> fct2(&vec); \/\/ pass reference<br> fct3(vec); \/\/ pass with move<br>}<\/code><\/pre><\/td><\/tr><\/tbody><\/table>let v1 = vec![1,2,3];<br>let v2 = v1.clone(); \/\/ copy<br>let v3 = v1; \/\/ move<br>let v4 = v1; \/\/ compiler error<\/code><\/td><\/tr><\/tbody><\/table>Rust-Pointer<\/h3>\n\n\n\n
Safe-Rust und Unsafe-Rust<\/h3>\n\n\n\n
Memory-Safety<\/h2>\n\n\n\n
CWE-787\/125: Out-Of-Bounds-Read \/ -Write | CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer<\/h3>\n\n\n\n
Typ<\/th> Array-Syntax (C\/C++)<\/th> Pointer-Syntax (C\/C++)<\/th> Assembly (MASM)<\/th><\/tr><\/thead> Out-Of-Bounds-Read<\/td> int i = arr[-1];<\/code><\/pre><\/td>int i = *(arr+(-1));<\/code><\/pre>
<\/td>mov r8d,dword ptr [arr-4]<br>mov dword ptr [i],r8d<\/code><\/pre><\/td><\/tr>Out-Of-Bounds-Write<\/td> arr[7] = i;<\/code><\/pre><\/td>*(arr+7) = i;<\/code><\/pre><\/td>mov r8d,dword ptr [i]<br>mov dword ptr [arr+28],r8d<\/code><\/pre><\/td><\/tr><\/tbody><\/table>bool boundsCheck = idx >= arr.size();<br>if (boundsCheck){<br> throw new OutOfBoundsException();<br>}<br>T v = arr[idx];<\/code><\/pre><\/td><\/tr><\/tbody><\/table>Rust-L\u00f6sung<\/h4>\n\n\n\n
CWE-416: Use After Free (Dangling Pointer)<\/h3>\n\n\n\n
Speicher-Art<\/th> Code (C\/C++)<\/th> Beschreibung<\/th><\/tr><\/thead> Stack<\/td> int* fct(){<br> int i = 4;<br> return &i;<br>}<\/code><\/pre><\/td>R\u00fcckgabe eines Pointers, welcher auf Stack-Speicher zeigt. Speicher wird automatisch bei Beendigung der Funktion frei gegeben.<\/td><\/tr> Heap<\/td> char *pBuffer = (char*)malloc(32);<br>free(pBuffer);<br>char i = pBuffer[4]; \/\/ read invalid data<br>pBuffer[8] = i; \/\/ write to invalid data<\/code><\/pre><\/td>Manuelle Speicher-Verwaltung: Anfrage und Freigabe des Speichers liegt in der Verantwortung des Programmierers.<\/td><\/tr><\/tbody><\/table> Rust-L\u00f6sung<\/h4>\n\n\n\n
C++<\/th> Rust<\/th><\/tr><\/thead> vector<string> v;<br>v.push_back("hello");<br>auto &str = v[0];<br>v.push_back("world");<br>cout << str.c_str() << endl;<\/code><\/pre><\/td>let mut v = vec![];<br>v.push("hello");<br>let str = &v[0];<br>v.push("world");<br>println!("{}",str);<\/code><\/pre><\/td><\/tr><\/tbody><\/table>fn fct() -> Box<i32> {<br> let x: i32 = 4;<br> Box<i32>::new(x)<br>}<\/code><\/pre><\/td><\/tr><\/tbody><\/table>CWE-476: Null-Pointer Dereferenzierung<\/h3>\n\n\n\n
Code (C\/C++)<\/th> Beschreibung<\/th><\/tr><\/thead> void fct(char *pIp){<br> char pHostName[64];<br> Obj *pHost = getHostByAddr(pIp);<br> strcpy(pHostName,pHost->m_name);<br> \/\/ ...<br>}<\/code><\/pre><\/td>Sollte die Adresse keinem Host zugeordnet werden k\u00f6nnen, wird ein Null-Pointer bei ‘getHostAddr()’ zur\u00fcck gegeben, was zu einer Null-Pointer-Dereferenzierung bei ‘pHost->m_name’ f\u00fchrt.<\/td><\/tr><\/tbody><\/table> Rust-L\u00f6sung<\/h4>\n\n\n\n
CWE-401: Missing Release of Memory after Effective Lifetime<\/h3>\n\n\n\n
Code (C\/C++)<\/th> Beschreibung<\/th><\/tr><\/thead> char* fct(){<br> char *pBuffer = (char*)malloc(size);<br> if (!bCond){<br> return nullptr;<br> }<br> return pBuffer;<br>}<\/code><\/pre><\/td>Sollte eine Bedingung ‘bCond’ fehlschlagen, wird direkt zur\u00fcck gekehrt, ohne den Speicher davor wieder frei zu geben.<\/td><\/tr><\/tbody><\/table> Rust-L\u00f6sung<\/h4>\n\n\n\n
fn fct() -> Option<Box<i8>> {<br> let x: Box<i8> = Box::new(5);<br> if !bCond {<br> None<br> }<br> Some(x)<br>}<br>fn main(){<br> let x = fct();<br> match x {<br> None => \/*handle nullptr*\/,<br> Some(x) => \/*handle valid value x*\/,<br> }<br>}<\/code><\/pre><\/td><\/tr><\/tbody><\/table>Optimierung: Null Pointer Optimization<\/h4>\n\n\n\n
CWE-190: Integer Overflow or Wraparound<\/h3>\n\n\n\n
Code (C\/C++)<\/th> Beschreibung<\/th><\/tr><\/thead> void fct(unsigned short val);<br>void fct2(){<br> unsigned int currAmount, transferAmount;<br> \/\/ ...<br> unsigned int newAmount = currAmount + transferAmount;<br> fct(newAmount);<br>}<\/code><\/pre><\/td>Wenn die Summe ‘currAmount’ gr\u00f6\u00dfer als der f\u00fcr ‘unsigned int’ m\u00f6gliche maximale Wert ist, entsteht ein falsches Ergebnis.
Sollte ‘currAmount’ gr\u00f6\u00dfer als f\u00fcr ‘unsigned short’ m\u00f6glich sein, wird das Ergebnis bei der Parameter-\u00dcbergabe teilweise abgeschnitten.<\/td><\/tr><\/tbody><\/table>Rust-L\u00f6sung<\/h4>\n\n\n\n
Thread-Safety<\/h2>\n\n\n\n
CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization (‘Race Condition’)<\/h3>\n\n\n\n
C++<\/th> MASM<\/th> MASM<\/th><\/tr><\/thead> ++x;<\/code><\/pre><\/td>inc dword ptr [x]<\/code><\/pre><\/td>mov eax,dword ptr [x]<br>inc eax<br>mov dword ptr [x],eax<\/code><\/pre><\/td><\/tr><\/tbody><\/table>Aktion<\/th> T1<\/th> T2<\/th> Speicher<\/th><\/tr><\/thead> –<\/td> –<\/td> –<\/td> 7<\/td><\/tr> T1-1<\/td> 7<\/td> –<\/td> 7<\/td><\/tr> T2-1<\/td> 7<\/td> 7<\/td> 7<\/td><\/tr> T2-2<\/td> 7<\/td> 8<\/td> 7<\/td><\/tr> T2-3<\/td> 7<\/td> 8<\/td> 8<\/td><\/tr> T1-2<\/td> 8<\/td> 8<\/td> 8<\/td><\/tr> T1-3<\/td> 8<\/td> 8<\/td> 8<\/td><\/tr><\/tbody><\/table> Mutexes und Locking in Rust<\/h4>\n\n\n\n
Code (Rust)<\/th> Beschreibung<\/th><\/tr><\/thead> fn mutex<T: Send>(t: T) -> Mutex<T>;<\/code><\/pre><\/td>Mutex-Erzeugung<\/td><\/tr> fn lock<T: Send>(mutex: &Mutex<T>) -> MutexGuard<T>;<\/code><\/pre><\/td>Lock-Anfrage<\/td><\/tr> fn access<T: Send>(guard: &mut MutexGuard<T>) -> &mut T;<\/code><\/pre><\/td>Ressourcen-Abfrage<\/td><\/tr><\/tbody><\/table> fn fct(mutex: &Mutex<T>){<br> let mut guard = lock(mutex);<br> let data = access(&mut guard);<br> \/\/ do something with data<br>}<\/code><\/pre><\/td><\/tr><\/tbody><\/table>Thread-Spawning<\/h4>\n\n\n\n
fn scoped<'a,T>(t: T) -> JoinGuard<'a> where F: 'a, ...<br><br>fn fct(){<br> let mut vec = Vec::new();<br> let guard = thread::scoped(|| {<br> fct2(&vec);<br> });<br>}<\/code><\/pre><\/td><\/tr><\/tbody><\/table>