Skip to content

Kernel security

Jump to bottom
CHEF-KOCH edited this page Apr 19, 2015 · 23 revisions

Index

An fantastic explanation and overview about Android's security can be found at the TheNewCircle [05.2013] or directly on source.android.com.

⚠️ This is a POC (Proof-of-Concept) and WIP (Work-in-process) article, it's not designed (and never will be) to explain everything or show every possible configuration (it's simply impossible) and is more designed to quickly show the most important configurations!

Due the lack of security of the consumer devices is not necessarily Android's problem. So far, most problems come from OEM's customization, and third party malicious apps pretending to be good citizen. Hardening the kernel won't fix all of these problems.

To prevent some of the latest networking attacks, you should try to keep your kernel version current as soon as possible.

The reason why Android (Kernel is based on Linux) and open source will always be more secure compared than Windows is because you can build advanced security right in.

Introduction

Since AFWall+ is a GUI for iptables, people may started to want to know more about how they can generally more secure the lowest-level (like iptables) - the Kernel itself. As the kernel controls your computer's networking, it is important that it be very secure, and not be compromised.

The config file of your currently running kernel is also always available in your file system at /proc/config.gz.

The main benefit and the main goal is to secure the kernel, so that no external tools are necessary.

The Linux Kernel isn't exactly the Android Kernel, there are several things you can't find in the original Linux kernel, like OOM, Wakelocks, pmem, Binder, logger, ... - These features are unique to Android only systems.

Kind of attacks:

  • Offline attacks (physical attacks, side-loading, bypassing, off-device attacks ...[mostly needs root]).
  • Online attacks (on the network stack against malware, dos, ...) (optional - OS specific)
  • On Android 5+ the user password is now protected against ordinary brute-force attacks using scrypt and, if available, the key is bound to the hardware keystore to prevent off-device attacks (i.e. brute-force). As always, the Android screen lock secret and the device encryption key are not sent off the device or exposed to any application.
  • TLSv1.1 + 1.2 are now enabled by default. Look, here that also means that Forward secrecy is enabled too which is used in AES-GCM (needs Services 7.x+ installed). The weak and vulnerably cipher suites like MD5, 3DES are by default disabled.

Implementations

The following examples show what can be integrated (of is already integrated) into the Kernel for security reasons:

  • grsecurity (not available for Android yet)
  • SELinux (introduced in Android 4.3.x -> Kernel 2.6+) up-to-date info is always available here
  • SecDroid (optional - deprecated)
  • CIS Benchmark (optional)
  • Pentests (optional - Penetrations tests are only for experts and can be used to find known holes, like Metasploit)
  • Bastille Linux (not available for Android yet)
  • IPTables (if not present AFWall+ brings them to your device)
  • LIDS (not available for Android yet)
  • Linux Security Modules (LSMs)
  • Cryptography, AES, RSA, DSA, and SHA + API's for SSL/TLS and HTTPS (since 3.0 but weak)
  • Encryption (since 3.0 but weak)
  • -> Known attacks can be found here [no direct links since they are mostly POCs and they of course will be fixed with next Android versions - so it's more for historical reasons]

Already implemented in every Android OS:

  • Basic Password protection
  • Process isolation like a Sandbox (Androids security model is based on application sandboxing)
  • Device Administration (Android 2.2+)
  • A permission model for each user like on UNIX
  • IPC security apps can explicitly share resources and data via Intents, ContentProviders, IPC and Binder and of course via the file system and local declared sockets)
  • (optional) The ability to remove apps/system related kernel parts which may be insecure by design (depending on needs)
  • Root ability (but restricted to the Kernel + a view core applications)
  • (optional) Security Tips | Android Developers
  • Android supports many cryptographic and encryption tools and algorithms such as AES, RSA, DSA, SHA, CBC, and ESSIV:SHA256. See also here, here, here and here.
  • Another powerful security measure is that fact that the Android operating system (Linux kernel, libraries, app runtime + framework, etc.) is on its own partition that is read-only. Also, Android uses Unix-style file permissions (except for FAT32 filesystems). Due performance and security reasons it's recommend to use ext4 (because the integrated encryption works only with this and on Samsung devices it must be vfat).
  • It is interesting to know that most of Android's security is meant to protect itself, not your personal files. While both are secured, there are more security measures that protect the operating system than the personal files (like pictures, music, contacts, etc.).

