y0o.de · GNU/Linux Nachrichten u.Ä.

🔒
❌ Über y0o.de
Es gibt neue verfügbare Artikel. Klicken Sie, um die Seite zu aktualisieren.
Heute — 18. Juni 2021Haupt-Feeds

Neue Lücke mit Exploit in Chrome

18. Juni 2021 um 10:47

Googel hat erneut vor Sicherheitslücken in seinem Browser Chrome gewarnt und stellt im stable Channel ein Update zur Verfügung. Auch für eine dieser Lücken gibt es einen Exploit.

Google Chrome 91.0.4472.114 für Linux, Mac und Windows schließt vier Sicherheitslücken. Alle vier sind von ihrem Bedrohungslevel als Hoch eingestuft und alle vier seien von externen Sicherheitsexperten entdeckt worden, heißt es seitens Google von Srinivas Sista, dem technischen Programm-Manager von Chrome.

Für eine der Lücke (CVE-2021-30554) sei bereits ein Exploit im Umlauf, so Sista weiter. Es handle sich bei der Lücke um ein Use after free-Problem in WebGL. Mehr Details zu Art des Speicherfehlers in WebGL nennt der Manager nicht.

Auch die drei weiteren Probleme basieren auf Speicherfehlern in unterschiedlichen Komponenten des Browsers. genannt sind die Bereiche Sharing, WebAudio und TabGroups.

Google hatte bereits vor einigen Tagen vor Sicherheitsproblemen in Chrome gewarnt, für die bereits Exploits im Umlauf sind. Das Update für Chrome, das die Lücken schließt, sei im stable Channel verfügbar und werde nun ausgerollt.

Der Beitrag Neue Lücke mit Exploit in Chrome erschien zuerst auf Linux-Magazin.

Ältere BeiträgeHaupt-Feeds

Google warnt vor Chrome-Exploit

10. Juni 2021 um 12:19

Google schließt mit einem Update seines Chrome-Browsers diverse Sicherheitslücken. Für eine davon sei ein Exploit unterwegs.

Wie gewohnt ist Google bei der Ankündigung seiner Browser-Aktualisierungen sparsam mit Informationen. Die Chrome-Version 91.0.4472.101 schließe 14 Sicherheitslücken, heißt es in der Ankündigung. Eine davon, CVE-2021-30551, wird bereits über einen Exploit ausgenutzt, so Google. Der mit der Qualifizierung „high“eingestufte Bug steckt in der Javascript-Engine V8 des Chrome-Browsers. Angreifer können damit eine Type-Confusion auslösen, so Google in der Meldung zum Update. Weitere Details verrät Google nicht, vermutlich lässt sich über diesen Speicherfehler dann aber Code ausführen.

Ein Update des Browsers ist also dringend nötig, auch weil es weitere Sicherheitslücken mit hohem und kritischem Risiko geschlossen werden.

Der Beitrag Google warnt vor Chrome-Exploit erschien zuerst auf Linux-Magazin.

Linux auf Chromebooks verlässt mit Chrome OS 91 Beta-Status

21. Mai 2021 um 08:20
Von: jdo

Die Beta-Phase für Linux auf Chromebook wurde bereits 2018 gestartet – damals mit Chrome OS 69. (Codename: Crostini). Mit Chrome OS 91, das binnen der nächsten Wochen erscheinen soll, wird Linux für Chromebooks nun die Beta-Phase verlassen. Ist die Funktion aktiv, kannst Du Deine Lieblings-Linux-Software installieren. Ich bin gespannt, wie gut das funktioniert. Damit wird ein Chromebook für mich ziemlich interessant, wenn ich unterwegs bin. GIMP, LibreOffice und so weiter könnte ich dann auf einem Chromebook mitnehmen. Sogar Firefox kann […]

Der Beitrag Linux auf Chromebooks verlässt mit Chrome OS 91 Beta-Status ist von bitblokes.de.

WordPress-Entwickler sehen FLoC als Sicherheitsrisiko

19. April 2021 um 09:53
NoFLoC

In der vergangenen Woche hatte sich breiter Widerstand gegen Federated Learning of Cohorts (FLoC), Googles neue Strategie zum Tracking der Anwender des Chrome-Browsers zu Werbezwecken formiert. Jetzt hat auch WordPress als das mit rund 41 % Marktanteil am weitesten verbreitete CMS Stellung bezogen.

FLoC als Sicherheitsrisiko

Der Vorschlag eines WordPress-Entwicklers vom Wochenende plädiert dafür, FLoC als Sicherheitsrisiko einzustufen und dementsprechend generell zu blockieren. Dazu liefert er gleich einen Patch mit vier Zeilen, der genau das tut. Es gehe darum, die Webseitenbetreiber zu schützen, denen gar nicht bewusst sei, dass Google den Anwendern FLoC per Opt-out weltweit unterschieben möchte. In Europa sind wir derzeit noch durch die DSGVO geschützt. Die Zukunft wird zeigen ob FLoC damit kompatibel ist.

Mehrheit stimmt zu

Durch die Einstufung als Sicherheitsrisiko seien die Entwickler in der Lage, FLoC kurzfristig zu sperren, ohne auf WordPress 5.8 zu warten, dass erst im Juli zur Veröffentlichung vorgesehen ist. Admins, die FLoC bewusst zulassen möchten, wüssten sowieso, was dafür zu tun ist. Ein Schalter zum Ein- und Ausschalten von FLoC könne in einem späteren Release folgen. Bereits jetzt steht ein Plug-in zum Sperren von FLoC für WordPress bereit. Die überwiegende Mehrheit der kommentierenden Entwickler stimmen zu, dass Handlungsbedarf bestehe und FLoC zur sofortigen Sperrung als Sicherheitsrisiko einzustufen sei.

