-
Notifications
You must be signed in to change notification settings - Fork 0
/
android.html
223 lines (193 loc) · 14.9 KB
/
android.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
<!DOCTYPE html>
<html lang=en>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="referrer" content="no-referrer">
<meta name="color-scheme" content="light dark">
<link rel="stylesheet" type="text/css" href="/styles.css">
<script src="/theme.js"></script>
<script type="module" src="/button.js"></script>
<title>Android | Madaidan's Insecurities</title>
</head>
<body>
<button class="theme-toggle">🌓</button>
<h1>Android</h1>
<p class="date"><em><time datetime="2022-03-11">Last edited: March 11th, 2022</time></em></p>
<p>
By default, Android has a <a href="https://arxiv.org/abs/1904.05572">strong security model</a> and incorporates
<a href="https://source.android.com/security/selinux/">full system SELinux policies</a>, <a
href="https://source.android.com/security/app-sandbox">strong app sandboxing</a>,
<a href="https://source.android.com/security/verifiedboot">full verified boot</a>, modern exploit mitigations like
<a href="https://source.android.com/devices/tech/debug/cfi">fine-grained, forward-edge Control Flow Integrity</a> and
<a href="https://source.android.com/devices/tech/debug/shadow-call-stack">ShadowCallStack</a>, widespread use of
memory-safe languages (Java / Kotlin) and more. As such, this article explains common ways in which people worsen the
security model rather than criticisms of the security model itself.
</p>
<h2 id="unlocking-the-bootloader"><a href="#unlocking-the-bootloader">Unlocking the bootloader</a></h2>
<p>
Unlocking the bootloader in Android is a large security risk. It disables <a
href="https://source.android.com/security/verifiedboot/">verified boot</a>, a fundamental part of the security
model. Verified boot ensures the integrity of the base system and boot chain to prevent <a href="https://en.wikipedia.org/wiki/Evil_maid_attack">
evil maid attacks</a> and malware persistence. <br>
<br>
Contrary to common assumptions, verified boot is not just important for physical security — it prevents the persistence
of <strong>any</strong> tampering with your system, be it from a physical attacker or a malicious application that has managed to
hook itself into the operating system. For example, if a remote attacker has managed to exploit the system and gain high
privileges, verified boot would revert their changes upon reboot and ensure that they cannot persist.
</p>
<h2 id="rooting"><a href="#rooting">Rooting your device</a></h2>
<p>
Rooting your device allows an attacker to easily gain extremely high privileges. Android's architecture is built
upon the <a href="https://en.wikipedia.org/wiki/Principle_of_least_privilege">principle of least privilege</a>. By default,
<a href="https://source.android.com/security/overview/implement#root-processes">only around 6 processes run as the root
user on a typical Android device</a>, and even those are still heavily constrained via the <a
href="https://source.android.com/security/selinux">full system SELinux policy</a>. Completely unrestricted root is found
nowhere in the operating system; even the init system does not have unrestricted root access. Exposing privileges far
greater than any other part of the OS to the application layer is not a good idea. <br>
<br>
It does not matter if you have to whitelist apps that have root — an attacker can fake user input by, for example,
<a href="https://en.wikipedia.org/wiki/Clickjacking">clickjacking</a>, or they can exploit vulnerabilities in apps that
you have granted root to. Rooting turns huge portions of the operating system into root attack surface; vulnerabilities
in the UI layer — such as in the display server, among other things — can now be abused to gain complete root access. In
addition, root fundamentally breaks verified boot and other security features by placing excessive trust in persistent
state. By rooting your device, you are breaking Android's security model and adding further layers
of trust where it is inappropriate. <br>
<br>
A common argument for rooting is that Linux allows root, but this does not account for the fact that the average
desktop Linux system does not have a security model like Android does. On the usual Linux system, <a
href="linux.html#root">gaining root is extremely easy</a>, hence Linux hardening procedures often involve
restricting access to the root account.
</p>
<h2 id="custom-roms"><a href="#custom-roms">Custom ROMs</a></h2>
<p>
The majority of custom ROMs severely weaken the security model by disabling verified boot, using userdebug builds,
disabling SELinux and various other issues. Furthermore, you are also usually at the mercy of the maintainer to
apply security updates properly. Certain ROMs often apply security patches late, or in some cases, not at all. The
latter especially applies to firmware patches.
</p>
<h3 id="lineageos"><a href="#lineageos">LineageOS</a></h3>
<p>
A common ROM that has many of these issues is <a href="https://lineageos.org/">LineageOS</a>:
</p>
<ul>
<li class="lilist">
LineageOS <a href="https://github.com/LineageOS/hudson/blob/master/lineage-build-targets">uses
userdebug builds by default</a>. This <a href="https://source.android.com/setup/build/building#choose-a-target">
adds many debugging features as additional attack surface</a>. It also <a
href="https://github.com/LineageOS/android_system_sepolicy/search?q=userdebug&type=code">weakens various SELinux
polices</a> and exposes root access via ADB, which, <a href="#rooting">as previously discussed</a>, is not a good
idea.
</li>
<li class="lilist">
LineageOS requires an unlocked bootloader, therefore disabling verified boot, <a href="#unlocking-the-bootloader">
which is essential to verify the integrity of the operating system</a>.
</li>
<li class="lilist">
It does not implement <a href="https://source.android.com/security/verifiedboot/verified-boot#rollback-protection">
rollback protection</a>. This allows an attacker to downgrade the system to an older version and then exploit already
patched vulnerabilities. The default updater even allows you to downgrade versions yourself.
</li>
<li class="lilist">
Most LineageOS builds also do not include firmware updates, which prevents users from getting new patches to fix
vulnerabilities. Instead, it gives a pop-up advising users to flash updates manually that most people will simply
ignore.
</li>
</ul>
<p>
This is a non-exhaustive list. There are more issues than just those listed above. LineageOS (and most other custom
ROMs) are focused on customising the device and not privacy or security. Of course, you could build LineageOS yourself
to fix many of these issues, but most users will not be capable of doing so.
</p>
<h2 id="microg-signature-spoofing"><a href="#microg-signature-spoofing">MicroG / Signature Spoofing</a></h2>
<p>
<a href="https://microg.org/">MicroG</a> is a common alternative to Google Play Services. It is often used to get rid
of Google's tracking, but most people do not realise that this can potentially worsen security, as
<a href="https://github.com/microg/android_packages_apps_GmsCore/wiki/Signature-Spoofing">it requires signature spoofing
support</a>, which allows apps to request to bypass signature verification. This subverts the security model and
breaks the application sandbox as an app can now masquerade itself as another app to gain access to the app's files.
In a system with signature spoofing, it is impossible to know anything — there is no way to trust that an application
is genuinely what it claims to be, and it is impossible to build a strong security model upon this. <br>
<br>
Although some signature spoofing implementations can restrict access to this functionality to reduce the risk by, for
example, allowing only microG to spoof the Play Services signature and nothing else.
</p>
<h2 id="firewalls"><a href="#firewalls">Firewalls</a></h2>
<p>
Firewalls, such as <a href="https://github.com/ukanth/afwall/">AFWall+</a> or <a href="https://www.netguard.me/">
Netguard</a>, are regularly used on Android to attempt blocking network access from a specific app, but these
do not reliably work — apps can use IPC to bypass such restrictions. If you cut off network access to an app, it
will not prevent the app from sending an <a href="https://developer.android.com/reference/android/content/Intent">
intent</a> to another app (such as the browser) for it to make the same connection. Many apps already do this
unintentionally whilst using APIs such as the <a
href="https://developer.android.com/reference/android/app/DownloadManager">download manager</a>. <br>
<br>
The most effective way to block network access is to revoke the <code>INTERNET</code> permission from the app
like <a href="https://github.com/GrapheneOS/platform_frameworks_base/commit/5e2898e9d21dd6802bb0b0139e7e496c41e1cd80">
GrapheneOS allows you to do</a>. This prevents abusing OS APIs to initiate network connections, as they contain checks
for that permission, one example of which is the aforementioned download manager. You should also run the app in its
own user or work profile to ensure that it cannot abuse third party apps either.
</p>
<h2 id="conclusion"><a href="#conclusion">Conclusion</a></h2>
<p>
The best option for privacy and security on Android is to get a Pixel 4 or greater and flash <a href="https://grapheneos.org/">
GrapheneOS</a>. GrapheneOS does not contain any tracking unlike the stock OS on most devices. Additionally, GrapheneOS
retains the baseline security model whilst improving upon it with <a href="https://grapheneos.org/features">substantial
hardening enhancements</a> — examples of which include a <a href="https://github.com/GrapheneOS/hardened_malloc">hardened
memory allocator</a>, <a href="https://github.com/GrapheneOS/platform_bionic">hardened C library</a>, <a
href="https://github.com/GrapheneOS/kernel_google_raviole">hardened kernel</a>, <a
href="https://github.com/GrapheneOS/platform_system_sepolicy">stricter SELinux policies</a> and more. <br>
<br>
Pixel devices are also the best hardware to use, as they implement a significant amount of security hardening that most
other devices lack. Examples of this include:
</p>
<ul>
<li class="lilist">
<a href="https://source.android.com/security/verifiedboot/">Full verified boot</a> with <a
href="https://android.googlesource.com/platform/external/avb/+/master/README.md#pixel-2-and-later">support for custom
signing keys</a> — certain Android OEMs often fail to implement verified boot properly, or at the very least, neglect
to include support for custom keys to be able to flash an alternative operating system without having to lose verified
boot. On Pixels, verified boot is implemented securely, and alternative operating systems are often signed with custom
keys to keep the security model intact.
</li>
<li class="lilist">
<a href="https://www.blog.google/products/pixel/titan-m-makes-pixel-3-our-most-secure-phone-yet/">The Titan M chip</a> —
the Titan M is a tamper-resistant hardware security module that provides a number of security properties. It can securely
store cryptographic material using the <a href="https://developer.android.com/training/articles/keystore#HardwareSecurityModule">
StrongBox keystore</a> and enforces throttling upon repeated failed login attempts to mitigate bruteforcing attacks.
Furthermore, it is integrated into the verified boot process, and due to its <a
href="https://android-developers.googleblog.com/2018/10/building-titan-better-security-through.html">tamper-resistant nature</a>,
it is <a href="https://www.google.com/about/appsecurity/android-rewards/">extremely difficult</a> to extract data from the chip
or bypass its security features; if any abnormal conditions are detected, such as unnatural changes in temperature, the Titan M
will erase all data stored within it, thereby categorically mitigating most side-channel attacks. Even if an attacker gained
access to Google's signing keys for the Titan M firmware, they would not be able to flash their own malicious firmware due to
<a href="https://android-developers.googleblog.com/2018/05/insider-attack-resistance.html">insider attack resistance</a>, which
prevents updating firmware until the valid lockscreen passcode is entered.
</li>
<li class="lilist">
<a href="https://android-developers.googleblog.com/2018/10/control-flow-integrity-in-android-kernel.html">
Fine-grained, forward-edge kernel Control Flow Integrity</a> (CFI) and <a
href="https://security.googleblog.com/2019/10/protecting-against-code-reuse-in-linux_30.html">ShadowCallStack</a> — the Pixel kernels
are compiled with custom hardening patches, which includes <a href="linux.html#cfi">CFI and ShadowCallStack</a> to mitigate code reuse
attacks, among various other mitigations. While such mitigations are commonly deployed throughout user space, as briefly mentioned at
the beginning of the article, it is up to the OEM to enable it in the kernel, which is uncommon outside of Pixel devices.
</li>
<li class="lilist">
Wi-Fi privacy features — devices connected to a Wi-Fi network can be tracked through a variety of different methods. Primarily, this occurs
through <a href="https://en.wikipedia.org/wiki/MAC_address">MAC addresses</a>, which are unique identifiers assigned to network interface
controllers (NICs). Every time a device connects to a network, its MAC address is exposed. This enables adversaries to track the device and
uniquely identify it on the local network. Certain mobile devices have attempted to resolve this issue by randomising the MAC address. However, <a
href="https://arxiv.org/pdf/1703.02874.pdf">many don't do this, and the ones that do often use a faulty implementation</a>, resulting in the MAC
address still being leaked. Furthermore, other Wi-Fi identifiers exist that can further enable fingerprinting or even be used to infer the MAC
address, including <a href="https://papers.mathyvanhoef.com/asiaccs2016.pdf">information elements in probe requests and predictable sequence
numbers</a>. In comparison, <a href="https://android-developers.googleblog.com/2017/04/changes-to-device-identifiers-in.html">Pixels use an
effective implementation of MAC address randomisation, minimal probe requests and randomised initial sequence numbers</a>.
</li>
</ul>
<p>
Remember that GrapheneOS cannot prevent you from ruining your privacy yourself. You still have to be
careful regardless of the operating system.
</p>
<a class="back" href="/index.html">Go back</a>
</body>
</html>