Christoph Schmees

Christoph Schmees

3 weeks ago • •

Christoph Schmees
3 weeks ago • •

Android-Updates 2025-12 — und die Lehren daraus

Mit den Dezember-Updates flickt Google insgesamt 107 Sicherheitslücken in Android und in der darunter liegenden Firmware. Zwei von denen sind Zero-Day Sicherheitslücken, die bereits ausgenutzt wurden/werden. Und zwar, so die offizielle Formulierung, für "begrenzte, gezielte Angriffe". Will sagen, es handelt sich um Hintertüren, die von staatlichen Akteuren (oder einschlägigen Firmen wie Cellebrite) gegen Zielpersonen ausgenutzt werden. So weit ich das verstehe, stecken die Sicherheitslücken im Open-Source AOSP, betreffen also auch alle darauf aufbauenden

pc-fluesterer.info/wordpress/2…

#Allgemein #Empfehlung #Hintergrund #Mobilfunk #Warnung #0day #android #cybercrime #exploits #google #hersteller #hintertür #smartphone #UnplugTrump #wissen

Android-Updates 2025-12 — und die Lehren daraus | pc-flüsterer bremen

^{www.pc-fluesterer.info}

This entry was edited (3 weeks ago)

in reply to Christoph Schmees

caravantravellers 🌈

in reply to Christoph Schmees • 3 weeks ago • •

Da war wohl vorher viel zu wenig Qualitätskontrolle am Werk. Das gilt sehr häufig in der IT. Es geht zu oft um "time to market".

in reply to caravantravellers 🌈

Christoph Schmees

in reply to caravantravellers 🌈 • 3 weeks ago • •

Ja, das ist die wohlwollende Betrachtung.
Dann erkläre mir doch mal, wieso der zweit platzierte im Markt (Qualcomm) Größenordnungen mehr "Sicherheitslücken" produziert als der erste (MediaTek).

in reply to Christoph Schmees

GrapheneOS

in reply to Christoph Schmees • 3 weeks ago • •

@caravantraveller A higher number of CVEs assigned by a company acknowledging vulnerability fixes in their products does not indicate they're less secure. In fact, you have this quite backwards. MediaTek has atrocious security and doesn't have anywhere near the level of care being put into security as Qualcomm. Qualcomm putting a lot of effort into finding and fixing vulnerabilities is a good thing. Not doing quiet fixes without it acknowledged + fixes propagated is a good thing.

@caravantravellers 🌈

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 3 weeks ago • •

@caravantraveller Android and Qualcomm assign a CVE to every High and Critical severity security vulnerability they fix in practice. Other companies avoid doing it exactly because of how you're portraying it. They prefer silently fixing issues and not informing people about them because it's better for public perception. If you're going to count CVEs to judge security that's rewarding not investing resources in finding/fixing vulnerabilities and especially quietly fixing them.

@caravantravellers 🌈

in reply to Christoph Schmees

GrapheneOS

in reply to Christoph Schmees • 3 weeks ago • •

The December 2025 bulletin is for the past 3-4 months of patches listed in 1 month, not 1 month of patches. There were no patches for AOSP in the December 2025 bulletin which weren't already patched in the GrapheneOS security preview releases at least a month earlier and most were patched in December. Counting CVEs in the way that's being done there is also nonsense. Most projects avoid assigning them.

ASB in split into AOSP (01) and Linux + driver/firmware patches (05).

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 3 weeks ago • •

Here's a list of CVE assignments for the Linux kernel by the Linux kernel project itself:

lore.kernel.org/linux-cve-anno…

Linux isn't even assigning CVEs to all the patched vulnerabilities let alone all the discovered vulnerabilities. They assign them based on patch backports to stable / longterm branches.

Most projects don't assign CVEs to each security issue they fix and only a tiny subset of security bugs have them assigned. Misuse of assigned CVEs like this is why.

linux-cve-announce.vger.kernel.org archive mirror

^{lore.kernel.org}

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 3 weeks ago • •

The Linux kernel project doesn't allow others to assign CVEs for legitimate vulnerabilities. They act as their own CNA and invalidate CVEs assigned for actual vulnerabilities assigned by others. They assign all the CVEs themselves based on what gets backported. The portion which get backported are a subset of what gets fixed. That's a subset of what gets publicly discovered/disclosed. There are many unpatched security vulnerabilities found via fuzzers which are publicly reported.

in reply to Christoph Schmees

Janik Besendorf

in reply to Christoph Schmees • 3 weeks ago • •

"Hintertüren" impliziert, dass die da absichtlich eingebaut wurden. Das ohne Belege zu behaupten ist unseriös.

in reply to Janik Besendorf

Christoph Schmees

in reply to Janik Besendorf • 3 weeks ago • •

@besendorf
Gerichtsfest beweisen können wird man das niemals. Aber es gibt so viele Indizien, dass kaum eine andere Erklärung möglich ist.
Qualcomm: Allein die schiere Anzahl im Vergleich mit MediaTek ist verdächtig: social.tchncs.de/@PC_Fluestere…
Hinzu kommt die Art der Schwachstellen. Oftmals sind die so beschaffen, dass man mit einem BESTIMMTEN passend gedrechselten Input den Fehler triggern kann. Wenn du dir mal die Details einiger Fehlerbeschreibungen ansiehst, wirst du das auch finden.
MaW: Wer den Schlüssel (den präparierten Input) kennt, kommt rein.
Auch die Zero-Days in Android kann man schwerlich durch Zufall finden, sondern man muss sie vorher kennen. Wer kennt die? Die werden meist erst öffentlich, wenn sie auffallen, weil sie in Angriffen ausgenutzt wurden.

