Hadmut Danisch
Ansichten eines Informatikers

Linux und seine Sicherheitsideologen…

Hadmut
10.9.2006 19:59
Broken by Design, Security

Linux-Kernel kompiliere ich seit fast dem Anfang von Linux an. Damals, als die Kompilation noch den ganzen Mann erforderte und die erste Linux-Distribution noch auf ein paar Disketten paßte. Ich kompiliere Linux-Kernel bis heute.

Und zwar als Root. Ich hole sie von Kernel.org, prüfe die Signatur, packe sie in /usr/src aus, make config, make , make install usw. Daß die Zugriffsrechte und UID/GID der Sourcen dabei teils chaotisch sind, ist mir schon öfters aufgefallen, aber ich habe es mir nie in der Tiefe angesehen oder drüber nachgedacht. chmod und gut is.

Bis ich mal eine fremde Maschine sicherheitsuntersucht habe und ein Scanscript festgestellt hat, daß sämtliche Dateien und Verzeichnisse world-writable sind, zusammen so über 20.000. Übel. Der Admin hatte sie genauso ausgepackt wie ich immer, aber nicht das chmod mitgemacht. Ich habs selbst wohl auch schon gelegentlich vergessen. Sowas ist echt übel:

  • Ein Angreifer, der in irgendeinen Dämon eindringt (Pufferüberlauf, PHP, sonstwas) hat sofort Platz, um völlig ungestört Dateien abzulegen, z. B. Binaries für den nächsten Kerneleinbruch, Linux hat ja genug davon.
  • Der Angreifer könnte die Makefiles ändern um irgendetwas beim nächsten Mal von Root ausführen zu lassen.
  • Der Angreifer könnte den Kernel selbst modifzieren.

Alles üble Sachen. Wie kommt es also? Ich habe mir die Kernel-tarballs mal näher angeguckt und festgestellt, daß sie tatsächlich für alle Dateien und Verzeichnisse die Zugriffsrechte 0666 bzw. 0777 haben, als für alle Welt schreibbar sind. Und zwar schon mindestens seit einigen Kernel-Versionen. Wer macht denn sowas? Muß ja ein grobes Versehen sein. Warum hat das noch niemand gemerkt?
Also hab ich mal den Maintainer des Kernel-Servers angemailt. Es interessierte ihn nicht. Ich könnte es ja mal auf der Kernel-Maintainer-Liste probieren, ob es da vielleicht irgendwen interessiert. Da kam ich mir dann schon etwas veralbert vor. Da spürt man schon so eine sicherheitsgefährliche Grund-Ignoranz. Ich hab das Problem deshalb mal auf Full-disclosure und Bugtraq gepostet. Dann habe ich mein blaues Wunder erlebt. Ich bin aus dem Staunen noch nicht wieder heraus. Auf den Listen und auch per direkter E-Mail wurde ich wegen des Hinweises regelrecht niedergeknüppelt, teils beschimpft und beleidigt, und mir attestiert, daß ich von Security und Linux überhaupt keine Ahnung hätte. Wie ich nur eine solche Frage wagen könnte. Die Zugriffsrechte sind absichtlich so gesetzt, aber einen triftigen Grund nennt man dafür nicht. Würde sich Microsoft so etwas erlauben, würde jeder gleich “Hidden Backdoor” schreien. Ich wurde zugeschüttet mit einer Flut von Argumenten, bei dem einem nur das kalte Grausen kommen kann. Ein paar File-Permissions sehe ich mittlerweile als vernachlässigbares Übel an. Das wirkliche Sicherheitsproblem dürften eher die Leute sein, die sich im Linux-Sicherheitsumfeld herumtreiben.

