Liebe Linuxfans,
ein kleines Interview als Teaser für Euch, denn Heiko hat eingewilligt nächste Woche bei Linux am Dienstag aus dem Eximnähkästchen zu plaudern. Er steht allen Interessierten gern Rede und Antwort. Ich rate Euch dringend diesen Termin wahrzunehmen, denn in unserem Vorgespräch offenbarten sich wahre Schätze an Wissen, das ganz dringend in den Tux in Euch rein muß 😉
21Nails: Interview mit Eximentwickler Heiko Schlittermann
Die Firma Qualys hat Ihre Entdeckung 21Nails genannt, aber Sargnägel waren es mit Sicherheit nicht. Eximmitentwickler Heiko Schlittermann stand uns heute morgen dankenswerterweise für ein kurzes Interview zur Verfügung.
„21 Lücken, 7 Monate bis zur Behebung, wieviele schlaflose Nächte waren das?“
Die meiste Zeit nicht mehr als sonst auch, aber die letzten zwei Wochen
vor dem public release waren etwas anstrengend, da einige Bugs erst in
letzter Minute auftraten – wir konnten ja nicht großflächig testen.
„Was hat Euch(Devs) so lange Zeit gekostet? War es die Qualität des Fixes an sich, oder die Kommunikation mit Qualys?“
Das ist eine längere Geschichte. Anfangs hatten wir nur die Bugreports
von Qualys. In diesem Zusammenhang muss ich noch mal deren sehr
professionelles und freundliches Verhalten bei der Zusammenarbeit
hervorheben.
Wir hatten zeitnah begonnen, uns um die Probleme zu kümmern. Eigentlich
hatte ich das Taintwarn-Feature in der Pipeline, denn ich wollte das
noch vor Debian11 rausbringen und ein 4.95-Release wäre eigentlich im
November dran gewesen.
Leider wurde einer der Entwickler vom Burnout aus der Kurve geschossen.
Qualys unterstützte uns dann mit Ressourcen: Sie haben uns die Patches
geliefert, die wir *eigentlich* nur noch importieren mussten. Es gab
aber intern einige Diskussion über die technische Umsetzung: es ist
wieder seteuid()* dabei, das eigentlich nicht mehr im Exim-Code
auftauchen sollte
*) Seteuid => setzt die effektive UserID eines Prozesses auf einen bestimmten User, damit der Prozess nur noch mit dessen Rechten läuft und falls dieser Prozess exploitet wird, ist der Schaden minimiert. Hier vom User „Root“, mit dem der Prozess startet, zu User „Exim“.
Wir suchten nach anderen Lösungen, aber das funktionierte alles nicht,
und das hat Zeit gekostet.
Einige Patches mussten geringfügig umgebaut werden. Und dann blieben bei
der Testsuite einige Tests auf der Strecke, da mussten die Ursachen
gefunden werden und gefixt werden. Exim hat eine Regression-Testsuite, mit gut
1000 Testsscripts, die jeweils im Schnitt 2…6 Einzeltests enthalten.
(Anm.d.R. insgesamt knapp 4000 Tests)
Qualys hat uns die ganze Zeit wertvoll unterstützt.
Mein Fazit: Wir hätten die Patches importieren sollen, Testsuite anpassen, shippen.
Und uns dann anschließend um Verschönerungsmaßnahmen kümmern. Auf der
anderen Seite wurde uns von Qualys kommuniziert, dass ja noch nichts brennt
und es keine Anzeichen gibt, dass eine der gefundenen Vulnerabilites aktiv genutzt wird.
„Wie kam es dazu, daß die Deadline so knapp war? Die Distros hatten ja kaum Zeit die neuen Versionen zu testen, geschweige denn zu shippen. Bei Fedora fiel die Testversion mit dem Releasedate des Advisories zusammen.“
Soweit ich den Prozess bei oss-security* verstehe, ist 1 Woche Vorlauf für die Distros schon gut bemessen. 3 Tage werden angestrebt.
(* Anm.d.R. OSS-Security ist eine öffentliche Mailingliste zu Securitymeldungen auf der u.a. die großen Distributionen und andere Organisationen vertreten sind )
„Da bleibt nicht viel Zeit für Test. Hat sich im Ablauf des Teams etwas geändert durch die Herkulische Aufgabe? Seit Ihr jetzt für die Zukunft besser bewappnet?“
Lesson learned. See above 🙂
„In der Mailing sieht man jetzt wieder sehr viele Hilferufe wegen „Tainting“. Erklärst Du mal, wie es dazu gekommen ist.“
Nun. Wir haben das Konzept von „tainted data“ mit 4.94 eingeführt. Da
werden Daten, die „von außen“ kommen als nicht vertrauenswürdig
betrachtet, und können z.B. nicht verwendet werden, um Dateien zu
öffnen. Der Klassiker
data = ${lookup{$local_part}lsearch{/etc/exim/virtual/$domain}}
geht dann plötzlich nicht mehr. Die „$domain“ ist „tainted“.
Wer jetzt beim Update von < 4.94 auf 4.94.2 aktualisiert hat, stand
plötzlich vor einer Herausforderung. Die Konfig ist nicht mehr sicher
und Exim arbeitet nicht mehr wie gewohnt.
Auch darüber hatten wir intern viele Diskussionen. (Das ist auch ein
Grund, warum wir 4.95 noch nicht released hatten: weil ich der Meinung
war, dass das mit dem Tainted so nicht bleiben kann.) Bisher waren
Updates des Exim immer möglich, ohne die Konfiguration ändern zu müssen.
(Der einzige „breaking Change“ war das aus Sicherheitsgründen
vorgenommene Bereinigen der Umgebungsvariablen für Kindprozesse. Da
hatten wir keine Wahl.)
Zurück zur Frage: Ja, wer jetzt plötzlich von < 4.94 auf >= 4.94
aktualisiert hat, hat möglicherweise ein Problem. Um das zu mildern, haben
wir eine Main-Config-Option eingeführt: „allow_insecure_tainted_data“.
Diese Option ist aber *nicht* Bestandteil von 4.94.2. Es gibt die
Meinung, dass wir alte Versionen vor 4.94 eh nicht unterstützen, und die
die sich den Exim selber bauen, sind schon bei 4.94, haben also mit dem
Update kein Problem. Ist sicher diskutierbar…
Wer über seine Distro aktualisiert, hat kein Problem, wir haben Debian
beim Backport der Patches auf 4.92 unterstützt. Von den anderen Distros
wissen wir nichts, aber es sieht so aus, als hätten die das auch
irgendwie gelöst.
Wer von Debian 10 auf Debian 11 aktualisiert, hat auch kein Problem, weil
Debian freundlicherweise den oben erwähnten „taintwarn“ Patch mit
übernommen hat.
Hm. Zu viel Antwort für die kurze Frage…:)
„Letzte Frage: Wird es jetzt aus Deiner Sicht Zeit, die Beispiele in der Eximdoku zu überarbeiten und Tainting-sichere Beispiele anzuführen?“
Ja, definitiv ist da noch etwas dokumentarische Arbeit nötig. Jeder
ist eingeladen, sich daran zu beteiligen.
Die Beispiel-Config ist „tainting sicher“.