madaidans-insecurities.github.io/linux-phones.html at master · madaidans-insecurities/madaidans-insecurities.github.io · GitHub

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
<!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>Linux Phones | Madaidan's Insecurities</title>
</head>

<body>
  <button class="theme-toggle">🌓</button>
  <h1>Linux Phones</h1>

  <p class="date"><em><time datetime="2022-03-06">Last edited: March 6th, 2022</time></em></p>

  <h2 id="comparison"><a href="#comparison">Comparison with Other Phones</a></h2>

  <p>
    Linux phones, such as the Librem 5 or Pinephone, are a major degradation from traditional mobile operating systems,
    such as Android or iOS. A few of the points in this article do apply to the Librem 5 specifically, but the majority
    applies to any Linux phone unless specified otherwise. <br>
    <br>
    Linux phones lack any significant security model, and the points from the <a href="linux.html">Linux article</a> apply to
    Linux phones fully. There is not yet a single Linux phone with a sane security model. They do not have modern security
    features, such as full system MAC policies, verified boot, strong app sandboxing, modern exploit mitigations and so on,
    which modern Android phones already deploy. <br>
    <br>
    Distributions like PureOS are not particularly secure. They are mostly a reskinned Debian and do not include substantial
    hardening. While AppArmor is enabled, the majority of processes still run unconfined, so that is mostly negligible. PureOS
    <a href="https://source.puri.sm/pureos/packages/pureos-security-hardening">changes a few security-relevant settings</a>, but
    these are also mostly negligible:
  </p>

  <ul>
    <li class="lilist">
      PureOS does not apply the exec-shield patch, so that sysctl doesn't even exist in the first place.
    </li>

    <li class="lilist">
      The purpose of disabling kexec is to prevent root from booting a malicious kernel, but <a
      href="https://mjg59.dreamwidth.org/55105.html">root can do so many other things to modify the kernel</a>, such as loading a
      kernel module.
    </li>

    <li class="lilist">
      Attempting to hide kernel symbols via <code>kptr_restrict</code> ignores the fact that they're clearly visible in
      the <code>System.map</code> file on disk, <a href="guides/linux-hardening.html#sysctl-kernel">among</a> <a
      href="guides/linux-hardening.html#other-kernel-pointer-leaks">other</a> <a
      href="guides/linux-hardening.html#kernel-self-compilation">sources</a>.
    </li>

    <li class="lilist">
      And finally, disabling source routing is already a Debian default.
    </li>
  </ul>

  <p>
    PureOS also uses <a href="https://en.wikipedia.org/wiki/Linux-libre">linux-libre</a>. This will prevent the user
    from loading any proprietary firmware updates, which just so happens to be almost all of them. <a
    href="https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurdle/">The Librem 5 prevents the user from updating
    new firmware even with an alternative kernel</a>, which forces the user to use outdated and insecure firmware with
    known vulnerabilities. <br>
    <br>
    The hardware itself lacks many modern security features too, such as <a href="https://source.android.com/security/verifiedboot/">
    proper verified boot</a>, <a href="https://source.android.com/security/keystore/">a hardware-backed keystore</a>
    (some PGP smartcard is not equivalent) and more. <br>
    <br>
    Although one way to fix the issues in software would be to install a more sane OS like Android or its derivatives,
    such as GrapheneOS, if support for the hardware was added. Keep in mind though that it would still lack important
    hardware and firmware security features like verified boot, so it still isn't close to a normal Android device. <br>
    <br>
    These devices are also not open hardware/firmware unlike what they try to imply. The majority of the
    hardware/firmware is still proprietary.
  </p>

  <h2 id="hardware-kill-switches"><a href="#hardware-kill-switches">Hardware Kill Switches</a></h2>

  <p>
    Hardware kill switches are nothing but marketing frills. <br>
    <br>
    The microphone kill switch is useless since audio can still be gotten via the sensors (such as the <a
    href="https://crypto.stanford.edu/gyrophone/files/gyromic.pdf">gyroscope</a> or <a
    href="https://dl.acm.org/doi/pdf/10.1145/3309074.3309076">accelerometer</a>). While the Librem 5 does have a "lockdown
    mode" that disables the sensors, it also requires flipping all of the other switches, including the network switches,
    which effectively turns your device into a brick just to prevent audio recording. <br>
    <br>
    The network kill switch has two primary threat models: preventing cell tower triangulation, or preventing data exfiltration
    after the device has been compromised. The switch is useless in either of these threat models:
  </p>

  <ul>
    <li class="lilist">
      To prevent cell tower triangulation, you can simply enable airplane mode and it is just as effective.
    </li>

    <li class="lilist">
      The network kill switch is useless for preventing data exfiltration since the attacker can just wait until you toggle
      the switch on again to exfiltrate data. If you need to temporarily disable network access, you can use airplane mode.
      Airplane mode can be disabled via a software vulnerability, but if an attacker has those capabilities already, then
      they can also simply sit and record any sensitive data and eventually upload it once you re-enable the hardware network
      kill switch, making it no more effective than airplane mode.
    </li>
  </ul>

  <p>
    The camera kill switch can be useful as a small usability improvement, but it is really no better than some tape.
  </p>

  <h2 id="modem-isolation"><a href="#modem-isolation">Modem Isolation</a></h2>

  <p>
    Modem isolation isn't anything special. For example, <a
    href="https://i.blackhat.com/USA-19/Thursday/us-19-Pi-Exploiting-Qualcomm-WLAN-And-Modem-Over-The-Air-wp.pdf">Qualcomm
    SoCs have isolated the modem via an IOMMU for years</a>, among others. The unorthodox way in which the Librem 5 attempts
    to isolate the modem is via the Linux kernel USB stack, which is not a strong barrier, as shown in the <a href="linux.html">
    Linux article</a>. <br>
    <br>
    There is also a lot of misinformation as to how the modem being on a separate chip means it's isolated — this is
    completely untrue. Just look at how, for example, <a
    href="https://en.wikipedia.org/wiki/IEEE_1394#Security_issues"> FireWire can be abused for DMA</a> while being completely
    separate from the rest of the hardware. Whether or not the modem is on a separate chip is irrelevant to if it's isolated.
  </p>

  <a class="back" href="/index.html">Go back</a>

</body>
</html>