YES —_ NLUB Ein DEN DIENSTGEBRAUCH

   

Bild 4: Flussdiagramm für Entschlüsselung eines Headers

Volume einhängen

Wurde ein - Volume erfolgreich geöffnet, so muss es danach noch
betriebssystemabhängig eingehängt werden, um dem Nutzer zur Verfügung zu
stehen.

Unter Windows wird das Einhängen direkt durch den Gerätetreiber durchgeführt,
sodass das Volume dann als eigenes Laufwerk zur Verfügung steht. \

Unter Linux hängt der Vorgang davon ab, ob der Linux Device Mapper genutzt
werden soll (wenn kryptografische Algorithmen des Kernels genutzt werden sollen),
oder die FUSE-Implementierung von TrueCrypt. -

Wird der Linux Device Mapper verwendet, so wird zunächst ein Loop Device
aufgesetzt, falls das Volume dateibasiert ist (für Partitionen/Geräte entfällt dieser
Schritt). Dann wird der Device Mapper für das Volume konfiguriert (erhäft u.a. das
Master Secret aus dem entschlüsselten Header sowie Informationen über den
verwendeten Algorithmus/Betriebsmodus) und das entstehende Mapper Device
eingehängt.

See 2 ven Ta ı 20:0

VS NUR FÜR DEN DIENSTGEBRAUCH

Wird die FUSE-Implementierung genutzt, so wird vor dem eigentlichen Öffnen des
Volumes zunächst ein Verzeichnis im temporären Verzeichnis des Systems angelegt,
dorthin das TrueCrypt-FUSE-Dateisystem gemountet und mit den nötigen
Parametem zum Öffnen versorgt. War das Öffnen erfolgreich, so wird für eine
spezielle Datei in diesem Dateisystem ein Loop Device aufgesetzt, dass dann
eingehängt wird. °

Anmerkung: Wurde im Schritt Volume öffnen ein Volume mit Hidden Volume
Protection angefordert, so wird Immer die FUSE-Implementierung zum Einhängen
benutzt, weil nur mit dieser Implementierung der Schutz des Hidden Volumes vor
Überschreiben sichergestellt werden kann.

Volumezugriff Lesen/Schreiben

Der Datenfluss beim Lese-. und Schreibzugriff hängt davon ab, welches

Betriebssystem mit welchen Einstellungen zum Einsatz kommt (siehe auch Volume
öffnen). : :

“ Unter Windows läuft die gesamte Abwicklung über den TrueCrypt-Gerätefreiber.

Hierfür registriert der Treiber sogenannte Filter für den Zugriff auf Volumes und
Devices. Das Filtersystem ist ein natives Interface vom Windows Device Driver Kit
um //O von Devices oder Volumes durch eine zusätzliche Implementierung zu filtern.
TrueCrypt nutzt dieses Interface, um die nötigen /O-Operationen durchzuführen, sich
Zustände der. einzelnen ‚Geräte zu merken und die Devices/Volumes betreffende
Kerneloperationen zu implementieren.

Seite 22 von 7 | 20:0

TrueGrypt Kemel Oriver

 
 

pasa requestio
underiying device

I

    
  
    

 

  

vO (encıyptad)
anne 2]
Volume

Bild 5: /O Schichten für TrueCrypt unter
Windows \

 

Um die Ver- bzw. Entschlüsselung abzuwickeln, fügt der DriveFilter den VO Request
in die EncryptedioQueue ein, die dem Gerät/Volume zugeordnet ist. Dort werden die
eigentlichen kryptografischen Aktionen sowie die WO auf das verschlüsselte
Device/File durchgeführt (siehe auch Bild 5).

Unter Linux ist der Betriebsmodus mit dem Linux Device Mapper (Bild 6 links) von
dem mit FUSE (Bild 6 rechts) zu unterscheiden. Kommt der Linux Device Mapper
zum Einsatz, so läuft die VO direkt über diesen Device Mapper im Kernel. Dort findet
die Ver- bzw. Entschlüsselung statt, Handelt es sich um eine verschlüsselte Partition
oder Disk, so findet dann die verschlüsselte /O direkt mit diesem Gerät statt. Bei
einem dateibasierten Volume ist ein Umweg über ein Linux Loop Device erforderlich,
welches die Datei als Device zur Verfügung stellt. .

