Apps senden heimlich Daten raus

Es geht hier also um Apps, die Daten leaken. Diese Apps sind selbst installiert, man könnte - aber auch nur "könnte" - den Leuten jetzt vorwerfen, das sie der App diese Rechte gegeben haben.

Einen anderen Aspekt bei der Sicherheits-Duskussion haben wir hier bisher aber außer Acht gelassen: Fehler im Betriebssystem.

In FroYo 2.2 gibt's zum Beispiel 'n Bug im Browser, der sämtliche gespeicherte Passwörter an eine Webseite übermittelt, wenn man sie aufruft. Dumm, oder?
Google hat reagiert und 2.2.1 herausgegeben. Damit ist das Problem behoben.

Aber auch 2.1 und ältere Versionen hatten bugs. Was machen also die Leute, die von ihrem Provider oder Hersteller kein Update mehr bekommen? Die haben Sicherheitslücken auf ihren Geräten. Und die bleiben auch da, die Lücken.

Die sich daraus entwickelnden Szenarien gefallen mir garnicht:
Man besucht eine präparierte oder verseuchte Webseite Durch einen Bug wird unbemerkt Software installiert Viele teure Anrufe in der DomRep Extrem hohe Telefonrechnung.

Und jetzt wiederleg' mal den Provider, der Deine 3000€ aus der Telefonrechnung haben möchte.

Oder, etwas polemisch, aber theoretisch möglich:
Schnell eine App mit adb installiert, die App gab's ja auf XDA - muss also OK sein Handy vertreibt im Internet Musik.

So, und jetzt wiederleg' mal den Ankläger, der Dich als Filesharer hinstellt. Klar, in dubio pro reo. Gibt's de facto nur nicht immer, gab's neulich mal 'n Artikel in c't dazu.

Zitat von marktwain

Man besucht eine präparierte oder verseuchte Webseite Durch einen Bug wird unbemerkt Software installiert Viele teure Anrufe in der DomRep Extrem hohe Telefonrechnung.

Halte ich an sich für unmöglich, da man beim Installieren von Software die Rechtevergabe jedesmal bestätigen muss, sonst bekommt die "unbemerkt" installierte App keine Rechte in ihre Sandbox gelegt ^^

Zitat von Frittenpiekse

Halte ich an sich für unmöglich, da man beim Installieren von Software die Rechtevergabe jedesmal bestätigen muss, sonst bekommt die "unbemerkt" installierte App keine Rechte in ihre Sandbox gelegt ^^

Prizipiell richtig, nur wenn's nen Bug gibt und jemand einen 0day exploit ausnutzt der das ermöglicht? VMware hatte mal was ähnliches, da konnte eine VM durch 'n Bug ausbrechen und vollständig auf das Host-Dateisystem zugreifen.
Theoretisch möglich, oder?

Zitat von marktwain

Prizipiell richtig, nur wenn's nen Bug gibt und jemand einen 0day exploit ausnutzt der das ermöglicht? VMware hatte mal was ähnliches, da konnte eine VM durch 'n Bug ausbrechen und vollständig auf das Host-Dateisystem zugreifen.
Theoretisch möglich, oder?

Also theoretisch schon. Aber das ist nicht so einfach vergleichbar. VMWare war darauf ausgelegt, bei Bedarf auf das Host-Dateisystem zugreifen zu können, bei Android ist es ja genau anders rum.
Die App wird ja nicht in die Sandbox installiert, sondern darin ausgeführt. Und die Sandbox stellt dann das/die Api zur Verfügung. Eine App die sich also heimlich installiert, ist auch erst mal auf die Sandbox beschränkt und die Sandbox öffnet dann entsprechend auch die Rechteabfrage.

Das was natürlich passieren könnte, ist das etwas wie ein "Jailbreak" gefunden wird, also die Möglichkeit direkt einen Dienst auf Systemebene außerhalb einer Sandbox zu starten. So was wäre auch mit einer Sicherheitslücke im Browser möglich, oder mit Sicherheitslücken in anderen Apps.

Aber das ist alles schon weit weg von dem Problem. Auch das es sich um Gratis Apps handelt macht es nciht besser, das ist eigentlich ein ziemlich billiges Argument. Die Entwickler werben mit der App-Funktion und nicht mit der Werbung die dahinter steht. Nach dem Motto "es ist doch klar, das die sich irgendwie anders finanzieren müssen" entspricht nicht unbedingt einem Kaufvertrag/Lizenzvertrag den man auch bei Gratisapps eingeht.

Natürlich sehe ich vor der Installation einer App, auf welche Dienste sie zugreifen kann. Ich habe aber keine Möglichkeit herauszufinden, was diese App mit diesen Diensten anstellt. Dabei ist es völlig egal ob die App kostenlos oder kostenpflichtig ist. Sprich: dass Freeware- und Verdienst-Argument zieht hier überhaupt nicht. Bei namhaften Apps wie Navigon, CoPilot, LauncherProPlus … werden eine Menge Dienste angezeigt. Bei den meisten aufgeführten Diensten ist mir völlig klar, warum diese Apps darauf zugreifen oder zugreifen müssen. Navigon hat Zugriff auf meine Kontakte- klar ich möchte den Luxus, dass ich direkt zu einem meiner Kontakte geleitet werde ohne das ich mir die Adresse aufschreibe um Sie dann im Navigon einzutippen- oder alternativ das Ganze per copy & paste realisiere. Somit habe ich „eigentlich“ kein Problem der Installation zuzustimmen. Aber wer sagt mir, dass Navigon meine Kontakte, meine GPS-Daten und sämtliche Netzwerkkommunikation nicht missbräuchlich verwendet? Hier bleibt nur eins, Userwertungen lesen, oder wie im Fall Navigon auf eine jahrelange gute Erfahrung vertrauen. Ich glaube nicht, dass die oben genannten Apps mich ausspionieren. Sollte das die Runde machen, dann sinkt das Vertrauen in diese Apps derart, dass die sich gleich vom Markt verabschieden können. Und ich glaube, dass die Entwickler der genannten Apps so clever sind, dass sie wissen, dass sie über den Verkauf der Apps mehr Geld verdienen können als über Datenweitergabe, geschweige denn möchte ich den Entwicklern auch nicht unterstellen derartige Gedanken zu hegen. Argumente wie, wenn du dich für ein offenes System entscheidest dann gehst du auch gewisse Risiken ein, finde ich etwas platt. Weil ich der Meinung bin, dass dir das auf jedem System passieren kann.

Zitat von thp

Argumente wie, wenn du dich für ein offenes System entscheidest dann gehst du auch gewisse Risiken ein, finde ich etwas platt. Weil ich der Meinung bin, dass dir das auf jedem System passieren kann.

Genau so ist es. Und genau das führt zu meinem Punkt:
Auf anderen Systemen werden zeitnah Informationen und Patches bereitgestellt.
Informationen gibt Google nicht heraus (weder Security Bulletins noch Changelogs) und Patches gibt's wenn Dein Hersteller 'ne neue Firmware bereitstellt.
Und wenn der das nicht tut? Dann bleibt die Sicherheitslücke auf Euren Handies drauf.
Das Handy hat dann ungeschützt Verkehr *g
Aber so lustig ist das garnicht mal, denn damit wird surfen zu einem finanziellen Risiko.

Jeder sollte für sich die Frage beantworten: Wie wahrscheinlich ist es, das die Sandbox 100% bugfrei programmiert ist?

Zitat von marktwain

Genau so ist es. Und genau das führt zu meinem Punkt:
Auf anderen Systemen werden zeitnah Informationen und Patches bereitgestellt.
Informationen gibt Google nicht heraus (weder Security Bulletins noch Changelogs) und Patches gibt's wenn Dein Hersteller 'ne neue Firmware bereitstellt.
Und wenn der das nicht tut? Dann bleibt die Sicherheitslücke auf Euren Handies drauf.
Das Handy hat dann ungeschützt Verkehr *g
Aber so lustig ist das garnicht mal, denn damit wird surfen zu einem finanziellen Risiko.

Jeder sollte für sich die Frage beantworten: Wie wahrscheinlich ist es, das die Sandbox 100% bugfrei programmiert ist?

Ich glaube, dass du hier zwei Probleme vermischst. Natürlich reicht es nicht, dass Problem mit den Apps, den genutzten Diensten, der fehlenden Transparenz und der damit verbundenen Gefahr zu lösen. Das Macht das ganze System noch lange nicht sicher. Ich habe gelesen, dass Google an einer neuen Struktur arbeitet und dass die Auslagerung von zum Beispiel Googlemail aus dem ROM ein bescheidener Anfang ist. Prinzipiell wäre eine neue Anordnung und Zugriffsberechtigung der Layer, wie könnten auch Schubladen oder sonst wie dazu sagen sinnvoll. Es macht einfach keinen Sinn, alles ins Betriebsystem oder auch ins ROM zupacken. Das führt bei der Vielzahl von Herstellern zu Problemen. Wir Alle können sehen was für Verzögerungen und Probleme beim Update auf Froyo aufgetreten sind. Das nervt und wird über lange Zeit die Kunden vergraulen. Keiner weiß, wie lange sein Handy supported wird und hofft auf die Gnade der Hersteller.

Layer 1: Der Kernel, da hat weder der Hersteller des Handys noch der Mobilfunkprovider was suchen. Die Rootrechte sollten weiterhin nicht so einfach zu erlangen sein. Jeder der sein Handy rooted sollte sich halt mit der Materie auskennen. Wenn nach dem Root was schief läuft ist der User halt selber schuld.

Layer 2: Hier befindet sich das Betriebssystem. Auch hier hat weder der Hersteller des Handys noch der Mobilfunkprovider was suchen. Goggle könnte jederzeit das Betriebssystem patchen, austauschen oder sonst wie modifizieren, ohne das sie auf die Hersteller und deren Support angewiesen sind. Einzig die Schnittstelle zum nächsten Layer (3) muss vorhanden und abwärtskompatibel sein.

Layer 3: Ist ein Hardwarelayer, der ganz klar definierte Schnittstellen zwischen den ersten zwei Layern hat. In diesem Layer dürfen die Hersteller nur ihre Hardwarespezifikationen (Treiber…) packen. Der Mobilfunkprovider darf hier keinen Zugriff haben.

Layer 4: Hier kommt die Software drauf. Hier könne die Hersteller ihre Oberflächen (Sense…) gerne vorinstallieren. Die GUIs gehören einfach nicht ins Betriebssystem oder aufs ROM- was die bisherige Praxis beweißt. Permanent ist der User darauf angewiesen, dass der Hersteller Lust hat das System anzupassen. LauncherPro und Andere beweisen das ein GUI/Homescreen Replacement … auch ganz normal als App installiert werden kann und trotzdem tadellos läuft. Selbst das Update von Android 2.1 auf 2.2 hat Apps wie zum Beispiel LauncherPro nichts ausgemacht. Ich musste nicht darauf warten, dass der Entwickler eine Version speziell für Froyo releast.

Natürlich sind das nicht alle Layer. Aber von der Struktur her könnte das doch funktionieren und die derzeitige Updateproblematik verbessern. Die Mobilfunkprovider wollen bestimmt auch noch ne Schublade. Damit sie uns die heißgeliebten Bootscreens, Favoriten… reinpacken können. Solange das nicht in den Kernel, das Betriebsystem und das Rom greift ist das kein Problem. Die Provider können dann gerne Monate damit verbringen ihren ungeliebten Quatsch anzupassen.

Die reale und Linuxarchitektur kennst du?

Layer 1: Hardware
Layer 2: kernel (3 Schichten)
Layer 3: BS

Der Hardwarelayer kann nicht über dem Kernel liegen. Es kann ja sonst nicht auf die Hardware zugegriffen werden.

Zitat von marktwain

Jeder sollte für sich die Frage beantworten: Wie wahrscheinlich ist es, das die Sandbox 100% bugfrei programmiert ist?

Das die Sandbox zu 100% bugfrei programmiert ist, ist unmöglich zu beweisen. Naja unmöglich nicht, aber es dauert sicher die nächsten Jahrtausende um das zu prüfen.


Das Schichtmodell von thp ist nicht korrekt und GalaxyS_User hat das schon schön geschrieben. Google denkt sicherlich darüber nach, aber nicht so.

Edit. Ich verkürze das ganze mal.

Edit2.

@thp Das Modell so ist Mumpitz.

Layer 0: Die unterste Schicht muss die Hardwareschicht sein. Und da auch nur die Abstraktion, also Buscontroller und entsprechend Adressen und Steuerbytes.

Layer 1 muss auch der Kernel bleiben, denn der Kernel soll ja die Hardware steuern und der Software die Hardware zur Verfügung stellen über entsprechende Schnittstellen.
Hier müssen auch immer die Hersteller der Telefone zugriff haben. Ich glaube du hast keine Vorstellung davon wie ein Rechner so wirklich funktioniert und was der Kernel macht. Es ist einfach nicht möglich aus einer oberen Schicht per dubioser Schnittstelle auf die Hardware einfach so zuzugreifen, ohne das der Kernel da nichts zur Verfügung stellt. Ein Treiber stellt auch immer ein entsprechendes Kernelmodul das geladen werden muss um die Hardware anzusprechen. Das enthält z.B. die Adressen der einzelnen Methodenregister und auch noch andere Zugriffsschnittstellen.

Der Kernel ist der Betriebssystemkern und das Betriebssystem ist die Software, die den Betrieb des Gerätes ermöglich.

Und gerade bei so Hochintegrierten Systemen ist die GUI ein wesentlicher Bestandteil. Das einfach so "aufgesetzt" zu lassen führt nicht aus dem Debakel, dass die Oberflächen lahm sind. Und eine Lahme weil in Sandbox laufende Oberfläche ist der Tod des Systems.


Es gibt nur zwei Möglichkeiten tatsächlich eine schnelle Updatekultur zu erstellen:

1. Wenn man die Hardwaretrennung will, dann muss seitens der Hardware ein Standardcontroller her. Der Controller bietet an den Kernel eine Standardschnittstelle an. Der Kernel muss so nicht verändert werden. Den Controller selbst programmiert dann der Hersteller.
Das ist natürlich nicht mehr so schnell und auch nicht so flexibel. Teuerer ist es auch ne ganze Ecke.

2. (Und diese Variante finde ich viel Sinniger) Google ändert den Lizenzvertrag, dass ein Update so schnell wie möglich umgesetzt werden muss, zur Not unter Konventionalstrafe. Viele Updates sind für die Hersteller kein Problem, gerade wenn es um Sicherheitslücken geht muss häufig der Kernel nicht neu kompiliert werden. Da reicht es bestimmte Patches einzusetzen und dann ein entsprechendes Rom herzustellen.
Das verhindert auch "Fire and Forget"-Phones, also Hersteller die Handys auf den Markt bringen und danach einfach vergessen, keine Updates herausbringen usw.

Zitat von KnightNoir

2. (Und diese Variante finde ich viel Sinniger) Google ändert den Lizenzvertrag, dass ein Update so schnell wie möglich umgesetzt werden muss, zur Not unter Konventionalstrafe. Viele Updates sind für die Hersteller kein Problem, gerade wenn es um Sicherheitslücken geht muss häufig der Kernel nicht neu kompiliert werden. Da reicht es bestimmte Patches einzusetzen und dann ein entsprechendes Rom herzustellen.
Das verhindert auch "Fire and Forget"-Phones, also Hersteller die Handys auf den Markt bringen und danach einfach vergessen, keine Updates herausbringen usw.

Ganz genau das wäre auch mein Vorschlag. Vertraglich einfach umzusetzen, technisch höchstens kleine Probleme. Das wäre eine schnell zu implementierende Idee, die nur leider von den Herstellern wenig akzeptiert würde. Denn genau wie Du sagst, es würde ihnen die Firmenpolitik des "Fire and Forget" verhageln!