Predatory Targeting

Die Electronic Frontier Foundation (EFF) sieht dagegen eher Risiken für die Privatsphäre, wenn sie schreibt: »Die Technologie vermeidet zwar die Datenschutzrisiken von Drittanbieter-Cookies, aber sie wird dabei neue Risiken schaffen. Sie kann auch viele der schlimmsten Probleme mit verhaltensbezogenen Anzeigen verschärfen, die nicht mit dem Datenschutz zusammenhängen, wie z. B. Diskriminierung und Predatory Targeting«.

Google schließt Sicherheitslücken in Chrome

22. April 2021 um 10:48

Mit dem Update des Stable-Channels seines Browsers Chrome auf Version 90.0.4430.85 beseitigt Google einige gefährliche Sicherheitslücken, für die in einem Fall bereits Exploits kursieren.

Ein Update des Browsers auf die neue Version ist angeraten, sollten die automatischen Update-Einstellungen nicht zur Anwendung kommen. Google führt die technischen Details zu den Lücken wie gewohnt nicht näher aus. Bei allen fünf genannten Sicherheitsproblemen ist das Risiko als Hoch eingestuft. Bei der Lücke, für die es nach Erkenntnissen des Anbieters Exploits gibt, handelt es sich um eine Type Confusion in V8. Mit V8 ist Googles Open-Source-Engine zum Ausführen von JavaScript-Code gemeint. Anscheinend lässt sich die Engine austricksen, indem sie die Datenverarbeitung für einen bestimmten Eingabe-Typ startet, und dann aber mit einem anderen Typ weitermacht. Die Type-Confusion führt regelmäßig zu Logik-Fehlern im Speicher der Anwendung und lässt sich zu verschiedenen böswilligen Angriffen ausnutzen, bis hin zur Ausführung von beliebigem Code. Das Update schließt noch eine weitere Lücke in der V8-Engine und weitere Speicherfehler nebst Bufferoverflows, teil Google mit.

Der Beitrag Google schließt Sicherheitslücken in Chrome erschien zuerst auf Linux-Magazin.

Raspberry Pi 4 Kiosk - Bildschirmschoner unter Raspberry Pi OS deaktivieren

10. April 2021 um 13:01

Der Raspberry Pi ist schon längere Zeit in Version 4 verfügbar, Raspbian heißt nun Raspberry Pi OS und der dazugehörige Imager hat mehr Optionen erhalten (Strg + Shift +X).

Dies sind allerdings nicht die einzigen Neuerungen. Denn eine oft gestellte Frage hat nun ebenfalls eine andere Antwort.

Wie deaktiviere ich den Bildschirmschoner unter Raspberry Pi OS

Um den Bildschirmschoner zu deaktivieren, konnten bisher in einigen Dateien Hand angelegt werden.

So mussten in der Vergangenheit diverse Werte im Autostart eingetragen werden:

/home/pi/.config/lxsession/LXDE-pi/autostart

Beziehungsweise unter:

/etc/xdg/lxsession/LXDE-pi/autostart 

Details dazu findet ihr in einem alten Artikel.

Mit der neuen OS Version, welche auf Debian Buster basiert, ist dies nicht mehr nötig.

Der Hersteller hat diese Option nun direkt im Konfigurationstool versteckt. 

sudo raspi-config

[Menu] --> [Preferences] --> [Screen Blanking]

raspberrypi4-screensaveDie alten Methoden funktionieren nicht mehr.

Ein weiterer Workaround wäre die Installation eines extra Screensavers ( sudo apt-get install xscreensaver ), welcher dann deaktiviert wird. Dieser Schritt sollte im Normalfall allerdings nicht nötig sein.

 

Piper Make – Drag&Drop Coding im Browser für Raspberry Pi Pico

31. März 2021 um 08:09
Von: jdo

Wer seinen Raspberry Pi Pico lieber mit der Maus programmieren möchte, kann das ab sofort tun. Piper Make nennt sich das Tool, das von Piper, Inc. ins Leben gerufen wurde. Es ist ein Browser-basiertes Tool. Die erste Überraschung gab es aber, als ich die dazugehörige Website make.playpiper.com mit Firefox besuchen wollte. Mein Browser wird derzeit nicht unterstützt und ich soll es mit Chrome, einem Chromebook oder einem kompatiblen Browser versuchen. Mit hat die Sache dann funktioniert – zumindest hat sich […]

Der Beitrag Piper Make – Drag&Drop Coding im Browser für Raspberry Pi Pico ist von bitblokes.de.

Googel beseitigt kritische Lücken in Chrome

15. März 2021 um 10:14

Mit dem Update auf Version 89.0.4389.90 ist der Chrome-Browser von Google fünf Sicherheitslücken los.

Eine der in Chrome nun geschlossenen Lücken (CVE-2021-21193) lässt sich nach den Erkenntnissen von Google über einen Exploit ausnutzen, heißt es im Chrome-Blog. Wie gewohnt hält Google Informationen zu den Sicherheitsproblemen zurück, um Angreifern keine Einblicke zu gewähren. Die möglicherweise bereits durch einen Exploit ausgenutzte Lücke steckt demnach als Use-after-free-Fehler in Blink, der HTML-Rendering-Engine von Chrome. Es handelt sich also um einen Speicherfehler, den durch den Exploit ausnutzen können. Das Risiko dieses Sicherheitsproblems ist als “Hoch” eingestuft. Diese Einstufung gilt auch für zwei weitere Sicherheitslücken, die von externen Experten gefunden wurden.