Kommt statt dem Device Mapper jedoch FUSE zum Einsatz, so findet die VO immer
auf einem Loop Device statt. Dieses Loop Device leitet die VO auf eine spezielle
Datei „volume“ weiter; die sich im zuvor eingehängten FUSE Dateisystem für dieses
Volume befindet. Die TrueCrypt-FUSE-Implementierung ‘kann Lese- und
Schreibzugriffe auf diese Datei abfangen und so intern die Ver- und Entschlüsselung,
sowie die /O auf das verschlüsselte Volume durchführen,

ve LP END HER nIc

 

Bild 6: /O Schichten unter Linux mit Device Mapper (links) und FUSE (rechts)

Passwort ändern

Das Ändern des Passworts entspricht bei TrueCrypt einer Umverschlüsselung des
entsprechenden Headers. Das bisherige Passwort ist also zwingend erforderlich, da
sonst die entschlüsselte Version des Headers für eine Newverschlüsselung nicht
vorliegt. Folgende Schritte werden für die Änderung des Passworts ausgeführt: |

Eingabe des alten und neuen Passworts
Auswahl der Hashfunktion für PBKDF2
Erzeugung eines neuen Salts
Neuverschlüsselung des Headers

DT =

Unter Windows liegt die Implementierung hierfür im Common-Subsystem in der
Password-Komponente (Funktion ChangePwd)..

Unter Linux liegt die Kernimplementierung hier in der Klasse CoreBase im Core-
Subsystem {Funktion ChangePassword) _ unter Verwendung der
ReEnceryptHeader-Funktion in der Volume-Klasse.

Header sichern/wiederherstellen

Die Funktionalität zum Sichern und Wiederherstellen von Volume-Headern ist auf
Windows und Linux getrennt implementiert, beide Implementierungen sind jedoch
semantisch ähnlich und führen folgende Aktionen zum Sichern durch:

a Entschlüsseln des bisherigen Headers .
*  Neuverschlüsselung des bisherigen Headers mit neuem Salt

« Falls ein Hidden Volume vorhanden ist,.werden die beiden Aktionen für den
Hidden Volume Header wiederholt, ansonsten wird dieser Platz im Backup mit
Zufallsdaten. initialisiert (der Nutzer muss angeben, ob ein Hidden Volume
vorhanden ist). i

« Die neu verschlüsselten Header werden in einer externen Datei gespeichert.

Zum Wiederherstellen kann der User zunächst wählen, ob aus dem internen Backup
(am Ende des Volumes), oder einer externen Backupdatei wiederherstellen möchte,
Der Header wird, wie beim Sichern auch, zunächst geöffnet und dann mit neuem Salt
verschlüsselt geschrieben. '

Unter Windows befindet sich die Implementierung hierfür im Mount-Subsystem in den
Funktionen Backup/RestoreVolumeHeader ().

Unter Linux liegt die Implementierung stattdessen im Main-Subsystem in der Klasse
TextUserInterface (Funktionen Backup/RestoreVolumeHeaders () }-

Sicheres Löschen/Überschreiben

TrueCrypt implementiert in der Wipe-Komponente des Common-Subsystems
mehrere Algorithmen zum sicheren Löschen von Daten (Übersicht der Algorithmen in
2.12 ). Diese werden jedoch ausschließlich verwendet, um bei der Verschlüsselung
bestehender Daten die Klartextdaten zu löschen, bevor sie mit der verschlüsselten
Variante überschrieben werden.

Siehe Sicheres Löschen von Volumes für eine Erweiterung von TrueCrypt zum
sicheren Löschen von Containem/Headern.

1.1.7. Designbewertung und Auffälligkeiten

Auffällig am Design ist, dass es praktisch aus zwei Designs besteht. Vermutlich
wurde das erste Design (wenig objektorientiert) nur für Windows geschrieben. Es
besteht hauptsächlich aus C-Code und wird bis zum jetzigen Zeitpunkt weiterhin für
Windows verwendet. Das zweite Design wurde offenbar nachträglich hinzugefügt,

