Februar 2014
Hier finden Sie Nachrichten und Einträge aus dem Februar 2014, die sich einmal als News direkt auf der Homepage befunden haben.
13. Februar 2014: Nach der Schwachstelle CVE-2014-0037 habe ich am 28. Januar 2014 eine weitere Schwachstelle in der Zarafa Collaboration Platform (ZCP) entdeckt. Zarafa ist eine Open-Source-Groupware-Suite, die volle Kollaboration bei E-Mail, Kalender, Kontakten und Aufgaben ermöglicht und als Alternative zu Microsoft Exchange verwendet werden kann. Diese weitere Schwachstelle ist theoretisch genauso alt, ist jedoch nur ausnutzbar, wenn Zarafa mit GLIBC 2.4 (oder neuer) kompiliert wurde. Eventuell haben auch irgendwelche Compiler-Flags noch Einfluss darauf. Letztendlich stürzt der Dienst "zarafa-server" mit einem "Segmentation fault" ab und verhindert die Nutzung von Zarafa - bis zu einem Neustart des Diensts. Da wohl nur die nicht offiziellen Zarafa-Pakete (z.B. in Fedora oder Fedora EPEL) mit einer halbwegs aktuellen GLIBC kompiliert werden, ist effektiv nun nur die Open-Source-Variante von Zarafa betroffen. Bis zu einem neuen Zarafa-Release muss jedenfalls mein Patch angewendet werden. Heute habe ich die Schwachstelle (mit Hilfe des Red Hat Security Response Team) selbst veröffentlicht und ist als CVE-2014-0079 und RHBZ #1059903 bekannt.
27. Februar 2014: Nachdem ich bei einem Java-Projekt, das ich immer mal wieder in meiner Freizeit unterstütze, leider einige Stunden mit dem Signieren eines Java-Applets mit einem offiziellen "Code Signing"-Zertifikat zugebracht habe, habe ich mein bereits vorhandenes und während dem Projekt zusätzlich erlangtes Wissen in einem Artikel dokumentiert. Dabei ist mir irgendwie immer klarer geworden, dass Java auf dem Client scheinbar eine wandelnde Sicherheitslücke ist, die nun prophylaktisch mit offiziellen signierten Java-Applets und standardmäßig gehärteten Sicherheitseinstellungen gestopft werden sollen. Letztendlich habe ich für die Signierung des JAR-Archivs so weit wie möglich "openssl" verwendet und nur die unbedingt notwendigen Schritte mit "keytool" durchgeführt - abgesehen vom sowieso immer erforderlichen "jarsigner". Dieses Herangehen unterstützt übrigens auch Entwickler, die das während dem "make"-Prozess automatisiert durchführen und dabei gleichzeitig auf Versionsverwaltung ohne unnötige binäre Dateien setzen möchten.