Episode 18

Posted on Tuesday, Jan 29, 2019
This week we look at some details of the 46 unique CVEs addressed across the supported Ubuntu releases and take a deep dive into the recent apt security bug.

Show Notes

Overview

This week we look at some details of the 46 unique CVEs addressed across the supported Ubuntu releases and take a deep dive into the recent apt security bug.

This week in Ubuntu Security Updates

46 unique CVEs addressed

[USN-3863-1, USN-3863-2] APT vulnerability

  • 1 CVEs addressed in Precise ESM, Trusty, Xenial, Bionic, Cosmic
  • MITM allowing RCE as root in the context of apt
  • Due to mishandling of HTTP redirect which would allow malicious mirror / MITM to inject content and then could allow arbitrary command execution
  • Fixed by simply disallowing control characters in HTTP redirect responses
    • See detailed discussion later in show

[USN-3864-1] LibTIFF vulnerabilities

[USN-3865-1] poppler vulnerabilities

  • 2 CVEs addressed in Trusty, Xenial, Bionic, Cosmic
  • Assertion failure and NULL pointer dereference triggered by crafted PDFs (crash -> DoS)

[USN-3707-2] NTP vulnerabilities

[USN-3866-1] Ghostscript vulnerability

  • 1 CVEs addressed in Trusty, Xenial, Bionic, Cosmic
  • Another week, another Ghostscript vulnerability courtesy of Tavis Ormandy (GPZ) (after a random look at the latest GS release 9.26)
    • See Episodes 5, 7, 10, 14 for more
  • Code execution via subroutine operators
    • Patches to fix quite invasive
  • Ghostscript is included in evince, ImageMagick, nautilus, GIMP, even less so able to target various commands to exploit

[USN-3867-1] MySQL vulnerabilities

[USN-3869-1] Subversion vulnerability

  • 1 CVEs addressed in Cosmic
  • DoS against Subversion server (mod_dav_svn) (only affects 1.10.0+ -> Cosmic)
  • Triggered by listing remote recursive directory contents BUT not providing the path to list - NULL pointer dereference -> crash

[USN-3868-1] Thunderbird vulnerabilities

Goings on in Ubuntu Security Community

apt / apt-get RCE (CVE-2019-3462)

  • Discovered by Max Justicz (provides a detailed write-up on his blog)
  • apt uses worker processes which communicate back to the main process when fetching content
    • workers get told what to download and where to put it and communicate back with parent via stdin/stdout
    • protocol is like HTTP, human readable text
    • can include directives from workers regarding redirects, completion (DONE) etc
    • when handling a HTTP Redirect from the server, apt http worker would append this contents in message sent back to parent
      • expect just a URI as the redirect content but could be anything - so could contain directives in the apt worker protocol which then get interpreted by the main apt process
      • so could signal DONE to parent as well as follow-up directives such as reporting false hashes for debs or even falsifying the location of the deb on the filesystem
      • So could use the Releases.gpg file as the location of the package on the filesystem - and actually inject our malicious package into the start of Releases.gpg - with trusted Releases.gpg content afterwards
      • Releases.gpg will still validate (since it ignores junk at the start) AND apt will still use the package since it will ignore the signature at the end
      • So can get malicious package installed - which due to debian packaging can run scripts on install etc and hence get RCE as root :(
  • Fixed by simply disallowing control characters in HTTP redirect responses
  • If we assume the mirrors are trusted, could have been mitigated via HTTPS
    • Since HTTPS would stop MITM attacks
    • Some Ubuntu mirrors offer HTTPS but this is not enabled by default since not all mirrors offer HTTPS
    • Official mirrors do not currently offer HTTPS - this is being reevaluated but is difficult for a number of reasons
    • Users can still easily enable HTTPS themselves by choosing an appropriate mirror with a HTTPS URI
  • If assume mirrors are untrusted then they could still have exploited this
    • So whilst HTTPS could help in this case is not a panacea

Get in contact