Mit Chrome 89.0.4389.90 sind in den Browser-Versionen für Linux, Mac und Windows diese Probleme beseitigt. Eine komplette Übersicht zu den Änderungen enthält die Log-Datei.

Der Beitrag Googel beseitigt kritische Lücken in Chrome erschien zuerst auf Linux-Magazin.

Google zahlt 6,7 Millionen Dollar an Bug-Jäger

09. Februar 2021 um 11:00

Im Jahr 2020 hat Google im Zuge seines Bug-Bounty-Programms 6,7 Millionen S-Dollar an Experten gezahlt, die Fehler in den Programmen und Services des Konzerns gefunden haben.

Mit 6,7 Millionen US-Dollar seien rund 280.000 Dollar mehr ausgezahlt worden, als im Jahr 2019, teilt Google mit. Der Browser Chrome, das Android-System und der App-Store Google Play sind die klassischen Jagdgründe, in denen Google Prämien für darin gefundenen Fehler zahlt. Die Bugs werden dabei klassifiziert und müssen ein gewisses Gefahrenlevel aufweisen. Daneben hat Googe auch ein Abuse Programm aufgelegt, mit dem Betrugsmaschen und Angriffsszenarien in den Goggle-Services aufgedeckt werden sollen. Im Jahr 2020 seien damit rund 100 Probleme in 60 Produkten identifiziert und gefixt worden. Zusätzlich sind mit Android Auto und Android Chipsets im Jahr 2020 neue Felder für die Fehlersuche eingeführt worden.

Stetiger Anstieg bei den Bug-Prämien. Quelle: Google

Die 2020 gezahlten Prämien gingen an 662 Forscher aus 62 Ländern, teilt Google mit. Die höchste Summe habe 132.000 US-Dollar betragen. 1,74 Millionen Dollar sind für Bugs in Android geflossen. Google hebt hervor, dass man die Android 11 Developer Preview in das Bounty-Proramm eingebunden habe. Dadurch seien die Fehler bereits vor Erscheinen von Android 11 beseitigt worden. 50.000 US-Dollar seien dafür ausgezahlt worden.

Zu den erfolgreichsten Jägern zählt Alpha Lab. Diesem Team sei es gelungen acht Exploits zu finden, darunter einen 1-Click-Remote-Root-Exploit.

Für die Fehler in Chrome hat Google 2,1 Millionen S-Dollar gezahlt. Durch eine Erhöhung der Prämien seien das 83 Prozent mehr als im Jahr 2019. Google Play kommt auf 270.000 US-Dollar. Weitere 400.000 US-Dollar sind in das Programm Vulnerability Research Grants geflossen. Mit dem honoriert Google Forscher, die sich den Code von Googles-Software prüfend anschauen. Die Top-Bugjäger und Sicherhitsexperten sind dabei und auch von Google eingeladenen Experten. Es geht bei den Prämien nicht um Bugs sondern und Unstimmigkeiten, veraltete Ansätze und Konzepte und neue Technologien.

Der Beitrag Google zahlt 6,7 Millionen Dollar an Bug-Jäger erschien zuerst auf Linux-Magazin.

Chromium – Google wird API-Zugriff einschränken ( Google Sync …)

25. Januar 2021 um 08:49
Von: jdo

Für manche Anwenderinnen und Anwender könnte Googles Schritt ein Ärgernis sein. Andere sind vielleicht froh, dass es künftig weniger Google in Chromium gibt. Auf jeden Fall wurde angekündigt, dass diverse Google-Funktionen künftig in Chromium und anderen darauf basierenden Browsern nicht mehr funktionieren. Der Zugriff auf die Chrome APIs wird ab dem 15. März 2021 eingeschränkt. Zu den eben angesprochenen Funktionen gehört auch Google Sync. Die Daten werden nicht gelöscht und Du findest sie weiter in Deinem Google-Konto. Allerdings kannst Du […]

Der Beitrag Chromium – Google wird API-Zugriff einschränken ( Google Sync …) ist von bitblokes.de.

Browser blockieren neues kasachisches Überwachungszertifikat

21. Dezember 2020 um 12:51

Die großen Browser-Hersteller blockieren ein Zertifikat der kasachischen Regierung. Das ist bereits der dritte HTTPS-Überwachungsversuch.

In einer koordinierten Aktion ist das aktuelle Überwachungszertifikat der kasachischen Regierung in den großen Browsern Chrome, Edge, Firefox und Safari blockiert worden, wie Mozilla mitteilt. Vor wenigen Wochen hatte die Regierung Kasachstans ihre Bürger in der Hauptstadt Nur-Sultan offenbar schon zum dritten Mal seit 2015 dazu aufgefordert, ein Root-Zertifikat auf ihren Geräten zu installieren, wenn diese auf Internetdienste im Ausland zugreifen wollen.

Mit Hilfe des installierten Zertifikats ist es möglich, einen Man-in-the-Middle-Angriff auf HTTPS-Verbindungen durchzuführen und so die sonst verschlüsselten Verbindungen zu überwachen. Die Zertifikate der Webseiten gewährleisten normalerweise, dass Man-in-the-Middle-Angriffe nicht möglich sind. Ist jedoch ein lokales Root-Zertifikat installiert, kann ein Anbieter, der den dazugehörigen privaten Schlüssel besitzt, dynamisch für jeden Webseitenaufruf ein neues Zertifikat generieren und so eben selbst die Verbindungen mitlesen.

