Vor einiger Zeit habe ich berichtet, dass unsere Webhosting-Kunden bei ihrem Webspace zwischen PHP 5.3 und 4.3 wählen können. Aufgrund des unglücklichen Umstandes, dass beispielsweise einige Content Management Systeme (CMS) wie TYPO3 4.2.x, Drupal 6.x und Joomla 1.5.x diverse und teilweise massive Probleme bzw. Schwierigkeiten mit der aktuellen PHP-Version 5.3 haben und leider keine schnelle Lösung von Seiten der Software-Entwickler in Sicht ist, steht unseren Kunden absofort auch das etwas ältere PHP 5.2 zur Verfügung.

Grund für die Probleme mit PHP 5.3 ist in den allermeisten Fällen das unsaubere Programmieren bzw. die Verwendung seit Jahren veralteter PHP-Funktionen im Quelltext der Webapplikation bei den jeweiligen Software-Projekten. Ein typisches Beispiel hierfür ist die Verwendung der PHP-Funktion eregi(), die schon seit Jahren besser nicht genutzt werden sollte, da sie als nicht “binary safe” bekannt ist.

Als Webhosting-Kunde können Sie selbst zwischen den bei uns verfügbaren PHP-Versionen wählen – wie dies funktioniert, ist in unserem Service-Bereich beschrieben. Sofern Ihre Webapplikation es zulässt, empfehlen wir immer den Einsatz der PHP-Version 5.3, da diese deutlich performanter und damit auch von uns als Standard für Ihren Webspace aktiviert ist.

Wenn Sie selbst Systeme mit Red Hat Enterprise Linux 5 (RHEL 5) bzw. einem Derivat wie CentOS 5 betreiben und PHP 5.3, das etwas ältere PHP 5.2 oder das noch ältere PHP 4.3 benötigen, so können Sie dafür die von uns gepflegten RPM-Pakete aus unserem ETES-Repository verwenden. Bitte beachten Sie, dass diese RPM-Pakete in einem separaten Zweig liegen und daher mittels der Direktive “etes-extras” in der Yum-Konfiguration explizit aktiviert werden müssen. Und vergessen Sie nicht zu bedenken, dass Sie an dieser Stelle absofort keine anderen binären RPM-Pakete für PHP z.B. aus EPEL oder CentOS Extras verwenden sollten, da PHP 5.1, 5.2 und 5.3 jeweils zueinander ABI-inkompatibel (d.h. nicht binärkompatibel) sind!

Nachdem vor etwa zwei Wochen die stabile Version 5.3 von PHP freigegeben worden ist, freuen wir uns, unseren Kunden auch diese neueste PHP-Version auf unserem Webhosting-Server zur Verfügung stellen zu können.

Über die Neuerungen und Verbesserungen in PHP 5.3 gibt es beispielsweise bei Heise weitere Informationen in deutscher Sprache, englischsprachige Details erhalten Sie natürlich auch direkt bei der PHP Group.

Sofern es eine Webapplikation zwingend erfordert, steht bis maximal Anfang 2012 zudem noch das ältere PHP 4.3 mit Sicherheitsupdates und Backports zur Verfügung. Beide PHP-Versionen können parallel genutzt werden, bei Fragen dazu wenden Sie sich bitte an unseren Webhosting-Support.

Wenn Sie selbst Systeme mit Red Hat Enterprise Linux 5 (RHEL 5) bzw. einem Derivat wie CentOS 5 betreiben und PHP 5.3 bzw. das ältere PHP 4.3 benötigen, so können Sie dafür die von uns gepflegten RPM-Pakete aus unserem ETES-Repository verwenden. Bitte beachten Sie, dass diese RPM-Pakete in einem separaten Zweig liegen und daher mittels der Direktive “etes-extras” in der Yum-Konfiguration explizit aktiviert werden müssen. Und vergessen Sie nicht zu bedenken, dass Sie an dieser Stelle absofort keine anderen binären RPM-Pakete für PHP z.B. aus EPEL oder CentOS Extras verwenden sollten, da PHP 5.1 und PHP 5.3 zueinander ABI-inkompatibel (d.h. nicht binärkompatibel) sind!

Seit einigen Tagen kursieren Gerüchte über eine mögliche Sicherheitslücke in OpenSSH in Red Hat Enterprise Linux (RHEL) und Derivaten wie CentOS. Für den Unternehmenseinsatz optimierte Linux-Distributionen halten üblicherweise an einer Software-Version fest und die Entwickler der Distribution portieren Fehlerkorrekturen und Sicherheitsaktualisierungen auf genau diese Version zurück; im Falle dieser angeblichen Sicherheitslücke müsste es sich um eine nicht korrigierte Schwachstelle in OpenSSH 4.3 handeln.

Das vermeintliche Protokoll des Angriffs zeigt einen SSH-Login auf ein aktuelles Red Hat Enterprise Linux 5.3-System über den standardmäßig von SSH verwendeten Port 22.

Auf Anfrage eines Mitarbeiters von Red Hat hat sich der OpenSSH-Entwickler Damien Miller auf der OpenSSH-Mailingliste dazu geäußert, jedoch liegen ihm keine geheimen Informationen vor, noch sieht er genügend Beweise für die Existenz einer solchen Sicherheitslücke, vielmehr geht er von einer simplen Brute-Force-Attacke aus. Auch das SANS-Institut sieht ebenfalls noch keinen Beweis für den angeblichen Zero-Day-Exploit, obwohl mittlerweile Hinweise über die Existenz der unbekannten Sicherheitslücke eingegangen sind. Ein weiterer kürzlich von SANS veröffentlichter Artikel lässt jedoch vermuten, dass es sich doch um eine simple Brute-Force-Attacke statt um eine Sicherheitslücke in OpenSSH handeln dürfte.

Als Mitwirkender beim Fedora Project habe ich mit Leuten des Fedora Sicherheitsteams gesprochen, die gleichzeitig im Red Hat Security Response Team arbeiten: Bislang wurden Red Hat keinerlei Einbrüche über eine OpenSSH-Sicherheitslücke auf Kunden-Systeme mit Red Hat Enterprise Linux gemeldet. Der Support von Red Hat steht auch im Kontakt mit den Kunden, um bei Bedarf proaktiv helfen und unterstützen zu können. Zudem konnte Red Hat bei den bislang von Kunden gemeldeten Verdachtsfällen keinen Hinweis für eine OpenSSH-Sicherheitslücke entdecken.

Zusätzlich hat sich ein Team bei Red Hat mit den Unterschieden zwischen OpenSSH 4.3 und der aktuellen Version 5.2 beschäftigt und konnte bei einer Quellcode-Analyse der beiden Versionen keine neuen bzw. korrigierten Sicherheitslücken finden.

Weiter verweist das Red Hat Security Response Team darauf, dass es vermutlich lediglich einen einzigen bekannten Angriff auf eine Webhosting-Firma gab und keine Angriffe auf größere bzw. interessantere Ziele, wie Banken oder Firmen, bei denen geheime Informationen erlangt und verwendet werden könnten. Wäre soetwas der Fall gewesen, hätte Red Hat darüber bereits Kenntnis erlangt und Administratoren würden diese Probleme auf Security-Mailinglisten wie Vendor-Sec oder bei diversen CERTs melden und beschreiben.

Scheinbar plant Red Hat in der nächsten Zeit eine offizielle Stellungnahme zu abzugeben, da trotz diverser investierter Ressourcen und Zeit keinerlei Anhaltspunkte für eine OpenSSH-Sicherheitslücke entdeckt werden konnten. Sollten widererwartend doch mehr Informationen und vor allem technische Details bekannt werden, wird Red Hat entsprechend reagieren. Laut Hinweisen die das SANS-Institut erhalten hat, sollen die Details zur Lücke auf der Ende Juli in Las Vegas stattfindenden Black-Hat-Sicherheitskonferenz öffentlich gemacht werden…

Edit am 1.6.2010: Toter Link zum Protokoll gelöscht.

Für die Suchmaschinen-Funktionalität des Contao Open Source CMS (vormals TYPOlight) wird die Unicode-Unterstützung der PCRE-Erweiterung in PHP benötigt. Ist diese Unicode-Unterstützung nicht gegeben, so schlägt eine Suche anschließend mit

Compilation failed: support for \P, \p, and \X has not been compiled

fehl. Bei Red Hat Enterprise Linux 5 und damit bei CentOS 5 ist diese Option standardmäßig nicht aktiviert, da der Einsatz erst in späteren Versionen von PCRE durch die Entwickler empfohlen worden ist. Man kann dieses Problem lösen, indem man PCRE beim Kompilieren um das Parameter --enable-unicode-properties erweitert, sofern PHP dynamisch gegen die PCRE-Bibliothek gelinkt ist (was bei RHEL 5 und CentOS 5 der Fall ist).

Da PCRE gelegentlich Sicherheitslücken aufweist, sollte man die Bibliothek jedoch nicht von Hand kompilieren, da sonst mögliche Sicherheitsupdates von Red Hat dies überschreiben bzw. je nach Pfad bleiben später eventuell die Sicherheitslücken von PCRE aus der eigenen Übersetzung der Bibliothek vorhanden und machen das System leicht verwundbar. Der richtige Weg ist es daher, das RPM-Paket mit der richtigen Option selbst neu zu bauen und auch selbst zu pflegen.

Um dies zu vereinfachen, haben wir unser ETES-Repository mit einem angepassten RPM-Paket der PCRE-Bibliothek erweitert; dort wurde der Parameter --enable-unicode-properties beim Kompilieren verwendet. Diese Aktualisierung ist in unserem ETES-Repository für die für den Unternehmenseinsatz optimierte Linux-Distribution Red Hat Enterprise Linux bzw. CentOS in Version 5 verfügbar.

Aktiviert wird das ETES-Repository durch die Installation des RPM-Pakets etes-release (rpm -Uvh etes-release-version.arch.rpm), welches sich im entsprechenden Unterverzeichnis, also z.B. /centos/5/i386/ für CentOS 5 mit 32 Bit oder /centos/5/x86_64/ für CentOS 5 mit 64 Bit, der oben angegebenen Adresse findet. Da sich die Paketnamen ändern können, ist hier bewusst keine direkte URL zu den RPM-Paketen verlinkt. Ist das ETES-Repository aktiviert, funktioniert die Aktualisierung wie folgt:

• yum update pcre
• service httpd restart

Der Neustart des Apache Webservers wird benötigt, damit die PHP-Umgebung mit den zugehörigen Bibliotheken neu in den Speicher geladen wird. Anschließend kann die Suchmaschinen-Funktionalität von Contao (vormals TYPOlight) ohne Fehlermeldungen verwendet werden.

Red Hat behandelt dieses Problem aktuell im Bugreport 457064 und schätzt, dass dieses Problem möglicherweise für Red Hat Enterprise Linux 5.4 (und damit auch CentOS 5.4) beseitigt werden kann…

Das von uns eingesetzte Warenwirtschaftssystem ESS (Enterprise Solution Server) der Firma Pentaprise bringt über die verschiedenen Software-Generationen und Versionen unterschiedliche Abhängigkeiten zu weiteren Software-Paketen mit, die bislang manuell von Hand nachinstalliert werden mussten.

Um dies zu vereinfachen, haben wir unser ETES-Repository mit zusätzlichen RPM-Paketen für das ESS erweitert. Diese enthalten jedoch nicht das gesamte ESS, lediglich die Abhängigkeiten zu Software-Paketen, die die jeweilige Generation des ESS benötigt. Aktuell gibt es Pakete für ESS 6.0.0.x, 6.0.2.x, 6.0.4.x und 6.0.6.x. Unser ETES-Repository gibt es zur Zeit für die für den Unternehmenseinsatz optimierte Linux-Distribution Red Hat Enterprise Linux bzw. CentOS in Version 4 und 5, sowie für den Vorreiter in Sachen Open Source Software, nämlich Fedora in Version 8, 9 und 10.

Aktiviert wird das ETES-Repository durch die Installation des RPM-Pakets etes-release (rpm -Uvh etes-release-version.arch.rpm), welches sich im entsprechenden Unterverzeichnis der oben angegebenen Adresse findet. Da sich die Paketnamen ändern können, ist hier bewusst keine direkte URL zu den RPM-Paketen verlinkt. Anschließend funktioniert die Installation wie folgt:

• ESS 6.0.6.x: yum install ess-606x
• ESS 6.0.4.x: yum install ess-604x
• ESS 6.0.2.x: yum install ess-602x
• ESS 6.0.0.x: yum install ess-600x

Kurze Zeit später fragt yum nach, ob die benötigten RPM-Pakete wirklich installiert werden sollen. Dies muss natürlich bestätigt werden und eine danach gestartete Installation des ESS funktioniert ohne die händische Nachinstallation weiterer Software-Pakete!