Ich will mal so die diversen Argumente, die mir an den Kopf geworfen wurden, lose und ohne bestimmte Reihenfolge zusammenstellen:

  • Die Frage hätten schon so viele Leute vor mir gestellt. Ich wäre dumm, sie erneut zu stellen.Ja und? Das Problem besteht immer noch. Als ob sich ein Angreifer davon abhalten ließe, daß die Frage schon so oft gestellt würde.
  • Wie ich dazu käme, eine Frage zu stellen, ohne vorher Google gefragt zu haben. Diverse Links auf Mails in irgendwelchen Mailinglistenarchiven wurden mir vorgehalten und der Vorwurf gemacht, daß man diese Mails von Google bei gewissen Eingaben als erste Antwort bekäme.Das ist das Standard-Google-Paradoxon: Wenn ich Stichworte aus einer Mail irgendeiner Mailing-Liste eingebe, weil ich die Mail schon kenne, bekomme ich sie natürlich an erster Stelle. Wenn ich sie aber noch nicht kenne, finde ich sie auch nicht.Außerdem wurde in keinem der Threads irgendein vernünftiger Grund genannt. Es zeigt nur, daß ich nicht der einzige bin, der darin ein erhebliches Sicherheitsproblem sieht. Die krude Logik ist aber, daß die Rüge eines Sicherheitsproblems umso unberechtigter ist, je mehr Leute sie äußern.
  • Es wäre unverzeihlich, daß ich es anders gemacht hätte, als die vielen Leute vor mir. Die hätten alle die Kernel-Maintainer befragt. Das hätte ich auch tun müssen.Sie haben damit aber nichts erreicht und auch keine Antwort erhalten. Wozu ich das dann auch tun sollte, konnte mir keiner sagen.
  • Die Zugriffsrechte seien kein Versehen und kein Sicherheitsloch, sondern Absicht.Als ob sich irgendein Angreifer dadurch abhalten ließe, die Rechte auszunutzen, weil sie absichtlich offen sind.
  • Was mir überhaupt einfiele, das zu rügen. Die einen meinten, die Kernel-Maintainer hätten das so festgelegt. Andere sagten, Linus Torvalds persönlich hätte das Skript geschrieben, das den tarball zusammenpackt.Aha. Es ist Gotteslästerung auf ein Sicherheitsproblem hinzuweisen, das von Linux persönlich verursacht wurde. Als ob Angreifer vor Erfurcht erstarrten, wenn sie den Dateien zu nahe kämen.
  • Das müßte so sein. Das wäre die einzig vernünftige Weise, den Linux-Kernel zu verteilen.Seltsam. Bei Debian und Gentoo sind die Rechte in den Kernel-Quellen richtig gesetzt. Nur bei kernel.org nicht.
  • Ob ich zu blöd wäre, die umask richtig zu setzen, dann käme das auch nicht vor.tar schert sich bei normalem Gebrauch als root nicht um die umask. Tar führt beim Start ein umask(0) aus.
  • Ob ich mich mit Zugriffsrechten nicht auskennen würde. Schließlich sei doch /usr/src nicht schreibbar, und deshalb auch die Kernel-Sourcen nicht, selbst wenn sie auf world-writable stünden.Quatsch. Um zu schreiben müssen nicht auch die übergeordneten Verzeichnisse schreibbar sein. Sonst könnte man nicht in sein Home-Verzeichnis schreiben.
  • Das einzige, was so etwas wie überhaupt ein Grund war: Das mache man der Bequemlichkeit wegen. Verschiedene Anwender hätten nämlich unterschiedliche Bedürfnisse und Policies, und wollten die Zugriffsrechte mal so und mal so haben. Wenn man den kernel nämlich als normaler Benutzer oder mit einer speziellen Option auspackt, dann maskiert tar das auch mit der umask. So könne jeder Benutzer einfach die Zugriffsrechte der Kernelsourcen durch Setzen der umask erreichen, ohne sich noch mit einem chmod -R abmühen zu müssen. Deshalb wäre es das praktischste, die Rechte so zu setzen.Das ist so ziemlich eines der idiotischsten Argumente, die mir je untergekommen sind.Alle sollen world-writable riskieren, nur damit irgendwo irgendwer , der die Quellen gerne schreibbar hätte, das chmod erspart bleibt. Sicherheit heißt eigentlich, daß Produkte mit geschlossener Tür geliefert werden, die man nach Bedarf öffnen kann. Hier werden weltweit offene Türen geliefert, weil irgendwer, bei dem es nichts zu klauen gibt, die Tür offenstehen haben will und man ihm die Mühe ersparen will, die Tür zu öffnen.

    Selbst wenn man diesen Zweck unterstellt, wären Gruppen-Schreibrechte angemessen und ausreichend. Warum überhaupt irgendwer die Kernel-Sourcen world writable haben sollte, und das auch noch so automatisiert, daß es nicht einmal eines einfachen chmod -R a+w bedürfen sollte, konnte mir keiner erklären. Genausowenig, warum die Dateien überhaupt generell schreibbar sein müssen.

    Man muß sich da echt mal an den Kopf fassen: Ich werde für blöd erklärt, weil ich angeblich nicht vermeiden könnte, daß die Sourcen beim Auspacken world writable werden. Man macht es aber gerade so, damit sie möglichst bequem und automatisiert word writable werden können.

  • Kernel-Sourcen hätten auf Maschinen mit Internet-Anschluß überhaupt nichts verloren. Jeder wisse doch, daß man auf einem Rechner mit Internet-Anschluß nicht kompilieren und erst gar keinen Compiler installieren dürfe. Sie müßten so knapp wie möglich installiert werden und der Kernel woanders installiert.Zeig mir mal einer Linux-Rechner, die nicht mit dem Internet verbunden sind. Dann dürfte man auch kein Perl, keine Shell usw. haben. Und dann bootet der Rechner gar nicht mehr. Dann braucht man auch keinen Compiler mehr.

  • Ich hätte keine Ahnung von Linux und überhaupt. Jedes Kind wisse, daß die Kernel-Maintainer zum Auspacken unter root die tar-Option –no-same-permissions empfehlen.Abgesehen davon, daß es sicherheitswidrig ist, Sourcen so zu verteilen, daß man sie mit einer exotischen Option auspacken muß, die einige Versionen von tar nicht haben, und das ganze so sehr fehleranfällig ist, stimmt es auch nicht. Im README des aktuellen Kernels steht nämlich:

    bzip2 -dc linux-2.6.XX.tar.bz2 | tar xvf –

    Wo das eigentlich stehen soll, daß die Maintainer das empfehlen, konnte mir keiner sagen. Aber ich wäre blöd, wenn ich das nicht wüßte. Nur noch mal zum Verständnis: Nur weil irgendwo irgendwem das chmod -R a+w erspart werden soll, müssen alle anderen –no-same-permissions eingeben.

  • Ich hätte keine Ahnung von Linux und überhaupt. Jedes Kind wisse, daß die Kernel-Maintainer empfehlen, den Kernel nicht als root zu kompilieren. Die Empfehlungen der Maintainer seien präzise zu befolgen. Für jede Abweichung sie man selbst verantwortlich.Auch das stimmt nicht. Keiner konnte mir sagen, wo das stehen soll, aber jeder meinte, das müssen man doch wissen (übrigens im Widerspruch zu der angeblichen Empfehlung mit –no-same-permissions). Im README steht nur, daß man den Kernel als anderer Benutzer kompilieren kann, aber nicht daß man es soll oder muß. Auf die Frage, wo das stehen soll, wurde mir vorgehalten, ich wäre unfähig, denn jeder wisse doch, daß man alles das, wozu man nicht root sein muß, auch nicht als root tun darf. Wenn also die Kernel-Maintainer schrieben, daß man den Kernel als Benutzer kompilieren kann, dann hieße das in Wirklichkeit, daß man es muß. Man befolgt die Anweisungen der Maintainer also präzise, indem man etwas anderes macht, als sie schreiben. Was sie denn dann davon abgehalten hat, daß gleich so hinzuschreiben, oder sogar das Makefile so zu bauen, daß es eine Warnung ausgibt, konnte mir keiner erklären.
  • Jeder wisse doch, daß man Software, Packages und auch den Kernel unter gar keinen Umständen als Root kompiliert. Das wäre unverantwortlich. Erst das make install dürfe man als Root ausführen.Worin der Sicherheitsgewinn liegen soll, den Kernel als Benutzer zu kompilieren, wenn ich doch ein und dasselbe Makefile hinterher sowieso als Root ausführe, konnte mir keiner erklären. Warum ein make install unter Root weniger gefährlich sein sollte als das make, konnte keiner sagen. Im Gegenteil: Normalerweise sollte Root nicht von normalen Benutzer abhängen. Jeder würde es als groben Fehler erkennen, wenn Root in der PATH-Variable das Directory eines normalen Benutzers einbinden würde. Aber hier soll man von einem Benutzer vorbereites Verzeichnis übernehmen.
  • Der Compiler könnte kompromittiert sein.Ja und? Was ändert es daran, daß ich den Kernel als Benutzer kompiliere? Das Kompilat ist dann genauso kompromittiert, als wenn ich es unter Root kompiliert hätte.

  • Es wäre generell unverantwortlich, einen Kernel einfach von irgendwoher aus dem Netz zu laden und als Root zu kompilieren. Auf meinen Einwand, daß die Kernel signiert sind und ich die Signatur prüfe, hieß es, daß die Signatur überhaupt nichts sage, sie bedeute nur, daß die Datei auf dem FTP-Server von kernel.org gelegen habe, aber sie sage nichts über die Sicherheit des Inhaltes.Hä!? Ich soll den Sourcen also nicht soweit trauen, daß ich die zu kompilieren wagen könnte, aber dann völlig normal ein make install machen und den Kernel zum normalen Gebrauch booten? Also die Gefahr liegt nur in den make build-Klauseln, aber nicht in den make install-Klauseln oder im Kern selbst?Wenn es doch von den Maintainer allgemein empfohlen sei, den Kernel nicht als Root zu kompilieren, warum sollte ein Angreifer dann so blöd sein, seine Angriffe nur da einzubauen?

    Wie kann man es unter einer solchen Aussage überhaupt noch verantworten, Linux einzusetzen?

Kein einziges logisches oder nachvollziehbares Argument. Pseudo-Argumente und angebliche Empfehlungen der Maintainer, die jeder kennen muß aber keiner weiß, wo sie stehen sollen.

Ein Quelltext, der mit Rechten als world-writable distributiert wird, die man nicht kritisieren oder antasten darf, von denen jeder meint, das muß so sein, aber keiner weiß warum. Jeder ist sich sicher, daß es geplante Absicht ist, aber keiner weiß, wozu es gut sein soll.
Aber (fast) alle sind sich einig, daß ich keine Ahnung von Security hätte, weil ich es für falsch halte, Kernel-Sourcen von vornherein als world-writable zu verteilen… Wenigstens bin ich da mit Debian und Gentoo in guter Gesellschaft.