Im aktuellen Fall ist unter dem Vorwand einer “Cyber-Sicherheitsübung” geschehen, wie ZDnet berichtete. Demnach leiteten die großen Internetprovider Nutzer auf eine eigenes dafür eingerichtete Webseite um, die sie zur Installation des Zertifikats auffordert. Einwohner der Hauptstadt seien außerdem per SMS zur Installation des Zertifikats aufgefordert worden.

Es ist nun schon der dritte Versuch, den die kasachische Regierung unternimmt, um ihren Bürgern Root-Zertifikate unterzuschieben, um HTTPS-Verbindungen mitlesen zu können. Bereits imJahr 2015 hatte das Land geplant, ein nationales Sicherheitszertifikat einzuführen, die Pläne aber schnell wieder eingestampft. Vor etwas mehr als einem Jahr hatten kasachische Internetprovider ähnlich wie nun im aktuellen Fall Nutzer dazu aufgerufen, ein Überwachungszertifikat zu installieren.

Und wie schon im vergangenen Jahr reagieren die Browserhersteller nun prompt. Das Zertifikat wird von den Browsern über entsprechende Listen hart blockiert. Die Browser verwalten Blocklisten, mit denen solche Sperren vorgenommen werden können.

Der Beitrag Browser blockieren neues kasachisches Überwachungszertifikat erschien zuerst auf Linux-Magazin.

Google schließt Sicherheitslücken in Chrome

08. Dezember 2020 um 11:18

Mit der neuen Version 87.0.4280.88 des Browsers Chrome hat Google diverse Sicherheitslücken beseitigt.

Die neue Version soll in den kommenden Tagen bei den Nutzern landen. Versionen für Linux, Windows und Mac OS sind verfügbar. Anscheinend waren alle von den Sicherheitsproblemen betroffen.

Wie gewohnt gibt Google keine Details zu den Sicherheitsproblemen bekannt, um nicht ungewollt Angreifer mit Informationen zu versorgen, bevor das Update nicht bei den Nutzern ist. In einer Meldung werden aber drei Sicherheitslücken mit hohem Risiko klassifiziert.

Alle drei Lücken stehen im Zusammenhang mit fehlerhafter Behandlung von dynamischem Speicher. Durch die sogenannten Use-after-free-Bugs, bei denen ein Programm den dynamischen Speicher nicht korrekt freigibt, lassen sich diese Programme eventuell durch Angreifer ausführen. Laut Google stecken die Lücken in Clipboard, Media und Extensions.

Der Beitrag Google schließt Sicherheitslücken in Chrome erschien zuerst auf Linux-Magazin.

Vivaldi mit E-Mail-Client, Feed Reader und Kalender (technische Vorschau)

25. November 2020 um 09:42
Von: jdo

Die aktuelle Snapshot-Version von Vivaldi bietet spannende Neuerungen. Es gibt eine technische Vorschau eines E-Mail-Clients, eines Kalenders und eines RSS Feed Readers. Die Entwickler schreiben allerdings, dass sich diese neuen Funktionen noch in einem Vor-beta-Stadium befinden. Aus diesem Grund sind sie nicht per Standard aktiviert. Mail, RSS und Kalender aktivieren Möchtest Du die neuen Funktionen testen, musst Du sie zunächst aktivieren. Das kannst Du, indem Du in der URL-Zeile vivaldi://experiments aufrufst. Im Anschluss ist ein Neustart des Browsers notwendig. Die […]

Der Beitrag Vivaldi mit E-Mail-Client, Feed Reader und Kalender (technische Vorschau) ist von bitblokes.de.

Porteus Kiosk 5.1.0 aktualisiert Software und bringt Änderungen

14. Oktober 2020 um 10:11

Die Linux-Distribution Porteus Kiosk verwandelt einen Rechner in ein Kiosksystem, bei dem die Nutzer ausschließlich den Browser eingeschränkt verwenden dürfen. Administratoren haben dabei jetzt die Wahl zwischen Chrome 85.0.4183.121 und Firefox 78.3.1 ESR.

Im Hintergrund läuft der Linux Kernel 5.4.70. Die Treiber für Broadcom- und Realtek PHY-Netzwerkchips sind direkt im Kernel enthalten, was wiederum auf entsprechend ausgestatteten PCs das Booten via PXE ermöglicht.

Dank einer Fehlerkorrektur ist das Silent Printing Feature wieder für Firefox verfügbar. Über den Parameter “persistence=wipe” lässt sich das Heimatverzeichnis remote löschen. Die URLs “irc://” und „ircs://“ haben die Porteus-Entwickler in Firefox deaktiviert, um Angreifern keine Angriffsfläche zu bieten. Porteus Kiosk bootet zudem jetzt auch auf einigen weiteren HP-Systemen mit EFI Firmware. Sämtliche Änderungen listet die offizielle Ankündigung auf.

Der Beitrag Porteus Kiosk 5.1.0 aktualisiert Software und bringt Änderungen erschien zuerst auf Linux-Magazin.

Chrome 86 bringt kurze URLs

07. Oktober 2020 um 11:53

Mit der neuesten Veröffentlichung seines Chrome-Browsers in Version 86 führt Google testweise die auf die Domain verkürzten URLs ein. Außerdem gibt es verschiedene kleine Sicheheitsupdates.

Zu letzteren zählt eine Warnmeldung, wenn per HTTPS geladene Webseiten Formulardaten über HTTP verschicken. Stellt Chrome dieses Verhalten bei einer Webseite fest, werden in das Formular auch keine gespeicherten Daten eingetragen (Autofill). Allergisch reagiert Chrome auch auf Downloads von Archiven, PDFs und Dokumenten über HTTP. Auch hier gilt, ist die Webseite über HTTPS geladen worden, der Download aber nicht, gibt es eine Blockade.

