VeraCrypt 1.18 mit kritischen Sicherheitslücken

Wie heute bekannt wurde, ist VeraCrypt auditiert worden und dabei sind mehrere kritische Sicherheitslücken aufgedeckt worden.

Aufgrund der Schwere der Sicherheitslücken ist ein sofortiges Update auf VeraCrypt 1.19 erfolderlich.

Ob die schweren Lücken für Linux, Windows oder MacOs gelten, ging aus der Nachricht bei  den Hackernews nicht hervor.

Wer sich die Lücken genau ansehen will, dann das HIER tun. Hier das Bestof :

High: AES implementation susceptible to cache-timing attacks
High: Out-of-date inflate and deflate
High: XZip and XUnzip need to be completely re-written
High: Integer overflow when computing the number of iterations for PBKDF2 when PIM is used
High: GOST 28147-89 Must Be Removed from VeraCrypt

UEFI:
High: Keystrokes are not erased after authentication
High: Sensitive data is not correctly erased
High: Memory corruption can occur when the recovery disk is read

Meiner bescheidenen Meinung nach, ist die Datenträgerverschlüsselung trotz der Bugs sicher. Alle Angriffe beziehen sich nur auf den direkten aktiven Betrieb von VeraCrypt.

Die neue Version von VeraCrypt gibt es hier:  https://veracrypt.codeplex.com/

Dürfen IP Adressen gespeichert werden?

Liebe Mitblogger,

der EuGH hat in einer Anfrage zur Speicherung von IP-Adressen durch Webserver vom BGH entschieden, daß das TMG(Telemediengesetz) gegen europäisches Recht verstößt, weil es (stark vereinfacht) keine Abwägung zwischen berechtigten Interessen des Betreibers und den Rechten der Person an Ihren Daten enthält.

Damit ist das generelle Verbot der Speicherung von IP Adressen nicht länger rechtens, aber noch nicht vom Tisch. Der BGH muß diese Entscheidung des EuGH in seiner anstehenden Entscheidung berücksichtigen. Erst wenn der BGH entschieden hat und das Urteil rechtskräftig ist, steht es final fest. Wer jetzt in vorauseillendem Gehorsam die Logfiles wieder aktiviert, könnte noch gegen geltendes Recht verstoßen.

Damit Euch das nicht passiert, hier Euer Schlupfloch:

am 31.01.2013 hat das Landgericht Berlin verkündet:

„Die Beklagte wird verurteilt, es zu unterlassen, die Internetprotokolladresse (IP-Adresse)
des zugreifenden Hostsystems des Klägers, die im Zusammenhang mit der Nutzung
öffentlich zugänglicher Telemedien der Beklagten im Internet – mit Ausnahme des
Internetportals “http://www.XXXXXXXXXXXX.de” – übertragen wird, in Verbindung mit dem Zeitpunkt
des jeweiligen Nutzungsvorganges über das Ende des jeweiligen Nutzungsvorganges
hinaus zu speichern oder durch Dritte speichern zu lassen,
– sofern der Kläger während eines Nutzungsvorganges selbst seine Personalien, auch in
Form einer die Personalien des Klägers ausweisenden E-Mail-Anschrift, angibt und
soweit die Speicherung nicht im Störungsfall zur Wiederherstellung der Verfügbarkeit des
Telemediums erforderlich ist.“

Zitat aus: LG Berlin 57 S 87/08  – 2 C 6/08 Amtsgericht Mitte / Tiergarten

Das meint, daß wenn Ihr Schutzmaßnahmen implemtiert haben müßt, um den Webserver vor Angreifern zu schützen,
und das sollte jeder WordPressbenutzer machen, wenn er einen reibungslosen Betrieb gewährleisten will, die Speicherung über den Zeitpunkt der Benutzung hinaus erlaubt ist.

Zu beachten ist, daß dieser Zeitraum nicht unendlich ist und konkret beziffert werden muß. Außerdem seid Ihr auch dafür verantwortlich, wielange der Hoster die Daten speichert. Fragt daher bei Eurem Hoster an, wie lange die Webserverlogs gespeichert bleiben und was der Hoster als Schutzmaßnahme für den Webserver betreibt.

WordPress ist täglich Ziel von vielfältigen Angriffen

wp-login.php per Bruteforceattacke,
auf die xmlrpc.php um Forenspam zu senden
Exploits von Themes und Plugins.

Um diese Angriffe abzuwehren, müssen zwangsweise IP’s gespeichert werden um automatisch zu überprüfen, ob ein BruteForceangriff vorliegt und um konkrete Gegenmaßnahmen, in Form von IP-Sperren, einzuleiten.

