5 Tage nach Erscheinen des Critical Patch Updates Juli 2007 wurde auf mehreren Blogs ein Exploit veröffentlicht, der die Sicherheitslücke DB17 (insert/update/delete auf Tabellen mit Nur-Lese-Recht) auf allen Datenbankversionen ausnutzt. Ich möchte dies bewusst nicht tun, da ich dies verantwortungslos finde.
Normalerweise haben DBAs 3 Monate zur Verfügung, um ein CPU einzuspielen, bevor gefundenen Sicherheitslücken veröffentlicht werden.
In grossen Unternehmen sehe ich diese Zeitspanne als richtig und wichtig an, da das Einspielen dringend getestet werden muss. Und wenn hunderte oder sogar tausende Datenbanken gepatcht werden müssen, braucht dies seine Zeit – und sicherlich mehr als 5 Tage.
Ausserdem waren zum Erscheinungstermin des Exploits noch nicht einmal alle Patches für alle Oracle-/Betriebssystemkombinationen verfügbar…
Weshalb ist es verantwortungslos den Exploit-Code zu veröffentlichen, wenn die Katze bereits aus dem Sack ist? Damit spielt man den Bösen nur in die Hände, da jeder Hacker/Security-Experte Webseiten wie milw0rm.com oder securiteam.com kennt und abonniert hat. DBAs erfahren oft nicht, dass solcher Code existiert und wiegen sich in (trügerischer) Sicherheit (“So wichtig ist der Patch nicht…”).
Dass die erste Veröffentlichung von solchem Exploit Code negativ ist, gebe ich Ihnen vollkommen recht. Oftmals ist es aber auch trivial (zumindest für Security Experten), eigenen Exploit Code für Sicherheitslücken zu schreiben. Da reicht alleine eine Überschrift.
Mir ist allerdings neu, dass DBAs normalerweise 3 Monate Zeit haben, bevor gefundene Sicherheitslücken veröffentlicht werden. Von solch einer “Regel” habe ich nicht gehört. Es gab eine Firma (NGS), die mal solch eine Policy hatte, davon aber wieder Abstand genommen hat.
>>Weshalb ist es verantwortungslos den Exploit-Code zu
>>veröffentlichen, wenn die Katze bereits aus dem Sack ist?
Nicht jeder kennt/liest Ihre genannten Webseiten. Ich rede hier nicht von den Security-Experten, sondern z.B. von den unzufriedenen Mitarbeitern, die damit eventuell eine Möglichkeit in die Hand bekommen, sich zu “rächen”. Diese sind typischerweise nicht in der Lage, anhand einer Überschrift eigene Exploits zu schreiben.
>>Mir ist allerdings neu, dass DBAs normalerweise 3 Monate Zeit haben,
>>bevor gefundene Sicherheitslücken veröffentlicht werden
An diese (minimalen) Zeitspanne – sprich an diese ungeschriebene Regel – habe sich doch viele gehalten. Öfters wurde der Exploit noch später veröffentlicht.
>>Dass die erste Veröffentlichung von solchem Exploit Code negativ ist, gebe ich Ihnen vollkommen recht
Ich denke, da sind wir uns einig – ich gehe aber eben noch einen Schritt weiter
Security through obscurity ist niemals ein approbates Mittel um Sicherheit zu erreichen. Sobald eine Lücke veröffentlicht wurde, kann diese Lücke von jedem (auch unzufriedenen Mitarbeiter) sehr einfach mit Google gefunden werden. Da spielt es keine Rolle, ob die Lücke nur einmal oder öfters veröffentlicht wurde. Google findet sie…
Andererseits hilft ein konkrekter Exploit, den DBAs bei der Abschätzung, wie kritisch eine Lücke wirklich ist (im Gegensaz zur Fehlerbeschreibung “Fehler im SQL Compiler”) und ob ein CPU eingespielt werden soll.
Zur (minimale) Zeitspanne von 3 Monaten:
Von den üblichen Researcher die Sicherheitslücken finden, veröffentlichen manche Exploits niemals (Steven), manche vorher oder direkt (Cesar, Esteban, Joxean), manche unterschiedlich (David, ich). Daraus kann ich leider keine 3-Monatsregel oder eine andere Regel erkennen. Dies kann ich natürlich mit den entsprechenden Links belegen