Skip to content

SSL Verkehr überwachen

Im letzten Artikel (zur Poodle Lücke) habe ich die klare Empfehlung ausgesprochen SSL 3.0 (und 2.0 sowieso) abzuschalten, wenn es nicht mehr benötigt wird. Hier stellt sich natürlich sofort die Frage: "gibt es noch kritische Verwender von SSL3 in meinem Netz".

Für die Unternehmens-IT kann das eine relativ komplizierte Angelegenheit werden die Owner aller Anwendungen zu befragen. Die Anwendungen zu ermitteln (einfach die Liste der freigeschaltenen Ports in der Firewall durchgehen) ist noch relativ einfach, ob aber die Befragten die Antwort kennen (oder die Frage verstehen) ist eine ganz andere Sache.

SSL Log im Apache aktivieren

Dazu kommt noch das Problem dass in jeder Anwendung die Art und Weise wie man die verwendeten SSL Protokolle sehen kann unterschiedlich ist. Teilweise ist die Funktion nicht aktiviert oder lässt sich nur mit vielen zusätzlichen Debug Meldungen einschalten.

Bei einem Apache httpd ist es eigentlich zwingend das erweiterte SSL Log Format "combinedssl" immer zu verwenden:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %{SSL_PROTOCOL}x %{SSL_CIPHER}x" combinedssl
CustomLog /var/log/httpd/access.log combinedssl

Es ist praktisch, wenn die SSL/TLS Terminierung an möglichst wenigen Stellen erfolgt. Zum Beispiel einen Cluster aus Reverse Proxies oder Load Balancern. Und natürlich sollte für diese Dienste ein entsprechendes Log bereitstehen.

tls-hello-dump

Aber nicht immer gibt es diese Möglichkeit (für alle Anwendungen). Insbesondere nicht bei Client Verbindungen. Es kann von daher notwendig sein auf Netzwerkebene den Datenstrom zu überwachen und eine Statistik zu erstellen (oder die IP Addressen der notorischen SSL3 Verwender manuell nach zu püfen. Es könnte ja auch der unternehmenskritische Bestellfluss des größten Auftraggebers sein). Ich vermute mal ein gutes Network Intrusion Detection System (NIDS) kann diese Statistiken liefern. Ist eine solche Klassifizierung des Traffics aber nicht gegeben, so beginnt die Suche nach einfachen Tools.

Mit tcpdump oder vergleichbaren Sniffern muss man recht viel selbst bauen. Auch ssldump ist hier recht sperrig (und auch nicht sehr aktuell). Das einfachste Tool was ich bisher gefunden habe ist tls-hello-dump von Georg Lukas. Es schreibt pro Handshake 2 Zeilen, eine für die vorgeschlagenen Ciphers des Clients (ClientHello) und eine für die vom Server angenommenen Parameter (ServerHello). Es setzt auf libpcap auf, kann somit auf Linux/FreeBSD einfach eingesetzt werden. Es kann sowohl Verbindungen an das lokale System überwachen als auch Netzwerktraffic (solange der Host auf dem tls-hello-dump läuft am Netzwerkport der in PROMISC geschaltet ist alle Daten sieht).

Hier als Beispiel ein Chrome38/Apache2.2 Handshake sowie ein (unbeantworteter) openssl s_client -ssl3 -connect versuch:

109.192.117.164 195.49.138.57   TLSv1 ClientHello TLSv1.2 :CC14:CC13:
  C02B:C02F:009E:C00A:C009:C013:C014:C007:C011:0033:0032:0039:009C:
  002F:0035:000A:0005:0004:

195.49.138.57   109.192.117.164 TLSv1.2 ServerHello TLSv1.2 cipher C02F

109.192.117.164 195.49.138.57   SSLv3 ClientHello SSLv3 :C014:C00A:C022:
  C021:0039:0038:0088:0087:C00F:C005:0035:0084:C012:C008:C01C:C01B:
  0016:0013:C00D:C003:000A:C013:C009:C01F:C01E:0033:0032:009A:0099:
  0045:0044:C00E:C004:002F:0096:0041:0007:C011:C007:C00C:C002:0005:
  0004:0015:0012:0009:0014:0011:0008:0006:0003:00FF:

Und das ganze noch einmal aufbereitet mit dem ebenfalls beigelegten sed script, welches aus den Hex-codes der Ciphers lesbare Namen macht.

109.192.117.164 195.49.138.57   TLSv1 ClientHello TLSv1.2 :TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256:
  TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256:TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:
  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:TLS_DHE_RSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA:
  TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:
  TLS_ECDHE_ECDSA_WITH_RC4_128_SHA:TLS_ECDHE_RSA_WITH_RC4_128_SHA:TLS_DHE_RSA_WITH_AES_128_CBC_SHA:
  TLS_DHE_DSS_WITH_AES_128_CBC_SHA:TLS_DHE_RSA_WITH_AES_256_CBC_SHA:TLS_RSA_WITH_AES_128_GCM_SHA256:
  TLS_RSA_WITH_AES_128_CBC_SHA:TLS_RSA_WITH_AES_256_CBC_SHA:TLS_RSA_WITH_3DES_EDE_CBC_SHA:
  TLS_RSA_WITH_RC4_128_SHA:TLS_RSA_WITH_RC4_128_MD5:

195.49.138.57   109.192.117.164 TLSv1.2 ServerHello TLSv1.2 cipher TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

109.192.117.164 195.49.138.57   SSLv3 ClientHello SSLv3 :TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:
  TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA:TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA:TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA:
  TLS_DHE_RSA_WITH_AES_256_CBC_SHA:TLS_DHE_DSS_WITH_AES_256_CBC_SHA:TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA:
  TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA:TLS_ECDH_RSA_WITH_AES_256_CBC_SHA:TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA:
  TLS_RSA_WITH_AES_256_CBC_SHA:TLS_RSA_WITH_CAMELLIA_256_CBC_SHA:TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA:
  TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA:TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA:
  TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA:TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA:TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA:
  TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA:TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA:TLS_RSA_WITH_3DES_EDE_CBC_SHA:
  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA:TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA:
  TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA:TLS_DHE_RSA_WITH_AES_128_CBC_SHA:TLS_DHE_DSS_WITH_AES_128_CBC_SHA:
  TLS_DHE_RSA_WITH_SEED_CBC_SHA:TLS_DHE_DSS_WITH_SEED_CBC_SHA:TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA:
  TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA:TLS_ECDH_RSA_WITH_AES_128_CBC_SHA:TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA:
  TLS_RSA_WITH_AES_128_CBC_SHA:TLS_RSA_WITH_SEED_CBC_SHA:TLS_RSA_WITH_CAMELLIA_128_CBC_SHA:TLS_RSA_WITH_IDEA_CBC_SHA:
  TLS_ECDHE_RSA_WITH_RC4_128_SHA:TLS_ECDHE_ECDSA_WITH_RC4_128_SHA:TLS_ECDH_RSA_WITH_RC4_128_SHA:
  TLS_ECDH_ECDSA_WITH_RC4_128_SHA:TLS_RSA_WITH_RC4_128_SHA:TLS_RSA_WITH_RC4_128_MD5:TLS_DHE_RSA_WITH_DES_CBC_SHA:
  TLS_DHE_DSS_WITH_DES_CBC_SHA:TLS_RSA_WITH_DES_CBC_SHA:TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA:
  TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA:TLS_RSA_EXPORT_WITH_DES40_CBC_SHA:TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5:
  TLS_RSA_EXPORT_WITH_RC4_40_MD5:TLS_EMPTY_RENEGOTIATION_INFO_SCSV:

Ich hab ein paar Patches beigesteuert die es etwas robuster machen, man muss sich aber vor Augen halten dass das Tool nur sehr einfache Handshakes versteht (diese müssen im Anfang der gefilterten IPv4 Pakete stehen). Schon ein TLS Alert (Warnung: unrecognized_name) verhindert, dass das ServerHello erkannt wird. Außerdem ist aktuell der Parser sehr ungenau was die Überprüfung der Paketformate angeht, es bietet sich also an das Tool nicht als Root auf einem kritischen System laufen zu lassen sondern vielmehr den Traffic mittels tcpdump -w file zu speichern und dann Offline auszuwerten (mit einem User ohne weitere Rechte).