Mit der Verkürzung von URLs experimentiert Google schon länger. Nun gibt es in Chrome 86 einen breiter angelegten Testlauf. In der Adresszeile des Browsers ist dann die URL auf die Domain verkürzt. Klickt der Nutzer in die Zeile, sieht er die komplette URL.

Mit dem Passwortschutz will Chrome ebenfalls die Sicherheit erhöhen. Sind in Chrome Passwörter des Nutzers gespeichert, die bereits kompromittiert wurden, etwa bei Datendiebstählen, warnt der Browser und bietet dem Nutzer an, das Passwort auf der entsprechenden Webseite zu ändern. Per Klick kommt der Nutzer dann dorthin, sofern die Entwickler eine URL dafür bereitstellen.

Der Beitrag Chrome 86 bringt kurze URLs erschien zuerst auf Linux-Magazin.

Die beste neue Funktion im neuen Firefox für Android

27. August 2020 um 13:25
Von: jdo

Der neue Firefox für Android wird durchaus kontrovers diskutiert. Das ist aber wohl immer so, wenn sich Dinge grundlegend ändern. Allerdings gibt es eine Funktion, die mir persönlich am beste gefällt. Bilder sagen mehr als 1000 Worte. Ich kann nun die Adresszeile / Symbolleiste an den unteren Bildrand verschieben – erreiche sie also mit dem Daumen, wenn ich das Smartphone in der Hand halte. Das war früher bei Chrome auch möglich und ich verstehe bis heute nicht, warum das geändert […]

Der Beitrag Die beste neue Funktion im neuen Firefox für Android ist von bitblokes.de.

Chrome verursacht 50 Prozent der DNS-Anfragen an Root-Server

25. August 2020 um 10:52

Um gegen DNS-Hijacking vorzugehen, erstellt der Chrome-Browser zufällige Domain-Anfragen. Diese sorgen inzwischen für extrem viel Traffic.

Einer Untersuchung des US-amerikanischen Internetanbieters Verisign zufolge verursacht der Chrome-Browser inzwischen rund 50 Prozent aller Anfragen an die DNS-Root-Server. Diese Angaben beziehen sich auf die von Verisign selbst betriebenen Root-Server und dürften sich so ähnlich wohl auch auf die anderen Root-Server übertragen lassen. Der Untersuchung zufolge, die als Gastbeitrag im Blog des APNIC veröffentlicht wurde, werden damit rund 60 Milliarden DNS-Abfragen an die Root-Server täglich allein durch den Browser verursacht.

Dass dies überhaupt geschieht und aus Sicht des Entwicklungsteam des Chrome-Browsers nötig ist, liegt an einer Kombination verschiedener Eigenheiten des Browsers sowie auch des DNS selbst. So startet die sogenannte Omnibox des Chrome-Browsers, also die zentrale Eingabezeile etwa für URLs, unter Umständen auch automatisch Suchabfragen in der Google-Suchmaschine, wenn eben keine komplette Domain angegeben wird. Der Browser zeigt hier dann alternativ möglicherweise auch einen Hinweis darauf, dass es sich um einen Tippfehler handeln könnte.

Bei derartigen Tippfehlern zeigen viele Internet-Provider jedoch eine eigene Webseite an, wenn die falsch eingegeben Domain nicht existiert. Letzteres wiederum ist nur durch sogenanntes DNS-Hijacking möglich. Statt der eigentlich richtigen Antwort (NXDomain), dass die Domain nicht existiert, liefert der Provider mit der eigenen Webseite eine andere und genau genommen falsche Antwort.

Der Chrome-Browser würde in diesem Fall jedoch ebenfalls ständig seinen Hinweis auf Tippfehler anzeigen. Um dies zu vermeiden, erzeugt der Browser drei zufällige Anfragen für Domains, die eben sehr wahrscheinlich nicht existieren. Erhalten diese jedoch die gleiche IP-Adresse als Antwort, eben weil der Provider diese Antworten umleitet, speichert dies der Browser. Diese Anfragen erzeugen den massiven Netzwerkverkehr an den Root-Servern.

Möglichkeiten, das bisherige Vorgehen des Chrome-Browser zu verändern, sind eher schwierig umsetzbar. In dem Blogeintrag wird etwa vorgeschlagen, diese Domaintests auf eigene Infrastruktur des Browser-Herstellers umzuleiten, statt die Root-Server abzufragen

Der Beitrag Chrome verursacht 50 Prozent der DNS-Anfragen an Root-Server erschien zuerst auf Linux-Magazin.

Chromium und die Root-DNS-Server

24. August 2020 um 18:45

Die APNIC zeigt, dass der Chromium-Browser mit einer unscheinbaren DNS-Probing-Technik mutmaßlich 51 % der DNS-Anfragen ausmacht. Ein Aufruf zum sorgsamen Umgang mit Ressourcen.

Wie schon öfter in meinem Blog praktiziert, beginnen wir das heutige Thema mit einem kleinen Exkurs: in der IT herrscht an vielen Stellen, zumindest früher, der Grundsatz, dass mit Ressourcen behutsam umgegangen wird. Ein gutes Beispiel dafür ist das Unix-Programm nice. Mit dem Programm ist es möglich, die niceness eines Prozesses festzulegen. Je höher der Wert eingestellt wird, desto geringer ist die Gewichtung des Prozesses. Anhand der Gewichtung weist das Betriebssystem dem Prozess entsprechende CPU-Zeit für Berechnungen zu. Je mehr CPU-Zeit der Prozess zugewiesen bekommt, desto schneller kann er eine vorgegebene Eingabe verarbeiten.

