Log and Camera permissions can be bypassed

[Lekensteyn]

Recently I found out that blocking access to logs in pdroid is not secure. Going deeper in this, I found out that more permissions are affected by this. Once an application has been granted a certain permission by Android, it becomes a member of a group.

A list of permissions that are bound to a user ID can be found in https://github.com/android/platform_frameworks_base/blob/master/data/etc/platform.xml Run the following command in frameworks/base to get a list of permissions that are bound to a group:

grep -oP '<permission name="\K[^"]+permission[^"]+' data/etc/platform.xml

Result when doing this on branch cm-10.1:
android.permission.BLUETOOTH_ADMIN
android.permission.BLUETOOTH
android.permission.BLUETOOTH_STACK
android.permission.NET_TUNNELING
android.permission.INTERNET
android.permission.CAMERA
android.permission.READ_LOGS
android.permission.READ_EXTERNAL_STORAGE
android.permission.WRITE_EXTERNAL_STORAGE
android.permission.WRITE_MEDIA_STORAGE
android.permission.ACCESS_MTP
android.permission.NET_ADMIN
android.permission.ACCESS_CACHE_FILESYSTEM
android.permission.DIAGNOSTIC
android.permission.READ_NETWORK_USAGE_HISTORY
android.permission.MODIFY_NETWORK_ACCOUNTING
com.tmobile.permission.ACCESS_DRM_THEME

Running the command grep -E "$(sed 's/\./\\./g' bar | tr '\n' '|' | sed 's/|$//') foo (with bar the above xml extract) on https://github.com/wsot/pdroid-manager gives a list of affected permissions:

• android.permission.CAMERA
• android.permission.READ_LOGS

I am mentioning it here so that nobody becomes surprised that this hole exist. From these two, the logs is the most severe issue here. It is trivial to execute logcat (reading /dev/log/ is trivial as well). I have not looked further at the camera, but with the right libraries it also becomes feasible to abuse the permission.

[Lekensteyn]

On the positive side, READ_PHONE_STATE can be enforced more easily. It looks reasonable safe, a separate program (com.android.phone) is listening for stuff (intents, broadcasts, whatever name it is). That

This program runs as the radio user (1001), just like /system/bin/rild. The radio group have fully access to devices like SIM. The following command was ran on GT-i9300 running CM9.

find /dev \( -user radio -o -group radio \) -exec busybox ls -l {} \;                                                                                                                                 
crw-rw----    1 radio        vpn           108,   0 Feb 11 18:33 /dev/ppp
crw-rw----    1 system       radio          10,  31 Feb 11 18:33 /dev/umts_loopback0
crw-rw----    1 system       radio          10,  32 Feb 11 18:33 /dev/umts_ramdump0
crw-rw----    1 system       radio          10,  33 Feb 11 18:33 /dev/umts_csd
crw-rw----    1 system       radio          10,  34 Feb 11 18:33 /dev/umts_router
crw-rw----    1 system       radio          10,  36 Feb 11 18:33 /dev/umts_boot0
crw-rw----    1 system       radio          10,  37 Feb 11 18:33 /dev/umts_rfs0
crw-rw----    1 system       radio          10,  38 Feb 11 18:33 /dev/umts_ipc0
crw-rw----    1 system       radio          10,  39 Feb 11 18:33 /dev/link_pm
crw-------    1 system       radio          10,  42 Feb 11 18:33 /dev/accelerometer
crw-------    1 system       radio          10,  43 Feb 11 18:33 /dev/akm8975
crw-rw-r--    1 system       radio          10,  51 Feb 11 18:33 /dev/alarm
brw-rw----    1 system       radio         179,   7 Feb 11 18:33 /dev/block/mmcblk0p7
srw-rw----    1 root         radio                0 Feb 11 18:35 /dev/socket/rild
srw-rw----    1 radio        system               0 Feb 11 18:35 /dev/socket/rild-debug

I have not thoroughly reviewed the pdroid code that is responsible for monitoring this permission, but if implemented well, privacy is kept.

[wsot]