Es sollte auch darauf hingewiesen werden dass es sich hier nur um die Handshakes handelt, Clients die viele erfolglose Verbindungen aufbauen sind in den Zahlen entsprechend überräpresentiert. Wenn eine persistente HTTPS connection tausende Anfragen verarbeitet steht diese nur einmal in der Liste. Ebenso sieht man nicht, ob ein Client, wenn er SSL3 offeriert bekam dieses auch akzeptiert (oder ablehnt).

tls-hello-dump kann nicht mit STARTLS (wie es z.B. in SMTP und IMAP Verwendung findet) umgehen. Das liegt hauptsächlich daran dass es sich nicht damit befasst die gefilterten Pakete zu TCP Strömen zusammenzusetzen. Das macht das Tool leichtgewichtig aber eben auch beschränkt. ssldump wäre für diesen Fall die bessere Wahl.

Compilieren und starten

tls-hello-dump steht auf GitHub als source code zur Verfügung (habe noch kein Binärpaket gesehen) und sollte auf jedem Linux Rechner mit entsprechenden Entwicklungspaketen übersetzbar sein:

git clone https://github.com/ge0rg/tls-hello-dump.git
cd tls-hello-dump/
make clean all
FILTER="tcp port 443 and tcp[tcp[12]/16*4]=22 and (tcp[tcp[12]/16*4+5]=1 or tcp[tcp[12]/16*4+5]=2)"
sudo tcpdump -p -s 1518 -i eth0 -w handshakes.pcap "$FILTER"
./tls-hello-dump handshakes.pcap | sed -f readable.sed 

Oder für die Mutigen: "sudo ./tls-hello-dump eth0 https | sed -f readable.sed"

Der Poodle bellt (SSL Sicherheitsschwäche)

Wieder einmal macht eine Sicherheitslücke mit einem klangvollen Namen die Runde. Poodle ist eine Schwachstelle in SSL 3.0, die sich aber auch auf neuere Clients auswirkt. Ausgelöst wurde das ganze durch ein Paper der Google Sicherheitsforscher Bodo Möller, Thai Duong und Krzysztof Kotowicz. Warum Sites wie Twitter mit der Abschaltung von SSL 3.0 reagieren möchte ich hier kurz darstellen.

Zuerst einmal eine Feststellung: SSL 3.0 (das Secure Socket Layer Protokoll in der Version 3.0 von 1996, nachträglich in RFC6101 dokumentiert) ist (trotz der Versionsnummer) der Vorgänger von TLSv1, TLS 1.1 oder dem aktuellen TLS 1.2 (RFC5246). Es hat eine Reihe von Sicherheitsproblemen und Unschönheiten und sollte schon länger nicht mehr verwendet werden.

Die Poodle Lücke hat das nur bestätigt: Durch eine ungeschickte Verwendung von Füll-Bytes bei dem CBC Modus (verwendet für DES, 3DES und RC2) kann ein Angreifer der mehrere SSL Anfragen beeinflussen und abhören kann, auf den Inhalt schließen. Diese Schwachstelle ist ähnlich zu der bereits vor einiger Zeit bekannt gewordenen BEAST Lücke.

Es sind verschiedene Situationen denkbar, bei denen diese Lücke ausgenutzt werden kann, aber im Web Browser Umfeld ist es dank JavaScript und Userinteraktion am Einfachsten.

Für SSL 3.0 kann dies nicht behoben werden (und selbst wenn wäre es einfacher direkt TLS 1.2 zu verwenden das die Lücke nicht hat). Bei Clients und Server die SSL 3.0 noch einsetzen könnte man die betroffenen CBC Ciphers abschalten, das ist aber leider keine sehr attraktive Lösung da sonst nur noch die eher unsichere RC4 Stromchiffre verwendet werden könnte.

SSL 3.0 muss sterben

Ohne jetzt nun näher zu bewerten wie einfach oder wie schwer die Lücke in welcher Situation ausgenutzt werden kann sind sich eigentlich alle einig: SSL 3.0 sollte nicht mehr verwendet werden und kann in Clients und Servern endlich abgeschaltet werden. Dies nimmt somit auch schon die Empfehlung vorweg und den Weg gehen alle mehr oder weniger schnell.

Ob man die Unterstützung für SSL 3.0 abschalten kann hängt vor allem damit zusammen ob alle potentiellen Gegenstellen ein gemeinsames neueres Protokoll sprechen. Als Web Server Betreiber stellt sich die Situation recht einfach dar: alle Clients außer Internet Explorer 6 auf einem Windows XP (und älter) können mindestens TLSv1, die meisten auch schon 1.1 oder 1.2 (wobei es nicht alle angeschaltet haben).

Internet Explorer 6 muss brennen

Aus einer ganzen Reihe von Gründen ist es eigentlich nicht mehr wünschenswert IE 6 zu benutzen, und schon gar nicht zu fördern. Da es selbst für Anwender die auf XP festsitzen Alternativen gibt (darunter Firefox und IE 7-8) sollte man inzwischen keinen Gedanken verschwenden und SSL 3.0 in öffentlichen Web Servern sofort abschalten.

CloudFlare, ein CDN und Cloud Security Dienstleister der weltweit viele Websites schützt und ausliefert hat Statistiken veröffentlicht, sie werden SSL 3.0 abschalten:

Across our network, 0.09% of all traffic is SSLv3. For HTTPS traffic, 0.65% across our network uses SSLv3. The good news is most of that traffic is actually attack traffic and some minor crawlers. For real visitor traffic, today 3.12% of CloudFlare's total SSL traffic comes from Windows XP users. Of that, 1.12% Windows XP users connected using SSLv3. In other words, even on an out-of-date operating system, 98.88% Windows XP users connected using TLSv1.0+ — which is not vulnerable to this vulnerability.

Wenn man weg geht von dem reinen Webbrowser/Server Umfeld, so ist die Unterstützung von neueren Protokollen nicht ganz so klar. Allerdings ist TLSv1 bereits in Java SE 1.4 enthalten, und so dürfte die Anzahl der Endpunkte die kein TLS können sich auf spezielle Embedded Hardware (und falsch konfigurierte Software) beschränken. Im System-to-System oder MFT Umfeld ist das Risiko der POODLE Lücke deutlich geringer (weil der interaktive Einfluss fehlt), aber auch hier wäre es ratsam und Risikofrei SSL 3.0 einfach abzuschalten.

SSL Fallback

Wenn sowohl Client als auch Server das TLS Protokoll sprechen so können Sie dies beim Verbindungsaufbau erkennen, und die gemeinsam gesprochene beste Version aushandeln. Dank Überprüfung dieses Handshakes ist es einem Angreifer auch nicht möglich der jeweils anderen Seite eine niedrigere Version vorzugaukeln.

Allerdings gibt es bei der Sache einen Haken: da manche Clients wenn ein Verbindungsaufbau mit einem TLS Handshake nicht klappt das ganze erneut mit einer älteren Version versuchen (out-of-band protocol fallback). Ein Angreifer muss damit nicht den ersten Handshake ändern (was TLS erkennt), sondern nur aufhalten (in der Praxis passiert dies sogar bei Überlastung ganz ohne Angreifer, was ebenso nicht erwünscht ist). Wenn der Client einen erneuten Versuch unternimmt und dabei nur SSL 3.0 ankündigt, so gelingt der Handschlag zwischen Client und Server mit einer unnötig alten (und unsicheren) Protokoll Version.

Dieser Downgrade Angriff ist Bestandteil der POODLE Lücke (wenn neuere Client und Server verwendet werden). Zur Verhinderung davon gibt es mehrere Möglichkeiten:

  • Clients verzichten auf den Fallback handshake und verlassen sich auf die TLS Versionslogik (dazu gehört zum Beispiel Java, wenn der Entwickler die Logik nicht selbst implementiert hat)
  • Auf Clients und Servern unsichere Protokollversionen gar nicht anbieten (SSL 3.0 abschalten)
  • Ein neuer Mechanismus bei dem ein Client der einen kompatiblen Handschlag versucht eine Markierung (die nicht entfernt werden kann) mitschickt, dass es ein Kompatibilitätsversuch ist. Server die von dieser Markierung wissen würden den Handschlag dann ablehnen (wenn sie eine neuere Version sprechen).