Aus der Praxis als Webhoster einiger bekannter WP-Blogs, kann ich Euch versichern, daß einige Angreifer mehr als 500.000 mal am Tag auf ein Blog zugreifen um es zu stören, zu hacken, oder zu missbrauchen. Ohne Serversicherungsmaßnahmen incl. IP Speicherung könnten wir diese Angriffe nicht abwehren.

Darüberhinaus könnte eine Änderung der Speicherpraxis auch damit begründet werden, daß ein Webservicebetreiber mit den IPs nicht direkt einen Besucher namentlich identifizieren kann. Der EuGH sieht zwar den Rechtsweg in Form einer Strafanzeige als möglichen Weg, um an die Personendaten zu gelangen, aber meiner Meinung nach ( die dafür nicht zählt ), ist das für Webseitenbetreiber ohne Juraabteilung nur in echten Strafverfahren möglich, was bedeutet, es gibt einen konkreten Grund, welchen Kriminalbeamte, Staatsanwälte und Richter vorher prüfen. (Arbeitsüberlastungen von kölner Gerichten sei mal nicht das Thema.) Es ist daher eher unrealistisch dies als gangbaren Weg anzuerkennen, zumal das BDSG auch zum Zwecke der Strafverfolgung eine Ausnahme erlaubt. Demnach dürfen auch Daten, die dem Datenschutz unterliegen, den Strafverfolgungsbehörden übermittelt werden. (Damit man das kann, müßte man sie vorher speichern.)

Fazit

Das Urteil des BGH in der Sache steht noch aus, aber es gibt jetzt schon Ausnahmen, die eine Speicherung der IP’s erlauben.
Es dürfte eine Wende in der Rechtssprechung in Deutschland geben.

Die Pressemitteilung des EuGH zu dem anstehenden Urteil könnt Ihr hier selbst lesen:

http://curia.europa.eu/jcms/upload/docs/application/pdf/2016-10/cp160112de.pdf

Alte Entscheidungen:

Landgericht Berlin 2013: http://www.jurpc.de/jurpc/show?id=20130179

ups … DNF deinstalliert und nu ?

Da will man ein harmloses Update einspielen und angeblich stört so eine Lib dabei. Naja, nichts besonders. Kommt öfters vor. Man deinstalliert das fragliche Programm und installiert es wieder: fertig.  Soweit in der Theorie.

„Götter irren sich nie – Root schon!“

Der Befehl : „dnf update –allowerasing“ sollte das eigentlich auch so gleich machen, wenn man Abhängigkeitsprobleme hat.
Vielleicht hätte er das auch, wenn man stattdessen nicht versucht hätte das Paket direkt zu löschen ( dnf erase packagename ). Den dabei unterlief mir ein Fehler bei der Blindbenutzung der Bash :

dnf erase dnf update –allowerasing

Und natürlich blind auf Ja gedrückt 🙂 Schon war DNF , YUM, YUMEX und ABRT verschwunden 🙁 Jetzt versucht mal ohne Paketmanager den Paketmanager DNF zu reinstallieren. Die Lösung ist natürlich relativ einfach: RPM direkt benutzen.

Jetzt ist natürlich nur die Frage: Woher nehmen ?

Die Frage hatte ich zum Glück schon mal in einem anderen Zusammenhang gestellt : Koji

Beispiel für HTTPD: http://koji.fedoraproject.org/koji/packageinfo?packageID=280

Koji ist eine Webseite des Fedoraprojekts, auf dem alle Builds für alle Fedoraversionen verfügbar sind. Dort können alte wie Betaversionen und natürlich die aktuellen Pakete gefunden werden. Einfach Downloaden und mit rpm installieren.

Wenn man die RPMS alle in einem Verzeichnis hat ist das ganz einfach: rpm -i *rpm

Sind alle Pakete mit Abhängigkeiten vorhanden, ist das Malheur in Minuten beseitigt. Allerdings muß man ganz schön viele Pakete runterladen, deswegen zuerst nur DNF und seine Abhängigkeiten installieren, dann per DNF alles, was bei dem Erase mit eliminiert wurde.

Wer eine Liste braucht :  grep Erased /var/log/dnf.rpm.log

