Linux-Chef: Alle Android-Geräte außer Pixel über den Kernel angreifbar

Der Linux-Kernel wird als eines der wichtigsten Stücke Software überhaupt durchaus immer sicherer. Allerdings bringen alle Bemühungen der Entwickler letztlich nur etwas, wenn die Verbesserungen auch zu den Nutzern durchgereicht werden - was vor ... mehr... Logo, Linux, Maskottchen, Pinguin Bildquelle: Linux Foundation Logo, Linux, Maskottchen, Pinguin Logo, Linux, Maskottchen, Pinguin Linux Foundation

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Was man dazu erwähnen kann, ist dass der Kernel eine sehr strikte Abwärtskompatibilitätspolitik fährt, was Anwendungsschnittstellen betrifft. Änderungen, die dazu führen, dass Anpassungen im Userspace nötig werden, rufen sofort Linus Torvalds auf den Plan (Zitat: "WE DO NOT BREAK USERSPACE!"). Auf einem GNU/Linux-System kann man Kernel-Upgrades praktisch blind durchführen (man muss natürlich immer überwachen, ob alles läuft, wenn man kritische Dienste von einer Maschine bereitstellt, aber ich habe noch etwas etwas gegenteiliges wegen eines Kernel Updates erlebt und Kernel Updates kommen regelmäßig).

Was ist also die Ursache für das Ausführen veralteter Kernels? Basierend auf meiner Linux-Erfahrung fallen mir zwei mögliche Gründe ein:
1) Proprietäre Treiber. Ein Treiber, der als Kernel-Modul ausgeliefert wird, muss für eine bestimmte Kernel-Version gebaut werden (er gehört nicht zum Userspace). Hier können sich die User bei den Treiberentwicklern bedanken, die ihren Source Code proprietär halten (als wäre er so wertvoll für die Konkurrenz, dass sie davon einen Wettbewerbsvorteil erhalten) und keine neuen Binaries für neue Kernel-Releases produzieren. Ferner müssen sich die User bei dem Smartphone-OEM bedanken, der den Komponentenzulieferern dieses Verhalten durchgehen lässt. Würde er das Mainlinen der Treiber für die gekauften Komponenten für einen Kauf voraussetzen, gäbe es für Kernel-Updates überhaupt keinen zusätzlichen Entwicklungsaufwand mehr.

2) Volle Absicht. Der Hersteller will kein Update durchführen, damit User aus Angst um ihre Sicherheit ein neues Gerät kaufen.
 
@dpazra: "rufen sofort Linus Torvalds auf den Plan"
Mal schauen ob das so bleibt, zumindest Linus wird da erst mal nicht mehr aufschlagen, er muss ja unbedingt Wortschatz im federkleid aufbauen

"Kernel-Upgrades praktisch blind durchführen" ist weder mit offenen noch mit "properitären" treibern faktisch so, du argumentiert gegen dich selbst ;)

"Würde er das Mainlinen der Treiber für die gekauften Komponenten für einen Kauf voraussetzen, gäbe es für Kernel-Updates überhaupt keinen zusätzlichen Entwicklungsaufwand mehr. "
Kostet Geld, ist keine sehr große usernachfrage führt zu Desinteresse der OEMs, an dem Zustand haben einzig und allein die User schuld weil es ihnen schlichtweg egal ist
 
@0711: "We do not break Userspace!" ist keine Beleidigung gegen Mitentwickler, religiöse oder ethnische Minderheiten oder sonst etwas. Es steht nichts im CoC, was verlangt, dass die Kompatibilitätsprinzipien über Bord geworfen werden.

Das mit den Kernel-Upgrades sehe ich anders. Ich hatte noch nie eine Regression nach einem apt-get dist-upgrade, die auf den Kernel zurückzuführen war (bei allen Servern, die ich administriert habe), ich habe noch nie von einem Kollegen gehört, dass er eine Userspace Regression durch ein Kernel-Upgrade hatte. Ich sage nicht, dass man apt-get dist-upgrade blind ausführen kann, denn dabei wird ja noch andere Software mitgezogen, aber im Bezug auf den Kernel muss man sich keine Sorgen machen. Es sei denn natürlich, man verwendet proprietäre Kernel-Module.

Es ist nur in dem Sinne die Schuld des Users, wie überhaupt alles die Schuld des Users ist, weil er ja mit seiner Geldtasche anders abstimmen könnte.
 
@dpazra: Das kenne ich auch so. Linux-Kernel-Updates funktionieren eigentlich immer und gehen vor allem auch schnell. Windows Updates hingegen dauern ewig und erzeugen jedes Mal wieder einen Nervenkitzel was danach alles nicht mehr funktioniert.
 
@TiKu: Bei Ubuntu und Co. gibts auch häufig Probleme bei Updates, vielleicht nicht auf den Kernel bezogen, aber auf die restlichen Teile des Systems.
 
@sav: Dafür das ich Ubuntu auf zahlreichen Clinton ausliefern und nicht weniger Server damit betreibe, aber noch nie größere Probleme hatte, kommt mir deine Aussage komisch vor.
 
@dpazra: ja es steht nichts im coc das die über board geworfen werden, Linus wird sie aber mit Gewissheit in nächster zeit nicht mehr so vehemment verteidigen und obs jemand anderes macht, schau mer mal.

Wie viele deiner Server nutzten spezifische Treiber eines Herstellers ob offen oder geschlossen? Vermutlich keiner...ja im userspace macht man selten was kaputt, ändert nichts daran dass man bei selbst eingebundenen treibern da nicht immer ganz stressfrei fährt und hier auch ein auge drauf haben muss
 
@0711: Dann liegt ein Missverständnis vor und wir haben keinen Widerspruch miteinander. Ich meinte genau das: Der Userspace ist in der Regel kein Problem beim Kernel-Upgrade, das Problem sind Kernel-Module, die nicht im Mainline-Tree sind. Das größte Problem sind proprietäre Treiber, da muss man den Hersteller bitten einen neuen zu bauen. Ist der Treiber frei, aber nicht im Tree kann man ihn zumindest in der Regel selbst kompilieren. Die Lösung ist das Mainlining aller Treiber.
 
@dpazra: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8a104f8b5867c682d994ffa7a74093c54469c11f

Grundsätzlich gilt: wir unterlassen alles, wo sich jemand angepisst fühlen könnte.
 
@eshloraque: Das ist eine Projektion und steht nirgendwo. Außerdem ist es eine in sich widersprüchliche Ausage. Leute wären auch angepisst (viel mehr als andersherum), wenn der Kernel links und rechts die APIs zum Userspace kaputt macht. Es ist klar in Linus Kommunikation und im CoC-Text, dass es um den Umgang zwischen Personen geht. Nirgends in diesem Text steht, dass die Maintainer aus irgendeinem Grund einen Patch annehmen müssen. Das bleibt ihre alleinige Entscheidung und an den technischen Grundsätzen der Kernelentwicklung hat sich genau gar nichts geändert.
 
@dpazra: Personen reichen Patches ein. Werden jene abgelehnt kann das auf objektive Gründe oder natürlich Diskriminierung beruhen. Wäre nicht die erste Person, die über solch eine Auslegung stolpert.
 
@eshloraque: "Der Patch ändert das Verhalten gegenüber dem Userspace." ist ein objektiver Grund. Das kann man auch objektiv belegen, indem man einen Bug in einem Userspace-Programm aufzeigt, der vorher nicht bestandt oder indem man zeigt, welche Funktion einen anderen Wert zurückliefert, als vorher.
 
Wenn alles so schlimm und einfach ist, bleibt halt die Frage: Wo bleiben die Angriffe? Wenn es angeblich so leicht ist, wundert es mich doch immer noch das nicht Abermillionen von Android Geräten gehackt und zum Bitcoin Mining, Botnetz und Co. missbraucht werden.
 
@sav: im Gegensatz zu Windows wird auf den allermeisten Geräten kein "Viren"scanner laufen. Und vielleicht werden Millionen Geräte schon missbraucht, das einzige was dem Nutzer auffällt ist: irgendwie hält mein Akku nicht mehr so lang wie früher.
 
@eshloraque: Auch auf Windows wird die Masse der Viren nicht durch irgend welche Virenscanner bei Heimanwendern auffallen sondern eben schon davor, bei den Laboren für Computervirenforschung / den Herstellern entsprechender Sicherheitssoftware. Gäbe es dort also solche Bedrohungen, hätte man diese schon im Labor auf den Honeypot Geräten gefunden / festgestellt.
 
@eshloraque: naja aber es muss ja schon über eine App erfolgen, heißt das man aktiv eine apk installiert die den Trojaner / Schadsoftware enthält. Entsprechendes würde dann auch ständig im Hintergrund laufen.
 
@legalxpuser: Jop, und genau da liegt der Hase. Windows im "S-Mode" ist genauso sicher oder unsicher. Das Problem sitzt heute größtenteils vorm Bildschirm. Dabei reicht natürlich ein Anwender mit ein wenig mehr Rechten, um ganzen Firmennetze zu Fall zu bringen.
 
@sav: 1. woher weißt du was nicht schon lange angegriffen wurde?
2. viele ganz schlimme angriffe gehen meist nur local
3. nicht jeder ist böse und greift ziellos an <- letztenendes ist das auch illegal
4. die leistungen von smartphones sind jetzt nicht der burner, dafür hackt man lieber server :P
5. würde man es merken, wenn man wirklich leistung zieht (so, akkuverbrauch und so)
 
@bear7: Weil bisher eben noch nie eine News Veröffentlicht wurde die in diese Richtung geht. Über Millionen von Kompromittierten Maschinen ließt man doch relativ häufig, über Smartphones bei denen die Menschen teilweise Ihr halbes Leben drauf haben aber eigentlich nie. Nur über potentielle Lücken aber über keine Fälle wo diese wirklich auch ausgenutzt werden.
 
@sav: wie geschreiben... local <- da wird es komplex millionen geräte zu übernehmen ^^
 
@bear7: Lokal kann man aber quasi alles übernehmen. Wenn nicht direkt am PC, dann über andere Maßnahmen um an die entsprechenden Passwörter zu kommen.
Kommentar abgeben Netiquette beachten!
Einloggen

Jetzt als Amazon Blitzangebot

Ab 00:00 Uhr TP-Link Archer T2U NanoTP-Link Archer T2U Nano
Original Amazon-Preis
14,90
Im Preisvergleich ab
13,38
Blitzangebot-Preis
11,90
Ersparnis zu Amazon 20% oder 3