Letzteres wird TLS_FALLBACK_SCSV genannt, es handelt sich um eine sogenannte Signalling Cipher, die aktuell in Diskussion ist (und Google Chrome sendet dies schon einige Zeit, Firefox ab Version 35). Damit diese funktionieren kann, müssen aber die Server diese auch kennen. Die Erweiterung ist umstritten, denn für den Fall SSL 3.0 ist ein abschalten einfacher, und für zukünftige TLS Protokoll sollten die Clients einen Fallback einfach gar nicht durchführen.

TLSv1

So positiv wie es zu sehen ist, dass sehr viele Lösungen mindestens TLSv1 sprechen, so ist dies auch ein deutliches Warnzeichen: TLSv1 ist auch schon stark angekratzt. Die meisten wirklich wünschenswerten Verbesserungen sind erst in TLSv1.1 oder 1.2 zu finden. Schon heute können Sicherheitsbewusste Anbieter TLSv1 abschalten (Der Mozilla Server Side TLS Security Guide nennt dies „Modern Compatibility“). Es ist entsprechend anzuraten gleich jetzt zu evaluieren ob man auch gleich TLSv1 verbannen möchte und sicherzustellen dass TLSv1.2 angeboten wird (und so konfiguriert ist, dass es Perfect Forward Secrecy unterstützt und auf Zertifikaten basiert die mit SHA2 statt SHA1 oder gar MD5 signiert sind).

Zum weiterlesen

Dell BIOS Upgrades (Latitude E6510)

Ich wollte meinem etwas älteren Dell Latitude E6510 ein BIOS update gönnen, in der Hoffnung ein paar der Probleme die ich mit dem Akku und dem thermischen Verhalten habe damit etwas in den Griff zu bekommen. Dank dem Service Tags konnte ich auf der Support Seite auch schnell die benötigten Downloads ausmachen. Mein Gerät hatte ein BIOS in der Version A06, auf der Webseite stand als letzte Version die A16 bereit.

ScreenshotDie BIOS Updates bei Dell kommen als Bundle mit Flashes für das Bios, das System Management, die Intel Management Engine und weiterer Komponenten. Wenn man das Programm startet so frägt es nach dem BIOS Passwort, und nach wenigen Sekunden wird der Rechner auch für den Update Rebootet. In meinem Fall geschah allerdings nach dem Reboot nichts weiter. Das System meldete die gleiche alte Version weiterhin. Keine Fehlermeldung. Ich hatte dann mit verschiedenen Optionen herumgespielt, z.B. den Upgrader als Administrator zu starten, oder im abgesicherten Modus meines Win7 x64. Aber alles hat nicht weitergeholfen.

Nach ein wenig herumsuchen auf den Support Webseiten habe ich festgestellt dass bei ein paar der älteren BIOS Versionen eine Mindestversionsnummer vorausgesetzt und auch abgeprüft wird. Ebenso gibt es die Empfehlung mit der BIOS Version zu beginnen die das System schon hat. Und tatsächlich haben sich einige der dazwischenliegenden Versionen auch geweigert eine ältere A06 zu aktualisieren. A06-A08 konnte ich allerdings gar nicht installieren, da der Upgrader statt zu rebooten gecrashed ist. Übrigens werden nicht alle älteren Versionen in der Rechner-spezifischen Supportseite angezeigt, die Volltext Suche jedoch findet die Downloads in allen benötigten Versionen.

Screenshot: USB BootIch habe dann gesehen, dass die Updater .exe Files nicht nur mit Windows benutzt werden können, sondern auch mit DOS. Und das war dann die Lösung: alle BIOS Versionen auf einen USB Stick kopiert auf dem SystemRescueCd (mit LinuxLiveUSB) installiert ist. Dieses bringt auch FreeDOS (für diverse DOS Firmware Utilities) mit. Davon gebootet zeigte die BIOS Update Routinen sich sehr leicht bedienbar, und vor allem erfolgreich beim Update. Zuerst von A06 auf A06 - das hat dazu geführt dass der nächste Update auf A07 schon besser die Versionen der einzelnen Systemkomponenten anzeigen konnte. Und vor allem fand nach dem Reboot auch ein Flash Vorgang statt, der vorher nicht zu sehen war.

Screenshot: BIOS Update unter DOsMeine Vermutung: ältere BIOS Updater können zwar noch richtig prüfen ob man auf einer erforderlichen Minimalversion ist, dafür stürzen diese aber unter aktuellem Windows 7 x64 ab. Neuere Updater (insbesondere A16) funktionieren zwar problemlos mit Windows 7, prüfen aber die Minimalvoraussetzung nicht. Nach dem Reboot wenn das BIOS geflashed werden soll, wird die Version geprüft und der Update verweigert - jedoch ohne sichtbare Fehlermeldung.

Es ist schade, dass Dell hier ein sehr uneinheitliches Erlebnis hat: die BIOS Updater sind einfach zu bedienen, arbeiten schnell und sind durch die Unterstützung von Windows und DOS sehr flexibel. Gleichzeitig erwartet anscheinend keiner bei DELL, dass man nicht alle 6 Monate ein neues BIOS einspielt, entsprechend lückenhaft ist die QA bei so einem Update Schritt. Dass es ärgerlich ist, dass ich 5 Zwischenversionen einspielen musste: geschenkt.

 

Übrigens bietet Dell in der Knowledgebase einen Artikel an, welche BIOS Versionen welche Mindestvoraussetzungen haben. Es steht nicht dabei dass es auch für Folgeversionen gilt, aber meine Erfahrung ist jetzt, man muss alle Zwischenschritte gehen:

Article ID: 603480 (2013-05-07): Dell Optiplex, Latitude and Precision BIOS Dependency Chart

Product Installed Must Update Before Version
Latitude E6510 A08 A09 A10
Latitude E6510 A10 A11 A12

Meine Reihenfolge: A06 -> A06 -> A07 -> A09 -> A10 -> A11 -> A16.

Eines der neuen Features der Firmware ist die (nicht wieder abschaltbare) Option nur BIOS Updates mit gültiger Dell Signatur zu erlauben. Das ist angesichts der Einfachheit mit der man den BIOS Update anstoßen kann sicherlich sehr empfehlenswert, allerdings scheue ich nach meinen Erfahrungen mit der schlampigen QA bei Dell doch etwas davor zurück.

FilterOutputStream - considered harmfull

Java besitzt mit java.io.FilterOutputStream eine Klasse die man als Entwickler extended kann um einen OutputStream zu implementieren der Daten filtert. Dabei implementiert die Basisklasse die unterschiedlichen Varianten von write() sowie flush() und close().

Ich hatte im Rahmen der Vorbereitung für eine Apache Commons VFS 2.1 release geschaut, ob der Code bereits mit Java 8 compiliert werden kann. Es sind noch ein paar Punkte offen, aber was besonders auffiel ist, dass ein Unit-Test fehlschlägt. Nach etwas Analyse (VFS-521) habe ich festgestellt, dass das Problem vom FilterOutputStream in Java 8 herrührt, der ein try-with-resource verwendet um flush() und close() durchzuführen. Wenn dabei beide Methoden die selbe Exception werfen so gibt es beim Hinzufügen der unterdrückten Exception statt der erwarteten IOException eine sehr störende IllegalArgumentException: Self-suppression not permitted.

Wenn man sich den Code älterer Java Implementierungen im Vergleich anschaut, so sieht man allerdings, dass diese noch viel problematischer waren. Denn diese verschlucken bei einem close() potentielle IOExceptions die im davor aufgerufenen flush() aufgetreten sind. Das ältere unsichere Verhalten des FOS ist auch ein "akzeptierter" Bug im JDK: JDK-6335274.

Da der FilteredOutputStream nur verschlimmbessert wurde ist meine Lösung Abstand von dessen close() Methode zu nehmen. Und dies gilt leider auch für den BufferedOutputStream. Hier eine Version ohne besondere Unterstützung für suppressed exceptions.

Mal sehen was auf der openjdk-corelibs-dev liste dazu herauskommt, dort habe ich das Problem mal geschildert. Ein JDK-Bug wurde angelegt, der ist aber noch unbearbeitet.

Heartbleed, woher kommt der Name

Wieder einmal macht SSL/TLS Schlagzeilen, dieses mal durch eine Sicherheitslücke in OpenSSL mit der Bezeichnung CVE-2014-0160 und dem Spitznamen "Heartbleed". Aber woher kommt dieser Name?

