summaryrefslogtreecommitdiff
path: root/content/0022-about-the-asn.1-vulnerability.html
blob: b546344e870bde9b7564d286f6cfa2fb62450610 (plain)
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
<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8" name="charset"><!-- pelican??? -->
    <title> About the ASN.1 Vulnerability</title>
    <meta name="date" content="2016-08-07 13:00:00">
    <meta name="last modified" content="2016-08-07 13:00:00">
    <meta name="keywords" content="neo900, ASN.1, security, modem separation, GTA0x">
    <meta name="authors" content="hellekin">
    <meta name="description" content="Neo900 is not vulnerable to ASN.1 vulnerability.  Here's why.">
  </head>

  <body>

    <p class="lead">
      A recent vulnerability disclosure threatens billions of
      smartphones.  What's the fuss about it?  How does Neo900 fare
      against this threat?  Hint: pretty well.
    </p>

    <h1 id="asn1-vulnerability">ASN.1 Vulnerability</h1>

    <p>Following the decision of <abbr title="National Institute for
      Standards and Technology">NIST</abbr> to deprecate usage of SMS in
      two-factor authentication (we'll come back on this in an upcoming
      installment), this vulnerability disclosure confirms the interest
      of the unique design of Neo900 that isolates the baseband chip
      from power supply, making it dependent on the <abbr title="Central
      Processing Unit">CPU</abbr> (and the <abbr title="Operating
      System">OS</abbr>) to access anything else on the system, and
      preventing remote activation of the chip in the first place.</p>

    <p>Lucas Molas of <em>Programa STIC</em> discovered a <cite>Heap
      memory corruption in ASN.1 parsing code generated by Objective
      Systems Inc. ASN1C compiler for C/C++</cite> potentially affecting
      billions of phone users worldwide.  The proprietary software
      vendor received a bug report via <em>plain text email</em> on
      June, 1<sup>st</sup>, 2016, according to
      the <a href="https://github.com/programa-stic/security-advisories/tree/master/ObjSys/CVE-2016-5080/">CVE-2016-5080</a>
      released on July, 18<sup>th</sup>, 2016 to the public in a
      coordinated release with the vendor.</p>

     <blockquote>Abstract Syntax Notation One (<abbr title="Abstract
       Syntax Notation One">ASN.1</abbr>) is a technical standard and
       formal notation that describes rules and structures for
       representing, encoding, transmitting, and decoding data in
       telecommunications and computer networking.</blockquote>

     <blockquote>A vulnerability found in the runtime support
       libraries of the ASN1C compiler for C/C++ from Objective
       Systems Inc. could allow an attacker to remotely execute code
       in software systems, including embeded software and firmware,
       that use code generated by the ASN1C compiler. The
       vulnerability could be triggered remotely without any
       authentication in scenarios where the vulnerable code receives
       and processes <abbr>ASN.1</abbr> encoded data from untrusted
       sources, these may include communications between mobile
       devices and telecommunication network infrastructure nodes,
       communications between nodes in a carrier's network or across
       carrier boundaries, or communication between mutually untrusted
       endpoints in a data network.</blockquote>

     <p>The proprietary software vendor released a hot patch (v7.0.1)
       available upon request to their customers, and will integrate the
       fix in the upcoming v7.0.2 of their compiler.</p>

     <p>On July, 1<sup>st</sup>, Programa STIC mentioned
       that <q>memory corruption bugs in <abbr>ASN.1</abbr> related
       components of an <abbr title="Long Term Evolution">LTE</abbr>
       stack have been announced or hinted at in several infosec
       conference presentations over the past few weeks and its likely
       the same or similar bugs will become public soon.</q></p>

     <h2>How is Neo900 Affected?</h2>

     <p>The short answer is: Neo900 is not affected.  Keep reading to
       know why.</p>

    <p>In
       our <a href="https://neo900.org/news/paypal-resumes-neo900-sources-again">last
       communication</a> we noted that <q><strong>Neo900 is the only
       phone that provides a hardware protection from remote
       activation of the baseband chip</strong></q>.</p>

    <p id="anchor-gta0x">In fact, the
      <a href="#note-gta0x"><strong>GTA0x</strong> design</a> contains
      two unique features:
      <ul>
        <li>the modem is detached from the power source, unlike other
          smartphones, so that the modem has to be authorized by
          the <abbr>CPU</abbr> before it can perform its tasks.</li>
        <li>the modem and the <abbr>CPU</abbr> <strong>do not share
          <abbr title="Random Access Memory">RAM</abbr>, which
          prevents a whole range of attack vectors where a rogue
          baseband chip, either by design, by "lawful" or illegal
          action, could take control of memory segments pertaining to
          other subsystems and inject malicious code.</li>
      </ul>
      Neo900 takes advantage of this and incorporates circuitry to
      give the <abbr>CPU</abbr> the capacity to monitor:
      <ul>
        <li>the modem access to power and its consumption</li>
        <li>the activity of the modem antenna</li>
        <li>the activation of the
          <abbr title="Global Positioning System">GPS</abbr>
          part of the modem</li>
        <li>other interfaces (e.g., digital
          <abbr title="Pulse-Code Modulation">PCM</abbr> audio</li>
      </ul>
    </p>

    <p>Therefore this vulnerability that potentially plagues most
       commercial phones on the planet, won't affect Neo900 like it
       will other devices. In other designs where RAM is shared and a
       rogue modem can access the power supply at will, the attack
       surface is infinitely larger, and exploiting a vulnerability
       such as the <abbr>ASN.1</abbr> bug will grant access to the
       whole system.</p>

    <p>But with Neo900, only a rare combination of hardware
       vulnerability in the <abbr title="Universal Serial
       Bus">USB</abbr> connecting the modem to the <abbr>CPU</abbr>,
       and a software vulnerability would have a remote chance to do
       that. As long as there's no proprietary vulnerable binary blobs
       in the Neo900 <abbr title="Application Processor
       Environment">APE</abbr>, the chance of a modem bug bubbling up
       to the rest of the system without a way to control it and fix
       it in software remains null.</p>

    <p>Our exclusive Neo900 design is more valuable than ever!</p>

    <p>Thank you for your attention,</p>

    <p>&ndash; hellekin for the Neo900 team</p>

    <p>P.S.: Feedback is welcome!  Did you enjoy reading this post?
      What else should it have covered?  What do you want to read in the
      news?  You can tell me: hellekin at neo900 dot org, or in the
      comments.</p>

    <p id="note-gta0x" class="footnote">Footnote: from Openmoko Neo
      1973 and FreeRunner, to Golden Delicious GTA04 and maybe the
      upcoming Pyra, and of course Neo900, GTA0x design supports modem
      separation, although not power separation in Neo 1973
      (GTA01). <a href="#anchor-gta0x" title="back to text">^^</a></p>

</body>
</html>