Mit nice ist es also möglich, Prozessen eine geringere Gewichtung zuzuweisen. Das macht besonders Sinn, wenn der Prozess eine hohe Arbeitslast, aber geringe Zeitpriorität hat, er also ruhig länger dauern darf. Ein Beispiel wäre das nächtliche Backup: Die Sicherung eines Servers kann somit herab gewertet werden, was dazu führt, dass das Backupprogramm die volle CPU-Zeit ausnutzen kann – sofern nichts weiter auf dem Server los ist (deswegen laufen Backups auch meist nachts). Sind allerdings andere Nutzer und Programme aktiv, wird die CPU-Zeit gemäß der Gewichtung aufgeteilt. Unix-Nutzer können also für ihre Prozesse einstellen, wie nett (= nice) sie zu den weiteren Benutzern sind.

So viel zum Grundsatz. Heute werden wir uns anschauen, dass dieses Prinzip, Ressourcen zu minimieren und andere nicht zu stören, schon durch kleine Codeblöcke massiv gestört werden kann.

Chromiums Innovation

Vor drei Tagen hat sich Matthew Thomas im Blog der APNIC, die für Asien und den Pazifik Netzwerkressourcen, darunter auch die Root-DNS-Server zur Verfügung stellt, zu Wort gemeldet. Er spricht eine interessante Beobachtung an: Eine Funktion vom Chromium-Browser verursacht 51 % des DNS-Traffics der dort verwalteten DNS-Root-Server.

Das Chromium-Projekt wurde vor über zehn Jahren bei Google ins Leben gerufen und bildet neben der eigenen Anwendung auch die Grundlage für Browser wie den Google Chrome oder neuerdings auch den Microsoft Edge. Zusammen erreicht Chromium inklusive der Derivate einen Marktanteil von über 70 %, wenn man dem W3Counter Glauben schenkt.

Chromium hat neben der drastischen Verbesserung der Geschwindigkeit auch viel Wert auf die als Omnibox bezeichnete Adressleiste gelegt. Die Funktionalität ist heute in so gut wie jedem Webbrowser vertreten, wurde zur Einführung allerdings besonders von Google beworben, da die Omnibox viele Suchresultate einblendet.

Die Omnibox...

Drückt man nach der Eingabe in der Adressleiste nun Enter, wird nicht zwangsläufig der eingegebene Begriff als URL aufgerufen: entscheidet die Omnibox, dass der Begriff wahrscheinlich keine URL ist, wird anstelle dessen eine Google-Suche durchgeführt.

Hieraus ergibt sich allerdings ein Problem: Was ist, wenn der eingegebene Begriff, zu dem die Google-Suche durchgeführt wird, in Wirklichkeit eine gültige URL ist? Beispiel "server1": die daraus resultierende URL http://server1/ kann durchaus gültig sein, wenn das DNS, eventuell in Verbindung mit einer sog. DNS-Suchdomäne (also einer automatisch angehängten Domäne bei solchen Suchbegriffen), diesen Namen auflösen kann. Dies ist nicht nur in Unternehmensnetzen verbreitet, sondern auch z. B. in FritzBox-Netzwerken. Wird hier unter Standardeinstellungen z. B. ein Computer "server1" (NetBIOS-Name) genannt, kann dieser unter http://heimpc/ erreicht werden, da intern mit DNS-Suchdomäne die Adresse http://server1.fritz.box/ entsteht, welche durch das FritzBox-DNS aufgelöst werden kann.

Damit die Nutzer weiterhin solche Seiten im Chromium öffnen können, haben sich die Entwickler etwas überlegt: führt eine solche DNS-Abfrage zur einer gültigen IP-Adresse, wird auf der Seite mit den Suchergebnissen oben vom Browser eine Leiste angezeigt, in der „Wollten Sie http://server1/ aufrufen?“ steht. Klickt man auf diesen Link, gelangt man sicher zur URL.

Clever gelöst, oder? Nicht ganz, denn können wir den DNS-Abfragen vertrauen?

... und ihre Probleme ...

Die Antwort lautet: nein. Denn oft werden DNS-Anfragen, deren Übertragung naturgemäß unverschlüsselt erfolgt, manipuliert – und das von vielen Intranets und selbst Internetprovidern. Diese Technik ist als „DNS hijacking“ bekannt und wird für unlautere als auch „gute“ Zwecke durchgeführt, um z. B. bei DNS-Anfragen, zu denen kein DNS-Eintrag (RR) hinterlegt ist, eine Suchseite anstatt einem Fehler vom Browser anzuzeigen. Solche DNS-Anfragen ohne mögliche Antwort werden standardmäßig mit NXDOMAIN beantwortet, hier wird also die NXDOMAIN-DNS-Antwort durch eine DNS-Antwort mit einer IP-Adresse für z. B. die Suchseite ausgetauscht. Dieser Sonderfall von DNS hijacking wird auch als NXDOMAIN hijacking bezeichnet.

Das führt schließlich dazu, dass Chromium bei Providern, die das einsetzen, für jeden Suchbegriff diese Hinweismeldung anzeigt.

... mit pragmatischen Lösungen

Nun setzen die Chromium-Entwickler seit 2010 auf eine eher unkonventionelle Technik, um solche Netzwerke mit eingesetzem DNS hijacking zu erkennen. Werfen wir dazu einen Blick in den Quelltext:

for (size_t i = 0; i < 3; ++i) {
    std::string url_string("http://");
    // We generate a random hostname with between 7 and 15 characters.
    const int num_chars = base::RandInt(7, 15);
    for (int j = 0; j < num_chars; ++j)
      url_string += ('a' + base::RandInt(0, 'z' - 'a'));
    GURL random_url(url_string + '/');
    // ...
}