Der Name setzt sich zusammen aus dem Begriff "Heartbeat" also Herzschlag und "to bleed" also bluten - oder wie in diesem Fall ausbluten.

Der technische Titel ist "TLS heartbeat read overrun". Angefangen hat alles mit einer TLS Erweiterung die im RFC 6520 "TLS/DTLS Heartbeat Extension" (Februar 2012) definiert ist. Diese erlaubt es in TLS Verbindungen (oder bei DTLS Paketen) zusätzlich zu den normalen verschlüsselten Sitzungsdaten auch beliebig große herzschlag Nachrichten auszutauschen. Diese sind benannt nach Ihrer Funktion: dem Nachweis dass die Gegenseite noch am Leben ist und erreichbar ist. Im Falle von DTLS wird die Möglichkeit zu bestimmen wie viele Daten gesendet (und wieder zurückgesendet werden) dazu benutzt um auszumessen was die maximale Paketgröße ist die aktuell verwendet werden kann.

Die Erweiterung an sich ist keine schlechte Idee (auch wenn natürlich alle Erweiterungen immer ein Risiko darstellen). Die Verwendung der Heartbeat Extension wird gegenseitig beim Verbindungsaufbau ausgehandelt, und nicht jede Software untersützt diese Funktion bereits. Mit einem Patch hielt diese Funktion dann auch vor 2 Jahren Einzug in OpenSSL 1.0.1.

Und dabei wurde, wie es schon zu erwarten ist ein Programmierfehler begangen: DTLS und TLS sind leider nicht die einfachsten Protokolle. Daten werden in Records übertragen, deren Länge am Anfang steht. Darin finden sich dann Nachrichten unterschiedlichen Types - wie zB die Heartbeat Anfrage und Antwort. Da die Nachrichten selbst unterschiedliche Länge haben wird innerhalb der Nachrichtenstruktur nochmal übertragen wie lange die Nachricht ist. Was der Code jetzt fälschlicherweise tut ist, er kopiert die heartbeat Daten der Anfrage in das Antwortpaket aber verlässt sich dabei auf die Längenangabe der Anfrage-Nachricht ohne vorher zu prüfen ob diese in den übertragenen SSL Record gepasst hätte.

Damit kopiert die Funktion nicht nur Daten des Angreifers sondern eben auch beliebige Speicherinhalte dahinter in die Antwortnachricht. Diese wird dann sauber und sicher verschlüsselt und zurückgesendet. Mit jeder Heartbeat Antwort können so knapp 64kb Daten aus dem Innersten des Prozesses an den Angreifer gesendet werden, der Prozess blutet damit quasi aus. Betroffen sind alle OpenSSL Versionen zwischen 1.0.1,1.0.1a-f sowie 1.0.2-betas.

Behoben ist das Problem in 1.0.1g (und zukünftig 1.0.2) nachdem sowohl Google als auch Codenomicon den Bug entdeckt und an das OpenSSL Team gemeldet haben (Wenn man der sehr vollständigen Beschreibung auf heartbleed.com glauben darf).

Was in den Daten steht die der Angreifer sich SSL gesichert herunterladen kann ist schwer zu sagen. Man sollte aber auf jeden Fall davon ausgehen dass der SSL Schlüssel des Servers sowie zufällige Sitzungsdaten davon betroffen sind. (Update 2014-04-26: inzwischen ist es klar (Rubin Xu), warum Teile des Schlüssels immer wieder im Heap auftauchen.)

BTW: wer es genau wissen will: XKCD#1354 :)

Search Meetup Karlsruhe

Search User Group KA LogoLetzte Woche fand das erste Meetup der neuen Search Meetup Gruppe in der IHK statt. Die Auftaktveranstaltung war gesponsort* von Exensio. Florian und Tobias die Organisatoren konnten einige Search-Begeisterte aus dem Raum Karlsruhe zusammenbekommen um die zukünftigen Themen des Meetups zu besprechen. Tobias ielt den ersten Kurzvortrag (den ich leider verpasst hatte). Anschliessend gab es noch angeregte Diskussionen um zukünftige Themen. Solange aus den unterschiedlichsten Unternehmen die rund um Karlsruhe Such Technologien (wie Lucene, Elastic Search oder Solr) einsetze Vortragsangebote kommen, sollten auch künftige Meetups spannend werden.

Twitter: @SearchKA
Meetup Gruppe: Search Meetup Karlsruhe

 * Es scheint garnicht zu einfach sein in der Technologie Region Karlsruhe kostenfrei Räumlichkeiten für UserGroups zu erhalten. Hier sollten sich die diversen Marketing-Arme der Stadt und "High Tech Industrie" mal was überlegen.

Oracle Container Datenbank

Seit einiger Zeit gibt es eine Neuauflage des SQL Datenbankklassikers von Oracle. Unter der Bezeichnung Oracle 12c (C wie Cloud) und der internen Versionsnummer 12.1 stehen einige neue Funktionen bereit.

Multitenant Architectur (CDB) 

Mit der 12c Release hat Oracle eine neue Multitenant Architektur eingeführt, die es erlaubt eigenständig verwaltbare Datenbanken in einer gemeinsamen Datenbankinstanz zu betreiben. Damit verbunden sind einige neue Features wie der Transport der gesamten Datenbank (nicht nur einzelner Tablespaces) von einer Instanz in eine andere. Es erlaubt ebenfalls das bereitstellen von Clones der Datenbank für Entwicklung und QA. Das Hauptargument ist jedoch die Selbstverwaltung durch beschränken der Sichtbarkeit der Datenbankobjekte auf den jeweiligen Untermieter - alles was man für die Konsolidierung von Datenbanken so braucht.

Damit zieht Oracle mit dem Microsoft SQL Server gleich, bei dem Datenbanken ja schon länger eigenständige Objekte (mit eigenen Usern) waren. Allerdings wirkt es wie gewohnt bei Oracle etwas aufgesetzter. So gibt es die normalen Systemuser die in allen PDB gelten (z.B. DBSNMP) aber für weitere User empfiehlt Oracle eine Namenskonvention "C##USERNAME" für gemeinsam benutzte (Common) User.

Meiner Erfahrung nach heißt es Vorsicht beim Umstieg auf 12c (wenn die CDB aktiviert ist). Die neue Multitenant Architektur ist zwar praktisch, DBA sind es aber nicht gewöhnt. So ist es z.B. wichtig vorhandene User+Rollen Definitionsscripte entweder im richtigen Container aufzurufen. Entweder man benutzt einen Common DB User und ändert den Session Context:

ALTER SESSION SET CONTAINER = 'PDBTEST'; 

Dann muss man sich aber auch regelmäßig vergewissern, welches die gerade aktive PDB ist:

SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM DUAL;

Oder man legt entsprechende Administrationuser in jeder PDB separat an. Dazu muss man dann auch einen TNS Connect String verwenden der auf einen Datenbank Service verweist, welcher der jeweiligen PDB zugeordnet ist. Wenn eine neue PDB angelegt wurde, wird auch ein neuer Service mit PDB Name + DB_Domain registriert:

> SELECT NAME,PDB,CON_ID from GV$SERVICES;
NAME                         PDB                  CON_ID
---------------------- -------------------------- ----------
pdbtest.eckenfels.net   PDBTEST                   4
pdborcl.eckenfels.net   PDBORCL                   3
orcl.eckenfels.net      CDB$ROOT                  1
SYS$BACKGROUND          CDB$ROOT                  1
SYS$USERS               CDB$ROOT                  1  

Die Arbeit mit CDBs macht Oracle nicht gerade einfach. Wenn man eine neue Container Datenbank mit dem Datebank Konfigurationsassistent (oder CREATE Statement) anlegt, so wird diese Datenbank bei einem Instanzstart nicht automatisch geöffnet. Man muss sich also mit einem Systemtrigger behelfen. Das hätte man wirklich komfortabler lösen können (und wenn Oracle in einer nächsten Version eine Lösung dafür anbietet wird man sich mit den Triggern wieder beschäftigen müssen).

Das ist übrigens ein sehr ärgerliches Problem, der Oracle SQL Developer gibt zwar in der Console eine entsprechende Fehlermeldung aus:

> ALTER SESSION SET container = PDBORCL;
session SET geändert.
> CREATE ROLE "NORMAL_USER";
Fehler beim Start in Zeile 1 in Befehl:
CREATE ROLE "NORMAL_USER"
Fehler bei Befehlszeile:1 Spalte:1
Fehlerbericht:
SQL-Fehler: ORA-01109: Datenbank nicht geöffnet
01109. 00000 -  "database not open"
*Cause:    A command was attempted that requires the database to be open.
*Action:   Open the database and try the command again
> ALTER PLUGGABLE DATABASE PDBORCL OPEN READ WRITE;
pluggable DATABASE geändert.
> CREATE ROLE "NORMAL_USER";
role "NORMAL_USER" erstellt.

Wenn man das ganze allerdings im SQL Developer macht, so wird die Meldung durch ein Fehler Pop-Up mit unverständlicher Fehlermeldung verdeckt:

Bei der Ausführung des angeforderten Vorgangs ist ein Fehler aufgetreten:
ORA-06550: Zeile 3, Spalte 35:
PLS-00201: Bezeichner 'DBMS_SQL.OPEN_CURSOR' muss deklariert werden
ORA-06550: Zeile 3, Spalte 19:
PL/SQL: Item ignored
ORA-06550: Zeile 13, Spalte 26:
PLS-00320: Die Typ-Deklaration dieses Ausdruckes ist unvollständig oder fehlerhaft
ORA-06550: Zeile 13, Spalte 9:
PL/SQL: Statement ignored
ORA-06550: Zeile 16, Spalte 17:
PLS-00201: Bezeichner 'DBMS_SQL.LAST_ERROR_POSITION' muss deklariert werden
ORA-06550: Zeile 16, Spalte 5:
PL/SQL: Statement ignored
ORA-06550: Zeile 18, Spalte 34:
PLS-00320: Die Typ-Deklaration dieses Ausdruckes ist unvollständig oder fehlerhaft
ORA-06550: Zeile 18, Spalte 11:
PL/SQL: Statement ignored
06550. 00000 -  "line %s, column %s:\n%s"
*Cause:    Usually a PL/SQL compilation error.
*Action:
Herstellercode 6550

Eine gute Zusammenfassung aller CDB spezifischen Punkte findet sich im Oracle Database Administrator's Guide im Kapitel 40 Administering a CDB with SQL*Plus

Enterprise Manager Database Express

Eine neue Funktion ist das Enterprise Manager Database Express Modul. Statt einen abgespeckten Enterprise Manager (Database Control) mit eigenem Prozess und Ablaufumgebung zu installieren kann man das in der Datenbank eingebaute Express Modul verwenden. Dieses basiert auf der AppEx Infrastruktur. Das als Performance Hub getaufte Dashboard profitiert dann auch mit den Offline abspeicherbaren HTML Reports. Ansonsten ist die Funktionalität allerdings sehr eingeschränkt. Es gibt z.B. keine DDL Funktionen zum Anlegen oder verwalten von Tabellen.

EM DB Express unterstützt die Verwendung von Plugable Databases dahingehend, dass man für jeden Tenant ein eigener http oder https Listener (Port) anlegen kann. Wenn man sich dann nicht im Root Container anmeldet, so sieht man dann erst die jeweils in der PDB angelegten User (Und leider nur dann).

> select dbms_xdb_config.gethttpsport from dual;
GETHTTPSPORT
------------
5500
> alter session set container = PDBTEST;
> select dbms_xdb_config.gethttpsport from dual;
GETHTTPSPORT
------------
> exec DBMS_XDB_CONFIG.SETHTTPSPORT(5502);
> select dbms_xdb_config.gethttpsport from dual;
GETHTTPSPORT
------------
5502

Wenn man sich mit einer PDB verbunden hat (in meinem Beispiel https://server:5502/em/) so wird in der Titelzeile des EM Express links oben nicht nur die SID, sondern auch den Namen der PDB angezeigt. Ebenso enthält die Userliste nicht mehr (nur) die Gemeinsamen User:

Das Jahr der Kryptografie

Ich habe bewusst keinen Jahresrückblick verfasst, jedoch hat sich einiges im letzten Jahr einiges entwickelt, das ich hier kommentieren möchte: die von Edward Snowden geleakten Dokumente über das Tun des us-amerikanischen NSA und des britischen GCHQ brachten neue Spekulationen über Methoden und Fähigkeiten hervor.

Besonders im Bereich der Kryptografie gibt es ja schon seit Jahren Spekulationen welche Möglichkeiten der Mathematikerstab und die Rechnerparks der NSA haben (oder welche Erkenntnisse die der Wissenschaft vorenthalten werden bekannt sind). Daran hat sich bisher noch nicht viel geändert, aber es kam eine neue Dimension dazu: Die Unterwanderung von Standardisierungsverfahren sowie die Beeinflussung von Software- und Hardwareherstellern.

Aktuell im Fokus steht dabei RSA Security LLC - laut Reuters Berichten gab es einen Zusammenhang zwischen Zahlungen der NSA und der Default Verwendung des ECPRNG Zufallsgenerators in der RSA BSafe library. Der Generator war in die Kritik gekommen, weil bei der Verwendung von im Standard vorgegebenen Punktkoordinaten es nicht ausgeschlossen ist, dass die Zahlenfolge vorhersehbar ist (für den Ersteller der Parameter). Diese Kritik ist schon länger bekannt, trotzdem hat RSA Security den Generator nicht nur implementiert und als default eingebaut, und auch nicht wieder zurückgerufen.

Von RSA Security (das inzwischen zu EMC gehört) erwartet man nicht wirklich transparentes vorgehen. Im Falle der SecurID Hardware Token hat RSA Security auch nur sehr zögerlich auf bekanntgewordene Probleme reagiert und war nie sehr transparent mit den eigentlich eingesetzten Algorithmen. Von daher hat das im Fall der RSA BSafe library nicht wirklich verwundert dass es immer noch kein klares Statement zu den Zahlungen und der Bewertung des Dual_EC_DRBG gibt. Update: Habe vergessen zu erwähnen dass auch Mikko Hypponen (Chief Research Officer bei f-secure) eine Meinung zum Verhalten von RSA hat, und seine Rede auf der RSA Conference abgesagt hat (Open Letter). Besonders brisant in dem Zusammenhang ist übrigens der Titel seines geplanten Vortrags: Governments as Malware Authors.

Schaut man sich allerdings die Historie etwas näher an (und dazu eignet sich besonders gut das Blog Post von Matthew Green) so kann man erkennen dass die Eigenschaften des Generators schon sehr früh bekannt waren (und sogar in einer Patentanmeldung erwähnt wurden). Die Mitglieder des Standardisierungsgremiums der ANSI & NIST sowie Mitarbeiter von RSA Security  mussten gewusst haben, dass eine Vorgabe von Parametern für den Generator sehr kritisch sind und nicht verwendet werden sollten. Das Unternehmen das die meisten Patente im Bereich der Eliptic Curve Cryptografie hält (und eben auch das Patent auf ECRNG) ist Certicom. Ich denke wir werden im Laufe dieses Jahres noch eine Diskussion über das Verhältniss zur NSA bekommen.

Das ist insbesondere deswegen wichtig, weil 2014 das Jahr ist in dem ECC eine weite Verbreitung erfahren wird. Viele neuen Protokolle setzen auf die effiziente Krypto (die mit kleineren Schlüsseln auskommt und damit besonders für Mobile Computing oder IoT geeignet ist). Darunter z.B. Bernsteins NaCl (gesprochen: Salt) oder die iOS Filesystem Verschlüsselung. Außerdem ändert sich die Einschätzung was im Bereich RSA Kryptosystem (Faktorisierungsproblem, Post-Quantum Cryptography) als sichere Schlüssellängen angesehen wird. Inzwischen gibt es schon Empfehlungen (ENISA) die auf RSA Schlüssellängen bis zu 16k bit hinweisen. In dieser Größenordnung wird RSA in vielen Einsatzgebieten unmöglich zu verwenden - auch hier wendet man sich dann eher ECC zu.

Deswegen muss jetzt auf den Tisch welche Schwächen eventuell im Design schon absichtlich eingebaut wurden. Tanja Lange und DJB haben in einem Vortrag bereits das Design und diverse Implementierungen der NIST standardisierten (und teilweise von NSA angestellten entworfenen) ECC Kurven kritisiert, und wir werden hier noch einiges zu hören bekommen.

IPv6 Kongress: Java-Anwendungen für IPv6 fit machen

Ich habe die Gelegenheit auf dem fünften IPv6 Kongress (6.-7. Juni in Frankfurt) über das Thema Java und IPv6 zu sprechen. (Programm). Hier das Abstract des Vortrags:
7.6.2013 14:00 - 14:30 Uhr Bernd Eckenfels: Java-Anwendungen für IPv6 fit machen Dass die Java-Plattform IPv6 unterstützt, ist allgemein bekannt – oder es wird vermutet. Aber sind dazu Änderungen an Anwendungen notwendig, die bisher nur für IPv4 getestet wurden? Welche Funktionen der IPv6-Protokollfamilie werden unterstützt? Welche Besonderheiten sind zu beachten, um Dual-Stack-fähige Anwendungen in Java zu erstellen? Der Vortrag betrachtet die Java-API für Netzwerkkommunikation und untersucht diese auf Relevanz für IPv6. Ein besonderes Augenmerk wird auf die Umsetzung von Dual-Stack-fähigen Geschäftsanwendungen (TCP- und TLS-Protokoll) gelegt. Implementierungsdetails von Java SE 7 (OpenJDK, Oracle und IBM) sind Teil des Vortrags.
Ich werde nicht auf die mobilen Java Profile oder Android eingehen. Und über Java 8 gibt es in dem Bereich keine Neuerungen zu vermelden.

HP-UX Development in the Cloud with HP ClOE

At $EMPLOYER we are developing and offering (Java based) COTS Enterprise Software to a wide range of customers. And while it looks like customer demand seem to concentrate on the various Linux enterprise distributions as well as Windows Server, there are of course still customers with different strategic platforms for Mission Critical applications. This includes AIX, HP-UX and Solaris which we all officially support. For a specialized ISV it is hard to have test systems for all those platforms combinations and keep up with the latest patches and Java versions. This is especially true if you do not want to maintain a whole datacenter full of test equipment. Luckily most of the system vendors offer some sort of partner program and provide opportunities to test. HP AllianceONE Partner Program Today I want to blog about the HP offering called Cloud Operating Environment (CLOE). As an HP AllianceOne Partner Program member we have access to this offering and can order virtualized HP-UX machines on a self-service portal for the purpose of porting, integrating and troubleshooting customer problems. The standard machines offered are OK for installation and compatibility testing or creating documentation for it. Simulating larger environments and doing load-tests requires different agreements. ClOE Web Page When ordering a new "Project" you have to give some details about the work you are planning to do (but I had actually never denied any request). Most of the work is related in trying out installer, shell scripts as well as Java dependencies. Remote Shell Access After ordering a Server (for example the medium configuration of HP-UX 11i v3 Data Center OE with 2 CPUs, 4GB RAM and 2 x 36GB HDD). After the server is provisioned (which takes about 12 minutes), you will receive an e-mail with the SSH key for root user. This SSH keyfile can be converted into a PuTTY .ppk file with the use of the PuttyGen Tool. The SSH access is the only open incoming network connection, so you need the SSH port forwarding feature available in PuTTY if you want to access or provide remote services. The login is a bit slow, I discovered, that it helps to put the option UseDNS no in /opt/ssh/etc/sshd_config to speed up the SSH login process. Otherwise you need to increase login timeout limits of some SFTP tools. PuTTY Login Installing Open Source Software On the first startup the system is pretty basic, there are only some Open Source goodies installed in /usr/contrib. But it is missing for example a modern shell. We can fix this with the help of the HP-UX Porting and Archive Centre:
# cd /var/tmp
# /usr/bin/ftp hpux.connect.org.uk
Name: ftp
Password: root@ 
ftp> cd /hpux/Sysadmin/depothelper-2.00/ 
ftp> get depothelper-2.00-ia64-11.31.depot.gz
ftp> quit
# /usr/contrib/bin/gunzip depothelper-2.00-ia64-11.31.depot.gz
# /usr/sbin/swinstall -s /var/tmp/depothelper-2.00-ia64-11.31.depot depothelper
... 
# /usr/local/bin/depothelper curl bash
# /usr/local/bin/bash
Bash-4.2$
Using remote X11 If you need to run applications with a graphical user interface, you need a way to display X11 sessions. There are basically two options. The first is, you install locally (on your PC) a X Window server (like Xming) and then set the X11 DISPLAY variable to a port which is forwarded by SSH back to your desktop. This requires no additional software on HP-UX side, but is not very fast. Another problem is, that if you lose the SSH connection all GUI applications on the remote side will be terminated. So the better option is to use a X11 simulating server on the HP side and connect to it. This allows to re-attach the session. Xvnc is a X11 server which can do that. It runs on the HP server talking X11 protocol to the local clients and publishes the frame buffer via VNC protocol. On the PC you only need a VNC client and connect (via a SSH port tunnel) to the remote. Unfortunately HP offers no Xvnc out of the box. But you can buy a version from RealVNC. There is also an older 4.1.2 PARISC binary floating around on the Internet which does not require a commercial license and works fine in the Aeries emulator:
# cd /var/tmp
# export PATH=$PATH:/usr/local/bin
# curl -o vnc-4_1_2-parisc_hpux.depot.gz http://www.grossmatten.ch/share-freeware/Network/VNC/4.1/vnc-4_1_2-parisc_hpux.depot.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1767k  100 1767k    0     0   158k      0  0:00:11  0:00:11 --:--:--  182k
# /usr/contrib/bin/gunzip vnc-4_1_2-parisc_hpux.depot.gz
# /usr/sbin/swinstall -s /var/tmp/vnc-4_1_2-parisc_hpux.depot VNC
...
# vncpasswd
Password: 
Verify:
# vncserver
xauth:  creating new authority file //.Xauthority

New 'aps39-92:1 (root)' desktop is aps39-92:1

Creating default startup script //.vnc/xstartup
Starting applications specified in //.vnc/xstartup
Log file is //.vnc/aps39-92:1.log
After this you need to forward port 5901 in PuTTY to localhost:5901 on remote, and can connect with a VNC Viewer on your Desktop. Expanding Filesystem Capacity The next task is, that the default filesystems are sized too small to install additional software, so you need to get access to the additional capacity. As I am not a HP-UX expert and I could not find a good tutorial on that, here is my attempt to mount the second disk and to increase the /var filesystem with the remaining LVM extends (I did not setup a LVM for the second disk to keep the two devices independent for better snapshotting):
# bdf
Filesystem          kbytes    used   avail %used Mounted on
/dev/vg00/lvol3    1048576  176080  865720   17% /
/dev/vg00/lvol1    1835008  167008 1655064    9% /stand
/dev/vg00/lvol8    4718592  899128 3794848   19% /var
/dev/vg00/lvol7    5472256 3340744 2114872   61% /usr
/dev/vg00/lvol4     524288   21200  499160    4% /tmp
/dev/vg00/lvol6    8708096 5689992 2994560   66% /opt
/dev/vg00/lvol5     106496    5792   99928    5% /home

# for i in /dev/disk/*; do diskowner -AF $i; done | grep -v ioerror
path=/dev/disk/disk4:owner=partition.vxfs
path=/dev/disk/disk4_p1:owner=vxfs
path=/dev/disk/disk4_p2:owner=lvm.vxfs
path=/dev/disk/disk4_p3:owner=vxfs
path=/dev/disk/disk5:owner=vxfs

# vgdisplay -v
…
--- Physical volumes ---
   PV Name                     /dev/disk/disk4_p2
   PV Status                   available
   Total PE                    4495
   Free PE                     1247
   Autoswitch                  On
   Proactive Polling           On

# lvdisplay /dev/vg00/lvol8
--- Logical volumes ---
LV Name                     /dev/vg00/lvol8
…
LV Size (Mbytes)            4608
Current LE                  576
Allocated PE                576
 
# lvextend -l $[576+1247] /dev/vg00/lvol8
Logical volume "/dev/vg00/lvol8" has been successfully extended.
 
# lvdisplay /dev/vg00/lvol8
...
LV Size (Mbytes)            14584
 
# fsadm -b 14584m /var
fsadm: /etc/default/fs is used for determining the file system type
vxfs fsadm: V-3-23585: /dev/vg00/rlvol8 is currently 4718592 sectors - size will be increased
 
# mkfs -F vxfs /dev/disk/disk5
    version 6 layout
    37748736 sectors, 37748736 blocks of size 1024, log size 16384 blocks
    largefiles supported

# mkdir /u01
# echo "/dev/disk/disk5 /u01 vxfs delaylog 0 3" >> /etc/fstab
# mount /u01

# bdf
Filesystem               kbytes      used        avail      %used Mounted on
/dev/vg00/lvol3    1048576    176080     865720   17% /
/dev/vg00/lvol1    1835008    167008   1655064    9% /stand
/dev/vg00/lvol8    14934016  899496 13930104    6% /var
/dev/vg00/lvol7    5472256    3340744 2114872   61% /usr
/dev/vg00/lvol4     524288      21200       499160    4% /tmp
/dev/vg00/lvol6    8708096    5689992 2994560   66% /opt
/dev/vg00/lvol5     106496      5792           99928    5% /home
/dev/disk/disk5    37748736  26333   35364760    0% /u01
The fsadm command to online-resize the filesystem is only available in the Data Center OE, the Base Operating Environment has not the required license option "Online JFS" activated In the next article I will have a look at installing patches and Quality Packs. Update 2012-05-13: How to get Started presentation from HP: http://h20195.www2.hp.com/V2/GetDocument.aspx?docname=c03201145. My Blog article is featured by @HPAllianceOne on Twitter.

Java Updates und der Java Installer

Aktuell geht es durch das soziale Dorf. Das Java Plug-In im Browser muss immer und immer wieder aktualisiert werden weil eine ganze Menge an wirklich kritischer Sicherheitsschwächen bekannt werden. Bei jeder dieser Update Installationen fragt die Oracle JVM ob sie nicht auch die Ask Toolbar installieren soll. Diese verunstaltet den Browser mit einer unbenutzbar schlechten Search Engine und ist auch ansonsten sehr auffällig. Aber schaut man sich den Java Installer genauer an, so ist es nicht das einzige Problem. Das Auto-Update lässt sich immer recht viel Zeit. Es hält "Recover" Kopien des kompletten Installers vor, es hat keine vernünftige Windows 7 Unterstützung (UAC Anforderung im Control Panel für Systemweite Einstellungen zum Auto Update funktionieren nicht). Außerdem ist eine Java Installation schnell mal kaputt, und der Installer bekommt es nicht immer hin die Registry aufzuräumen. Alles in allem ist man als Verwender von Applets oder WebStart (und JavaFX) sehr stark mit Support beschäftigt, weil sich immer mal wieder inkompatible Änderungen einschleichen. Ganz aktuell quäle ich mich z.B. mit Problemen beim Aufruf der JavaScript bridge auf Web Seiten herum. Aber auch die Dokumentation zum Deploy Toolkit, die Detection im Browser, ja selbst die Startup Zeiten sind immer noch (trotz neuem Plug-In und Java Kernel) verbesserungsfähig. Wenigstens gegen die Toolbar läuft jetzt eine change.org Petition: https://www.change.org/petitions/oracle-corporation-stop-bundling-ask-toolbar-with-the-java-installer Übrigens, kleiner Tipp. Wenn man die JRE (oder das JDK) nicht von java.com installiert, sondern den (Offline) Installer von den Oracle Seiten nimmt, so bekommt man die Frage nach der Ask-Toolbar nicht. Dürfte alle Firmen-Admins ohne Softwareverteilung freuen.

SSL Renegotiation DoS und Java JSSE SSLServerSocket

Öffentlich zugängliche SSL/TLS Dienste bilden das Rückgrat der Internet Anwendungen und haben zugleich das Problem, dass der initiale Handshake eine CPU intensive Crypto-Operation auf dem Server erfordert. Das ist deswegen problematisch, weil der Server erst nach dieser Operation feststellen kann ob der Client den Rechenaufwand ebenfalls eingegangen ist, oder einfach nur zufällige Daten beim Schlüsselaustausch geschickt hat. Dieses Ungleichgewicht kann ein Angreifer bei einem DoS (Deny of Service) Angriff ausnutzen und wiederholt (ggf. von verschiedenen bots) eine solche SSL Verbindung anfordern. Dadurch kann es dann zu Überlastungen der Server kommen, ohne dass der Angreifer viele Ressourcen investieren müsste. Diese Form des SSL DoS lässt sich aber zum Glück einfach erkennen und dank Rate Limits in Firewalls oder SSL Accelerators auch einfach abwehren. Etwas problematischer ist es da schon, dass auch in einer bestehenden TLS Verbindung die Gegenstelle eine neue Aushandlung der Schlüsseldaten anfordern kann. Dazu sind keine von der Firewall bemerkbaren neuen Verbindungen notwendig, und auch die Handshake Records die bei SSL ausgetauscht werden sind als solche nur mit anfälliger Heuristik zu erkennen. Wenn man das nun mit der Eigenheit von RSA kombiniert, dass das entschlüsseln auf der Serverseite mehr CPU Zeit beansprucht als die Verschlüsselunsoperation, so erhält man eine neue Klasse von Angriffen auf die die deutscheinternationale Security Research Gruppe THC 2011 aufmerksam gemacht hat. Und obwohl ein dDoS Angriff auf den initialen Handshake um ein vielfaches wirkungsvoller ist hat die Veröffentlichung des Tools einige Hersteller dazu bewegt etwas dagegen zu unternehmen (die meisten schalten die Renegotiation komplett ab). Hinweis: THC spricht von Faktor 15 mehr Rechenaufwand auf dem Server als auf dem Client, dem widersprechen allerdings die Zahlen von Vincent (s.u.). Jedenfalls ist es für einen öffentlich angebotenen SSL Server wichtig die Renegotiation Anfragen der Clients zu erkennen und zu limitieren. Neben den häufig verwendeten nativen Libraries wie puressl oder openssl gibt es auch noch weitere Implementierungen, z.B. den SSLServerSocket bei Java (im Falle der JVM von Oracle mit der ehemals von Sun stammenden JSSE Implementierung). Für diese bleiben aktuell zwei Strategien: a) HandshakeListener auf jedem SSLServerSocket registrieren: dieser wird bei jedem erfolgreichen Handshake aufgerufen, er kann also mitzählen und ggf. Gegenmaßnahmen einleiten. Das hat aber einen großen Nachteil: der Listener selbst wird Asynchron in einem neuen Thread aufgerufen. Und dies auch dann wenn die Funktion im Listener nicht mehr macht als einen Zähler hochzählen. Das starten des Threads ist im Vergleich dazu viel belastender für den Server. Es sollte also vermieden werden überhaupt einen Listener zu registrieren. b) Nach dem initialen Handshake die Liste der erlaubten Ciphers auf eine leere Liste setzen. Das führt dazu, dass alle weiteren Handshake Anfragen mit einem SSL Alert abgebrochen werden. Leider gilt das allerdings auch für Handshakes die vom Server angefordert werden (z.B. wenn Client Zertifikate angefordert werden sollen) oder auch bei sehr seltenem Schlüsselaustausch (bei lange bestehenden SSL Verbindungen sinnvoll). Ich würde mir deswegen wünschen Oracle bessert hier an zwei Stellen nach: zum einen sollte man bei SSLServersockets direkt die Renegotiation die von Clients angefordert wird mittels eines Flags ignorieren/ablehnen können. Zudem macht es Sinn wenn der SSLServerSocket diese automatisch in der Anzahl begrenzen. Zum anderen sollte es möglich sein auf die Erzeugung eines Threads pro Handshake Event zu verzichten, z.b. indem der Anwender einen eigenen Executor mitgeben kann (der einen Pool hat oder aber bei sehr leichtgewichtigen Listener einfach synchron ausführt). Übrigens bietet die JSSE2 Implementierung von IBM eine Systemproperty (com.ibm.jsse2.renegotiate=NONE) an, mit der man die Renegotiation ausschalten kann. Im Falle von Oracle kann nur die unsichere Renegotiation (ohne RFC5746) verboten werden. Das hilft aber nicht gegen den DOS Angriff. Zum Weiterlesen

