Sicherheitsupdate für Chromium.

[slu]

Ich werde so langsam mit dem Chromium unsicher, derzeit läuft auf meinem Debian Stretch 64.0.3282.119, die ist vom Januar 2018.
https://chromereleases.googleblog.com/2 ... op_24.html

Ich verfolge den Browser nicht so sehr, einige meiner User möchten den verwenden, aber mir kommt das schon sehr alt vor.
Gab es seither keine Security Fixes?

[breakthewall]

Ich werde so langsam mit dem Chromium unsicher, derzeit läuft auf meinem Debian Stretch 64.0.3282.119, die ist vom Januar 2018.
https://chromereleases.googleblog.com/2 ... op_24.html

Ich verfolge den Browser nicht so sehr, einige meiner User möchten den verwenden, aber mir kommt das schon sehr alt vor.
Gab es seither keine Security Fixes?

Klingt etwas übertrieben. Die Version von Chromium ist für Debian-Stable völlig in Ordnung. Diese wird ebenso mit Sicherheitsupdates versorgt, was auch mittels "apt changelog PAKETNAME" überprüfen kannst. Und nicht zuletzt kannst deinen Browser auch mittels Firejail oder AppArmor isolieren, um mögliche Sicherheitsprobleme präventiv einzudämmen.

Code: Alles auswählen

apt install firejail
firejail chromium

[NAB]

Klingt etwas übertrieben. Die Version von Chromium ist für Debian-Stable völlig in Ordnung. Diese wird ebenso mit Sicherheitsupdates versorgt,

Wird sie nicht. Debian spielt einfach eine höhere Version ein, wie hier:
https://security-tracker.debian.org/tra ... -2018-6054
62 -> 64
Und wenn ich mir die Liste der offenen Fehler so angucke:
https://security-tracker.debian.org/tra ... um-browser
scheint sich da seit Ende Januar nichts mehr getan zu haben.
Version 65 schließt etliche davon:
https://chromereleases.googleblog.com/2 ... sktop.html
Die ist seit Anfang März verfügbar - nur nicht bei Debian.

[breakthewall]

Wird sie nicht. Debian spielt einfach eine höhere Version ein, wie hier:
https://security-tracker.debian.org/tra ... -2018-6054
62 -> 64
Und wenn ich mir die Liste der offenen Fehler so angucke:
https://security-tracker.debian.org/tra ... um-browser
scheint sich da seit Ende Januar nichts mehr getan zu haben.

Es werden nicht nur höhere Versionen eingespielt. Das hängt auch davon ab, ob es für bekannte Probleme auch offizielle Patches gibt. Wenn nicht dann wird das Security-Team (DSA) von Debian von sich aus aktiv, sofern jene Sicherheitslücken auch akut gefährlich sind. Ansonsten sind Maintainer auch nur Menschen, womit Aktualisierungen je nachdem etwas dauern können. Es wird ja nicht direkt über den Entwickler aktualisiert. Daher auch die Empfehlung mit der Sandbox, was eigentlich nie verkehrt ist, da es immer Sicherheitslücken geben wird.

Version 65 schließt etliche davon:
https://chromereleases.googleblog.com/2 ... sktop.html
Die ist seit Anfang März verfügbar - nur nicht bei Debian.

Diese Version existiert bereits in Debian-Unstable. Von daher kann es nicht mehr lange dauern, bis das in Debian-Stable erscheint.

[NAB]

Wenn nicht dann wird das Security-Team (DSA) von Debian von sich aus aktiv, sofern jene Sicherheitslücken auch akut gefährlich sind.

Also auf anderen Platformen spielt man einfach eine Version ein, die die bekannten Sicherheitslücken nicht mehr hat, während man bei Debian darauf warten muss, dass das DSA-Team ausgeknobelt hat, ob die Sicherheitslücken für den individuellen Anwendungsfall auch gefährlich sein könnten ... nunja.

Sichert firejail inzwischen eigentlich irgendwie gegen Spectre ab?

[RobertDebiannutzer]

65 existiert schon seit dem 20.02. in unstable:
https://tracker.debian.org/pkg/chromium-browser
Wie man sieht, ist sogar schon 66 längst in unstable.
Die Maintainer werden sich sicher was bei denken und ich würde ihnen mehr vertrauen als Google.

(Außerdem: wer einen browser von google verwendet, braucht sich um Sicherheit eh keine Gedanken zu machen... )

[NAB]

Die Maintainer werden sich sicher was bei denken und ich würde ihnen mehr vertrauen als Google.

Ich bezweifele weder, dass die Maintainer sich was denken, noch, dass sie sehr bemüht sind. Es sieht mir eher so aus, als ob sie nicht hinterherkommen ... ähnlich wie bei Firefox damals.

Übrigens müssen auch die Maintainer Google vertrauen ... darauf dass Google sämtliche Sicherheitslücken auch deutlich per CVE oder anderweitig dokumentiert, inklusive Patch. Andernfalls müssen sie jegliche Code-Änderung auf eigene Faust darauf hin abgrasen, ob sie vielleicht (auch) eine Sicherheitslücke schließt.

[tobo]

(Außerdem: wer einen browser von google verwendet, braucht sich um Sicherheit eh keine Gedanken zu machen... )

Unsarkastisch betrachtet ist das völlig korrekt - problematisch sind die datenschutztechnischen Details. Aber Firefox ist da ja auch schwer am aufholen. Die wären in dem Punkt eigentlich heute schon fast gleich unbrauchbar, wenn man Firefox nicht noch so großzügig umkonfigurieren könnte!?

[breakthewall]

Also auf anderen Platformen spielt man einfach eine Version ein, die die bekannten Sicherheitslücken nicht mehr hat, während man bei Debian darauf warten muss, dass das DSA-Team ausgeknobelt hat, ob die Sicherheitslücken für den individuellen Anwendungsfall auch gefährlich sein könnten ... nunja.

Sichert firejail inzwischen eigentlich irgendwie gegen Spectre ab?

So war das eigentlich nicht gemeint. Zumal seitens Debian nur dann eingegriffen wird, wenn es für Sicherheitslücken noch keine korrigieren Versionen gibt, bzw. wenn das Security-Team selbst Sicherheitslücken findet. Das ist doch an sich etwas Gutes, gerade wenn akut Handlungsbedarf besteht. Und anhand veröffentlichter CVEs ist auch ersichtlich, welche Sicherheitslücken eine besonders hohe Priorität haben. Da wird eher nichts ausgeknobelt.

Und was Spectre angeht, so ist das eine reine Baustelle für GCC, den Linux-Kernel, und muss via CPU-Microcode bzw. mittels verbesserter CPU-Architektur adressiert werden. Hier wäre Firejail die falsche Adresse. Wobei Firejail ohnehin auf Technologien basiert die der Linux-Kernel zur Verfügung stellt, und damit unmittelbar davon abhängig ist. Mittlerweile existieren ja schon einige wirksame Gegenmaßnahmen, nur Spectre v1 wird auf längere Sicht ein Problem bleiben. Zumal das Problem derart umfassend ist, dass immer wieder neue Angriffsvektoren auftauchen können, wo man kaum drum herum kommt die CPU-Architektur zu ändern. Nur das ist auch wieder so eine Sache, weil das zugrundeliegende Problem, die spekulative Ausführung, insbesondere für ein erhebliches Plus an Geschwindigkeit sorgt, und nicht mal eben komplett ausgeschaltet werden kann. Daher sehen die Gegenmaßnahmen im Linux-Kernel unter anderem auch vor, besondere Bereiche die davon betroffen sind, von der spekulativen Ausführung auszuschließen.