nachdem TrueCrypt auf andere Betriebssysteme, wie z.B. Unix und Derivate, portiert
werden sollte. Dieses Design ist deutlich stärker objektorientiert und. darauf
ausgerichtet, unterschiedliche Plattformen einfach zu unterstützen. Es ist nahezu
vollständig in C++ geschrieben. \

Es ist zu vermuten, dass der jetzige Windowscode zu einem späteren Zeitpunkt
ebenfalls in das neue Design integriert werden soll.

1.1.8 Sicherheitsrelevante Designschwächen

Least Privilege Prinzip

TrueCrypt bietet sowohl unter Windows als auch unter Unix die Möglichkeit, sich für
bestimmte Aktionen erhöhte Rechte zu beschaffen. Unter Windows wird hierfür VAC
(User Account Control) verwendet, unter ‚unixartigen Systemen führt TrueCrypt
mittels „sudo“ eine zweite Instanz von sich selbst aus, welche bedingt durch spezielle
Parameter nur einen „CoreService“ betreibt, der dann bestimmte Aktionen mit
‚Rootrechten ausführt. Hierfür muss zumindest das Ausführen von TrueCrypt mit dem
entsprechenden Parameter mit „sudo“ für den User erlaubt sein.

Problematisch ist dies, wenn TrueCrypt in einer Umgebung eingesetzt wird, in der
mehrere User das Produkt (auf dem gleichen Rechner) verwenden sollen. In einer
solchen Situation darf kein User vollen Rootzugriff erhalten. Es liegt aber nahe, den
Usern per „sudo“ generell das Ausführen von TrueCrypt zu erlauben. In diesem Falle
prüft TrueCrypt nicht, ob erhöhte Privilegien nicht benötigt werden und startet ggf.
auch Browser und andere Anwendungen als root (siehe auch POS02-C, Cert Secure
Coding Standard).

Ein Konfigurationsfehler kann so sehr einfach zu vollem Rootzugriff durch TrueCrypt

führen. Die Sicherheit des CoreService-Interfaces muss gesondert geprüft werden
(siehe 1.2.5). en

Bewertung: In einer Mehrbenutzerumgebung besteht das Risiko einer
‚Falschkonfiguration durch administratives Personal (moderat). In einer Umgebung,

in der der Nutzer sowieso vollen Rootzugriff erhalten soll, ist das ‚Problem nicht
relevant. . | "

CoreService Designfehler

Wie im letzten Abschnitt bereits beschrieben, ist der sogenannte CoreService der Teil
von TrueCrypt, der letztendlich unter Rootrechten läuft, falls dies erforderlich ist.
Dazu muss dieser Teil (also mindestens der Befehl truecrypt --core-service)
mittels sudo startbar sein. Wie auch schon zuvor beschrieben, ist es hier wichtig,

dass jeder einzelne Nutzer keine vollen Rootrechte hat, sofern mehrere Nutzer das
‚Produkt am gleichen Rechner nutzen sollen.

Das Design des CoreService erlaubt es jedoch jedem Benutzer, der den CoreService
mit Rootrechten mittels sudo ausführen darf, auch volle Rootrechte zu erlangen:
Über die SetFileOwnerRequest-Anforderung kann TrueCrypt den CoreService dazu
veranlassen, den Besitzer einer bestimmten Datei zu ändem. Dies wird

Seite 20 von 7 En | 20:0

normalerweise dazu verwendet, um Mountpoints nach dem Einhängen dem Benutzer
zugänglich zu machen. Jedoch kann der Benutzer auch selbst beliebige
Anforderungen an den CoreService stellen und somit u.a. von jeder beliebigen Datei
den Besitzer beliebig ändern.

Bewertung: In einer Mehrbenutzerumgebung kann jeder Benutzer vollen Rootzugriff
erhalten (kritisch). In einer Umgebüng, in der der Nutzer sowieso vollen Rootzugriff
erhalten soll, ist das Problem nicht relevant. :

1.1.9 Sicherheitsrelevante Codeschwächen

Veraltete/Unsichere Funktionen