Oct 18 00:37:20 INFO Erased: abrt-desktop-2.8.0-5.fc23.x86_64
Oct 18 00:37:20 INFO Erased: abrt-cli-2.8.0-5.fc23.x86_64
Oct 18 00:37:20 INFO Erased: abrt-addon-vmcore-2.8.0-5.fc23.x86_64
Oct 18 00:37:21 INFO Erased: anaconda-23.19.10-1.fc23.x86_64
Oct 18 00:37:21 INFO Erased: abrt-addon-python3-2.8.0-5.fc23.x86_64
Oct 18 00:37:21 INFO Erased: initial-setup-gui-0.3.37-1.fc23.x86_64
Oct 18 00:37:21 INFO Erased: anaconda-gui-23.19.10-1.fc23.x86_64
Oct 18 00:37:21 INFO Erased: initial-setup-0.3.37-1.fc23.x86_64
Oct 18 00:37:21 INFO Erased: abrt-addon-python-2.8.0-5.fc23.x86_64
Oct 18 00:37:21 INFO Erased: anaconda-core-23.19.10-1.fc23.x86_64
Oct 18 00:37:21 INFO Erased: anaconda-tui-23.19.10-1.fc23.x86_64
Oct 18 00:37:21 INFO Erased: python3-meh-gui-0.43-1.fc23.noarch
Oct 18 00:37:21 INFO Erased: python3-meh-0.43-1.fc23.noarch
Oct 18 00:37:21 INFO Erased: yumex-3.0.17-2.fc23.noarch
Oct 18 00:37:22 INFO Erased: yum-utils-1.1.31-508.fc23.noarch
Oct 18 00:37:22 INFO Erased: yum-langpacks-0.4.5-2.fc23.noarch
Oct 18 00:37:22 INFO Erased: python-meh-gui-0.43-1.fc23.noarch
Oct 18 00:37:22 INFO Erased: python-meh-0.43-1.fc23.noarch
Oct 18 00:37:22 INFO Erased: dnf-plugin-system-upgrade-0.7.1-1.fc23.noarch
Oct 18 00:37:22 INFO Erased: createrepo-0.10.3-3.fc21.noarch
Oct 18 00:37:22 INFO Erased: anaconda-yum-plugins-1:1.0-10.fc20.noarch
Oct 18 00:37:22 INFO Erased: abrt-python-2.8.0-5.fc23.x86_64
Oct 18 00:37:22 INFO Erased: abrt-addon-ccpp-2.8.0-5.fc23.x86_64
Oct 18 00:37:22 INFO Erased: abrt-gui-2.8.0-5.fc23.x86_64
Oct 18 00:37:23 INFO Erased: abrt-addon-pstoreoops-2.8.0-5.fc23.x86_64
Oct 18 00:37:23 INFO Erased: abrt-tui-2.8.0-5.fc23.x86_64
Oct 18 00:37:23 INFO Erased: yum-3.4.3-507.fc23.noarch
Oct 18 00:37:23 INFO Erased: dnf-yum-1.1.10-1.fc23.noarch
Oct 18 00:37:23 INFO Erased: abrt-addon-kerneloops-2.8.0-5.fc23.x86_64
Oct 18 00:37:23 INFO Erased: gnome-abrt-1.2.2-3.fc23.x86_64
Oct 18 00:37:23 INFO Erased: abrt-retrace-client-2.8.0-5.fc23.x86_64
Oct 18 00:37:23 INFO Erased: libreport-python-2.6.4-2.fc23.x86_64
Oct 18 00:37:23 INFO Erased: abrt-addon-xorg-2.8.0-5.fc23.x86_64
Oct 18 00:37:24 INFO Erased: abrt-plugin-bodhi-2.8.0-5.fc23.x86_64
Oct 18 00:37:24 INFO Erased: setroubleshoot-3.3.11-1.fc23.x86_64
Oct 18 00:37:24 INFO Erased: policycoreutils-devel-2.4-21.fc23.x86_64
Oct 18 00:37:24 INFO Erased: abrt-java-connector-1.1.0-6.fc23.x86_64
Oct 18 00:37:24 INFO Erased: abrt-dbus-2.8.0-5.fc23.x86_64
Oct 18 00:37:24 INFO Erased: abrt-python3-2.8.0-5.fc23.x86_64
Oct 18 00:37:24 INFO Erased: abrt-2.8.0-5.fc23.x86_64
Oct 18 00:37:24 INFO Erased: libreport-python3-2.6.4-2.fc23.x86_64
Oct 18 00:37:24 INFO Erased: dnf-1.1.10-1.fc23.noarch

Natürlich kann man das jetzt mit etwas Bashmagie automatisch reinstallieren lassen. Kleiner Denkanstoß :

grep „Erased:“ /var/log/dnf.rpm.log | sed -e „s/^.*Erased:/dnf install -y/g“ | bash

Eine kleine Nacharbeit muß man dann aber noch tun: die Configfiles für YUM und DNF sollten restauriert werden, denn nach dem Install sind die wieder default. Zum Glück ist RPM clever und legt bei sowas eine Sicherungsdatei an:

-rw-r–r–. 1 root root 833 18. Okt 01:00 /etc/yum.conf
-rw-r–r–. 1 root root 833  3. Apr 2016  /etc/yum.conf.rpmsave

Und immer dran denken: bis auf  „dd if=/dev/zero of=/dev/sda1“ aka „format c:“ kann man alles unter Linux reparieren.