News Google und Microsoft: Sicherheitslücken in Chrome und Edge geschlossen

Es könnte daran liegen, dass Microsoft viele Dinge von Chromium (und Google) nicht 1:1 übernimmt.
Hier ein Beispiel, was es betrifft:
1655027483858.png

Eine von vielen Quellen: https://www.theverge.com/2019/4/8/1...ervices-removed-changed-chromium-edge-browser
 
Zuletzt bearbeitet:
Artikel-Update: Vivaldi schließt Chromium-Sicherheitslücken
Als einer der ersten Chromium-Browser wechselt Vivaldi 5.3 mit dem neuesten Build 2679.55 auf Chromium 102.0.5005.125 und zieht damit mit Google Chrome gleich.

Damit sind die insgesamt sieben Sicherheitslücken, die auch mit Google Chrome v102.0.5005.115 geschlossen wurden, jetzt auch in Vivaldi behoben worden.

Vivaldi 5.3, der nun auch editierbare Symbolleisten bietet, kann wie gewohnt direkt unterhalb dieser Meldung aus dem Download-Bereich von ComputerBase heruntergeladen werden.
 
  • Gefällt mir
Reaktionen: BrollyLSSJ und barmbekersurfer
Nein, die Chromium Entwickler haben dem ganzen ja schon ein #wontfix gegeben - die wird nicht geschlossen. Bzw eigentlich ist das ein Problem auf Betriebssystem Ebene.
 
@kim88
deswegen auch meine Verwirrung. Erst lese ich von einer Lücke, dann vom patchen.
 
Wölkchen schrieb:
Ja und? Qt WebEngine enhält LGPL-Code und muss daher auch in der kommerziellen LTS-Version offengelegt werden und deswegen wird das von mir verlinkte Repo auch weiter aktualisiert.
Bei LGPL müssen aber nur die Bestandteile veröffentlicht werden, die unter LGPL stehen und somit nicht unbedingt der vollständige Code des Projekts.
 
Hallo32 schrieb:
Bei LGPL müssen aber nur die Bestandteile veröffentlicht werden, die unter LGPL stehen und somit nicht unbedingt der vollständige Code des Projekts.
Deswegen ist das auch nur der Code von Qt WebEngine und nicht komplett Qt LTS. Um mehr geht es hier doch gar nicht.
 
Artikel-Update: Auch Microsoft schließt Chromium-Sicherheitslücken
In der Zwischenzeit hat auch Microsoft die Chromium-Sicherheitslücken in seinem Browser Edge geschlossen. Mit der neuesten Version 102.0.1245.41 werden die vier Schwachstellen CVE-2022-2007, CVE-2022-2008, CVE-2022-2010 und CVE-2022-2011 beseitigt.

Die drei übrigen Sicherheitslücken, die mit Google Chrome v102.0.5005.115 geschlossen wurden, sind für Microsoft Edge nicht relevant, da dieser keine Google Dienste integriert hat.

Die neueste Version von Microsoft Edge kann wie gewohnt direkt unterhalb dieser Meldung aus dem Download-Bereich von ComputerBase heruntergeladen werden.
 
  • Gefällt mir
Reaktionen: keepsmiley5750
Artikel-Update: Chrome 103 schließt 14 Sicherheitslücken
Google hat seinen Browser Chrome auf die Version 103.0.5060.53 aktualisiert und damit insgesamt 14 Sicherheitslücken geschlossen. Eine der Schwachstellen wurde dabei als „Critical“, zwei als „High“, drei als „Medium“ und drei als „Low“ eingestuft.

Neben der Desktop-Version für Windows, macOS und Linux wurden auch die Ableger für Android und iOS entsprechend aktualisiert.

Wie so oft werden aus Sicherheitsgründen nicht alle Sicherheitslücken in den Release Notes aufgelistet.


  • CVE-2022-2156, Critical
  • CVE-2022-2157, High
  • CVE-2022-2158, High
  • CVE-2022-2160, Medium
  • CVE-2022-2161, Medium
  • CVE-2022-2162, Medium
  • CVE-2022-2163, Low
  • CVE-2022-2164, Low
  • CVE-2022-2165, Low

