OpenSSH ist eine auf dem SSH-Protokoll basierende Sammlung von abgesicherten Werkzeugen zum Netzwerken. Das gerade veröffentlichte OpenSSH 8.8 deaktiviert die Unterstützung für RSA-Signaturen mit dem SHA-1-Hash-Algorithmus. Für die meisten Benutzer sollte diese Änderung unmerkbar sein und es besteht keine Notwendigkeit, ssh-rsa-Schlüssel zu ersetzen, da die Funktion UpdateHostKeys die Clients auf einen verlässlicheren Algorithmus aktualisiert. Inkompatibilitäten können lediglich bei Verwendung älterer SSH- Implementierungen auftreten.
Sicherheitsproblem bei sshd behoben
Darüber hinaus kündigen die Entwickler an, in einer der nächsten Ausgaben von OpenSSH scp, das Protokoll zur verschlüsselten Übertragung von Daten von der Verwendung des scp/rcp-Protokolls auf die Verwendung von SFTP umzustellen. Die neue Version behebt zudem ein Sicherheitsproblem, das dadurch verursacht wurde, dass sshd seit OpenSSH 6.2 Benutzergruppen fälschlicherweise initialisierte, wenn Befehle aus den Sektionen Authorized Keys Command und Authorized Principals Command ausgeführt wurden, bei denen eine AuthorizedKeysCommandUser– oder AuthorizedPrincipalsCommandUser-Direktive gesetzt wurde, um den Befehl unter einem anderen Benutzer auszuführen. Dadurch konnten je nach Systemkonfiguration unbeabsichtigte Nutzerprivilegien vergeben werden.
ClamAV® ist eine Open-Source-Antivirus-Engine zur Erkennung von Trojanern, Viren, Malware und anderen Bedrohungen und stellt unter Linux den Standard zur Abwehr dieser Bedrohungen dar. Gerade ist ClamAV 0.104.0 als neue stabile Version erschienen.
LTS-Programm aufgelegt
Die Entwickler kündigen im Blog des Projekts im Rahmen einer Aktualisierung ihrer End-of-Life (EOL)-Politik ein neues Long Term Support (LTS)-Programm an. Das LTS-Programm beginnt rückwirkend mit der letzten Hauptversion ClamAV 0.103. Die neue LTS-Richtlinie verlängert die Lebensdauer von 0.103 bis September 2023. LTS-Ausgaben werden mindestens drei Jahre lang unterstützt.
Jede LTS-Version wird mit kritischen Patch-Versionen und Zugang zu Signatur-Updates für die Dauer des dreijährigen Supportzeitraums unterstützt. Etwa alle zwei Jahre wird ein neues LTS-Feature-Release vorgestellt. Nicht-LTS Releases werden mit kritischen Patch-Versionen für mindestens vier Monate ab dem ursprünglichen Veröffentlichungsdatum des nächsten Feature-Releases oder bis zur Veröffentlichung des darauffolgenden Feature-Releases unterstützt. Ausführliche Informationen zum Long Term Support-Programm sind im Blogbeitrag zur LTS-Ankündigung und in der LTS-Richtlinie in der Online-Dokumentation zu finden.
Neue Scan-Option
Unter den Verbesserungen von ClamAV 0.104.0 ist eine neue Scan-Option, die vor fehlerhaften Mediendateiformaten warnt. Diese Funktion mindert das Risiko von bösartigen Änderungen an Mediendateien, mit denen Schwachstellen in anderer Software ausgenutzt werden sollen. Um diese Funktion zu aktivieren, muss in der Konfigurationsdatei clamd.conf die neue Option AlertBrokenMedia auf yes gesetzt oder beim Aufruf von Clamscan der Parameter --alert-broken-media verwendet werden.
Jetzt auch im Docker-Container
Des Weiteren erhielt ClamAV ein lange erwartetes offizielles Docker-Image, sodass ClamAv nun in einem Docker-Container laufen kann. Dazu gibt es eine Einführung in der ClamAV-Dokumentation. Windows-Anwendern bietet ClamAV jetzt die Möglichkeit, clamd und freshclam als Windows-Dienste auszuführen. Um neue Versionen von ClamAV schneller zu den Anwendern zu bringen, stehen neue Pakete bereit. Dazu zählen Pakete für x86_64 als DEB und RPM sowie ein ARM64 macOS-Installer, der mit Intel- und Apple M1-Systemen kompatibel ist. Für die Zukunft hoffen die Entwickler, dieses Angebot durch ARM64 Linux DEB- und RPM-Pakete und ein x86_64 FreeBSD-Paket zu ergänzen.
Forscher beim Berliner IT-Sicherheitsunternehmen Positive Security haben eine kritische Schwachstelle im Pling-Store entdeckt, der von App-Stores für freie und quelloffene Software genutzt wird. Die Lücke kann potenziell missbraucht werden, um Supply-Chain-Attacks über eine XSS-Lücke zu inszenieren und Remote Code Execution (RCE) auszuführen.
Kein Kontakt
Da die Entdecker der Lücke seit Februar nicht in der Lage waren, einen Verantwortlichen bei der Firma Hive01, die den Pling-Store betreibt, zu erreichen, gehen sie jetzt mit der bisher ungepatchten Lücke an die Öffentlichkeit. Betroffen sind unter anderem:
appimagehub.com
store.kde.org (Discover)
gnome-look.org
xfce-look.org
pling.com
Installation mit einem Mausklick
Pling-Store ermöglicht es Anbietern, Dinge wie Erweiterungen, Themes, Icons oder Mauszeiger mit einem Klick zu installieren, die in den Distributionen selbst vielleicht nicht verfügbar sind. Derzeit werden die Desktops KDE Plasma, Gnome, XFCE, Mate, Cinnamon, Budgie, LXQt, Elementary und Enlightenment unterstützt. Die entdeckte Schwachstelle liegt in der Methode, wie Entwickler im Pling-Store eine App anlegen und Metadaten etwa zur Beschreibung der App im Listenfeld HTML or Embed Media Code anlegen. Dieses Listenfeld lässt sich leicht missbrauchen, um eine XSS-Nutzlast unterzubringen.
Zugriff auf aktive Angebote
Die gespeicherte Nutzlast ließe sich verwenden, um bereits aktive Angebote zu ändern oder neue Angebote im Pling-Speicher im Kontext anderer Benutzer zu veröffentlichen, was zu einem wurmfähigen XSS führt. Neben den typischen XSS-Implikationen würde dies einen Supply-Chain-Attacke-XSS-Wurm mit einer JavaScript-Nutzlast ermöglichen, um trojanisierte Versionen von Software hochzuladen und die Metadaten der Auflistung eines Opfers so zu verändern, dass sie den Angriffscode enthalten und verbreiten.
Über eine Electron-App, die Pling-Store allen Nutzern empfiehlt, gelang es den Forschern, über die XSS-Lücke eine App zu installieren und damit Code auszuführen. Wenn ein Anwender eine bösartige Website besucht, während der Pling-Store im Hintergrund aktiv ist, wird der XSS-Code innerhalb der Pling-App ausgelöst. Der JavaScript-Code in der Website kann nun nicht nur eine Verbindung zum lokalen WebSocket-Server herstellen, der verwendet wird, um Nachrichten von der App abzuhören, sondern er nutzt ihn auch, um Nachrichten zu senden, um beliebigen nativen Code auszuführen, indem er ein AppImage herunterlädt und ausführt.
Auch wenn bei der zu Blue Systems gehörenden Firma Hive01 niemand auf den Versuch, die Lücke zu melden, reagiert hat, so haben die Entwickler von GNOME und KDE die unter CVE-2021-28117 katalogisierte Lücke mittlerweile geschlossen.
Polkit, das früher PoilcyKit hieß ist der mit Systemd verbandelte Berechtigungsdienst, der es unprivilegierten Prozessen ermöglicht mit ihren privilegierten Kollegen sprechen können. Wenn also eine Anwendung für eine Aufgabe Root-Rechte benötigt, fragt Polkit nach dem entsprechenden Passwort.
CVE-2021-3560
Wie auf GitHub aktuell zu lesen ist, wurde kürzlich eine Sicherheitslücke entdeckt, die seit sieben Jahren in Polkit vorhanden war und als CVE-2021-3560 (Common Vulnerabilities & Exposures) katalogisiert ist. Sie war mit 7.8 von 10 Punkten als kritisch eingestuft.
Ausweitung der Rechte
Bei der Lücke handelte es sich um eine mögliche Privilegien-Eskalation, die sehr einfach durchzuführen war. Sie war mit Commit bfa5036 in Version 0.113 eingeschleppt worden. Wie Kevin Backhouse, der Entdecker der Lücke schreibt, waren zur Ausnutzung lediglich einige Kommandozeilen-Werkzeuge und Befehle wie bash, kill und dbus-send notwendig. Die Schwachstelle wird durch das Starten eines dbus-send-Befehls ausgelöst, der jedoch sofort per kill beendet wird, während Polkit noch mitten in der Verarbeitung der Anfrage steckt.
Polkit ging mit der Antwort auf die bereits beendete Anfrage falsch um. Anstatt den Vorgang abzubrechen, ging Polkit davon aus, dass die Anfrage von einem Prozess mit der UID 0 gekommen sei, also von einem Root-Prozess und genehmigte die Anfrage. Das gelang zwar nicht immer, aber oft genug, um den Aufwand gering zu halten.
Bitte zeitnah aktualisieren
Der Fehler betrifft Distributionen, die Polkit in Version 0.113 oder später verwenden. Welche Distributionen das sind, lässt sich mit Repology nachvollziehen. Debian hat mittlerweile mit Version 0.105-31 einen Patch für Unstable und Testing bereitgestellt, den Ubuntu für 21.04 übernommen hat. Unter anderem auch Arch Linux, Red Hat und SUSE haben ihre Pakete gepatched.
Der bei GitHub angestellte Sicherheitsforscher Kevin Backhouse hat zwei Lücken in Ubuntu 20.04 LTS entdeckt, deren Kombination es einem lokalen Angreifer mit einfachen Mitteln erlaubte, einen Root-Account zu erlangen. Die Lücken sind mittlerweile gepatched.
Ohne eine Zeile Code
Backhouse schrieb, es sei ungewöhnlich, dass eine Schwachstelle in einem modernen Betriebssystem so leicht ausgenutzt werden kann wie hier. Zur Ausnutzung der von ihm gefundenen Lücken muss keine einzige Zeile Code geschrieben werden. Die Lücke zur Ausweitung der Rechte ist zweigeteilt. Der erste Teil des Angriffs nutzt einen Fehler im Accountsservice aus, einem Daemon zur Verwaltung von Userkonten. Dieser Daemon stammt eigentlich aus dem freedesktop-Projekt, wurde aber von den Ubuntu-Entwicklern modifiziert, um eine Datei im Home-Verzeichnis des Benutzers zu lesen.
Backhouse hat zunächst die Datei namens .pam_environment über einen symbolischen Link an die virtuelle Gerätedatei /dev/zero geschickt. Der anschließende Versuch, die Sprache des Desktops zu ändern lässt die entsprechende Dialogbox einfrieren. Im Terminal stellt er fest, dass Accountsservice nun einen CPU-Kern zu 100% auslastet. Nun löscht Backhouse den Symlink, um sich nicht selbst auszusperren.
Der Daemon wird gecrashed
Als Nächstes sendet er das Signal SIGSTOP zum Unterbrechen von Programmprozessen an den Accountsservice. Jetzt folgt der einzig kritische Punkt des Exploits: Bevor sich Backhaus von seinem Konto abmeldet, setzt er zunächst per nohup einen Timer, der ihm das Ausloggen ermöglicht bevor er den Konten-Dämons crasht. Ohne diesen Schritt würde er einfach ausgesperrt und der Exploit wäre fehlgeschlagen.
GDM3 erlaubt Root-Account
Nun stellt beim Login per GDM3 dieser fest, dass kein User-Konto besteht und schaltet das Setup ein, als wäre die eine Neuinstallation. Nun kann ein Root-Account angelegt werden und das System gehört dem Angreifer. BeideLücken, die Ubuntu-Ausgaben von 16.04 LTS bis zu 20.10 betrafen, sind mittlerweile geschlossen.
Vor rund einer Woche erschien hier ein Bericht über Bestrebungen des russischen Geheimdienstes und der Telekommunikationsbehörde Roskomnadsor, verschiedene ausländische Mail-Provider in Russland zu sperren, darunter auch den Berliner Dienstleister mailbox.org.
ProtonMail gesperrt
Dieses Schicksal ereilte Ende Januar bereits den Anbieter ProtonMail. Als Begründung im Fall des Sperrantrags gegen mailbox.org wurde bereits im September 2019 der Vorwurf erhoben, der Provider habe auf eine Auskunftsanfrage im 2. Quartal 2019 nicht reagiert und sei nicht im russischen Telekommunikationsverzeichnis »ARI« eingetragen. Direkter Anlass sollen über mailbox.org und andere Provider versandte E-Mails mit Bombendrohungen gewesen sein.
Sperrantrag zurückgezogen
Ende letzten Jahres hatte Roskomnadsor vor einem Gericht in Moskau die Sperrverfügung beantragt, der Prozess fand am gestrigen 5. Februar in Moskau statt. Wie mailbox.org im Firmenblog mitteilt, zog die Aufsichtsbehörde vor Gericht ihren Sperrantrag zurück.
Im Vorfeld hat sich mailbox.org mit seinen russischen Anwälten dazu entschieden, die eigenen Kontaktdaten in das russische Telekommunikationsverzeichnis aufnehmen zu lassen, da es sich dabei lediglich um Daten handelt, die auch dem Impressum der Firmenwebseite zu entnehmen sind.
Klares Dementi
Einer gestrigen Meldung (russ. Originaltext) der Nachrichtenagentur Interfax zufolge soll sich mailbox.org auch zur Speicherung von Nutzerdaten in Russland bereit erklärt haben. Das dementiert der Mail-Provider ausdrücklich und betont, dass mailbox.org niemals Daten seiner Nutzer in Russland speichern würde.
Auch soziale Netzwerke betroffen
Auch Facebook und Twitter sehen sich in Russland von Strafen und Sperrung bedroht, da die Dienste sich weigern, Nutzerdaten von lokalen Anwendern auf Servern in Russland zu speichern. Die russischen Behörden entsprechen mit diesem Verlangen einem Gesetz, dass die Speicherung solcher Daten auf russischem Hoheitsgebiet vorschreibt.
Lobenswerte Entwicklung
Diese Vorgänge sind im Licht der Bestrebungen Russlands zu sehen, den Einfluss proprietärer ausländischer Software im eigenen Land zurückzutreiben. Um die Macht von Android zu brechen, steckten bereits 2015 damals nicht näher benannte russische Finanziers eine ungenannte Summe in das leckgeschlagene finnische Unternehmen Jolla, um aus deren mobilem Betriebssystem Sailfish OS eine russische Alternative zu Android zu machen.
Ein neues Gesetz schrieb 2016 dem öffentlichen Sektor Russlands vor, freie Software einzusetzen und mit der globalen freien Software-Gemeinschaft zusammenzuarbeiten. Proprietäre Software ist demnach nur noch in gut begründeten Fällen erlaubt.
Begründete Sorge
Die Bestrebungen der russischen Führung, die Kontrolle über die im Land verwendete Software zurückzugewinnen ist bestimmt lobenswert. Aktionen wie die hier beschriebenen geplanten Sperrungen hinterlassen dagegen leider einen säuerlichen Geschmack von Zensur und Kontrolle der eigenen Bevölkerung.
Die russische Telekommunikationsbehörde Roskomnadsor sperrt derzeit im Auftrag des Geheimdienstes FSB ausländische Mail-Provider. Roskomnadsor unterstehen im Rahmen der Presseaufsicht unter anderem die Ressorts Informationstechnologie und Massenmedien.
ProtonMail bereits gesperrt
Jetzt sind mehrere Mail-Provider, bei denen die Sicherheit der Kommunikation im Vordergrund steht, von der Sperrung bedroht. So berichtete ProtonMail gestern von Sperrungen ihres Dienstes innerhalb Russlands. Betroffen sind Nutzer von ProtonMail und ProtonVPN, die zum Zeitpunkt der Sperrung nicht eingeloggt waren. ProtonMail rät als erste Maßnahme zum Verwenden des Tor-Browsers zum Umgehen der Sperre.
Nun auch mailbox.org bedroht
Heute vermeldet auch der deutsche Mail-Provider mailbox.org in einem Blogeintrag, von der Sperrung bedroht zu sein. Auch bei dem von Peer Heinlein in Berlin gegründeten Mail-Versender stehen Sicherheit und Schutz der Privatsphäre im Vordergrund.
Registrierungspflicht
Bereits im September 2019 wurde die geplante Sperrung bekannt. Der Vorwurf lautet, der Provider habe auf eine Auskunftsanfrage im 2. Quartal 2019 nicht reagiert und sei nicht im russischen Telekommunikationsverzeichnis „ARI“ eingetragen. Anlass sollen über bestimmte Provider versandte E-Mails mit Bombendrohungen sein.
Keine Anfrage bekannt
Peer Heinlein sagte damals, ihm sei »keine Anfrage von Roskomnadsor bekannt«. Am 29. Dezember 2019 hat Roskomnadsor vor einem Gericht in Moskau die Sperrverfügung beantragt. Der Berliner Provider wird sich beim am 5. Februar anstehenden Prozess anwaltlich vertreten lassen um »für eine freie, sichere Kommunikation einzutreten«.
Heinlein tritt mit seinem Unternehmen gegen diese Art von Zensur ein und äußerte sich im September zu einem Workaround:
Dieser Vorfall zeigt einmal mehr, wie wichtig freie Kommunikationsstrukturen wie das weltweite TOR-Netzwerk sind. Dieses ermöglicht Anwendern auch in totalitären und überwachenden Staaten die sichere Teilnahme am Internet und der freien Kommunikation. Aus diesem Grunde betreibt mailbox.org zur sicheren Kommunikation eigene TOR-Server und ist auch über die sogenannten TOR-Onion-Adressen weltweit erreichbar.
Google hat auf seiner Entwickler-Messe Google I/O im kalifornischen Mountain View verkündet, Erstausrüster (OEM) von Android-Geräten künftig vertraglich zu regelmäßigen Sicherheits-Updates zu verpflichten. Über die Frequenz und die genauen Bedingungen ist allerdings noch nichts bekannt. Der einzige Hersteller der seine Gerätereihen – Nexus und Pixel – zuverlässig und pünktlich monatlich mit Sicherheits-Updates versorgt ist Google selbst. Alle anderen Hersteller handeln in dieser Hinsicht nach Gutdünken und oft lückenhaft und mit großer Verzögerung.
Umdenken
Im Jahr 2015 hatten Lücken in Androids Stagefright-Engine, einer Komponente zum Abspielen und Streamen von Medien auf Android-Geräten, Google zum Umdenken gebracht. Der Konzern beschloss, Android-Sicherheits-Updates künftig monatlich für die Erstausrüster zur Verfügung zu stellen. Viele große Hersteller sagten zu, diese auch zeitnah ausliefern zu wollen. Die vorher sehr schlechte Versorgung mit Updates hat sich seitdem verbessert, jedoch ist es vielfach beim Wollen geblieben.
In den Jahren 2016 und 2017 wurden immerhin jeweils rund 30 Prozent mehr Geräte mit Updates versorgt als im Jahr zuvor. Trotzdem sind von den mehr als zwei Milliarden Android-Smartphones viele mit gravierenden Sicherheitslücken behaftet, weil die Hersteller die Geräte nicht mehr mit Updates versorgen. Hier will Google nun mit vertraglichem Druck für mehr Sicherheit zumindest bei aktuellen Geräten sorgen.
Project Treble
Vor ziemlich genau einem Jahr hatte Google die Bedingungen dafür durch die Ankündigung des Project Treble verbessert. Treble stellt eine stabile Hardware-Abstraktionsschicht für Android dar, die Herstellern bei jeder neuen Android-Version unter anderem alle Treiber portieren zu müssen. Realisiert wird das über eine niedrig angesiedelte Schnittstelle, die Google schlicht »Vendor Interface« nennt.
Patches ausgelassen
Allerdings zeigt eine aktuelle Studie der deutschen Security Research Labs, dass selbst Hersteller, die monatlich Updates ausliefern, oft wichtige Patches auslassen, ihre Anwender aber mit falschen Angaben in Sicherheit wiegen. Nun reagiert Google auf die immer noch katastrophalen Zustände bei der Android-Sicherheit. Auf der Google I/O erklärte David Kleidermacher, Chef der Android-Sicherheit, Änderungen am Sicherheitsmodell der kürzlich vorgestellten nächsten Version Android P würden die Sicherheit von Android wesentlich verbessern.
[su_quote style=“modern-light“ cite=“David Kleidermacher“]»Wir haben auch daran gearbeitet, Sicherheitspatches in unsere OEM-Verträge einzubauen. Nun wird dies wirklich zu einem massiven Anstieg der Anzahl der Geräte und Benutzer führen, die regelmäßig Sicherheitspatches erhalten.« [/su_quote]
Solange allerdings die Bedingungen dieser Vertragsklauseln nicht bekannt sind, lässt sich nicht absehehen, wieviel davon Wunschdenken oder Augenwischerei ist und wie viel davon wirklich beim Endkunden ankommt.