HTTP Header und Browser Sicherheit

Web Anwendungen werden immer essentieller und es zeigen sich immer mehr Schwachstellen und Risiken. Als Web Application Entwickler kann man einige Technologien verwenden (die mehr oder weniger verbreitet sind) um das Risiko zu reduzieren. Hier möchte ich Funktionen sammeln die als "neue" HTTP Header bereitgestellt werden:

Content-Security-Policy: (CSP) Dieser HTML5 Header erlaubt es dem Web Server der eine HTML Seite ausliefert Beschränkungen für den html/javascript code zu definieren in Bezug auf Quellen für Code (und andere Ressourcen wie Fonts und Bilder). Sinnvoll ist dieses Verfahren insbesondere in Verbindung mit Web Seiten die keinen Inline JavaScript code enthalten (nur script tags) sowie auf eval in JavaScript verzichten. Eine gute Zusammenfassung findet sich auf html5rocks.com. Leider ist die Unterstützung in den Browsern noch eingeschränkt und die verschiedenen Engines benutzen noch nicht den offiziellen Header name. [W3C Working Draft Content Security Policy 1.0]

Strict-Transport-Security: (HSTS) Ein Problem mit https (SSL/TLS) ist, wenn es nicht oder falsch verwendet wird. Mit dem HSTS header wurde eine Möglichkeit geschaffen dass Web-Seiten dem Browser der User dazu zwingen können für bestimmte URLs nur die SSL Variante zuzulassen. Der Nutzen ist ein wenig umstritten, da es zum einen noch das Henne und Ei Problem gibt und zum Anderen der Header nicht vor man-in-the-middle (MITM) Angriffen oder Phisching Angriffen mittels alternativen URLs schützen kann. Es ist aber trotzdem eine gute Idee den Header einzusetzen, vor allem wenn die Browser Hersteller dann eigene Listen erstellen und diese fest mit der Software ausliefern (und damit das Henne und Ei Problem umgehen). Die OWASP Initiative hat weiterführende Informationen. [IETF WEBSEC Draft: HTTP Strict Transport Security]

