Lade Inhalt...

Sicherheit von Android-Betriebssystemen

von Daniel Szameitat (Autor) Martin Haug (Autor)

Seminararbeit 2013 17 Seiten

Informatik - IT-Security

Leseprobe

Inhaltsverzeichnis

1 Einleitung
1.1 Android-Architektur
1.2 Android-Apps

2 Betriebssystem-Ebene
2.1 Linux-Kernel
2.2 Application-Sandbox
2.3 Dateisystem-Verschlüsselung
2.4 Memory Management und Sicherheitsfeatures
2.5 Rooting

3 App-Sicherheit
3.1 Bestandteile einer Android-App
3.2 Geschützte Programmierschnittstellen
3.3 Datenschutz in Android
3.4 Sicherheit von Google Play
3.5 Signaturen für Apps
3.6 Digital Rights Management

4 Diskussion
4.1 Updates
4.2 Fernzugriff auf Geräte

A Schichtenarchitektur

B Memory-Sicherheit

1 Einleitung

1.1 Android-Architektur

Bevor man die verschiedenen Sicherheitsaspekte, die Google in sein Android-System eingebaut hat, verstehen kann, muss man den Aufbau von Android verstehen. Android befindet sich zurzeit in der Version 4.x. Die Android-Architektur gliedert sich in eine Fünf-Schichtenarchitektur (siehe Anhang A). Die erste Schichte - auf der alles aufbaut - ist der Linux Kernel. Dieser ist aktuell in Version 2.6 (weitere Informationen finden sich in Unterabschnitt 2.1). Darüber liegt zum einen die zweite Schicht, welche die von Google eigens entwickelte Android Runtime darstellt und zum anderen die Schicht drei, welche eine Sammlung von Standard Bibliotheken beinhaltet. Grob betrachtet ist die Android Runtime der eigentliche Kern des Systems, welcher Android von anderen Linux Systemen unterscheidet. Hier hat Google die Verwaltung von Applikationen - mit einer eigenen Implementierung der virtuellen Java-Sandbox - realisiert. Die neue virtuelle Umgebung läuft unter dem Namen Dalvik Virtual Machine (DVM). Intern kompiliert sie den Java Code in einen Bytecode um. Der resultierende Bytecode wurde für ein Maximum an Performance optimiert. Das Prinzip erinnert stark an Microsofts Common Language Runtime, die im .Net Framework zum Einsatz kommt. Etwas merkwürdig erscheint, dass die Bibliotheken der Schicht drei nativer C/C++ Code ist, welcher nicht in der DVM ausgeführt wird. Die Schicht 4 nutzt die vorherigen Schichten um den Entwicklern von Applikationen ein simples Framework bereitzustellen. Durch komfortable Schnittstellen erleichtert das Framework den Zugriff auf verschiedenste Funktionen und Treiber des Systems. Die fünfte und letzte Schicht beinhaltet die Applikationen selbst. Prinzipiell kann man sich noch eine weitere sechste Schicht dazu denken: Dies wäre dann der von Google geführte App-Store (Google Play). Für alle Schichten gilt folgendes Prinzip:

Each component assumes that the components below are properly secured. —Quelle: Android Open Source Project 2012a Kurz gesagt bedeutet dies, dass jede Schicht sich darauf verlässt, dass die untere Schicht sicher ist. Ein Vorteil davon ist, dass ein Exploit nur Schaden auf der jeweiligen Schicht anrichtet. Der Nachteil davon ist, dass, wenn der Fehler schon im Kernel steckt, die Schichten darüber ebenfalls unsicher werden. Die Folgende Arbeit orientiert sich an der Schichten Architektur. So finden sich in Abschnitt 2 Sicherheitsfeatures der Schicht eins und zwei. Abschnitt 3 behandelt dann die Schichten vier, fünf und sechs.

1.2 Android-Apps

Die größte Menge aller Applikationen für Android befindet sich im Android Market (Google Play). Google Play ist ein Platz, an dem alle Entwickler ihre Apps veröffentlichen können und alle Benutzer des Systems diese Apps beziehen. Im ersten Moment erinnert Google Play an den App-Store von Apple, allerdings gibt es hier gravierende Unterschiede bei der Verwaltung, da Google keine Genehmigungsverfahren für Apps vorgesehen hat. Google setzt vielmehr auf eine Bewertungsstrategie, bei der die Apps, welche fehlerhaft

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Android-Versionen3

sind, durch schlechte Bewertungen bedeutungslos werden. Im Notfall hat sich aber auch Google eine Hintertür geschaffen. Wird eine App als gefährlich eingestuft, kann sie durch das ”Remote Application Removal Feature“ nachtr¨aglich von Google auf dem Handys gelöscht werden. Ein bekannter Fall, bei dem Google dieses Feature nutzte, war im Jahre 2010, als eine App zum Installieren von böswilligen Apps in Umlauf gekommen war1. Neben diesem Vorfall sind auch noch andere Fälle bekannt. So löschte Google im Jahr 2012 ohne Begründung eine App aus Google Play, die dem Benutzer mehr Möglichkeiten und Sicherheit beim Installieren von Apps geben sollte2. So kann man zusammenfassend sagen, dass Google seinen Android Market gut positioniert hat und auch Möglichkeiten hat auf Sicherheitsvorfälle zu reagieren. Kritisch ist dabei, dass es teilweise mehrere Tage dauern kann, bis Kritisch ist dabei, dass es teilweise mehrere Tage dauern kann, bis Google reagiert und dass sich Google auch vorbehält ohne Angabe von Gründen Apps aus Google Play zu entfernen.

2 Sicherheit auf Betriebssystem-Ebene

2.1 Linux-Kernel

Google verwendet für sein Android Betriebssystem einen Linux Kernel. Dabei profitiert Android davon, dass der Kernel sich schon in der Praxis bewährt hat und sowohl si- cher als auch stabil läuft. Google selbst hat den Linux Kernel so angepasst, dass er für Smartphones optimiert ist. In Tabelle 1 sind die verwendeten Kernel-Versionen in Android aufgeführt.

Eine erste sicherheitsrelevante Schwachstelle fällt an dieser Stelle schon auf. Um sie zu erkennen, muss man allerdings noch Tabelle 1 betrachten: Hier sieht man die Verbreitung der Android-Versionen weltweit. Zu sehen ist, dass mit 54% die Version 2.3 am weitesten verbreitet ist. Allerdings steckt in dieser Version ein älterer Linux Kernel mit Version

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Versionsverteilung4

2.6. Eine einfache Suche-Anfrage bei nur einer Exploit-Datenbank zeigt schon ca. 50 bekannte Exploits5. Google sollte die Verbreitung der neusten Versionen vorantreiben, um weiteren Negativ-Schlagzeilen aus dem Weg zu gehen.

Google hat eine Reihe gravierender Eingriffe im Kernel vorgenommen. Dabei bestand am Anfang eine Kooperation mit der Linux Community. Zu dieser Zeit war Android im Linux Staging Tree integriert und somit Teil des Kernels. Das änderte sich mit der Version 2.6.33. Die Linux Community entschied, dass Google sich nicht genug um ihren Code kümmert und verbannte Android aus dem Kernel. Der Linux-Kernelentwickler Greg Kroah-Hartmann schrieb in seinem Blog als Begründung:

So, what happened with the Android kernel code that caused it to be deleted? In short, no one cared about the code, so it was removed.

—Quelle: Kroah-Hartmann 2010, ”Whats wrong“

Als Folge davon sind der Android-Kernel und der Linux-Kernel inkompatibel. Das ver- hindert, dass offizielle Kernel-Updates eingespielt werden können. Hier sind die Android Nutzer auf die sparsamen Updates von Google angewiesen (siehe Unterabschnitt 4.1). Bei einer etwas älteren Untersuchung aus dem Jahr 2010 hat das Sicherheitsunternehmen Coverity festgestellt, dass das Androidsystem 0,78 Bugs auf 1000 Zeilen Code enthält. Insgesamt wurden in der Version 2.6 359 ”software defects“ gefunden. Das Kritische dabei ist, dass25% davon als riskant eingestuft wurden6. Im Vergleich zu anderer Soft- ware ist die Analyse zwar positiv für Android ausgefallen. Allerdings besitzen ähnliche Systeme wie z.B. der reine Linux Kernel deutlich weniger Bugs pro 1000 Zeilen.

[...]


1 Heise Security 2010.

2 Frickel 2012.

5 Offensive Security 2012.

6 Coverity Inc. 2012.

Details

Seiten
17
Jahr
2013
ISBN (eBook)
9783656493891
ISBN (Buch)
9783656493662
Dateigröße
520 KB
Sprache
Deutsch
Katalognummer
v232592
Institution / Hochschule
Hochschule Aalen
Note
1.3
Schlagworte
sicherheit android-betriebssystemen

Autoren

Teilen

Zurück

Titel: Sicherheit von Android-Betriebssystemen