Domino 9 und frühere Versionen > ND8: Administration & Userprobleme

CVE-2013-0127;CVE-2013-0538; IF1 für Notes 9 & 8.53 FP4

<< < (8/10) > >>

Micha B:

--- Zitat ---Auch habe ich bei IBM angefragt, ob es für andere Version auch ein IF geben wird.
--- Ende Zitat ---
Da sie bisher keins dafür anbieten, denke ich, wird es auch keine weiter geben. Für Versionen ohne FP soll man ja die Notes.ini Parameter setzen.

Günther Rupitz:

--- Zitat von: Ralf_M_Petter am 07.05.13 - 12:52:55 ---Was ist den der APAR für das Problem mit dem Client Access in Zusammenspiel mit Notes. Wir verwenden nämlich auch beides und da wüsste ich gerne vorher welches Problem zu erwarten wäre.

--- Ende Zitat ---

Inzwischen gibts eine offizielle Fehlerbeschreibung, ich teste gerade ob es unser Problem löst:

http://www-01.ibm.com/support/docview.wss?uid=swg21637068&myns=swglotus&mynp=OCSSKTWP&mync=E

omega:

--- Zitat ---
Inzwischen gibts eine offizielle Fehlerbeschreibung, ich teste gerade ob es unser Problem löst:

http://www-01.ibm.com/support/docview.wss?uid=swg21637068&myns=swglotus&mynp=OCSSKTWP&mync=E

--- Ende Zitat ---

Ich bezweifle, dass der Link von IBM besonders geschickt ist.
Die OriginalRuntime von 2006 ist ein wenig alt und funktioniert nicht mit allen Programmen.

mezz:

--- Zitat von: hallo.dirk ---Ich geb ja zu, das ich von Programmierung nicht viel Ahnung habe, aber wie soll Notes ein Applet ausführen, wenn es nich der korrekten Syntax entspricht?

Von daher währe es schon nicht schlecht, wenn Du ein bisschen genauer sein würdest...

--- Ende Zitat ---

Das Problem ist das es hier um zwei Sicherheitslücken geht, zum einen CVE-2013-0127 das ist die Lücke über die hier so heiß diskutiert wird.
Ausserdem gibt es keine Garantie das dein Zeichenkettenfilter nicht einfach unterlaufen wird, im einfachsten Fall reichen z.b. einfach ein paar Whitespaces in das <applet>-Tag und schon wird es nicht mehr gefiltert aber ist noch "gültiges" HTML.


--- Zitat von: cg-home ---Wir können die drei Notes.ini Parameter auch nicht verwenden, da dann unser CRM nicht mehr geht.
Eine "schnelle" Installation auf eine der Versione mit IF geht bei uns leider auch nicht.
Unser CRM-Anbieter hat gemeint, dass die beiden Notes.ini Parameter
  EnableJavaApplets=0
  EnableLiveConnect=0
auch langen. dann geht unser CRM noch und die Sicherheitslücke ist dennoch "geschlossen".

--- Ende Zitat ---

Das bezieht sich auf CVE-2013-0127, ist auch soweit korrekt. Was hier aber übersehen wird ist das IBM hingegangen ist und ein Advisory für zwei Sicherheitslücken veröffentlicht hat - wohl weil beides miteinander zusammenhängt. Die zweite Sicherheitslücke CVE-2013-0538 ist hier eine Javascript-Injection über die ebenfalls potenzieller Schadcode eingeschleust werden kann.

Wenn ihr also nur Java ausknippst hilft das nicht wirklich viel weiter!

hallo.dirk:

--- Zitat von: mezz am 13.05.13 - 09:19:10 ---
--- Zitat von: hallo.dirk ---Ich geb ja zu, das ich von Programmierung nicht viel Ahnung habe, aber wie soll Notes ein Applet ausführen, wenn es nich der korrekten Syntax entspricht?

Von daher währe es schon nicht schlecht, wenn Du ein bisschen genauer sein würdest...

--- Ende Zitat ---
Das Problem ist das es hier um zwei Sicherheitslücken geht, zum einen CVE-2013-0127 das ist die Lücke über die hier so heiß diskutiert wird.
Ausserdem gibt es keine Garantie das dein Zeichenkettenfilter nicht einfach unterlaufen wird, im einfachsten Fall reichen z.b. einfach ein paar Whitespaces in das <applet>-Tag und schon wird es nicht mehr gefiltert aber ist noch "gültiges" HTML.

--- Ende Zitat ---

So ganz locker kann immer noch nicht lassen:

Zunächst einmal muss ich mich in sofern korrigieren, als dass ich auf die Kombination <applet und applet> achte.
Vielleicht hilft das ja schon zur Erklärung.
Trotzdem habe ich eben mal ein bisschen recherchiert und bin der Meinung, dass <Leerzeichenapplet oder Leerzeichenapplet> nicht mehr sauber erkannt werden kann, zumindest laut Definition von w3.org.
Also dürfte hier nichts anbrennen...

Nun kann man ja wohl auch etwas anderes als  UTF 8 / ASCII nehmen um Zeichen zu umschreiben.
Aber selbst bei UTF-32 sind die Spitze Klammer und die lateinischen Zeichen an der gleiche Stelle.

Bliebe noch zu klären was passiert wenn man in HTML code in hex. schreiben würde, geht das überhaupt?
Würden dieses alle gängigen Clients unterstützen?

Was habe ich übersehen?

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete