Ruby / RoR

Syndicate content
Aktuelle Meldungen zum Thema Ruby und Ruby on Rails (RoR).
Updated: 20 hours 57 min ago

Mailinglisten vorübergehend abgeschaltet

Sa, 2014-05-31 12:30

Wir haben die auf ruby-lang.org gehosteten Mailinglisten vorübergehend abgeschaltet.

Unsere Mailinglisten wurden mit einer Spam-Bombe angegriffen. Wir haben daraufhin die folgenden Listen abgeschaltet:

  • ruby-core
  • ruby-talk
  • ruby-dev
  • ruby-list
  • ruby-cvs
  • ruby-doc
  • ruby-ext
  • ruby-fr
  • ruby-math

Es tut uns Leid, wenn der Ausfall Ihnen Probleme bereitet und arbeiten daran, die Listen so schnell wie möglich wieder zu reaktivieren.

Geschrieben von hsbt am 31.5.2014
Übersetzt von Quintus

Ruby 1.9.3-p547 veröffentlicht

Fr, 2014-05-16 14:59

Ruby 1.9.3-p547 wurde soeben veröffentlicht.

Ruby 1.9.3 befindet sich derzeit in der Security-Maintenance-Phase. Das bedeutet, dass wir nur beim Auftreten von Sicherheitslücken eine neue Version veröffentlichen. Mit einer Ausnahme: wie bereits angekündigt werden wir neue Versionen auch veröffentlichen, falls kritische Regressionen gefunden werden.

Einige Nutzer berichteten von Problemen in Umgebungen, die eine alte Version von OpenSSL verwenden, wie zum Beispiel Ubuntu 10.04 LTS. Diese Regression wurde mit Ruby 1.9.3-p545 eingeführt. (Das selbe Problem trat auch in Ruby 2.1.1 und Ruby 2.0.0-p451 auf und wurde bereits korrigiert mit Ruby 2.1.2 und Ruby 2.0.0-p481.) Siehe Bug #9592 für weitere Informationen.

Daher haben wir uns zur Veröffentlichung dieser Version entschieden. Sie sollten nur auf die neue Version umstellen, wenn Sie von diesem Problem betroffen sind.

Diese Version beinhaltet nur zwei Änderungen:

  • einen Bugfix für eine alte OpenSSL-Version,
  • eine kleine Änderung in common.mk für unsere Release-Verwaltung (betrifft Nutzer nicht).
Download Veröffentlichungskommentar

Vielen Dank für alle Fehlermeldungen.

Geschrieben von usa am 16.5.2014
Übersetzt von Marcus Stollsteimer

Ruby 2.1.2 veröffentlicht

Fr, 2014-05-09 12:00

Wir freuen uns die Veröffentlichung von Ruby 2.1.2 bekannt geben zu können.

Diese Veröffentlichung enthält die Korrektur einer Regression in Hash#reject in Ruby 2.1.1, Unterstützung für Build mit Readline-6.3 (siehe Bug #9578), eine Aktualisierung der von psych mitgelieferten Version von libyaml und weitere Fehlerkorrekturen.

Siehe die Tickets und das ChangeLog für weitere Informationen.

Download Release Comment

Viele Committer, Entwickler und Nutzer, die Fehlermeldungen eingereicht haben, halfen mir bei diesem Release. Vielen Dank für ihren Beitrag.

Geschrieben von nagachika am 9.5.2014
Übersetzt von Marcus Stollsteimer

Anfechtung der Sicherheitslücke CVE-2014-2734

Fr, 2014-05-09 05:33

Wir sind vor kurzem über eine Sicherheitslücke informiert worden, die als CVE-2014-2734 veröffentlicht wurde. Aufgrund unserer unten dargelegten detaillierten Analyse glauben wir jedoch nicht, dass Ruby verwundbar ist.

Diese Sicherheitslücke kann es einem Angreifer ermöglichen, beliebige Wurzelzertifikate zu fälschen, wobei er effektiv den privaten Schlüssel des Originalzertifikats durch seinen eigenen ersetzt.

Proof of Concept

Folgend finden Sie unsere Analyse von CVE-2014-2734; wir konnten den ursprünglichen Nachweis auf diesen unserer Meinung nach den Kern des Problems beschreibenden Code reduzieren:

require 'openssl' forge_key = OpenSSL::PKey::RSA.new(2048) raw_certificate = File.read("arbitrary.cer") cert = OpenSSL::X509::Certificate.new(raw_certificate) resigned_cert = cert.sign(spoof, OpenSSL::Digest::SHA1.new) resigned_cert.verify(key) #=> true

Es mag überraschend erscheinen, dass X590Certificate#verify den Wert true zurückgibt. Das Originalzertifikat kann eine Subject Public Key Info enthalten, die auf den ursprünglichen öffentlichen Schlüssel verweist, der sich von forge_key unterscheidet. Augenscheinlich handelt es sich bei dem Schlüsselpaar, mit dem das Zertifikat neu signiert wurde, nicht mehr um das in der Subject Public Key Info referenzierte Schlüsselpaar. Weshalb also ergibt #verify den Wert true?

Wie Schlüssel verifiziert werden

X509Certificate#verify bedient sich OpenSSLs X509_verify-Funktion, welche wiederum an ASN1_item_verify delegiert. Diese beiden Funktionen stellen die Gültigkeit der Signatur anhand des angegebenen öffentlichen Schlüssels sicher. Sie verifizieren jedoch nicht, ob der angegebene Schlüssel mit demjenigen, der im Zertifikat referenziert wird, übereinstimmt. Daraus folgt, dass die Rückgabe von true in diesem Szenario das für X590Certificate#verify erwartete Verhalten ist. Das Auslassen dieser Prüfung hat keine wesentlichen Auswirkungen auf die Gesamtsicherheit des X.590-Vertrauensmodells.

Abschnitt 4.1.1.3 von RFC 5280 stellt ausdrücklich fest, dass die CA bei der Berechnung einer Zertifikatssignatur die Richtigkeit der im Zertifikat enthaltenen Informationen zu bestätigen hat. Zwar wird dieses Prinzip durch den obigen Beispielcode verletzt, jedoch stellt dies keine Bedrohung der Sicherheit da. Ein in dieser Weise gefälschtes oder verändertes Zertifikat kann nicht benutzt werden, solange niemand Sie dazu bringt, einem dieses Prinzip verletzenden Zertifikat zu vertrauen.

Potenzielle Risiken

Es gibt zwei Fälle zu beachten:

Neusignierung eines Wurzelzertifikats

Als Nutzer vertrauen wir den Wurzelzertifikaten uneingeschränkt. Selbst dann, wenn sie keine gültigen Informationen enthalten, hat dies auf ihren Status als öffentlich beglaubigtes Wurzelzertifikat keinerlei Einfluss. Es handelt sich um vorkonfigurierte Werte in den Vertrauensdatenbanken unserer Browser und Betriebssysteme, durch ihre bloße Verarbeitung kommt ihr Status als gültiger Vertrauensanker zustande. Beispielsweise überprüft nicht einmal OpenSSL selbst standardmäßig die Signatur eines selbstsignierten Wurzelzertifikats aus denselben Gründen, vgl. die Dokumentation zu X509_V_FLAG_CHECK_SS_SIGNATURE.

Ein neu signiertes Wurzelzertifikat wird zu einem de facto selbstsignierten Zertifikat (wenn auch mit falscher Subject Public Key Info). Dies ist nicht gefährlicher als ein gewöhnliches selbstsigniertes Wurzelzertifikat. Tatsächlich ist es jedermann möglich, ein selbstsigniertes Wurzelzertifikat zu erstellen, das mit einem gültigen Wurzelzertifikat vollständig übereinstimmt — außer in der Signatur. Da wir Wurzelzertifikaten bereits durch Besitz vertrauen, ist ein derartig verändertes Zertifikat ohne die explizite Zustimmung des Clients zum Vertrauen bedeutungslos.

Neusignierung eines Zwischen- oder Blattzertifikats

Auch die Neusignierung eines Nicht-Wurzel-Zertifikats verletzt nicht das X.590-Vertrauensmodell. Zwar besitzen wir diese Zertifikate üblicherweise nicht im Voraus, jedoch würde deren Fälschung beim Pfadvalidierungsprozess auffallen. Hierbei wird die Signatur jedes Nicht-Wurzel-Zertifikats anhand des öffentlichen Schlüssels des beglaubigenden Zertifikats überprüft; an irgendeinem Punkt der Zertifikatskette würde eine Fälschung zwingend in der Form einer ungültigen Zertifikatssignatur auftreten.

Zusammenfassung

Unterm Strich glauben wir, dass sich X509Certificate#verify so verhält wie erwartet. Unabhängig davon sind andere bereits zum selben Ergebnis gekommen, weshalb wir CVE-2014-2734 angefochten und seinen Widerruf beantragt haben. Sie können die vollständige Analyse und das ursprüngliche Proof of Concept samt Kommentaren ebenfalls einsehen.

Geschrieben von emboss am 9.5.2014
Übersetzt von Quintus

Ruby 2.0.0-p481 veröffentlicht

Fr, 2014-05-09 03:00

Wir freuen uns, die Veröffentlichung von Ruby 2.0.0-p481 ankündigen zu können.

Dieses Release enthält zahlreiche Fehlerkorrekturen, unter anderem:

Siehe die Tickets und das ChangeLog für weitere Informationen.

Download Veröffentlichungskommentar

Ich bin allen Leuten, die Ruby unterstützen, dankbar. Vielen Dank.

Geschrieben von usa am 9.5.2014
Übersetzt von Quintus

Schwere Sicherheitslücke in TLS-Heartbeat-Erweiterung von OpenSSL (CVE-2014-0160)

Do, 2014-04-10 01:04

In der OpenSSL-Implementation der Heartbeat-Erweiterung (RFC6520) von TLS/DTLS (Protokolle zum Verschlüsseln der Transportschicht) wurde eine kritische Sicherheitslücke entdeckt. Es handelt sich hierbei um ein schwerwiegendes Sicherheitsproblem, dem die CVE-Kennung CVE-2014-0160 zugewiesen wurde.

Seine Ausnutzung kann das Auslesen des Serverspeichers durch den Client und umgekehrt ermöglichen; ein Angreifer kann auf diese Weise sensible Daten wie beispielsweise — aber nicht nur — die für die SSL-Verschlüsselung genutzen geheimen Schlüssel und Authentifizierungs-Tokens erhalten.

Weitere Informationen zu den Angriffen finden Sie auf heartbleed.com.

In wiefern ist Ruby betroffen?

Ruby ist dann betroffen, wenn es über die OpenSSL-C-Extension in der Standard Library statisch gegen eine verwundbare Version von OpenSSL gelinkt wurde.

Von diesem Angriff betroffen sind die OpenSSL-Versionen 1.0.1 bis 1.0.1f (eingeschlossen). Sie können wie folgt herausfinden, mit welcher Version der OpenSSL-Bibliothek Ruby gelinkt wurde:

ruby -v -ropenssl -rfiddle -e 'puts Fiddle::Function.new(Fiddle.dlopen(nil)["SSLeay_version"], [Fiddle::TYPE_INT], Fiddle::TYPE_VOIDP).call(0)'

Um herauszufinden, welche Version von OpenSSL momentan mit Ruby installiert ist, gehen Sie so vor:

ruby -ropenssl -e 'puts OpenSSL::OPENSSL_VERSION'

Mit emboss’ Skript können Sie überprüfen, ob Ihre Client-Software oder ein Service verwundbar ist.

Lösungen

Zur Aktualisierung auf OpenSSL Version 1.0.1g oder jünger sollten Sie den Paketmanager Ihres Betriebssystems darauf hin überprüfen, ob ein aktuelles OpenSSL angeboten wird. Möglicherweise müssen Sie, um die Frage zu beantworten, ob die angebotene Version von OpenSSL unabhängig von der verfügbaren Versionsnummer gepatched wurde, Ihren Betriebssystem-Distributor kontaktieren.

Wenn eine Aktualisierung keine Möglichkeit darstellt, kompilieren Sie ein korrigiertes OpenSSL mit der Option -DOPENSSL_NO_HEARTBEATS.

Bei einem aktualisierten OpenSSL wird empfohlen, Ruby neu zu kompilieren um sicherzustellen, dass keine Links zu einer verwundbaren OpenSSL-Version mehr zurückbleiben.

Das bedeutet auch, dass alle Werkzeuge, mit denen Ruby gebaut werden kann, also etwa RVM oder ruby-build, ebenfalls aktualisiert werden müssen. Wenn Sie Ruby selbst kompilieren, benutzen Sie die --with-openssl-dir-Option, um gegen das aktualisierte OpenSSL-Installationsverzeichnis zu linken.

$ ./configure --with-openssl-dir=/path/to/openssl $ make $ make install

Nachdem Sie OpenSSL und Ruby aktualisiert haben, ist es erforderlich, alle Programme, die noch die verwundbare Version benutzen, neu zu starten.

Zahlreiche Betriebssystemdistributionen bieten bereits korrigierte Versionen und neu gebaute Pakete für die von diesem Angriff betroffenen Bibliotheken an (oder werden es in naher Zukunft tun). Es ist daher für die Aufrechterhaltung Ihrer Sicherheit unerlässlich, Ihren Betriebssystem-Distributor im Auge zu behalten.

Geschrieben von hone and zzak am 10.4.2014
Übersetzt von Quintus