Googles neues Update-System sorgt für leere Rollouts – bekannte Lücken bleiben länger bestehen

[Spock]

Android: Googles neues Update-System sorgt für leere Rollouts - bekannte Lücken bleiben länger bestehen

Finde ich bedenklich ….

 

[Regentanz]

bedenklich ….

Warum?

 

[swa00]

@Spock

Finde ich bedenklich ….

Ein älteres Update kann durchaus schon aktueller sein, als manche die erst später ausgerollt werden - und ja sie können dann von ihrem Nähwert dann "leer" sein - das ist aber immer schon so gewesen - nichts Neues.
Das kann organisatorische oder technische Gründe haben.

Ergo : Kein relevantes Sicherheitsmerkmal für den Alltag - irgendwann pendelt sich das bei allen Geräten ein.


Mit solchen privat - von einer Person - gepflegten Artikeln sollte man daher immer vorsichtig sein. Insbesondere dann , wenn nicht explizit auf Modelle und Herstellern im Vergleich eingegangen wird.

Und solche Zitate sind dabei eher tendenziös Clickbait, ohne konkret & neutral genanntes Beispiel.

Die Hersteller werden auch weiterhin schlampig arbeiten – warum sollten sie das plötzlich ändern? Dazu kommt allerdings, dass viele Sicherheitslücken und Probleme ungefixt bleiben, obwohl Google diese bekannt sind und die Fixes auch schon fertig in der Schublade liegen. Doch statt das Ökosystem bzw. die einzelnen Geräte zu schützen, lässt man die Lücken offen und hofft darauf, dass diese nicht vorab ausgenutzt werden. Welchen Sinn ergibt das?

 

[Spock]

Dann schau mal was die Graphene-OS Entwickler davon halten

 

[Klaus986]

@Spock Man sollte in diesem Kontext auch einen vorherigen Artikel von diesem Autor mit einbeziehen:

Um Druck herauszunehmen, hat Google ohne jegliche Ankündigung ein ganz neues System eingeführt, das sich „RBUS“ (Risk-Based Update System) nennt – einfach übersetzt auf risikobasiertes Update-System. Statt wie bisher einen Stichtag zu setzen und alle bis dato fertiggestellten Patches in das monatliche Update zu bringen, wird es jetzt einen deutlich längeren Zeitraum geben. Denn die Updates sollen nur noch alle drei Monate – im März, Juni, September und Dezember – veröffentlicht werden. Eine Ausnahme bilden lediglich die hochriskanten Schwachstellen, die weiterhin einmal pro Monat veröffentlicht und ausgerollt werden sollen.

Das bedeutet, dass es zu Beginn eines jeden Monats nur noch Updates für die „hochriskanten Schwachstellen“ gibt oder diese bei akuter Gefahr auch unter dem Monat veröffentlicht werden können. Gibt es in einem Monat keine hochriskanten Schwachstellen, die bereits aktiv ausgenutzt werden, kann das Update auch einmal leer sein. Das bedeutet, dass auch fertig-entwickelte Patches trotz eines veröffentlichten Updates liegenbleiben.

Quelle: Android: Google reduziert die monatlichen Updates - Probleme bleiben bestehen und ein Schlag für das AOSP

 

[swa00]

@Spock

Dann schau mal was die Graphene-OS Entwickler davon halten

Das hat jetzt erst mal nichts mit der Überschrift deines verlinkten Artikels, noch mit deinem Titel zu tun.
(Und darauf bin ich eingegangen)

Das ist nämlich eine ganz andere Baustelle (AOSP)
Und ja, es macht auch mittlerweile durchaus Sinn, den Source nicht mehr während der internen Entwicklungsphase freizugeben, sondern nur auch nur quartalsmäßig.

 

[Klaus986]

@Spock Um dieses Vorgehen korrekt zu beurteilen, sollte man sich am besten die Hintergründe und den Ablauf klar machen:

Schätzungsweise 99% aller Lücken werden entweder von Google selbst oder anderen Devs entdeckt, die mit dem AOSP arbeiten. Von der Entdeckung bis zum fertigen Patch, der in Form eines Updates an die Nutzer weitergegeben wird, vergehen i.d.R. mehrere Monate.
Diese Lücken stellen auch keine reale Bedrohung dar, weil sie immer nur dann ausgenutzt werden können, wenn alle anderen Sicherheitsmaßnahmen, die tief im AOSP oder Kernel integriert sind, umgangen worden sind.

Die restlichen geschätzten 1% (wenn es überhaupt so viel ist) sind aktive Lücken, die ein hohes Risiko darstellen und auch weiterhin sofort gepatcht werden.

Vor diesem Hintergrund sollte das Ganze bewertet werden.

 

[prx]

Und ja, es macht auch mittlerweile durchaus Sinn, den Source nicht mehr während der internen Entwicklungsphase freizugeben, sondern nur auch nur quartalsmäßig.

Ich kann mir das so vorstellen: Wenn man auf der Suche nach Lücken ist, die man ausnutzen möchte, sucht man frische Änderungen im Source, die auf einen Fix hindeuten. So lange der Code noch nicht ausgerollt ist, ist eine damit verknüpfte Lücke ausnutzbar. Erspart Gaunern und Schlapphüten sehr viel Arbeit bei der Suche.

 

[Klaus986]

@prx Das ist alles noch viel einfacher: Die Patches werden dem alten Code im AOSP gegenübergestellt, nachdem sie veröffentlicht wurden. Du musst nicht wirklich danach suchen. Du musst nur ein Gerät finden, dass diesen Patch noch nicht hat und das ist sehr einfach.

Aber wie wir alle sehen, ist es gar nicht ohne weiteres möglich, diese Lücken einfach so auszunutzen. Denn es gibt noch einige Sichermaßnahmen, die dafür im Vorfeld umgangen werden müssen.

 

[prx]

@Klaus986 So hatte mir die Suche vorgestellt, nur weniger technisch ausgedrückt. Sowas kommt aus Source Code / Revision Management Systemen automatisch hinten raus.

 

[Klaus986]

@prx Nur bringt der Code alleine nichts, um wirklich Schaden anzurichten. Daher sind diese Bedrohungsszenarien auch meist nichts weiter als pure Theorie. Die wirklich interessanten und gefährlichen Exploits liegen gut gehütet bei irgendwelchen Regierungen oder Firmen wie Cellebrite.