Access-Control-Allow-Origin: (CORS) Die Access-Control-Allow Header sind genau genommen kein Mechanismus um die Möglichkeiten einer Web Seite zu beschränken, sondern um diese feingranular um Zugriffe auf fremde Server (die dem zustimmen) zu erweitern. Dies erlaubt unter anderem die Vermeidung des eher problematischen JSON-P Verfahrens (das auf JavaScript eval basiert). Eine gute Beschreibung wie das Verfahren eingesetzt werden kann findet sich bei html5rocks.com. [W3C Working Draft Cross Origin Resource Sharing]

Cache-Control: no-store Diese Einstellung bietet sich vor allem für dynamisch erstellte HTML Seiten an die sensible Daten enthaten die nicht permanent auf dem Client Rechner gespeichert werden sollen. Es sollte nicht für statische ressourcen (Bilder) gesetzt werden, da dies Geschwindigkeit der Web Anwendung durch ständiges neu-übertragen eben solcher verschlechtert. [W3C RFC2616 HTTP/1.1]

Cookies: HttpOnly secure Cookies werden in Web Anwendungen unter anderem dazu eingesetzt Einstellungen oder Details auf dem Client zu erinnern oder eine Session ID zu speichern. Damit sind Cookies eine Achillesferse jedes Authorisationssystems und bedürfen besonderem Schutz (vor Einsichtname oder Auslesen). Wenn ein Server ein Cookie mittels Header anlegt, so kann er diesen Attribute mitgeben die zum einen regeln wann das Cookie zurückgeschickt wird (secure = nur wenn https methode verwendet wird) und zum anderen ob das Cookie mittels JavaScript/DOM ausgelesen werden kann, oder einfach nur für alle weiteren Zugriffe bereitsteht. Web Anwendungen sollten zum Schutz der Session Information unbedingt dieses Verfahren erzwingen: session cookies mit HttpOnly Attribut. [IETF RFC6255 HTTP State Management Mechanism] X-Frame-Option: Erlaubt Web Seiten die nicht in Frames eingesperrt werden dürfen. Dies hat den Vorteil dass es Angreifern etwas schwerer gemacht wird eine Webseite anzuzeigen die normale Funktionalitäten bereitstellt, der Angreifer aber Clicks und Eingaben abfangen kann. Außerdem bietet es auch Schutz Trittbrettfahrern die Ihre eigenen Vorstellungen von Betrieb eines Services haben. (IE8 Security Blog: Clickjacking Defense) [Quelle?]

Server:/X-Powered-By:/Via: Um es (automatisierten) Angreifern nicht so einfach zu machen sollten Header die eine schnelle Identifikation (Fingerprinting) der eingesetzten Software Version erlauben entfernt (im Fall von X-Powered-By: was gerne von JSP compilern erstellt wird) werden. Der Punkt ist eher umstritten: es reduziert die Gefahr dass bekannte Lücken einfach ausprobiert werden nicht, dafür erschwert es den Administrator und Partnern die Überprüfung der Konfiguration. Da aber viele Assessment Tools das Vorhandensein der Header anmerken ist es für einen Softwareersteller ratsam diese Header (und Versionsstrings in Fehlerseiten) konfigurierbar zu machen. In dem zusammenhang ist die Empfehlung einen falschen Versionsstring zurückzuliefern sehr kritisch zu betrachten, lieber einen unkonkreten generischen Header. Z.b. gibt der Apache httpd nur "Server: Apache" aus, wenn "ServerTokens ProductOnly" gesetzt wird. [W3C RFC2616 HTTP/1.1] Übrigens haben all diese Mechanismen bekannte (und unbekannte) Bugs in verschiedenen Browser Versionen. Nicht alle Browser unterstützen die Header im gleichen Funktionsumfang oder nach der gleichen Methode. Es macht dennoch Sinn diese einzusetzen da die Sicherheit von Web Anwendungen für größere Benutzergruppen dennoch verbessert wird. Zudem achten viele (automatisierten) Audits auf das Vorhandensein, so lässt sich mit geringem Aufwand bei der Anwendungserstelllung eine bessere Compliance erreichen.

Update 2012-11-08: Server header hinzugefügt, IE8 Security Blog artikel verlinked der X-Frame-Option erklärt.

TODO 2012-11-23: Es gibt noch die /crossdomain.xml policy files die von Flash und wohl auch dem Java Plugin beachtet werden. Diese Technologie kennt den X-Permitted-Cross-Domain-Policies: header. Dieser fehlt im Artikel noch.

Update 2014-02-16: Google setzt den X-XSS-Protection:"1; mode=block" header, welcher vom IE8 verstanden wird.

Oracle Java SE (hotspot) GC Logfile rotation

Zufällig bin ich bei den Java Flags über die Option -XX:GCLogFileSize=x gestolpert. Da ich bei Oracle (im Gegensatz zur IBM JVM) einige Diagnosefunktionen, wie z.b. rollierende GC logfiles vermisste habe ich weiter gesucht, und den RFE 6941823 gefunden, der (für Java 7U2+) beschreibt, dass das Feature jetzt vorhanden ist, und (umständlich) mit 3 Optionen konfiguriert werden muss:
C:> java -XX:+PrintFlagsFinal -version | find "GCLog"
    uintx GCLogFileSize                              = 0               {product}
    uintx NumberOfGCLogFiles                         = 0               {product}
     bool UseGCLogFileRotation                       = false           {product}
java version "1.7.0_07"
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)
Ich würde das ganze immer zusammen mit der Details und Datestamp Option verwenden:
java  -Xloggc:log/app.vgc
      -XX:GCLogFileSize=10M -XX:NumberOfGCLogFiles=10 -XX:+UseGCLogFileRotation
      -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:-PrintGCTimeStamps
Bei IBM kann man das übrigens dank kompaktem Syntax und Variablenexpansion deutlich besser machen:
$ java -Xverbosegclog:app.%Y%m%d.%H%M%S.%pid.vgc,10,10000
Und dazu liefert IBM sogar noch ein Handbuch...

In-Memory Data Management (openHPI)

Hmm.. heute kommt ein SAP Newsletter mit einem Hinweis auf einen 6 wöchigen Online Kurs am HPI (im Rahmen der openHPI Initiative) über das In-Memory Data Management. Der Kurs hat zwar schon vor 2 Tagen angefangen, aber ich schreibe mich mal dennoch ein. Keine Ahnung warum der Newsletter so spät rausging. Aber einen Kurs mit Hasso himself kann man sich doch nicht entgehen lassen, oder? Das ganze ist natürlich nur eine 25h Aktion, aber vielleicht ja dennoch interessant, ich werde hier berichten.