[manjaro-security] [MSA-201808-1] Local PrivEsc, ACE, and DoS vulnerability in manjaro-system 20180716-1 and earlier

[Philip Müller]

Manjaro Linux Security Advisory MSA-201808-1
============================================

Severity: Medium
Date    : 2018-08-28
CVE-ID  : CVE-2018-15912
Package : manjaro-system
Type    : Local PrivEsc, ACE and DoS
Remote  : No
Link    : n/a

Summary
=======

The package manjaro-system before version 20180828-1 is vulnerable to
local PrivEsc, ACE and DoS attacks.

Resolution
==========

Upgrade to 20180828-1.

# pacman -Syu "manjaro-system>=20180828-1"

The issue was fixed via 'manjaro-system 20180828-1' [1] package.

[1] https://gitlab.manjaro.org/packages/core/manjaro-system/commit/8208b8a

-------- Weitergeleitete Nachricht --------
Betreff: Local PrivEsc, ACE, and DoS vulnerability in manjaro-system
20180716-1 and earlier
Datum: Tue, 28 Aug 2018 01:43:18 +0200
Von: Robin Broda <robin at broda.me>
An: jonathon at manjaro.org
Kopie (CC): philm at manjaro.org, eschwartz at archlinux.org

Hello,

I have discovered an issue with one of your core Manjaro packages,
`manjaro-system` 20180716-1 and earlier.
The issue allows a local attacker to execute a Denial of Service,
Arbitrary Code Execution, and Privilege Escalation attack.

More specifically, the pacman post-upgrade hook `manjaro-update-system.sh`.
The hook stores state in several files under `/tmp/` using the naming
scheme `/tmp/cmdN` - where N is a number starting at 1.
Before the hook is ran, these files do not exist, and as such any user
(i.e. `nobody`) may create a file with the same name.

That works because /tmp/ is shared and writable by everyone,
and because the bash redirection `>` used in the hook does not
*recreate* the files
but rather opens them for writing, so if `/tmp/cmdN` does *not* exist
before running the hook
they will be created as root:root, whereas any existing files under that
name will keep their current permissions - an attacker can thus start a
TOCTOU race writing a payload to these files like so:

To set up the payload injection, a couple values have to be written into
otherwise unrelated files:
`nvidia-utils` to `/tmp/cmd1`
`` to `/tmp/cmd3`
`a` (or any arbitrary non-zero length string) to `/tmp/cmd4`

Now, an attacker can write any arbitrary list of packages or pacman
options into `/tmp/cmd5`
this causes the checks on line 60 and 69 of `manjaro-update-system.sh`
to succeed, and then run
`pacman --noconfirm -Rdd $(cat /tmp/cmd5)`, and
`pacman --noconfirm -S $(cat /tmp/cmd5 | sed 's|nvidia|nvidia-390xx|g')`

This allows a local attacker to:
- Remove arbitrary packages skipping dependency checks
- Install arbitrary packages
- Pass arbitrary options to pacman
  - This would allow for strings like `-y --config /tmp/malicious.conf
--overwrite '*' malicious-package` which:
    - Pulls fresh repos using a custom config path
    - Install the arbitrary package `malicious-package` provided by a
custom repo defined in `malicious.conf`
      - This package will run its pacman hooks (as root!)
      - using `--overwrite '*'` allows us to replace arbitrary system
files by providing them in malicious-package

An advanced Proof-of-Concept script, written by Eli Schwartz and me,
tested on a recent Manjaro ISO with manjaro-system 20180716-1, is
attached to this mail.
To execute, run the attached script as any user on a freshly booted
system and then reinstall manjaro-system
or run a full system upgrade that happens to upgrade manjaro-system.

I would advise against running the PoC on a production machine as it may
not clean up after itself.

I will be requesting a CVE at Mitre shortly after sending this mail,
which will then be updated with information about the vulnerability
shortly after the vulnerability has been fixed.

Regards,
Robin Broda

-------------- next part --------------
A non-text attachment was scrubbed...
Name: manjaro-system-exploit.sh
Type: application/x-shellscript
Size: 2297 bytes
Desc: not available
URL: <http://lists.manjaro.org/pipermail/manjaro-security/attachments/20180828/d4b87da4/attachment.bin>