In unserem Podcast diskutiert Thomas Bahn über Nutzen, Anwendungen und Erfahrungen aus den Bereichen Chatbots und Künstliche Intelligenz. Mehr erfahren

Change a running system! (Update)

von Thomas,
assono GmbH, Standort Kiel,

Häufig sagt man ja in der IT: "Never change a running system" in leichter Abwandlung des englischen Sprichworts: "Never change a winning team".

Ich meine, dass kann man so nicht stehen lassen. Selbst bei einem ziemlich sicheren System wie IBM Lotus Notes/Domino gibt es hin und wieder Sicherheitslücken und Fehler in der Software, die sich von bösen Menschen ausnutzen lassen.

Zurzeit ist so eine Zeit. Im Newsticker auf heise.de wurde der Eintrag "Schwachstellen in Lotus Notes und Domino" veröffentlicht, in dem gleich fünf (!) sicherheitsrelevante Probleme aufgelistet und kurz beschrieben werden.

Buffer overflow vulnerability in Lotus Notes file viewers (.wpd, .sam, .doc, and .mif)
Ein Angreifer kann mittels Pufferüberlauf beliebigen Code ausführen lassen, wenn eine entsprechende manipulierte Datei im Betrachter (Anhang - Ansicht) des Notes-Client geöffnet wird. Die Datei könnte z. B. als Anhang in einer E-Mail verschickt werden.
Die Fehler sind bzw. werden beseitigt in Lotus Notes 7.0.3 und 8.0 (.sam, .doc, .mif) bzw. 8.0.1 (.pwd).
Bis im Dezember 7.0.3 bzw. nächstes Jahr 8.0.1 rauskommt, empfehle ich entweder die von IBM genannten Workarounds oder das Blocken entsprechender E-Mail-Anhänge von externen Absendern, z. B. mit der iQ.Suite. Ok, .doc geht wohl nicht so einfach, aber die anderen sollten in freier Wildbahn kaum vorkommen, oder?

Lotus Domino IMAP buffer overflow vulnerability
Wenn der IMAP-Serverprozess konfiguriert ist und läuft, kann ein Angreifer mit gültigen Anmeldedaten (Benutzername und Passwort) unter Ausnutzung dieses Problems beliebigen Code auf dem Domino-Server ausführen.
Der Fehler ist bzw. wird beseitigt in Lotus Domino 6.5.6 Fix Pack 2, 7.0.3 and 8.0.
Ich persönlich kenne nicht viele Firmen, die den E-Mail-Zugriff per IMAP erlaubent. IBM empfiehlt, wenn man den Server nicht aktualsieren kann, den Zugang zum IMAP-Port (Standard: 143) per Firewall möglichst weitgehend zu beschränken.

Evaluate LotusScript method returns unexpected results
Interessante Wortwahl: unexpected (unerwartet): Natürlich ist es "unerwartet", wenn ein Benutzer Zugriff auf Daten bekommt, die er nicht sehen dürfte...
Zurück zur Sache: Wenn man mittels Evaluate, einem Befehl in LotusScript, bestimmte @-Formeln ausführt in Zusammenhang mit der Gestaltung von Agenten und Ansichten (IBM gibt da keine genaueren Details), dann wird das Evaluate teilweise mit den Rechten des Servers ausgeführt. Und der darf meistens mehr sehen, als der Angreifer selbst.
Der Fehler ist bzw. wird beseitigt in Lotus Domino 7.0.3 und 8.0.
Richtig beseitigt wird er eigentlich erst in 8.0. Bei 7.0.3 muss man zusätzlich noch den notes.ini-Parameter Enforce_EffectiveUserRights_EvaluteCommand auf 1 setzten. Am besten natürlich in dem *-Konfigurationsdokument für alle Server.
Am besten gleich heute setzen (wirkt sich aber noch nicht aus), dann ist mit der Aktualisierung auf 7.0.3 alles ok, sonst muss man später noch einmal daran denken.
Die 6er/6.5er-Versionen werden wohl nicht mehr mit einer Korrektur bedacht, also am besten in Kürze auf zumindest 7.0.3 bringen.

