Debian und Red Hat schließen Exim-Lücke (teilweise)

[Joe User]

http://www.heise.de/newsticker/meldung/ ... 51620.html

Fazit:
Es zeigt sich wiedereinmal das Debians Security-Policy nicht taugt und den Maintainern zum Teil das nötige Know-How für ihre Aufgabe fehlt. Beides ist für den Einsatz von Debian auf produktiven Systemen ein schlichtes No-Go.

[daemotron]

Vielleicht um das ganze noch mal zu präzisieren: Es ging um einen möglichen Buffer Overflow in Zusammenhang mit Format-Strings (C-Programmierer können ein Lied davon singen...).

Gefixt wurde dieser Fehler bereits mit Version 4.70, und selbiger Fix wurde auch im Change Log erwähnt - allerdings nicht fett, rot und mit 42 Ausrufezeichen garniert. So haben ihn offenbar einige Package Maintainer einfach übersehen.

Sowohl Debian Lenny als auch RHEL 5.x nutzen ältere Versionen (Lenny 4.69, RHEL 5.5 ist mit 4.63 unterwegs). Und in beiden Fällen ist dieser kleine, aber entscheidende Change Log Eintrag durch die Lappen gegangen. Entsprechend wurde der Fix nicht zurückportiert und die Debian- und RHEL/CentOS-Packages blieben verwundbar.

Das belegt für mich wieder ein Stück weit die These, dass Zurückportieren kein guter Ansatz ist. Selbst einem professionellen Team wie bei Red Hat können kritische Bugs durch die Lappen gehen. Systeme mit Rolling Releases sind von diesem Bug jedenfalls verschont geblieben, einige andere hatten IMHO schlicht Glück, dass durch einen kürzeren Release Cycle ohnehin schon die neuere Version am Start war.

P. S. fast vergessen, hier das offizielle Statement auf exim-announce dazu: http://lists.exim.org/lurker/message/20 ... 4b.en.html

[Joe User]

Wäre der Speicherfehler in string_format nicht als "potential...overflow..." gekennzeichnet gewesen, sondern lediglich als "bug in string_format", dann wäre das Übersehen beim Backporting entschuldbar. Aber die Kombination aus potential und overflow begründet grundsätzlich einen must-have-Bugfix, auch wenn er sich unwahrscheinlicherweise später als unbegründet erweisen sollte.

Noch schlimmer wiegt aber der Root-Exploit den man bei Debian auch nach dem Presseecho nicht zeitnah gefixt und damit etliche gerootete Systeme billigend in Kauf genommen hat. Primär hierauf bezieht sich auch mein Rant im ersten Post.

Und spätestens seit dem die Kernel-Devs öffentlich bestätigten, dass sie Security-Bugs im Allgemeinen nicht als solche deklarieren, hat das Konzept des Version-Freeze und Backporting seine Daseinsberechtigung verloren. Zumal es immer mehr Projekte wie die Kernel-Devs machen und in schon zuvor gemacht haben und Security-Bugs nicht entsprechend deklarieren.

Version-Freeze und/oder never-change-a-running-system sind schon lange keine "guten" Ansätze mehr, es geht heute nur noch mit Rolling-Releases...

[daemotron]

Die Entwicklung, dass man Security Fixes nicht mehr als solche deklariert und die Gewichtung von Features über die von Bugs und Security gestellt werden ist leider nichts neues und verschlimmert sich zunehmend.

Aus Programmierer-Sicht kann ich das aber sehr gut nachvollziehen. Ich finde einen Bug in meiner Software, oder jemand macht mich darauf aufmerksam. Also fixe ich ihn, stelle den Patch (oder ein Patch-Release) zum Download bereit, und gut ist.

Die Unterscheidung, ob ein Fehler in einer Software sicherheitskritisch ist oder nicht, ist in meinen Augen eine rein künstliche. Potenziell ist jeder Bug (auch jeder logische!) ein mögliches Sicherheitsrisiko. Ob er tatsächlich zu einem Problem wird, hängt allzu oft auch von der Umgebung ab, in der die Software eingesetzt wird.

Ergo würde ich als Programmierer mir nicht anmaßen, behobene Bugs in Kategorien wie sicherheitskritisch und nicht sicherheitskritisch zu unterteilen, weil ich das schlicht nicht beurteilen kann.

Rolling Releases sind auch kein Garant für mehr Sicherheit. Im Prinzip, in der Wirkung, auch nur ein Vertuschen und Verschleppen etwaiger Probleme durch Masse an Code.

Rolling Releases beheben wenigstens das Problem der Bug-Selektion. Damit liegt zwar die alleinige Verantwortung für die Fehlerfreiheit beim Programmierer der Anwendung, aber das tut sie eigentlich ohnehin schon. Maintainer portieren in der Regel ja eh nur Bugfixes zurück, die sowieso schon in neuere Releases eingeflossen sind, oder für die zumindest ein bekannter Patch existiert.

Darauf bezog sich meine oben geäußerte Kritik an Stable Releases - die zusätzliche Selektion bringt (meistens) kein Plus an Sicherheit (es sei denn, man hat es mit Software zu tun, in die jeder Fix zwei weitere Löcher reißt).

