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?! 
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:
- 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.
- 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
