Virtuelle Brunnenvergifter

Posted by Jesco Freund at March 3, 2008 5:05 p.m.

FreeBSD hat ihn, Open- und NetBSD auch. Gentoo hat noch ein bisschen „age“ draufgepackt und gleich das Basissystem plus Kernel mit hineingepackt. Die Rede ist vom Ports- oder Portage-Tree, einem Verzeichnisbaum voller Bauanleitungen und Patches, der bei den genannten Betriebssystemen das herkömmliche Paketverwaltungssystem à la RPM, PKG, DEB etc. ersetzt oder ergänzt. Soweit nichts ungewöhnliches, doch unter bestimmten Umständen kann ein solcher Source Tree zum Angriffsvektor werden.

Kombiniert man eines der genannten Systeme mit einer nahezu beliebigen Virtualisierungstechnik (egal ob Xen, OpenVZ, Jails oder einfach nur gehärtete Chroot-Umgebungen), erscheint es schon bei einigen wenigen Instanzen interessant, den Quellenbaum nur einmal zentral für alle Instanzen vorzuhalten – das spart nicht nur Speicherplatz, sondern auch Bandbreite, und zwar in erheblichem Maße. Allerdings ist der gemeinsame Source Tree, egal ob über NFS oder mount-bindings bereitgestellt, nun auch von jeder virtuellen Instanz aus zugänglich. Die Kompromittierung eines virtuellen Subsystems könnte also auch die Kompromittierung des Ports- oder Portage Trees nach sich ziehen und einer Angriffsform Tür und Tor öffnen, die man als Ports Tree Poisoning bezeichnen kann. Hierbei wird gezielt ein Metapaket manipuliert (z. B. ein zusätzlicher Patch mit untergeschoben), wobei auch Digest-Files und das ggf. vorhandene Changelog mit angepasst werden, um die Paketverwaltungswerkzeuge zu überlisten. Gelingt dies einem Angreifer bei einem Port oder ebuild, der in wahrscheinlich allen virtuellen Instanzen installiert ist (ein gutes Ziel wäre eines der Paketmanagement-Tools selbst, OpenSSH o. ä.), bestehen große Chancen, dass der Admin des Systems mit dem nächsten Update aus der vergifteten Quelle schöpft und damit dem Angreifer sprichwörtlich die Schlüssel zum System überreicht.

Die Gefahr für ein solches Horrorszenario stellt sich je nach System allerdings ein wenig unterschiedlich dar. Bei Gentoo Linux etwa könnte der Portage-Tree den virtuellen Instanzen read-only zur Verfügung gestellt werden – kein Problem, da emerge die Kompilier-Arbeit in /var/tmp erledigt und nicht in einem Unterverzeichnis des ebuilds. Außerdem erfolgt die Synchronisierung des Portage-Trees mittels rsync; dabei wird der gesamte Tree überprüft und Fremdkörper zuverlässig entfernt. Entsprechende Sorgfalt vorausgesetzt, spricht hier also wenig gegen Source Tree Sharing – ein (minimales) Restrisiko besteht dennoch.

Deutlich risikoreicher nimmt sich die Lage bei FreeBSD aus: Der Ports-Tree darf nicht read-only sein, da das kompilieren der Pakete in einem Unterverzeichnis (./work) des jeweiligen Ports erfolgt. Updates des Ports-Trees erfolgen entweder direkt per CVS (csup bzw. cvsup) oder über Patches (portsnap). Dabei werden aber nur Änderungen übermittelt, die am zentralen Ports-Tree vorgenommen wurden. Manipulationen an nicht von Updates betroffenen Ports fallen hingegen nicht auf und werden auch nicht überschrieben. Ports Tree Sharing für FreeBSD Jails ist also indiskutabel, wenn das betreffende System zumindest minimalen Sicherheitsanforderungen genügen soll.

Fazit: Wird eine OS-Level-Virtualisierung à la Jails eingesetzt, um die Gesamtsicherheit eines Systems zu erhöhen, sollte man sich diesen Sicherheitsgewinn nicht durch unbedachte „Tunnel“ zunichte machen. Auch wenn Ports- und Portage-Tree sich auf den ersten Blick stark ähneln – es sind die Details in der Implementierung, die hier über sicher oder nicht sicher entscheiden.

2 comments | Defined tags for this entry: FreeBSD, Gentoo, security, hardware virtualization

Comments