So wie es in der ganz normalen Marktwirtschaft an guten Fachkräften zunehmend mangelt, mangelt es leider auch bei den Opensource Projekten zunehmend an Fachkräften. Um mal das Rad zur jüngsten "Backdoor" Diskussion zu schlagen....

In dem Punkt ist meine Meinung vielleicht etwas ambivalent. Ich denke, der Fachkräftemangel ist sowohl in Wirtschaft wie auch FOSS-Projekten ein überwiegend hausgemachtes Problem.

Die Wirtschaft hat sich's überwiegend versaut, weil sie permanent versucht, Arbeitskräfte in ein Wettbewerbsverhältnis mit Programmierern im Ausland drängen - einige Beispiele sind mir da durchaus bekannt (und der Wettbewerb ist durchaus nicht fair - da wird nur auf den Stundensatz in der Angebotskalkulation geschielt, nicht auf die am Ende tatsächlich benötigte Anzahl Manntage, Reibungsverluste, Nachbesserungen etc). Dazu dann noch eine strategische Ausrichtung à la "wir kaufen Programmierleistung nur ein, selber machen wir nur Planung, Koordination und Integration" - das hat einfach viele junge talentierte Leute in andere Richtungen vergrault, wo's mehr zu holen gibt und die Perspektiven besser sind.

Die FOSS-Projekte haben es auf andere Weise versaut. In der Boom-Zeit gab es einfach viele Studenten und Uni-Abgänger, die richtig programmieren konnten. Genug "Rohstoff" für die FOSS-Projekte. Ergo hat sich dort eine Kultur etabliert, die für Einsteiger nicht gerade förderlich ist. Die Hürden liegen ziemlich hoch ("lies dich erst mal in den Code ein" ist eine nicht unübliche Form der Begrüßung), und ordentliches Mentoring sucht man meist vergebens.

Dabei müssten sich die Projekte längst darüber im Klaren sein, dass sie ihren Nachwuchs heute aus den Powerusern anwerben und dann ausbilden müssen. Programmierpraxis bekommt man in keiner Ausbildung und in keinem Studium vermittelt. UML, Java und SQL helfen halt nicht, wenn die Software in C geschrieben ist, und Erfahrung in diesem Umfeld bringen heute halt nur Leute mit, die etwas älter sind, einen Job mit >40h/Woche haben und auch sonst vielleicht nicht die vielen Stunden Zeit aufwenden können, um in FOSS-Projekten zu programmieren.

IMHO müssten daher sowohl Firmen als auch Projekte den Fokus wieder stärker darauf legen, Leute anzuwerben, die programmieren wollen (und logisch denken können) und bei denen dann die nötige Erfahrung und Praxis durch Mentoring aufzubauen. Ein Uni-Schein, auf dem "kann Java" steht, heißt halt noch lange nicht, dass jemand auch wirklich in einem Projekt produktiv mitarbeiten kann.

[daemotron]

Ich glaube, wir meinen doch beide das Gleiche: Im Studium habe ich Grundlagen und Methoden gelernt - also Programmierparadigmen, Modellierung, Algorithmen und Datenstrukturen gepaukt, auch ein bisschen das Drumherum (XP, Function Point und was damals halt so "in" war). Formal glaube ich damit eine ziemlich fundierte Ausbildung genossen zu haben - programmieren (in größeren Projekten zumindest) konnte ich trotzdem hinterher nicht.

Auch wenn viele das nicht einsehen, dass sie es noch nicht können - die eigentliche Lernphase kommt erst danach, wenn man die ersten Gehversuche macht, sein Wissen mal in einem richtigen Projekt mit echten Deadlines und ungeduldigen Kunden zur Anwendung bringen darf.

Und genau hier sehe ich den Clash: Die Firmen erwarten, dass ein fertiger Absolvent auch sofort (nach kürzester Einarbeitung) 100% output-fähig ist. Gleichzeitig soll die Studien- oder Ausbildungsdauer immer weiter gedrückt werden, und bei 4 Jahren muss doch auch noch ein halbes BWL-Studium mit reinpassen. Ergo: In Studium oder Ausbildung wird gepaukt, aber nicht geübt und trainiert.

Bei mir kam damals noch erschwerend hinzu, dass alle Firmen, mit denen ich während oder nach dem Studium zu tun hatte, auf dem Outsourcing-Trip waren. Alle waren mehr oder minder fest davon überzeugt, dass noch in der ersten Dekade des gerade laufenden Jahrtausends sämtliche Programmierung in Indien stattfinden würde.

Folglich erschien es auch nicht gerade lohnenswert, sich auf die Lernphase nach dem Studium einzulassen - die Konsequenz daraus ist bekannt. Aus meiner Generation haben sich viele auf Planung, Projektmanagement, IT-Controlling, Consulting etc. spezialisiert. Wenn jetzt die Wirtschaft schreit, dass ihnen die Programmierer mit ~10jähriger Berufserfahrung fehlen, dürfen sie von mir jedenfalls kein Mitleid und auch keine Unterstützung erwarten - nicht bei dem Affenzirkus, den ich damals miterlebt habe.