Vertrauenswürdiger Code

Shownotes

• Prolog: in der IT-Sicherheit meist der Angreifer im Vorteil, weil vielfache Wiederholung bzw. Fächerung von Angriffen vergleichsweise einfach ist und am Ende nur einer durchkommen muss

  • offensive Verteidigung ("Hackback") problematisch aufgrund schwieriger Attributierung (wenn der Angreifer keine offensichtlichen Fehler macht), also defensive Strategien notwendig
  • bisher zur Angriffsseite: STP049 Schadcode, STP051 Ablauf eines IT-Angriffs
  • bisher zur Verteidigungsseite: STP023 Virtualisierung (und darin Sandboxing), STP038 Software-Tests, STP078/080 Common Weakness Enumeration
  • heute heben wir wieder den Schild anstelle des Schwertes

• Code Signing

  • Idee: nur Code aus vertrauenswürdigen Quellen ausführen
  • vgl. STP048: Vertrauen klassischerweise durch eine PKI nach X.509 (analog zu Transportverschlüsselung TLS bei Webseiten)
  • als Wurzelzertifikatsautorität tritt der Plattformbetreiber auf, z.B. der App-Store-Betreiber oder bei Kerneltreibern der Betriebssystem-Hersteller

• Seitenleiste: die entsprechenden Signaturschlüssel sind sicherheitskritisch und werden heutzutage meist in HSM (Hardware-Sicherheitsmodulen) aufbewahrt

• Problem: Was bringt eine signierte Programmdatei, wenn die Ausführungsumgebung schon kompromittiert ist?

  • Idee: Secure Boot und vergleichbare Technologien
  • schon der Prozessor selber kann beim Start Code-Signaturen prüfen, ab dann Code Signing auf allen Ebenen über das Betriebssystem bis zum Anwendungsprogramm

• Vorteile von Code Signing und Secure Boot:

  • verhindert bestimmte Einschlesungspfade für Malware (z.B. wenn man "libreoffice download" sucht und nicht die offizielle LibreOffice-Webseite findet, sondern eine legitim wirkende Virenschleuder)
  • verhindert bestimmte Methoden für Lateral Movement und Persistierung (selbst wenn ein Prozess kompromittiert ist, kann er nicht zum Beispiel neue Programmdateien mit Malware auf die Platte schreiben und ausführen)

• Nachteile von Code Signing und Secure Boot:

  • kein perfekter Schutz (aber was ist das schon)
  • Ablauf des signierenden Zertifikats könnte ansonsten unveränderte Systeme funktionsunfähig machen -> deswegen bei Code Signing meist nur Prüfung auf "Signatur vor Ablauf", nicht auf "aktuelle Zeit vor Ablauf"
  • erlaubt Willkür seitens der Geräte- bzw. Betriebssystemhersteller (siehe z.B. Entfernung von ICEBlock aus dem iOS-App-Store)
  • zieht Eigentümerschaft am Gerät in Zweifel; vgl. Jay Freemans Diktum von "Felony Contempt of Business Model" ("verbrecherische Missachtung des Geschäftsmodells") zur Beschreibung des Effektes von DMCA Section 1201 und vergleichbaren Gesetzen (in Dtl. § 95a UrhG), welches die Umgehung von "wirksamen technischen Maßnahmen" zum Schutz von Urheberrechten kriminalisiert

• ganz anderer Ansatz: Reduktion der Trusted Computing Base (TCB) ("vertrauenswürdige Rechenbasis" bzw. eher "der man vertrauen muss")

  • TCB: "die Gesamtmenge an Hardware und Software, die für den sicheren Betrieb eines Systems essentiell sind"
  • nicht ganz dasselbe wie "weniger Programmcode = weniger Programmierfehler"
  • z.B. bei Sandboxing ist nur die Sandbox selber Teil der PCB; Code innerhalb der Sandbox sollte dann (hoffentlich!) auch im Fehler- oder Infektionsfall keinen Schaden anrichten können
  • praktisches Beispiel: in meinem LDAP-Server Portunus gibt es einen Teil, der mit Root-Rechten ausgeführt werden muss; dort habe ich mal reguläre Ausdrücke (vgl. STP021) durch explizite Parser ersetzt, weil das Entfernen der Regex-Bibliothek das Root-Binary um 10-15% verkleinert hat
  • Randbemerkung: TCB-Reduktion ist auch, warum ich lieber 100 Zeilen Code selber schreibe, als eine Bibliothek zu importieren, die die eine Sache macht, die ich brauche... und dann noch zig andere Sachen mit unzähligen weiteren Abhängigkeiten (Symbolbild)

• Videoempfehlung für diese Art, über Software nachzudenken: Fefe über "Das Nützlich-Unbedenklich-Spektrum"

  • in den Lektionen einiger Überlapp mit "Vom Mythos des Mann-Monats" (vgl. STP068/STP074/082)
  • aber mit deprimierendem Einschlag: "Angenommen, jemand findet einen Weg, besser mit Komplexität umzugehen. Was passiert dann? Schreiben wir dann alle die alte Software neu, aber besser? Nein! Wir schreiben dann neue, noch größere Software. Wieder am Limit dessen, was mit den neuen Methoden machbar ist." (Der Talk ist von 2019. Jede Parallele zu Coding-Agenten ist rein zufällig.)
  • Xyrills Favorit: die Wortprägung "Bugwelle" für die immer größer werdende Flut von Bugreports, die ein langlaufendes Softwareprojekt vor sich herschiebt