Chromium generiert hierbei drei Testadressen, die im Grunde genommen keinen Sinn ergeben – und auch möglichst zu einer NXDOMAIN-Antwort führen sollen. Geschieht dies auch, so werden höchstwahrscheinlich alle unbekannten DNS-Anfragen nicht im Stil eines DNS Catch-All umgeleitet und es kann auf die DNS-Antworten für die Hinweisleiste vertraut werden.

Das Problem für die DNS-Root-Server

Jetzt kommen allerdings die DNS-Root-Server ins Spiel. Diese werden in der Regel bei unbekannten Adressen als erstes angefragt, da DNS-Root-Server Auskunft über die DNS-Server der Top-Level-Domains geben können. Soll also der Domainname von beispielsweise v-gar.de aufgelöst werden, wird ein DNS-Server seine Anfrage zuerst an die voreingestellten Root-Server richten und sie fragen, ob Sie bei der Adresse weiterhelfen können. Sie können zwar nicht die IP-Adresse direkt zurückgeben, aber mit der Adresse des DNS-Servers für ".de" weiterhelfen. Diese Server kennen dann den DNS-Server für "v-gar.de" und dieser kann schlussendlich sagen, ob für "v-gar.de" ein Eintrag existiert und wenn ja, welche IP-Adresse zugewiesen wurde. Das DNS ist somit hierarchisch aufgebaut.

Wir können also nun sehen, dass sich speziell bei den DNS-Root-Servern diese Anfragen anhäufen. Mich überrascht es auch, dass es 51 % des gesamten DNS-Anfrageaufkommens sind. Das ist enorm und wird konkret im erwähnten Blogartikel genauer mit Statistiken erörtert.

Ein kritischer Blick

Um nicht voreilige Schlüsse zu ziehen, sollten wir uns vor Augen führen, dass ein solcher Traffic nicht zwangsläufig durch Chromium entstehen muss. So wird auch in den Kommentaren erwähnt, dass eine ähnliche Technik von Malware verwendet wird, um zu erkennen, ob gerade versucht wird, diese zu analysieren.

Trotzdem lässt sich an diesem Beispiel gut vorführen, wie sehr eine jede Codezeile mit Bedacht gewählt werden muss. Die Einführung der Funktion war zu einer Zeit, als Chromium noch einen Marktanteil von gut 10 % hatte. In den nächsten Jahren hat sich der Code durch die Popularität des Chromes und Forks anderer Browser massiv verbreitet, sodass die Funktion auch nicht mehr einfach aus der Welt geschafft werden kann. Die Befürchtungen wurden zwar bereits im Rahmen des Codereviews geäußert, die Funktionalität war aus UI-Gründen allerdings nötig.

Auch der ursprüngliche Autor des Codes hat sich im Blogartikel mit Verständnis geäußert und erklärt, dass die Problematik besonders durch den Einsatz des DNS hijackings durch die Provider erschwert wird und mehrere Versuche seitens der Provider unternommen wurden, die Erkennung zu umgehen.

Alternativen

Aber aus heutiger Sicht gibt es verschiedene Möglichkeiten: so nennt Thomas im Blogpost unter anderem die RFCs 8020 und 7816, die darauf abzielen, NXDOMAIN-Antworten klarer zu gestalten und somit die Anzahl der nötigen Anfragen zu senken. Eine Schwierigkeit dabei ist allerdings, dass alle Beteiligten hier zuarbeiten müssen, damit die angesprochenen Aspekte so umgesetzt werden können.

Eine weitere interessante Variante lässt sich in der RFC 8806 finden, denn hier wird vorgeschlagen, gleich lokal selber einen der genannten DNS-Root-Server zu betreiben, indem man die Root-Zonen, in denen die DNS-Einträge organisiert werden, spiegelt. Hiermit ist in gewisser Weise Hilfe zur Selbsthilfe gegeben, wenn man selber die Last von den DNS-Root-Servern weglenken möchte und Erfahrung im Betrieb von DNS-Servern hat. Entscheidend hierbei: die IANA stellt die notwendigen Zonen-Dateien für den Betrieb eines DNS-Root-Servers auf deren Homepage direkt bereit, alternativ ist es sogar möglich, von ausgewählten DNS-Root-Servern wie b.root-servers.net einen direkten AXFR-Zonen-Transfer über TCP nach der RFC 5936 durchzuführen, sodass man sich ähnlich wie ein Secondary-Nameserver an die Zonen hängt. Ein entscheidender Punkt bei dieser Lösung ist nämlich, dass, wenn wir DNS-Suchdomänen außen vor lassen, die gestellten Anfragen vom Chromium allesamt Top-Level-Domains (TLDs wie .de) sind und die wenigsten dabei zu den von der ICANN zugelassenen TLDs gehören. Ein eigener Root-Server mit den Zoneninformationen kann also diese Entscheidung, ob die TLD gültig ist, also schon im eigenen Netzwerk treffen und möglicherweise schon mit NXDOMAIN antworten. Ausschließlich Anfragen mit gültiger TLD werden dann im öffentlichen Internet weiter bei den Nameservern angefragt. Auch aus Sicht des Datenschutzes eine interessante Lösung.

Hier arbeitet man allerdings in ersten Linie an den Syptomen eines anderen Problems: dem Abweichen vom DNS-Standard. Denn all dieser Aufwand ist ja ursprünglich nur notwendig, da dieses vom Standard abweichende Verhalten zu falsch positiven Abfragen führt.