Just to clarify: what you're saying is that even though PDroid adds security checks to the Camera.java class (and others), it is possible for an app with the Camera permission to directly read from the device, ignoring the class?
(and the same applies to reading logs: it can just execute logcat, it doesn't need to use the java interface).
And this is caused by the group id being assigned to the app which allows permission to use logcat, and directly access the camera device?

[mateor]

That sounds like a hole in Android, unless I am missing something. I am going to look through that tonight and see what it looks like, since that sounds interesting to say the least.

[Lekensteyn]

@wsot Correct, but now I have a bigger WTF moment:

$ find /dev \( -user camera -o -group camera \) -exec busybox ls -l {} \;
crw-rw-rw-    1 system       camera         81,   3 Feb 11 18:33 /dev/video3
crw-rw-rw-    1 system       camera         81,   2 Feb 11 18:33 /dev/video2
crw-rw-rw-    1 system       camera         81,   1 Feb 11 18:33 /dev/video1
crw-rw-rw-    1 system       camera         81,   0 Feb 11 18:33 /dev/video0

WTF! world-readable/writable? (this is CM9, I am waiting for more RAM to arrive for building CM10.1) So useless, every program providing its own library bindings can use the camera here (without needing the permission AFAICS)... This a configuration issue, not a flaw in Android though.

@mateor No, that is not a hole in Android. Once you granted an app the permission, it will become a member of the group. For fun, apply this patch to the TestCmd program and execute it (updated to bump targetSdkVersion to avoid asking too many permissions):

diff --git a/AndroidManifest.xml b/AndroidManifest.xml
index e379a88..f1186c9 100644
--- a/AndroidManifest.xml
+++ b/AndroidManifest.xml
@@ -3,6 +3,8 @@
       package="nl.lekensteyn.TestCmd"
       android:versionCode="1"
       android:versionName="1.0">
+    <uses-permission android:name="android.permission.CAMERA" />
+    <uses-permission android:name="android.permission.READ_LOGS" />
     <uses-sdk
         android:minSdkVersion="1"
         android:targetSdkVersion="17" />

[Lekensteyn]

Interesting, while looking for where these groups are assigned, I found the
frameworks/base/services/java/com/android/server/pm/PackageManagerService.java code. It seems also possible to assign/revoke permissions at runtime in Jelly Bean and newer (public void revokePermission(String packageName, String permissionName)). You need android.Manifest.permission.GRANT_REVOKE_PERMISSIONS though.

It looks like we are getting optional permissions!

commit e639da7baa23121e35aa06d6e182558e0e755696
Author: Dianne Hackborn <hackbod@google.com>
Date:   Tue Feb 21 15:11:13 2012 -0800

New development permissions.

These are permissions that an application can request, but won't
normally be granted.  To have the permission granted, the user
must explicitly do so through a new "adb shell pm grant" command.

I put these permissions in the "development tools" permission
group.  Looking at the stuff there, I think all of the permissions
we already had in that group should be turned to development
permissions; I don't think any of them are protecting public APIs,
and they are really not things normal applications should use.

The support this, the protectionLevel of a permission has been
modified to consist of a base protection type with additional
flags.  The signatureOrSystem permission has thus been converted
to a signature base type with a new "system" flag; you can use
"system" and/or "dangerous" flags with signature permissions as
desired.

The permissions UI has been updated to understand these new types
of permissions and know when to display them.  Along with doing
that, it also now shows you which permissions are new when updating
an existing application.

This also starts laying the ground-work for "optional" permissions
(which development permissions are a certain specialized form of).
Completing that work requires some more features in the package
manager to understand generic optional permissions (having a
facility to not apply them when installing), along with the
appropriate UI for the app and user to manage those permissions.

[Lekensteyn]

And as for where group permissions are handed out:

• services/java/com/android/server/am/ActivityManagerService.java#startProcessLocked
• calls getPackageGids on a PackageManager instance for the given package name.
• (through some interfaces), base/services/java/com/android/server/pm/PackageManagerService.java#getPackageGids is called which looks up gids..
• which have been granted in grantPermissionsLPw (and in JB it is also possible to dynamically grant/revoke permissions)

[wsot]

Thanks for this great investigation Lekensteyn.
One thing that has crossed my mind: since the permissions are allocated by a user which isn't root (I assume the system user) then I imagine it would also be possible to revoke those permissions as the system user. By this, I mean remove the app from the 'camera' group.

I had noticed quite a while ago that 'optional' permissions were mentioned in the documentation about permissions, but I'm very excited about them actually getting implemented.

With respect to the 'world-writable' camera: that is a specific configuration issue in CM right? (I'll have to check my CM10.1 builds, but since they merged 4.2.2 my builds don't boot).

[Lekensteyn]

The gids are passed to android.os.Process#start. I have not looked at that code, but I guess it uses a similar structure as Linux. In that case, it is unlikely that group membership can be revoked because that requires additional privileges (CAP_SETGID on Linux), and some permission models may be based on being a member of a group (for example, sshd with Match groups sftp-only).

On my GT-i9300 (Exynos running CM10.1 based on 4.2.1), I have the following:

shell@android:/dev $ find /dev \! -type l -perm -02 -exec busybox ls -ld {} \;                                                                    
find: /dev/com.noshufou.android.su: Permission denied
--w--w--w-    1 root         root                 0 Feb 16 21:54 /dev/cpuctl/apps/bg_non_interactive/cgroup.event_control
-rw-rw-rw-    1 system       system               0 Feb 16 21:54 /dev/cpuctl/apps/bg_non_interactive/tasks
--w--w--w-    1 root         root                 0 Feb 16 21:54 /dev/cpuctl/apps/cgroup.event_control
-rw-rw-rw-    1 system       system               0 Feb 16 21:54 /dev/cpuctl/apps/tasks
--w--w--w-    1 root         root                 0 Feb 16 21:54 /dev/cpuctl/cgroup.event_control
crw-rw-rw-    1 system       system        244,   0 Feb 16 21:54 /dev/mali
crw-rw-rw-    1 system       system         81,  20 Feb 16 21:54 /dev/video20
crw-rw-rw-    1 system       graphics       81,  11 Feb 16 21:54 /dev/video11
crw-rw-rw-    1 root         root            5,   2 Feb 19 15:27 /dev/ptmx
crw-rw-rw-    1 root         root            5,   0 Feb 16 21:54 /dev/tty
crw-rw-rw-    1 root         root            1,   9 Feb 16 21:54 /dev/urandom
crw-rw-rw-    1 root         root            1,   8 Feb 16 21:54 /dev/random
crw-rw-rw-    1 root         root            1,   7 Feb 16 21:54 /dev/full
crw-rw-rw-    1 root         root            1,   5 Feb 16 21:54 /dev/zero
crw-rw-rw-    1 root         root            1,   3 Feb 16 21:54 /dev/null
crw-rw-rw-    1 root         log            10,  42 Feb 16 21:54 /dev/log/sf
crw-rw-rw-    1 root         log            10,  43 Feb 16 21:54 /dev/log/system
crw-rw-rw-    1 root         log            10,  44 Feb 16 21:54 /dev/log/radio
crw-rw-rw-    1 root         log            10,  45 Feb 16 21:54 /dev/log/events
crw-rw-rw-    1 root         log            10,  46 Feb 16 21:54 /dev/log/main
crw-rw-rw-    1 root         root           10,  47 Feb 16 21:54 /dev/binder
crw-rw-rw-    1 system       graphics       10, 240 Feb 16 21:54 /dev/fimg2d
crw-rw-rw-    1 system       graphics       10, 252 Feb 16 21:54 /dev/s3c-mfc
crw-rw-rw-    1 root         root           10,  60 Feb 16 21:54 /dev/ashmem
crw-rw-rw-    1 system       system         10,  63 Feb 16 21:54 /dev/ion
crw-rw-rw-    1 system       graphics      243,   0 Feb 16 21:54 /dev/ump
find: /dev/block/vold: Permission denied
crwxrwxrwx    1 root         root           10,  61 Feb 16 21:54 /dev/s5p-smem
crw-rw-rw-    1 system       system         81,   3 Feb 16 21:54 /dev/video3
crw-rw-rw-    1 system       system         81,   2 Feb 16 21:54 /dev/video2
crw-rw-rw-    1 system       camera         81,   1 Feb 16 21:54 /dev/video1
crw-rw-rw-    1 system       system         81,   0 Feb 16 21:54 /dev/video0
srw-rw-rw-    1 root         root                 0 Feb 16 21:55 /dev/socket/keystore
srw-rw-rw-    1 root         root                 0 Feb 16 21:54 /dev/socket/property_service
$ find /dev \! -type l \( -user camera -o -group camera \) -exec busybox ls -ld {} \; 2>/dev/null
crw-rw----    1 system       camera         81,  12 Feb 16 21:54 /dev/video12
crw-rw----    1 system       camera          1,  14 Feb 16 21:54 /dev/exynos-mem
crw-rw-rw-    1 system       camera         81,   1 Feb 16 21:54 /dev/video1

Some Exynos-specific stuff:

• s5p-smem gives any user full access to DMA memory through an ioctl (kernel/samsung/smdk4412/arch/arm/mach-exynos/secmem-allocdev.c)
• s3c-mfc mmap code is huge, potentional bugs (integer overflowing?)

All video devices are world-readable/writable, not sure what the exact implications are (likely free access to anyone unless Android does some locking or sth?)

[wsot]

Ok. To be honest, I know jack about the lower-level Linux stuff. I learned some stuff about it some years ago, but haven't been hired to work on it so never learned it properly.

With the GIDs: the key thing would be that the app would be included in the group, rather than the the GID passed to Process#start I would imagine (although again that could be my ignorance of how Linux actually works). I'll have a poke around at the GIDs on my phone and see if I can get my head around them.