Custom Query (19868 matches)

New version.

Product: systemd (tmpfiles)
Versions-affected: 239 and earlier
Author: Michael Orlitzky
Fixed-in: v240
Bug-report: https://github.com/systemd/systemd/issues/7986
Acknowledgments:
  Franck Bui of SUSE put forth a massive amount of effort to fix this,
  and Lennart Poettering consistently provided timely reviews over the
  course of a few months.


== Summary ==

Before version 240, the systemd-tmpfiles program will follow symlinks present in a non-terminal path component while adjusting permissions and ownership. Often -- and particularly with "Z" type entries -- an attacker can introduce such a symlink and take control of arbitrary files on the system to gain root. The "fs.protected_symlinks" sysctl does not prevent this attack. Version 239 contained a partial fix, but only for the easy-to-exploit recursive "Z" type entries.


== Details ==

The systemd-tmpfiles program tries to avoid following symlinks in the last component of a path. To that end, the following trick is used in src/tmpfiles/tmpfiles.c:

  fd = open(path, O_NOFOLLOW|O_CLOEXEC|O_PATH);
  ...
  xsprintf(fn, "/proc/self/fd/%i", fd);
  ...
  if (chown(fn, ...

The call to chown will follow the "/proc/self/fd/%i" symlink, but only once; it will then operate on the real file described by fd.

However, there is another way to exploit the code above. The call to open() will follow symlinks if they appear in a non-terminal component of path, even with the O_NOFOLLOW flag set. Citing the open(2) man page,

  O_NOFOLLOW

  If pathname is a symbolic link, then the open fails, with the error
  ELOOP. Symbolic links in earlier components of the pathname will still
  be followed.

So, for example, if the path variable contains "/run/foo/a/b" and if "a" is a symlink, then open() will follow it. If systemd-tmpfiles will be changing ownership of "/run/foo/a/b" after that of "/run/foo", then the owner of "/run/foo" can exploit that fact to gain root by replacing "/run/foo/a" with a symlink. With a Z-type tmpfiles.d entry, the attacker can create this situation himself.

The "fs.protected_symlinks" sysctl does not protect against these sorts of attacks. Due to the widespread and legitimate use of symlinks in situations like these, the symlink protection is much weaker than the corresponding hardlink protection.


== Exploitation ==

Consider the following entry in /etc/tmpfiles.d/exploit-recursive.conf:

  d /var/lib/systemd-exploit-recursive 0755 mjo mjo
  Z /var/lib/systemd-exploit-recursive 0755 mjo mjo

Once systemd-tmpfiles has been started once, my "mjo" user will own that directory:

  mjo $ sudo ./build/systemd-tmpfiles --create
  mjo $ ls -ld /var/lib/systemd-exploit-recursive
  drwxr-xr-x  2 mjo mjo 4.0K 2018-02-13 09:38 /var/lib/systemd...

At this point, I am able to create a directory "foo" and a file "foo/passwd" under /var/lib/systemd-exploit-recursive. The next time that systemd-tmpfiles is run (perhaps after a reboot), the tmpfiles.c function item_do_children() will be called on "foo". Within that function, there is a macro FOREACH_DIRENT_ALL that loops through the entries of "foo".

The FOREACH_DIRENT_ALL macro defers to readdir(3), and thus requires the real directory stream pointer for "foo", because we want it to see "foo/passwd". However, while the macro is iterating, the "q = action(i, p)" will be performed on "p" which consists of the path "foo" and some filename "d", but without reference to its file descriptor. So, between the time that item_do_children() is called on "foo" and the time that "q = action(i, p)" is run on "foo/passwd", I have the opportunity to replace "foo" with a symlink to "/etc", causing "/etc/passwd" to be affected by the change of ownership and permissions.

But there's more: the FOREACH_DIRENT_ALL macro processes the contents of "foo" in whatever order readdir() returns them. Since mjo owns "foo", I can fill it with junk to buy myself as much time as I like before "foo/passwd" is reached:

  mjo $ cd /var/lib/systemd-exploit-recursive
  mjo $ mkdir foo
  mjo $ cd foo
  mjo $ echo $(seq 1 500000) | xargs touch
  mjo $ touch passwd

Now, restarting systemd-tmpfiles will change ownership of all of those files...

  mjo $ sudo ./build/systemd-tmpfiles --create

and it takes some time for it to process the 500,000 dummy files before reaching "foo/passwd". At my leisure, I can replace foo with a symlink:

  mjo $ cd /var/lib/systemd-exploit-recursive
  mjo $ mv foo bar && ln -s /etc ./foo

After some time, systemd-tmpfiles will eventually reach the path "foo/passwd", which now points to "/etc/passwd", and grant me root access.

A similar, but more difficult attack works against non-recursive entry types. Consider the following tmpfiles.d entry:

  d /var/lib/systemd-exploit 0755 mjo mjo
  d /var/lib/systemd-exploit/foo 0755 mjo mjo
  f /var/lib/systemd-exploit/foo/bar 0755 mjo mjo

After "/var/lib/systemd-exploit/foo" is created but before the permissions are adjusted on "/var/lib/systemd-exploit/foo/bar", there is a short window of opportunity for me to replace "foo" with a symlink to (for example) "/etc/env.d". If I'm fast enough, tmpfiles will open "foo/bar", following the "foo" symlink, and give me ownership of something sensitive in the "/etc/env.d" directory. However, this attack is more difficult because I can't arbitrary widen my own window of opportunity with junk files, as was possible with the "Z" type entries.


== Resolution ==

Commit 936f6bdb, which is present in systemd v239, changes the recursive loop in two important ways. First, it passes file descriptors -- rather than parent paths -- to each successive iteration. That allows the next iteration to use the openat() system call, eliminating the non-terminal path components from the equation. Second, it ensures that each "open" call has the O_NOFOLLOW and O_PATH flags to prevent symlinks from being followed at the current depth. Note: only the recursive loop was made safe; the call to open() the top-level path will still follow non-terminal symlinks and is vulnerable to the second attack above.

The commits in pull request 8822 aim to make everything safe from this type of symlink attack. As far as tmpfiles is concerned, the main idea is to use the chase_symlinks() function in place of the open() system call. Since chase_symlinks() calls openat() recursively from the root up, it will never follow a non-terminal symlink. Commit 1f56e4ce then introduces the CHASE_NOFOLLOW flag for that function, preventing it from following terminal symlinks. In subsequent commits (e.g. addc3e30), the consumers of chase_symlinks() were updated to pass CHASE_NOFOLLOW to chase_symlinks(), preventing them from following any symlinks.

The complete fix is available in systemd v240.

There is an authentication bypass issue in OpenSSH, done by adding a . or a blank filename in SCP:

In OpenSSH 7.9, scp.c in the scp client allows remote SSH servers to bypass intended access restrictions via the filename of . or an empty filename.

​https://github.com/openssh/openssh-portable/commit/6010c0303a422a9c5fa8860c061bf7105eb7f8b2

Here's the advisory text that I received:

scp client multiple vulnerabilities
===================================
The latest version of this advisory is available at:
https://sintonen.fi/advisories/scp-client-multiple-vulnerabilities.txt


Overview
--------

SCP clients from multiple vendors are susceptible to a malicious scp server performing
unauthorized changes to target directory and/or client output manipulation.


Description
-----------

Many scp clients fail to verify if the objects returned by the scp server match those
it asked for. This issue dates back to 1983 and rcp, on which scp is based. A separate
flaw in the client allows the target directory attributes to be changed arbitrarily.
Finally, two vulnerabilities in clients may allow server to spoof the client output.


Impact
------

Malicious scp server can write arbitrary files to scp target directory, change the
target directory permissions and to spoof the client output.


Details
-------

The discovered vulnerabilities, described in more detail below, enables the attack
described here in brief.

1. The attacker controlled server or Man-in-the-Middle(*) attack drops .bash_aliases
   file to victim's home directory when the victim performs scp operation from the
   server. The transfer of extra files is hidden by sending ANSI control sequences
   via stderr. For example:

   user@local:~$ scp user@remote:readme.txt .
   readme.txt                                         100%  494     1.6KB/s   00:00
   user@local:~$ 

2. Once the victim launches a new shell, the malicious commands in .bash_aliases get
   executed.


*) Man-in-the-Middle attack does require the victim to accept the wrong host
   fingerprint.


Vulnerabilities
---------------

1. CWE-20: scp client improper directory name validation [CVE-2018-20685]

The scp client allows server to modify permissions of the target directory by using empty
("D0777 0 \n") or dot ("D0777 0 .\n") directory name.


2. CWE-20: scp client missing received object name validation [CVE-2019-6111]

Due to the scp implementation being derived from 1983 rcp [1], the server chooses which
files/directories are sent to the client. However, scp client only perform cursory
validation of the object name returned (only directory traversal attacks are prevented).
A malicious scp server can overwrite arbitrary files in the scp client target directory.
If recursive operation (-r) is performed, the server can manipulate subdirectories
as well (for example overwrite .ssh/authorized_keys).

The same vulnerability in WinSCP is known as CVE-2018-20684.


3. CWE-451: scp client spoofing via object name [CVE-2019-6109]

Due to missing character encoding in the progress display, the object name can be used
to manipulate the client output, for example to employ ANSI codes to hide additional
files being transferred.


4. CWE-451: scp client spoofing via stderr [CVE-2019-6110]

Due to accepting and displaying arbitrary stderr output from the scp server, a
malicious server can manipulate the client output, for example to employ ANSI codes
to hide additional files being transferred.


Proof-of-Concept
----------------

Proof of concept malicious scp server will be released at a later date.


Vulnerable versions
-------------------

The following software packages have some or all vulnerabilities:

                   ver      #1  #2  #3  #4
OpenSSH scp        <=7.9    x   x   x   x
PuTTY PSCP         ?        -   -   x   x
WinSCP scp mode    <=5.13   -   x   -   -

Tectia SSH scpg3 is not affected since it exclusively uses sftp protocol.


Mitigation
----------

1. OpenSSH

1.1 Switch to sftp if possible

1.2 Apply the following patches to scp:
    CVE-2018-20685: https://anongit.mindrot.org/openssh.git/commit/?id=6010c0303a422a9c5fa8860c061bf7105eb7f8b2
    CVE-2019-6109: https://anongit.mindrot.org/openssh.git/commit/?id=8976f1c4b2721c26e878151f52bdf346dfe2d54c
    CVE-2019-6111: https://anongit.mindrot.org/openssh.git/commit/?id=391ffc4b9d31fa1f4ad566499fef9176ff8a07dc

1.3 Alternatively apply the following patch to harden scp against most server-side
    manipulation attempts: https://sintonen.fi/advisories/scp-name-validator.patch

    NOTE: This unofficial patch may cause problems if the the remote and local shells
    don't agree on the way glob() pattern matching works. YMMV.

2. PuTTY

2.1 No fix is available yet

3. WinSCP

3.1. Upgrade to WinSCP 5.14 or later



Similar or prior work
---------------------

1. CVE-2000-0992 - scp overwrites arbitrary files


References
----------

1. https://www.jeffgeerling.com/blog/brief-history-ssh-and-remote-access


Issue tracking
--------------

Arch Linux
  https://security.archlinux.org/CVE-2018-20685

Debian GNU/Linux
  https://security-tracker.debian.org/tracker/CVE-2019-6111
  https://security-tracker.debian.org/tracker/CVE-2018-20685
  https://security-tracker.debian.org/tracker/CVE-2019-6109
  https://security-tracker.debian.org/tracker/CVE-2019-6110

Gentoo Linux
  https://bugs.gentoo.org/show_bug.cgi?id=CVE-2019-6111
  https://bugs.gentoo.org/show_bug.cgi?id=CVE-2019-6109
  https://bugs.gentoo.org/show_bug.cgi?id=CVE-2019-6110

Red Hat Linux
  https://access.redhat.com/security/cve/cve-2019-6111
  https://access.redhat.com/security/cve/cve-2018-20685
  https://access.redhat.com/security/cve/cve-2019-6109
  https://access.redhat.com/security/cve/cve-2019-6110

SUSE Linux
  https://www.suse.com/security/cve/CVE-2019-6111
  https://www.suse.com/security/cve/CVE-2018-20685
  https://www.suse.com/security/cve/CVE-2019-6109
  https://www.suse.com/security/cve/CVE-2019-6110

Ubuntu
  https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-6111.html
  https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2018-20685.html
  https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-6109.html  
  https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-6110.html  

WinSCP
  https://www.cvedetails.com/cve/CVE-2018-20684

PuTTY PSCP
  https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/pscp-unsanitised-server-output.html


Credits
-------

These vulnerabilities were discovered by Harry Sintonen / F-Secure Corporation.


Timeline
--------

2018.08.08  initial discovery of vulnerabilities #1 and #2
2018.08.09  reported vulnerabilities #1 and #2 to OpenSSH
2018.08.10  OpenSSH acknowledged the vulnerabilities
2018.08.14  discovered & reported vulnerability #3 to OpenSSH
2018.08.15  discovered & reported vulnerability #4 to OpenSSH
2018.08.30  reported PSCP vulnerabilities (#3 and #4) to PuTTY developers
2018.08.31  reported WinSCP vulnerability (#2) to WinSCP developers
2018.09.04  WinSCP developers reported the vulnerability #2 fixed
2018.11.12  requested a status update from OpenSSH
2018.11.16  OpenSSH fixed vulnerability #1
2019.01.07  requested a status update from OpenSSH
2019.01.08  requested CVE assignments from MITRE
2019.01.10  received CVE assignments from MITRE
2019.01.11  public disclosure of the advisory
2019.01.14  added a warning about the potential issues caused by the patch
2019.01.15  added issue tracking section (Arch, Debian, Red Hat, SUSE, Ubuntu)
2019.01.15  fixed patch for BROKEN_ONE_BYTE_DIRENT_D_NAME
2019.01.17  updated Ubuntu issue tracking, added Gentoo issue tracking
2019.02.01  added PuTTY PSCP issue tracking
2019.02.09  added links to official patches to mitigation section

New point version

Hello!

I'm writing you to announce the release of nine separate security advisories concerning libssh2.

All these fixes are also included in the brand new libssh2 1.8.1 release, just shipped and available on https://www.libssh2.org/

CVE-2019-3855
 Possible integer overflow in transport read allows out-of-bounds write
 URL: https://www.libssh2.org/CVE-2019-3855.html
 Patch: https://libssh2.org/1.8.0-CVE/CVE-2019-3855.patch

CVE-2019-3856
 Possible integer overflow in keyboard interactive handling allows
 out-of-bounds write
 URL: https://www.libssh2.org/CVE-2019-3856.html
 Patch: https://libssh2.org/1.8.0-CVE/CVE-2019-3856.patch

CVE-2019-3857
 Possible integer overflow leading to zero-byte allocation and out-of-bounds
 write
 URL: https://www.libssh2.org/CVE-2019-3857.html
 Patch: https://libssh2.org/1.8.0-CVE/CVE-2019-3857.patch

CVE-2019-3858
 Possible zero-byte allocation leading to an out-of-bounds read
 URL: https://www.libssh2.org/CVE-2019-3858.html
 Patch: https://libssh2.org/1.8.0-CVE/CVE-2019-3858.patch

CVE-2019-3859
 Out-of-bounds reads with specially crafted payloads due to unchecked use of
 `_libssh2_packet_require` and `_libssh2_packet_requirev`
 URL: https://www.libssh2.org/CVE-2019-3859.html
 Patch: https://libssh2.org/1.8.0-CVE/CVE-2019-3859.patch

CVE-2019-3860
 Out-of-bounds reads with specially crafted SFTP packets
 URL: https://www.libssh2.org/CVE-2019-3860.html
 Patch: https://libssh2.org/1.8.0-CVE/CVE-2019-3860.patch

CVE-2019-3861
 Out-of-bounds reads with specially crafted SSH packets
 URL: https://www.libssh2.org/CVE-2019-3861.html
 Patch: https://libssh2.org/1.8.0-CVE/CVE-2019-3861.patch

CVE-2019-3862
 Out-of-bounds memory comparison
 URL: https://www.libssh2.org/CVE-2019-3862.html
 Patch: https://libssh2.org/1.8.0-CVE/CVE-2019-3862.patch

CVE-2019-3863
 Integer overflow in user authenicate keyboard interactive allows
 out-of-bounds writes
 URL: https://www.libssh2.org/CVE-2019-3863.html
 Patch: https://libssh2.org/1.8.0-CVE/CVE-2019-3863.txt

-- 

 / daniel.haxx.se