Und das ist sicherlich ein weiteres Argument für DNS-over-HTTP. Ich selber bin noch nicht ganz davon überzeugt, am Betriebssystem vorbei alle Namensanfragen zur Auflösung von Domains über das HTTP(S)-Protokoll abzuwickeln, aber das ist ein Thema für einen anderen Blogpost. Solche Umstände sind jedenfalls Wasser auf die Mühlen der DoH-Verfechter.

Zusammenfassung

Ressourcen müssen auch in der IT sinnvoll eingesetzt werden. Dies ist nicht nur aus ökonomischer Sicht zu sehen, da diese sicherlich vermeidbaren DNS-Anfragen Traffic verursachen, der bei vielen Providern durch kostenpflichtiges Peering, etc. ins Geld geht. Ressourcen sollten auch sinnvoll genutzt werden, damit Innovation sich proportional zu den Fortschritten der Hardware entwickeln kann – und nicht durch unvorhergesehene Ereignisse Engpässe zustande kommen.

Ressourcen sinnvoll zu nutzen bedeutet allerdings auch, sich an vielen weiteren Stellen Gedanken bei der Entscheidungsfindung zu machen. Wer durch DNS hijacking für eine erzwungene „Komfortfunktion“ andere dazu zwingt, weitere ärgerliche Workarounds zu implementieren, kann dadurch ein Eigentor verursachen, wenn der resultierende Traffic auf Kosten der eigenen Infrastruktur geht.

Chrome-Update schließt Sicherheitslücken

14. August 2020 um 11:26

Google hat ein Update für seinen Webbrowser Chrome angekündigt, das 15 Sicherheitslücken schließt. Der überwiegende Teil davon trägt die Risikoeinstufung “high”.

Zu den Sicherheitsproblemen gibt Google in einem Beitrag zur Release der Chrome-Version 84.0.4147.125 nur wenig bekannt. Sie stecken in den verschiedenen Bereichen, etwa dem Task-Scheduler oder auch in den Extensions und der Media-Verarbeitung. In der Regel entsteht das Problem durch Speicherfehler nach der Use-after-free-Problematik. Google gibt an, die neue Version in den kommenden Tagen bereitzustellen. Bei Linux-Distributionen wie Ubuntu ist das Update bereits in den Repositories.

Von den Patches für die Sicherheitsprobleme profitieren auch die Anwender von Microsofts Browser Edge, der seit Neuestem ebenfalls auf Chromium basiert. Microsoft übernimmt die Patches für seine Browser-Versionen für Windows, iOS und Android.

Der Beitrag Chrome-Update schließt Sicherheitslücken erschien zuerst auf Linux-Magazin.

Adblocker: 80 Millionen Installationen schädlicher Add-ons für Chrome

05. August 2020 um 13:28
Von: jdo

Uff, das ist eine satte Zahl: 80 Millionen Leute hatten angebliche Adblocker für Google Chrome installiert, die in Wirklichkeit Malware eingespeist und anderen Unsinn getrieben haben. Dabei müssen Anwender nicht lange suchen, um die Wölfe im Schafspelz zu finden. AdGuard hat herausgefunden, dass sich bösartige Produkte recht schnell in den Suchergebnissen finden lassen. Sie tauchen schnell auf, wenn der Anwender nach Adblocker und dergleichen sucht. Die Produkte sehen einigermaßen echt aus und da sie im vertrauenswürdigen Chrome Web Store sind, […]

Der Beitrag Adblocker: 80 Millionen Installationen schädlicher Add-ons für Chrome ist von bitblokes.de.

Update für Chrome schließt Sicherheitslücken

29. Juli 2020 um 11:41

Ein Update des Stable Channels von Chrome auf Version 84.0.4147.105 schließt insgesamt acht Sicherheitslücken.

Google will das Update des Chrome-Browsers in den kommenden Tagen und Wochen automatisch verteilen. Aus diesem Grund sind die Sicherheitslücken auch nicht näher beschrieben, um die bis dahin ungepatchten Browser nicht potenziellen Angreifern auszusetzen. Lediglich die Klassifizierung der Bedrohungsstufe der Lücken ist erkennbar und bei sechs davon auf High gesetzt. Zudem sind die betroffenen Bereiche in der Release-Ankündigung genannt.

Die neue Chrome-Version bringt daneben zahlreiche Bugfixes für die einzelnen Plattformen Linux, Windows und MacOS mit. Google hat zudem die Chrome-Version für Android ebenfalls auf 84.0.4147.105 gebracht. Das Update soll ebenfalls in den kommenden Wochen im Play-Store auftauchen, teilt Google mit. Interessierte Entwickler bekommen ebenfalls ein Update, Der Dev-Channel für Chrome listet für Linux seit Neuestem die Version 86.0.4214.2.

Der Beitrag Update für Chrome schließt Sicherheitslücken erschien zuerst auf Linux-Magazin.

Ubuntu Web mit Firefox soll Alternative zu Chrome OS werden

25. Juli 2020 um 08:46
Von: jdo

Weil sich die digitale Welt immer weiter in Richtung Cloud verschiebt, können wir schon sehr viele Dine einfach in einem Webbrowser erledigen. Das gilt für viele alltägliche Aufgaben wie E-Mail, Office-Anwendungen und so weiter. Alleine die Nextcloud kann eine recht ordentliche Zahl von alltäglichen Aufgaben zur Verfügung stellen. Nun wurde Ubuntu Web mit Firefox angekündigt und es soll dem beliebten Chrome OS Konkurrenz machen. Hinter dem Projekt steht allerdings nicht Canonical, sondern der junge Entwickler Rudra Saraswat, der auch für […]

Der Beitrag Ubuntu Web mit Firefox soll Alternative zu Chrome OS werden ist von bitblokes.de.

❌