In MSC34-C des Cert Secure Coding Standard werden eine Reihe von C-Funktionen
aufgelistet, die als veraltet oder unsicher gelten und daher nicht mehr verwendet
werden sollten. Hierzu zählen u.a. auch bekannte Funktionen wie strepy, strcat und
ihre Widecharacter-Äquivalente. Ein Beispiel, wo eine solche Funktion sogar mit
einer Variable verwendet wird, die aus einer anderen Funktion übergeben wird, findet
sich z.B. im Mount-Subsystem:

 

Mount /Mount..c Line 3363 ff.

static BOOL Mount (HWND hwndDlg, int nDosDriveNo, char
*szFileName) {

strepy (PasswordDlgVolume, szFileName);

 

 

Weiterhin hat TrueCrypt sogar eigene unsichere Funktionen im gleichen Stil, hierzu
zählen z.B. z.B. Upper/LowerCaseCopy:

Common/Dlgeoda.c Line B22lrr®
void UpperCaseCopy [char *IpszDest, const char *lpszSource)

int i = strlen (lpszSource);
lpszDest [i] = 0;

while (--i >= 0)

{

lpszDest[i] = (char) toupper {lpszSource[i]);

 

 

Sorte 27 von 7 En | 20:0

YS— NUR EÜR DEN DIENSTGEBRAUCH

Diese Funktionen haben keinerlei Informationen über die Größe des Zielpuffers,

kopieren aber trotzdem alle Daten des Quellpuffers (siehe ARR33-C des Cert Secure
Coding Standard). ze

Die Verwendung solcher Funktionen sollte generell vermieden werden. Bekannte
Funktionen können über statische Analyse (z.B. flawfinder / rats) gefunden werden.
Eigene Implementierungen solcher Funktionen sollten neu geschrieben werden.

Unsichere Umgebungsvariablen /execvp() ohne Pfadangaben

Der Cert Secure Coding Standard gibt vor, dass Umgebungsvariablen grundsätzlich
als ungeprüft angesehen werden müssen, und daher vor allem beim Starten von
externen Programmen das Environment geprüft werden muss (siehe ENVO3-C).
TrueCrypt fügt hierfür bestimmte Pfade in die PATH-Variable ein, um zu erzwingen,
dass Programmaufrufe aus diesem Pfad gewählt werden:

Main/Unix/Main.cpp Line 30 ££.

\// Make sure all required commands can be executed via
‚default search path

\string sysPathstr = "/usr/sbin:/sbin:/usr/bin:/bin";

Ichar *sysPath = getenv ("PATH");
ji {sysPath)

|
sysPathStr += ":!";
sysPathStr += sysPath;
}

 

setenv ("PATH”, sysPathStr.c_str(), 1);

 

Problematisch ist. hier, dass die eigene Pfadvariable weiterhin im PATH enthalten ist.
Zwar wird der PATH durch sudo in seiner‘ Defaulteinstellung zurückgesetzt
(env_reset), dennoch sollte die Sicherheit des Codes nicht auf der Konfiguration
von sudo beruhen. Alle externen Programme, die von TrueCrypt gestartet werden,
werden ohne Pfadangaben gestartet. Liegt das Programm also im Suchpfad aus
irgendeinem Grund nicht vor, so kann möglicherweise Programmcode des Angreifers

ausgeführt werden.
Modprobe Umgebungsvariable

Direkt zusammenhängend zum vorhergehenden Problem steht ein Problem mit
modprobe und Umgebungsvariablen. Unter Linux liest modprobe standardmäßig
seine Argumente auch aus der Umgebungsvariable MODPROBE_OPTIONS. Da

Seite 28 von 7a VE | 20:0

man über diese Argumente auch den Ort angeben kann, aus dem die jeweiligen
Kemelmodule geladen werden sollen, kann man so TrueCrypt dazu veranlassen,
eigene Kernelmodule zu laden (TrueCrypt lädt standardmäßig unter Linux die
Kemelmodule für den Device Mapper).

In einer Mehrbenutzerumgebung, in der einzelne User keine vollen Rootrechte haben
sollen, kann dies eine kritische Sicherheitslücke darstellen, sofern sudo nicht so
konfiguriert ist, dass alle Umgebungsvariablen zurückgesetzt werden {env_reset).

Um das Problem zu lösen, muss entweder die Environment-Variable von TrueCrypt
selbst gefiltert werden (zu empfehlen), oder ein statischer Kernel verwendet werden,
der von Haus aus keinerlei Module erlaubt.

Off-by-one Overflow

Die im Plafform-Subsystem enthaltene Implementierung von Process: :Execute
enthält einen Off-by-one-Overflow:

 

‚Platform/Unix/Process.cpp Line 25 f£.

|string Process:;:Execute (const string &processName, const list
<string> Sarguments, int timeOut, ProcessExecFunctor *execFunctor,
‚const Buffer *inputData) {

char *args[32];
if (array capacity (args) <= arguments.size())
throw ParameterTooLarge (SRC_POS):

int argIndex = 0;
ıf (lexecFunctor)

args [argIndext+] = const cast <char*> (processName.c_str(}):

foreach (const string &arg, arguments) {

(un = nulliptr;

args[argIndex++] = const_cast <chart> (arg.c_strt());

Im letzten Schritt wird args [argIndex] mit NULL überschrieben, wobei argIndex
hier maximal den Wert 32 haben karın (was einem off-by-one Fehler entspricht). Da
args als erste Variable auf dem Funktionsstack liegt, wird hier der Stack Frame
Pointer überschrieben, was zu einem Crash führen kann. Kann die Adresse NULL

DT U —=

alloziert werden, ist diese Schwachstelle auch exploitbar.

1.1.10 . Bewertung

Auffällig ist, dass die meisten Designschwächen im Linuxcode (d.h. im neuen
Design) zu finden sind. Dies ist hauptsächlich dadurch erklärbar, dass zum einen der
Code sehr viel neuer und jünger ist, zum anderen aber auch die Entwickler offenbar
mehr Erfahrung mit der Windowsplattform haben.

Bei einer oberflächlichen Analyse des Windows Gerätetreibers, insbesondere der
extern zugänglichen VO Befehle, konnten bislang keine nennenswerten
Designschwächen entdeckt werden.

Die Existenz von Codeschwächen im Windowscode hingegen ist hauptsächlich
dadurch zu erklären, dass als Sprache hier C verwendet wird. und der Code
gewachsen ist.

1.1.11. Empfehlung

Sowohl Design- als auch Codeschwächen müssen genauer analysiert werden. Ein
vollständiger Reviewprozess für alle betroffenen Codestellen, ggf. unterstützt durch
statische Analyse muss durchgeführt werden. -

Ideal wäre eine Behebung aller Design- und Codeschwächen durch den Einsatz von
sicheren Funktionen und der gezielten Abgabe von Privilegien. Eine vollständige
Umsetzung. des Cert Secure Coding Standards ist anzuraten. Hier sind für die
Beseitigung von Codeschwächen (z.B. Verwendung veralteter Funktionen) ca. 8
Personentage pro Betriebssystem zu veranschlagen. Eine genaue Abschätzung der
durchzuführenden Arbeiten ist jedoch ohne ein vollständiges Codereview nicht
abschließend durchführbar.

Die Designschwachstelle im CoreService (nur Linux) erfordert vermutlich eine
komplette Designüberarbeitung, sofern das Produkt in einer Mehrbenutzerumgebung
unter Linux ohne administrativen Zugriff jedes Benutzers eingesetzt werden soll. Hier
sind mindestens 14 Personentage für eine Ausbesserung zu veranschlagen.

1.2 Functional Specification

Im folgenden werden die einzelnen extern sichtbaren Schnittstellen, ihre Parameter,
Sicherheitsleistungen und Fehlermeldungen dargestellt.

1.2.1 Entrypoints (Windows)

Wie zuvor beschrieben, ‚besitzt TrueCrypt unter Windows zwei Entrypoints, zum
einen die Mount-Anwendung, zum anderen den Formatter.

1.2.2 Entrypoints (Unix)

Unter unixbasierten Systemen wird die Anwendung ausschließlich über die zuvor
beschriebene Main-Methode gestartet. Bei Angabe des Kommandozeilenparameters
„-core-service wird der Betrieb als Core Service aufgenommen, siehe dazu 1.2,5

DT 22