{"id":29583,"date":"2022-12-09T16:04:56","date_gmt":"2022-12-09T14:04:56","guid":{"rendered":"https:\/\/www.kaspersky.de\/blog\/?p=29583"},"modified":"2022-12-09T16:04:56","modified_gmt":"2022-12-09T14:04:56","slug":"the-long-road-to-memory-safety","status":"publish","type":"post","link":"https:\/\/www.kaspersky.de\/blog\/the-long-road-to-memory-safety\/29583\/","title":{"rendered":"Der lange Weg zum sicheren Umgang mit RAM"},"content":{"rendered":"

Im November 2022 ver\u00f6ffentlichte die National Security Agency der Vereinigten Staaten ein Bulletin<\/a>, das ein klares Statement zum sicheren Umgang mit Arbeitsspeichern (RAM) setzt. Werfen wir einen Blick auf andere<\/a> NSA-Bulletins, stellen wir fest, dass diese sich in den meisten F\u00e4llen auf die Datenverschl\u00fcsselung oder den Schutz von Produktionsschleifen und andere organisatorische Fragen konzentrieren. Dass sich die NSA direkt an Softwareentwickler wendet, ist recht ungew\u00f6hnlich. Deshalb scheint es sich in diesem Ausnahmefall um ein besonders wichtiges Thema zu handeln. Im Grunde genommen fordert die NSA Softwareentwickler dazu auf, Programmiersprachen zu verwenden, deren Architektur eine h\u00f6here Sicherheit bei der Speicher-Arbeit bietet. Der Einsatz von C und C++ soll vor diesem Hintergrund vermieden werden. Dar\u00fcber hinaus wird empfohlen, eine Reihe von Ma\u00dfnahmen zu ergreifen, um Software auf Schwachstellen zu testen und deren Exploit zu verhindern.<\/p>\n

F\u00fcr Programmierer sind diese Dinge offensichtlich, und die Forderungen der NSA richten sich nicht direkt an sie, sondern an Unternehmensleitungen und -Vertreter. Lassen Sie uns, ohne auf technische Details einzugehen, die vorgebrachten Argumente analysieren.<\/p>\n

Speichersicherheit<\/h2>\n

Werfen wir zun\u00e4chst einen Blick auf unseren j\u00fcngsten Bericht<\/a> \u00fcber die Bedrohungsentwicklung im 3. Quartal 2022 und die Schwachstellen, die am h\u00e4ufigsten f\u00fcr Cyberangriffe genutzt werden. An erster Stelle steht nach wie vor die 2018 entdeckte Schwachstelle CVE-2018-0802<\/a> in der Komponente Equation Editor der Microsoft Office-Suite. Sie wird durch eine fehlerhafte Datenverarbeitung im RAM-Speicher verursacht, wodurch das \u00d6ffnen eines b\u00f6sartigen Microsoft Word-Dokuments zur Ausf\u00fchrung von beliebigem Code f\u00fchren kann. Eine weitere bei Cyberkriminellen beliebte Sicherheitsl\u00fccke ist CVE-2022-2294<\/a> in der WebRTC-Komponente des Google Chrome-Browsers. Sie f\u00fchrt aufgrund eines Puffer\u00fcberlauffehlers<\/a> zur Ausf\u00fchrung von beliebigem Code. Eine weitere Sicherheitsl\u00fccke \u2013 CVE-2022-2624<\/a> \u2013 im PDF-Viewer-Tool von Chrome kann ebenfalls zu einem Puffer\u00fcberlauf f\u00fchren.<\/p>\n

Nat\u00fcrlich sind nicht alle Software-Schwachstellen auf eine unzureichend gesicherte Handhabung des Arbeitsspeichers zur\u00fcckzuf\u00fchren, aber viele. Das NSA-Bulletin zitiert Statistiken<\/a> von Microsoft, wonach Fehler bei der Speicherverwaltung 70 % der entdeckten Schwachstellen verursachen.<\/p>\n

\"Microsoft-Statistiken

Microsoft-Statistiken zufolge sind zwei Drittel der Sicherheitsl\u00fccken Speicher-Bugs zu verschulden. Quelle.<\/p><\/div>\n

\u00a0<\/p>\n

Aber warum passiert so etwas? Wenn Speicherlecks ein so ernsthaftes Problem darstellen, warum h\u00f6ren wir dann nicht einfach auf, anf\u00e4lligen Code zu schreiben? Die Wurzel des Problems liegt in der Verwendung der Programmiersprachen C und C++. Ihre Architektur bietet Entwicklern viel Freiheit bei der RAM-Arbeit. Doch Freiheiten bringen immer auch Verantwortung mit sich. C\/C++-Programmierer m\u00fcssen selbst Mechanismen f\u00fcr das sichere Schreiben und Lesen von Daten implementieren. Andere hochrangige Programmiersprachen wie C#, Rust, Go und andere k\u00fcmmern sich jedoch automatisch darum. Der Punkt ist, dass beim Kompilieren des Programmquellcodes die Mittel f\u00fcr eine sichere Speicherhandhabung automatisch eingef\u00fchrt werden und die Entwickler keine Zeit mehr daf\u00fcr aufwenden m\u00fcssen. Um die Sicherheit zu verbessern, ergreift Rust zum Beispiel noch mehr Sicherheitsma\u00dfnahmen; dazu z\u00e4hlt unter anderem die Kompilierungsparalyse von potenziell gef\u00e4hrlichem Code und das Anzeigen von Fehlern f\u00fcr Programmierer.<\/p>\n

Nat\u00fcrlich ist es nicht realistisch, einfach auf C\/C++ zu verzichten, solange diese Sprachen f\u00fcr bestimmte Aufgaben unverzichtbar bleiben, beispielsweise wenn Code f\u00fcr MCUs oder andere Ger\u00e4te mit stark eingeschr\u00e4nkter Rechenleistung und Speichergr\u00f6\u00dfe ben\u00f6tigt wird. Unter sonst gleichen Bedingungen k\u00f6nnen hochrangigere Programmiersprachen des Weiteren zur Entwicklung von ressourcenintensiveren Programmen f\u00fchren. Doch die allgemeinen Bedrohungsstatistiken zeigen, dass Angriffe meist auf gew\u00f6hnliche Anwendersoftware (wie Browser und Texteditoren) abzielen, die auf sehr leistungsf\u00e4higen Computern l\u00e4uft (im Vergleich zu MCUs).<\/p>\n

Der Wechsel zu einer neuen Programmiersprache ist nicht ganz leicht<\/h2>\n

Dessen ist sich die NSA bewusst. Eine gro\u00dfe Datenbank mit Software, die in einer \u201eunsicheren\u201c Programmiersprache geschrieben wurde, kann nicht \u00fcber Nacht in eine andere Sprache portiert werden. Selbst wenn es darum geht, ein Softwareprodukt von Grund auf neu zu schreiben, kann es durchaus ein etabliertes Team, eine Infrastruktur und Entwicklungsmethoden f\u00fcr eine bestimmte Programmiersprache geben.<\/p>\n

Zum Vergleich: Stellen Sie sich vor, Sie m\u00fcssten aus Ihrem Haus ausziehen, nur weil es alt ist. Sie wissen jedoch, dass das Geb\u00e4ude absolut massiv ist und nur im Fall eines starken Erdbebens einst\u00fcrzen w\u00fcrde. Dazu kommt, dass Sie selbstverst\u00e4ndlich daran gew\u00f6hnt sind, dort zu leben \u2013 schlie\u00dflich ist es Ihr Zuhause. In einem Beitrag<\/a> stellt das Entwicklerteam von Google Chrome klar, dass es derzeit nicht m\u00f6glich ist, auf eine andere Programmiersprache mit integriertem Schutz (in diesem Fall Rust) umzusteigen. Dies k\u00f6nnte in Zukunft m\u00f6glich werden. Aber im Hier und Jetzt ist eine andere L\u00f6sung erforderlich.<\/p>\n

Im selben Beitrag der Google Chrome-Entwickler wird auch erkl\u00e4rt, warum man die Sicherheit von C\/C++-Code nicht grundlegend \u00e4ndern kann. Diese Programmiersprachen wurden schlichtweg nicht daf\u00fcr entwickelt, alle Kompilierungsprobleme auf einen Schlag zu l\u00f6sen. Aus diesem Grund werden im NSA-Bulletin zwei Alternativma\u00dfnahmen genannt:<\/p>\n