@Janik Besendorf

in reply to Christoph Schmees

GrapheneOS

in reply to Christoph Schmees • 3 weeks ago • •

@besendorf A higher number of CVEs assigned by a company acknowledging vulnerability fixes in their products does not indicate they're less secure. In fact, you have this quite backwards. MediaTek has atrocious security and doesn't have anywhere near the level of care being put into security as Qualcomm. Qualcomm putting a lot of effort into finding and fixing vulnerabilities is a good thing. Not doing quiet fixes without it acknowledged + fixes propagated is a good thing.

@Janik Besendorf

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 3 weeks ago • •

@besendorf Android and Qualcomm assign a CVE to every High and Critical severity security vulnerability they fix in practice. Other companies avoid doing it exactly because of how you're portraying it. They prefer silently fixing issues and not informing people about them because it's better for public perception. If you're going to count CVEs to judge security that's rewarding not investing resources in finding/fixing vulnerabilities and especially quietly fixing them.

@Janik Besendorf

in reply to Christoph Schmees

Kachelkaiser

in reply to Christoph Schmees • 3 weeks ago • •

laut deiner Aussage sind alle Roms die auf AOSP basieren nicht vertrauenswürdig. Dann sind das eigentlich alle, denn alle basieren auf AOSP, auch Samsung etc. Alle sind auf die Patches von Google angewiesen.

Google verwendet seit der Pixel 6 Reihe 2021 keine Qualcomm Prozessoren mehr, sondern eigenentwickelte Tensor Prozessoren. Somit sind die Lücken der QC-Prozessoeren für Pixel Geräte nicht relevant.

Warum bist du mit deinem Phone mit QC-Protessor auf der sicheren Seite?

This entry was edited (3 weeks ago)

in reply to Kachelkaiser

Christoph Schmees

in reply to Kachelkaiser • 3 weeks ago • •

@Kachelkaiser
Das stimmt, kein AOSP basiertes ROM ist vertrauenswürdig. Deshalb wird ja an echtem Linux gearbeitet.

Stimmt auch: Der Prozessor ist schon länger nicht mehr von QC, aber das Baseband. Auch dort stecken "Sicherheitslücken". Google will erst mit dem Pixel 10 von Qualcomm (oder Samsung) weggehen. technode.com/2024/12/17/google… Wie der aktuelle Stand ist, weiß ich nicht. Meinen Blogbeitrag habe ich entsprechend nachgebessert.

Mit dem QC in meinem Shift6mq bin ich nicht "auf der sicheren Seite", sondern so sicher oder eben unsicher wie alle Geräte, die QC enthalten. Da ich - vermutlich - keine Zielperson bin, also sicher, weil iodé darauf läuft.

Google Pixel 10 to ditch Qualcomm and Samsung modems in favor of MediaTek in 2025: report

Google's flagship Pixel 10 series smartphones will reportedly switch from Qualcomm and Samsung modem chips to MediaTek's in 2025, according to an

^{TechNode Feed (TechNode)}

@Kachelkaiser

This entry was edited (3 weeks ago)

in reply to Christoph Schmees

GrapheneOS

in reply to Christoph Schmees • 3 weeks ago • •

@Kachelkaiser Android is a real Linux distribution. Android Open Source Project provides dramatically better privacy and security than desktop Linux distributions. Investing substantial resources into finding and fixing vulnerabilities is a positive thing, not a negative as you're portraying it. Assigning CVEs to anything deemed to be a High and Critical severity vulnerabilities instead of quietly fixing and not backporting it is a good thing. Most projects don't acknowledge it.

@Kachelkaiser

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 3 weeks ago • •

@Kachelkaiser iodéOS has extraordinarily poor privacy and security. It doesn't keep up with the current privacy and security patches. It lags weeks to months behind official dates which are months behind when it's disclosed to OEMs and allowed to be fixed. March 2026 Android Security Bulletin patches are largely available and allowed to be shipped, contrary to what you likely believe based on the date of the bulletins. Shiftphone and iodéOS have much worse security, not better.

@Kachelkaiser

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 3 weeks ago • •

@Kachelkaiser Most of what's written at discuss.grapheneos.org/d/24134… applies to a Shiftphone with iodéOS. We link to information from Divested Computing and Mike Kuketz on /e/ there and both have similar articles about iodéOS. iodéOS lags far behind on AOSP, kernel, driver and firmware patches, although not quite as much as /e/ does. Both /e/ and iodéOS set an inaccurate Android security patch level despite not having all the patches for it and downplay the major issues.

Devices lacking standard privacy/security patches and protections aren't private - GrapheneOS Discussion Forum

GrapheneOS discussion forum

^{GrapheneOS Discussion Forum}

@Kachelkaiser

in reply to GrapheneOS

GrapheneOS

in reply to GrapheneOS • 3 weeks ago • •

@Kachelkaiser Look at lore.kernel.org/linux-cve-anno… for the Linux kernel itself and bear in mind that's only the subset they backported to the stable/longterm releases. Compare the number of vulnerabilities patched in the Linux kernel itself to the counts you're using for firmware and drivers for Snapdragon. There are wildly higher number of CVEs for the upstream Linux kernel itself. CVE counts mean very little and it's a good thing to acknowledge security patches, not a bad thing.

linux-cve-announce.vger.kernel.org archive mirror

^{lore.kernel.org}

@Kachelkaiser

⇧