Brave zieht als erster Browser nach
Als erster Chromium-Browser ist Brave 1.40.105 ebenfalls auf die neuste Chromium-Basis gewechselt und hat die 14 Schwachstellen damit ebenfalls behoben. Microsoft Edge, Opera und Vivaldi folgen in der Regel innerhalb einer Kalenderwoche auf das neue Chromium-Release.
 
  • Gefällt mir
Reaktionen: slawa.dev und Y2KCertified!
SVΞN schrieb:
Google hat seinen Browser Chrome auf die Version 103.0.5060.53 aktualisiert und damit insgesamt 14 Sicherheitslücken geschlossen. Eine der Schwachstellen wurde dabei als „Critical“, vier als „High“, fünf als „Medium“ und vier als „Medium“ eingestuft.

Sollte das zweite "Medium" vllt. ein "Low" sein?
 
  • Gefällt mir
Reaktionen: SVΞN
Schön zu hören, dass Brave hier an vorderster Update-Front ist. War das nur Zufall, weil sich die Aktualisierungstermine überschnitten hatten, oder ist der immer recht fix?
 
kim88 schrieb:
Chromium Entwickler haben dem ganzen ja schon ein #wontfix gegeben - die wird nicht geschlossen. Bzw eigentlich ist das ein Problem auf Betriebssystem Ebene.
Bis und falls überhaupt da im OS was kommt lehnen sie sich also zurück und scheissen auf die Sicherheit der User.
Und derweil bauen findige Hacker tolle Tools um das auszunutzen.

Ich bin nun aber auch nicht sicher in wie weit AMD Ryzen Pro da ein Vorteil wäre.
Wenn ja würde es AMD gut stehen dieses Feature auch in Konsumer CPUs zu verbauen.
Aber da die Gier bekanntlich größer ist als Nutzen wird das denk auch nix.

Hauptsache Cookie-Shit-Popups beglücken uns täglich.
Wo ja überhaupt noch was ohne Cookies und JS läuft.
 
Naja das Angrissszenario ist sehr konstruiert. Es braucht physischen Zugriff auf den Computer.

Und ja es ist ein Betriebssystem Problem, das kannst du nicht mit einem Browserupdate fixen, falls doch kannst du sicher gerne einen Fix schreiben.
Bei Passwörtern, kann man im Grunde das selbe machen was viele Passwort Manager schon tun: Nämlich das Passwort aus dem RAM manuell nach XY Sekunden rauszulöschen.

Die Session kannst du aber nicht löschen - kannst du schon das würde einfach den Nutzer permanent ausloggen.

Das Betriebsystem oder auch Hardware muss Optionen bieten wie man Werte zwischenspeichern kann, die nicht ausgelesen werden können. Anders geht nicht - und da den Browser Entwickler einen Vorwurf zu machen ist einfach falsche Adresse.
Ergänzung ()

Was Cookies und JavaScript damit zu tun haben ist mir aber ein komplettes Rätsel...
 
Was ich so las
Der Browser speichert sensible Daten wie Passwörter und Cookies, wie beispielsweise Account- und Zugangsdaten, unverschlüsselt im Klartext im Arbeitsspeicher.
ist so gut wie alles unverschlüsselt.

Klar wäre eine Implementierung im OS auch toll.
Leider muss man davon ausgehen dass MS wenn überhaupt es nur in Win11 implementieren wird.

Und warum kann ein Programm so etwas nicht selbst verschlüsseln und ggf. vor dem löschen mit Müll überschreiben.
Möglichkeiten gibt es sicher auch noch andere. Man muss nur wollen.
 
@cbtestarossa wohin soll er es sonst speichern? Du gibst diese Daten unverschlüsselt in ein Formular ein, die Werte müssen also zu diesem Zeitpunkt im Klartext vorliegen.

Wie bereits erwähnt, theoretisch könnte man Browser dazu trimmen ähnlich wie gewisse Passwort Manager, dass er die Passwörter wieder aus dem Arbeitsspeicher löscht.
Das funktioniert aber nicht mit den Sessions - und wäre daher kein richtiger Fix und wenn überhaupt nur eine Symptombekämpfung.

Betriebsysteme müssen eine Möglichkeit bieten wie man Daten zwischenspeichern kann die nicht ausgelesen werden können.

Ähnlich wie die Security Chips in iPhones/MacBooks wo Daten von Gesichts- oder Fingerabdruckentsperrung hinterlegt sind - die von niemanden gelesen werden können.

Da brauch tes aber entsprechende Hardware (evtl kann man sowas mit TPM abbilden) und entsprechende Funktionen im Betriebssystem.