For app developer:

  • SIM Card Access - Low level access to the SIM card is not available to third-party apps. The OS Handles all communication with the SIM Card.
  • Cost Sensitive APIs - Cost sensitive means using them might generate cost, thus android provides a protection in OS level. Applications must grant explicit permission to use these APIs. Mostly: SMS/MMS, Telephony, Network/Data, In-App Billing or NFC Access.
  • Sensitive Data Input Devices - Applications must grant an explicit permission to use input devices such as the Camera, GPS and the Microphone.
  • Device Metadata - Device information might contains user information, thus applications must grant to access the OS system logs, Browser history, Hardware (such as network identification information) and the Phone number.
  • Application Signing - ......
  • Storing Data - Internal Storage - By default, files that you create on internal storage are accessible only to your app, make sure you not use MODE_WORLD_READABLE & MODE_WORLD_WRITEABLE (Google Play Store also scans for this) + Use content provider for share and prefer encryption for additional protection
  • Storing Data - External Storage - Do not store executables or class files. + Always retrieve signed and verified files. See also here.
  • Android Resources/Assets - Please never share/store any sensitive information and if possible meta-data such as the keystore, keys,[...] because they can read and accessed by anyone.
  • Permission Model - If possible: Minimize the permission request and never request unless it's really needed or it would break your app. Protect the IPC via permissions to avoid leak permission-protected data.
  • Performing Input Validation - If possible beware of JavaScript injection and SQL injection and verify the format. + Make sure if native code is used that there are non potential secure issues.
  • Handling User Data - If a GUID is required, use UUID. Do not use phone identifiers.
  • WebView - ....
  • Handling Credentials - ...
  • Be aware of reverse engineering - The application apk can be exported easily. Apk itself is a zip folder and it is very easy to extract it (via apktool and others).
  • Be aware of app licensing - Google Play offers a licensing service that lets you enforce licensing policies for applications that you publish on Google Play. With Google Play Licensing, your application can query Google Play at run time to obtain the licensing status for the current user, then allow or disallow further use as appropriate.

Networking:

  • CONFIG_FIREWALL

  • CONFIG_IP_FORWARD

  • CONFIG_SYN_COOKIES

  • CONFIG_IP_FIREWALL

  • CONFIG_IP_FIREWALL_VERBOSE

  • CONFIG_IP_NOSR

  • CONFIG_IP_MASQUERADE

  • CONFIG_IP_MASQUERADE_ICMP

  • CONFIG_IP_TRANSPARENT_PROXY

  • CONFIG_IP_ALWAYS_DEFRAG

  • CONFIG_NCPFS_PACKET_SIGNING

  • CONFIG_IP_FIREWALL_NETLINK

  • AID_NET_BT

  • AID_NET_BT_ADMIN

  • AID_INET

  • AID_NET_RAW

  • AID_NET_ADMIN

The full list can be found [here](https://github.com/ukanth/afwall/wiki/Android-kernel-traffic#protocol-statistics

Kernel Compiling:

  • CONFIG_FILTER

Kernel-level security

An overview which permission an application use can be done via terminal find /data/data -type f | xargs ls -l | sort -k3 -n. To get the an sample process list we just can use ps.

Application-level security

Android also uses a user-space level security system to regulate communication and interaction among applications and system components.

Disable binaries

Each application is given its own Linux user ID (UID) and group ID, besides this indication some apps need the following binaries to work, so removing them blocks possible attacks direct on the device (Offline).

  • irsii
  • bash
  • SQL
  • nano
  • nc (net cat)
  • netserver
  • netperf
  • opcontrol
  • rsync
  • scp
  • sdptest
  • ssh
  • sshd
  • strace
  • tcpdump
  • vim
  • ping (needs root)
  • pm (needs root)
  • adbd (needs root -> adb deamon)

Security Tricks

Some applications request more permissions (e.g. Flashlight) than they really need. You can alter the set of permissions granted to an application by editing /data/system/pacakges.xml. After editing you need to reboot the device, because it gets overwritten by the system again. All changes will be read at system boot.

On some external ROMs, there is also an GUI for this, it's called Privacy Guard which first was introduced in CyanogenMod 11. This makes it easier for users to disable critical permissions on an app-by-app basis.

SMS: With Android 4.2, the user gets a notification when the SMS feature is used, then user decides to whether send the message or not.

Application Signing: Never ever forget your keystore. Send it via email to yourself to keep it. If you lose your keystore, you won't be able to get it back and you cannot update your application anymore.

Useful links

Footer

Clone this wiki locally