Potential security issue with Domino Certificate Authority (CA) process commands
Wenn man den CA-Prozess (Certificate Authority, siehe Serverbasierte Zertifizierungsstelle) benutzt, um ID-Dateien automatisch signieren und verlängern zu lassen, muss dieser Prozess auf der Serverkonsole aktiviert werden. Dazu ist die Eingabe eines Passwortes notwendig.
Bis Version 6.5.4 konnte dieses Passwort im Klartext im Protokoll (log.nsf und Console.log) erscheinen. Dann hat ein cleverer Programmierer bei IBM ein Filter programmiert, der das verhindert. Leider scheint der Mensch einen Zeichenkettenvergleich nur mit Kleinbuchstaben zu machen, so dass wenn ein Großbuchstabe im Befehl verwendet wird, der Filter nicht greift und das Passwort wieder im Protokoll sichtbar wird.
Also tell ca activate <certifier number> <password> und tell ca unlock <idfile> <password> sind okay, aber z. B. tell CA activate <certifier number> <password> nicht. Großbuchstaben im Passwort sind übrigens egal.
Der Fehler ist bzw. wird beseitigt in Lotus Domino 7.0.3 und 8.0.
Bis dahin immer daran denken und diese Befehle klein schreiben.

Potential vulnerability in Notes/Domino memory mapped files
Um miteinander zu kommunizieren, benutzen einige Prozesse (z. B. nlnotes und ntaskldr) im Notes-Client und im Domino-Server Dateien, sog. memory mapped files. Der Zugriff auf diese Dateien ist unbeschränkt, so dass jeder, der sich bei dem Rechner anmelden kann, auf dem der Client oder der Server läuft, diese Datei auslesen und sogar verändern könnte. Der Domino-Server ist normalerweise ja schon gut geschützt und der Notes-Client läuft auf einem Arbeitsplatzrechner, an dem sich auch nur der davor Sitzende anmelden kann. Oder? Naja, wenn man einen Terminal-Server oder Citrix benutzt, können sich eben doch ganz viele Benutzer auf einem Rechner anmelden, auf dem ein Lotus Notes läuft. Dann kommt diese Lücke richtig zum Tragen.
Der Fehler ist bzw. wird beseitigt in Lotus Notes 6.5.6, 7.0.3 und 8.0 und in Lotus Domino und Lotus Domino 6.5.5 Fix Pack 3, 7.0.2 Fix Pack 1, 6.5.6, 7.0.3 and 8.0.
Und wie weiter oben ist der Fehler allein mit dem Einspielen der neuen Version noch nicht erledigt, sondern man muss wieder einen notes.ini-Parameter, diesmal SharedMemoryAllowOnly auf 1 setzen. Beim Server wie geschrieben am besten per Konfigurationsdokument, beim Notes-Client per Richtlinie.

(Aktualisierung: und noch einmal 4 weitere Sicherheitslücken)

Lotus Notes buffer overflow vulnerability with HTML message
Wenn unter Lotus Notes eine speziell preparierter HTML-Code, zum Beispiel in einer E-Mail, weitergeleitet, auf sie geantwortet oder in die Zwischenablage kopiert wird, kann über einen Pufferüberlauf beliebiger Code auf dem Notes-Client ausgeführt werden.
Wird solch eine E-Mail empfangen, wird sie in das interne Notes-RichText-Format konvertiert. Wird nun dieser RichText wieder zurück in HTML umgewandelt, was z. B. passiert, wenn eine Antwort oder Weiterleitung ihn enthält, kommt es zu dem genannten Fehler.
Wer die automatischen Fehlerberichte (Lotus Notes/Domino Fault Reports/lndfr.ntf) aktiviert hat, könnte dann eine spezifischen StackTrace im Bericht finden (siehe IBM-Artikel).
Der Fehler ist bzw. wird beseitigt in Lotus Notes 7.0.3 und 8.0.

Potential Notes workstation Execution Control List (ECL) security vulnerability
Diese Fehlerbeschreibung habe ich selbst nicht so genau verstanden?! sad.gif
Es geht um .nsf- und .ntf-Dateianhänge und die ECL (Execution Control List), die normalerweise Warndialoge anzeigt, wenn etwas ausgeführt werden soll, was gefährlich sein könnte. Jedes Gestaltungselement und Stückchen Code ist grundsätzlich von demjenigen unterschrieben, der es zuletzt gespeichert oder per E-Mail verschickt hat. In der ECL ist festgelegt, wer (Unterzeichner) was (potentiell gefährliche Aktion) darf. Ist eine bestimmte Aktion für einen bestimmten Unterzeichner dort nicht erlaubt, wird normalerweise ein Warnhinweis angezeigt und der Benutzer kann auswählen, ob er die Aktion nicht, einmalig oder immer ausführen lassen möchte (für diesen Unterzeichner). Und genau dieser Warnhinweis unterbleibt in bestimmten Situationen (Code im Navigator) und der Code wird ohne Nachfrage ausgeführt.
Der Fehler ist bzw. wird beseitigt in Lotus Notes 7.0.3 und 8.0.
Zusätzlich kann man sich überlegen, ob man .nsf- und .ntf-Dateianhänge verbietet (z. B. mit der iQ.Suite). Meiner Meinung nach wäre das kein großer Verlust, da man Notes-Datenbanken und -Schablonen wunderbar packen kann und dann z. B. als ZIP-Archiv verschicken kann.

