Wurster et al. [WO09] merkt ebenfalls eine vernachlässigte Betrachtung des Prozesses der Software-Installation an. Auf Grund der verliehenen Rechte „können leicht beliebige Systemkonfigurationen“ während der Installation durchgeführt werden. Dies birgt ein Risiko der Ausnutzung in sich. Sein Ansatz beschreibt eine Abspaltung der Berechtigung zur Systemkonfiguration von den Superuser-Privilegien. Die Rechte zur Systemkonfiguration überträgt er an einen einzigen Dienst configd. Dieser Dienst erhält alle Anfragen zur Modifikation der Systemdateien und speichert sie in einer Warteschlange. Insbesondere auch Änderungen mit der Benutzerkennung root werden an configd weitergeleitet. Durch die Ausführung potentiell gefährlicher Software-Installer leitet Wurster et al. eingangs eine nötige Trennung der Privilegien ab. Daraus ergeben sich für root Einschränkungen, die weit über das Zeitfenster der Installation hinausbestehen bleiben. Bei unserer kontrollierten Software-Installation findet solch eine dauerhafte Einschränkung des Superusers nicht statt. Einzig die Privilegien des ausgeführten Installationsprozesses setzen wir herab; sie entsprechen der Berechtigung eines normalen Benutzers.

Bei Wurster et al. erfolgt die Ausführung des Installationsprozesses weiterhin unterder Benutzerkennung root. Seiner Theorie nach, nimmt configd alle durch die Installation hervorgerufenen Systemänderungen entgegen und speichert sie. Ist die Installation abgeschlossen, authentifiziert sich der Benutzer mit einem zuvor durch configd erstellten USB-Schlüssel. Unter Benutzerinteraktion nimmt der Dienst die Abarbeitung der aufgelaufenen Anfragen vor. Er zeigt auf der Konsole die angeforderten Systemänderungen, in Form von Pfadangaben, nacheinander an. Der Benutzer kann jeweils zustimmen oder ablehnen. Erst mit Zustimmung führt der Dienst tatsächlich Modifikationen am System aus.

Wurster et al. merkt an, dass Paketmanager die zukünftige Verwendung von configd erleichtern. Unserer Auffassung nach führt sein Ansatz bei vielen Paketinstallationen zu vermehrten Abbrüchen. Wie folgt skizzieren wir unsere Annahme.

Gegeben sei der Installationsprozesses _inst und die Menge seiner systemmodifizierenden Operationen OP = {op₁,...,op_n}. Angenommen _inst besitzt Anzahl k viele, unterschiedliche op_j ∈ OP, die erst nach op_i ∈ OP ausgeführt werden (können), für i < j und k > 0.

Also muss der Benutzer die Installation k-mal ausführen unter der Bedingung gleich oft die zwischengespeicherten Systemänderungen per USB-Schlüssel autorisieren zu müssen. Sonst ist kein Installationsfortschritt möglich.

Daneben weist Wurster et al. auf ein Problem bei der Benutzerinteraktion hin: Viele Benutzer stufen die von configd präsentierten Informationen als unzureichend ein. Als mögliche Erweiterung sieht er die Fähigkeit Beschreibungen zu gewissen Pfadangabenhinzufügen zu können. Unsere kontrollierte Software-Installation hingegen unterscheidet bereits jetzt drei Sicherheitskategorien. Die Einteilung der installationsbedingten Modifikationen erfolgt automatisiert und ist hilfreich.

Auf mögliche Sicherheitslücken untersucht Cappos et al. [CSBH08] zehn verbreitete Paketmanager, darunter auch APT. Er nimmt in seinem Angriffsszenario an, dass ein Angreifer auf Client-Anfragen von Paketmanagern antworten kann. Dadurch ergeben sich unterschiedliche Angriffsvektoren:

• a) Arbitrary Package: Anstelle des angeforderten Pakets liefert der Angreifer ein Eigenes aus.
• b) Replay Attack: Eine ältere Version des Pakets wird ausgeliefert. Diese ist zwar korrekt signiert, enthält aber eine Verwundbarkeit. Der Angreifer kennt diese Sicherheitslücke und nutzt sie anschließend, um das System zu kompromittieren.
• c) Freeze Attack: Dem Client werden Aktualisierungen vorenthalten. Sein System friert somit in einem Zustand ein, der möglicherweise verwundbar ist.
• d) Extraneous Dependencies: Ursprünglich nicht angeforderte Pakete werden ausgeliefert. Durch eine bekannte Verwundbarkeit ermöglichen sie den Einstieg in das System.
• e) Endless Data: Der Angreifer sendet einen unendlichen Strom an Paketdaten zurück. Der Speicher der Clientmaschine wird vollkommen verbraucht und diese stürzt folglich ab.

Die Angriffe finden in der Phase des Bezuges der Paketdaten statt. Jedoch wird inden Fällen a), b) und d) eine Installation zur Schädigung ausgeführt. Unsere kontrollierte Software-Installation erfasst keine Pakete, die auf Grund ihrer veralteten Version eine Verwundbarkeit aufweisen. Die durch Cappos et al. erstellten Bedrohungen dienen als klare Abgrenzung zu unserer Ausarbeitung. Ferner erweitern wir unseren Untersuchungskontext auch über die Grenzen der offiziellen Distributionsquellen hinaus.

Es existieren weitere Arbeiten und Softwareentwicklungen, die das Thema der Systemsicherheit bei Paketinstallationen tangieren. Stellvertretend für viele ähnliche Lösungen, nennen wir Tripwire[Tri10]. Es überwacht die Systemintegrität wiefolgt.

Zu einem als sicher¹⁾ bewerteten Zeitpunkt t_i generiert dieses Werkzeug mit der Funktion w() zu jeder Datei d_j einen Hashwert w(d_i)_ti, für 1 ≤ j ≤ n. Diesen legt es in einer internen Datenbank _ti ab. Nach einer durchgeführten Paketinstallation zum Zeitpunkt t_i+1 erkennt es anschließend die am System ausgeführten Modifikationen. Tripwire vergleicht die Hashwertemenge _ti = {w(d₁)_ti,...,w(d_n)_ti} mit der gespeicherten Menge _ti+1 = {w(d₁)_ti+1,...,w(d_n)_ti+1}. Es fand eine Modifikation von d_j statt, wenn w(d_j)_ti ≠ w(d_j)_ti+1 gilt.

Tripwire untersucht alle Dateien auf Veränderung. Unsere kontrollierte Software-Installation hingegen legt die Modifikationen ausschließlich unterhalb des rw-Ordners an. Wir müssen dadurch deutlich weniger Dateien begutachten als Tripwire, um die paketinstallationsbedingten Veränderungen festzustellen.

Außerdem verhindert unsere kontrollierte Software-Installation eine Änderung des Betriebssystems. Der durch Tripwire genutzte reaktive Sicherheitsmechanismus hingegen wird erst nach einer Änderung aktiv. Hierdurch lässt es potentiell schädliche Modifikation am System zu, die schwerwiegende Folgen haben können.

Mit Hilfe von Skoudis et al.[SZ03] skizzieren wir, dass diese verzögerte Alarmierung genutzt werden kann, um die Systemintegrität unbemerkt zu verletzen. Während einer Paketinstallation fügt ein darin enthaltenes Rootkit dem System ein böses Kernel-Modul hinzu ²⁾. Dieses ermöglicht Systemaufrufe wie 'SYS_open'' oder 'SYS_read' nach Belieben umzuleiten. Erfolgt ein Systemaufruf durch Tripwire, referenziert der Kernel die originale Datei. Tripwire stellt den gleichen Hashwert fest. Bei anderen Aufrufern führt der Kernel eine schädliche Version aus.

• Zusammenfassung
• Einführung
• Vergleichbare Arbeiten
• Hintergrund
• kontrollierte Installation
• Ausblick und Schlusswort