Mit Cookies und JavaScript hat das immer noch nichts zu tun. Gerade Cookies konnte ich und kann ich immer lesen wenn ich Zugriff auf deinen Rechner habe.
 
Betriebsysteme müssen eine Möglichkeit bieten wie man Daten zwischenspeichern kann die nicht ausgelesen werden können.
Aber wenn zB der Browser selbst solche Daten verschlüsselt speichert dann kann doch von außen her niemand klartext lesen oder?
Eventuell wäre eine Sandbox oder VM Technik dafür geeignet den Speicher nur für ein jeweiliges Programm zugänglich zu machen.
Das kann doch nicht so schwer sein zu realisieren.
 
kim88 schrieb:
Naja das Angrissszenario ist sehr konstruiert. Es braucht physischen Zugriff auf den Computer.
Nein, warum? Du musst "nur" in der lage sein ein Programm unter dem selben user auszuführen, wie der Browser. Aber ein legitimer Einwand bei all solchen Schwächen ist halt: Wenn es soweit gekommen ist, dann kann mans dem Angreifer vielleicht noch schwerer machen, aber weder kannst du deinem System noch vertrauen, noch kannst du den Abfluss von Daten komplett verhindern.

cbtestarossa schrieb:
Aber wenn zB der Browser selbst solche Daten verschlüsselt speichert dann kann doch von außen her niemand klartext lesen oder?
Die Daten müssen aber um genutzt zu werden irgendwo im Klartext vorliegen. Das ist das Kernproblem bei der Sache. Was der Browser tun kann (und meiner Meinung nach sollte) ist die Zeit zu minimieren in der Passwörter im Klartext vorliegen (wobei vermutlich es garnicht so leicht ist sicher zu gehen, dass wirklich alle Kopien wieder gelöscht sind) und deren Auffinden erschweren. Was da in der Praxis gemacht wird und was man noch machen könnte bzw. wie viel mehr an Sicherheit es bringen würde: K.A.

cbtestarossa schrieb:
Eventuell wäre eine Sandbox oder VM Technik dafür geeignet den Speicher nur für ein jeweiliges Programm zugänglich zu machen.
Das kann doch nicht so schwer sein zu realisieren.
Wenn Browser ne UWP App wäre, dann wäre genau das vermutlich der default case (zumindest können UWP Apps nicht ohne weiteres den Speicher andere Apps auslesen. Ich weiß nicht, ob das umgekehrt genauso gilt). Aber das wollen die Leute ja nicht, weil sie dadurch in ihren Freiheiten eingeschränkt werden - oder so ähnlich (etwas polemisiert ausgedrückt. Natürlich gibts gute, Valide Argumente dafür und dagegen).
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: kim88
In wie fern ist diese Lücke relevant für Chrome OS selbst ?

Ich habe jetzt die Versionsnummer : Version 102.0.5005.125

Die xxx103 kam bisher noch nicht an hier.

Mein Gerät selbst ist ein Lenovo Chromebook S 330

Er sagt mir:

Firmwareupdates für externe Geräte​

All firmwares are up to date
 
Mir scheint, das ich seitdem den 0 byte crdownload bug habe, auf bestimmten Webseiten.
 
Richtig ärgerlich ist der GPO Bug, den Google mit der Version 103.0.5060.53 eingeführt und mir der neusten Version 103.0.5060.66 offenbar wieder beseitigt hat. Denn der Fehler ist jetzt auch im Edge 103.0.1264.37 vorhanden und wurde bisher nicht von Microsoft gefixt.

Dabei "vergisst" der Browser quasi bei jedem GPO Refresh die ganzen Policies. Abhilfe schafft ein Neustart des Browsers oder der Aufruf der Seite edge://policy und dort ein Reload der Policies (man sieht dann dort auch, dass die Policies vorher leer sind).

Bis ich darauf gekommen bin, dass es sich um einen Bug des Browsers handelt 😤
Ich hatte leider ziemlich zeitgleich zur neuen Version die aktualisierten ADMX Files eingespielt und die neuste Security Baseline GPO importiert. Außerdem noch einige GPOs anders verlinkt und Prioritäten verändert. Da habe ich natürlich gedacht, dass ich den Fehler verursacht hätte. So etwas Dämliches! 🤬
 
Zurück
Oben