Buffer overflow vulnerability in Lotus Notes file viewers (multiple file formats)
Eigentlich der gleiche Fehler wie weiter oben, betrifft aber zusätzliche Datei-Typen: Adobe Acrobat FrameMaker (.mif), Applix Words (.aw), Applix Presents (.ag), Dynamic Link Library (.dll), Microsoft Rich Text Format (.rtf), Microsoft Word - (.doc) und Portable Executable (.exe).
Der Fehler ist bzw. wird beseitigt in Lotus Notes 7.0.3 und 8.0.
Ich denke, alles bis auf .doc und .rtf kann man einfach als E-Mail-Anhang verbieten. Und natürlich sollte man seine Benutzer bezüglich Sicherheit (immer wieder) schulen, so dass sie zumindest nicht gleich jeden Anhang von jedem Empfänger öffnen.

Potential denial of service in Lotus Notes due to malformed SMTP message
Nicht wirklich eine Sicherheitslücke, kann aber trotzdem ärgerlich sein: Bestimmte "kaputte" E-Mails aus dem Internet können den Notes-Client zum Absturz bringen.
Der Fehler ist bzw. wird beseitigt in Lotus Notes 7.0.3 und 8.0.
Gegenmaßnahme: E-Mail löschen.


Ich habe da noch zwei Anmerkungen:

  1. Ich finde es nicht gut, dass es die deutsche Version 7.0.3 erst in zwei Monaten gibt. Bis dahin können Kunden, die die aktuelle Version 7 einsetzen, nichts gegen diese sicherheitsrelevanten Fehler unternehmen. Und ein Fix Pack wird zwischenzeitlich sicherlich auch nicht mehr erscheinen. sad.gif
  2. IBM hat die an sich gute Politik innerhalb einer Hauptversion (z. B. 7.x.x) keine Neuerungen einzubringen, die als Vorgabe aktiv sind. Die beiden obigen Fälle, wo ein notes.ini-Parameter gesetzt werden muss, damit der Fehler beseitigt ist, sind ein Beispiel dafür. Ich denke, dass in diesem Fall, also Sicherheitsproblemen, es anders herum sein müsste: Korrektur per Vorgabe aktiv. Es könnte zwar sein, dass in ganz esoterischen Fällen dadurch ein laufendes System nach einer Aktualisierung Probleme verursacht, aber ich meine, dass dieses Risiko relativ klein ist gegenüber einer offenen, dokumentierten Sicherheitslücke.

Quellen: Schwachstellen
in Lotus Notes und Domino
im Heise
Newsticker


Security
vulnerability fixes in Notes and Domino 7.0.3

im Notes
from Lotus Support
-Blog

Fachbeitrag HCL Notes HCL Domino HCL Notes Traveler Sicherheit Administration

Sie haben Fragen zu diesem Artikel? Kontaktieren Sie uns gerne: blog@assono.de

Sie haben Interesse an diesem Thema?

Gerne bieten wir Ihnen eine individuelle Beratung oder einen Workshop an.

Kontaktieren Sie uns

Weitere interessante Artikel

Sie haben Fragen?

Wenn Sie mehr über unsere Angebote erfahren möchten, können Sie uns jederzeit kontaktieren. Gerne erstellen wir eine individuelle Demo für Sie.

assono GmbH

Standort Kiel (Zentrale)
assono GmbH
Lise-Meitner-Straße 1–7
24223 Schwentinental

Standort Hamburg
assono GmbH
Bornkampsweg 58
22761 Hamburg

Telefonnummern:
Zentrale: +49 4307 900 416
Vertrieb: +49 4307 900 402

E-Mail-Adressen:
kontakt@assono.de
bewerbung@assono.de