Overview
In this Halloween Special, Joe and Alex talk about what scares them in
security, plus we look at security updates for Firefox, PHP, Samba,
Whoopsie, Apport and more.
This week in Ubuntu Security Updates
26 unique CVEs addressed
[USN-4165-1] Firefox vulnerabilities [00:46]
- 13 CVEs addressed in Xenial, Bionic, Disco, Eoan
- 1 high priority, 11 medium and 1 low
- Heap buffer overflow via a crafted WebRTC video - originally for
Chromium and was fixed for that last year - Firefox suffered similarly
but disables the feature by default - has finally been fixed for
Firefox as well by integrating the original fix from Chromium
- Usual suspects of stack-based buffer overflows, UAFs, a heap buffer
overflow in bundled expat (Episode 47),
- 1 CVEs addressed in Precise ESM, Trusty ESM, Xenial, Bionic, Disco, Eoan
- RCE in PHP (FPM - FastCGI Process Manager) - possible to cause the FPM
module to write past allocated buffers - and so ends up also writing into the FCGI
protocol data buffers - which can then create a chance for RCE
- Exploit on github targetting vulnerable PHP-FPM servers which use nginx
in a particular configuration
- 3 CVEs addressed in Precise ESM, Trusty ESM, Xenial, Bionic, Disco, Eoan
- DoS from a user with “get changes” permissions - could crash an AD DC
LDAP server due to a NULL pointer deref when using dirsync with ranged results
- Can configure AD DC to call out to a custom command to verify password
complexity - is handed a copy of the cleartext password - but if this
contained any multi-byte characters, would not get the full password -
since it would pass the password as bytes but only copy the number of
characters - and since multi-byte characters take more than 1 byte would
miss the last few bytes of the password - so could circumvent password
complexity requirements
- Malicious server could craft filenames which contain relative path
characters (../ etc) which would then cause an SMB client to access local
files for reading / writing rather than remote files - so a remote server
could cause a client to create files outside the working directory on the
local machine
[USN-4168-1] Libidn2 vulnerabilities [05:15]
- 2 CVEs addressed in Bionic, Disco
- Library for handling internationalised domain names
- Heap based buffer overflow via a too-long domain name (greater than 63
characters - in library, caller passes a buffer that is specified to be a
minimum of 64 bytes - but libidn strcpy()’s into it so could easily overflow.
- Possible domain name impersonation since doesn’t bother to check unicode
conversions - so could use punycode (ascii representation of certain
unicode characters) to impersonate a unicode domain
[USN-4169-1] libarchive vulnerability [06:32]
- 1 CVEs addressed in Trusty ESM, Xenial, Bionic, Disco
- UAF in certain failure conditions when handling RAR archives
[USN-4170-1] Whoopsie vulnerability [06:52]
- 1 CVEs addressed in Xenial, Bionic, Disco, Eoan
- Kevin Backhouse from Semmle Security Research Team - integer oveflow ->
heap based buffer overflow -> code executions a whoopsie user
[USN-4171-1] Apport vulnerabilities [07:51]
-
5 CVEs addressed in Xenial, Bionic, Disco, Eoan
-
Kevin Backhouse from Semmle Security Research Team
- reads /proc/PID files as root - so if can race on process ID reuse
could cause Apport to generate a crash dump of a privileged process
that is readable by a normal user (so starts dumping an unprivileged
process, then PID race, new PID as privileged user -> this crashes ->
Apport starts writing out the crash report for the first process but
using the details of the new privileged process - since this was
originally an unprivileged process, the crash dump is then unprivileged
too). Fixed by making sure Apport drops privileges to the original
unprivileged user before reading /proc/PID info so if this happens to
then be a different user’s process will not be able to generate the
crash dump
- Apport would read a per-user configuration file - but would do so as
root - and so this could be a symlink to a root owned file and Apport
would happily read it (but might error out if it looked invalid) - so
drop privileges to read it so it doesn’t include anything which it
shouldn’t in the final crash report
-
Sander Bos
- Apport had a lock file in a world-writable directory - so anyone could
create it to either stop Apport running or to control the execution of
Apport over time - fixed to place in a non-world writable location
instead
- When using containers, Apport uses a socket file to allow it to forward
crash dumps that it captured on the host to an Apport instance running
within a container containers - it finds the socket file from the host
using the /proc/PID/root magic link - but this could allow an
unprivileged user who (using unprivileged usernamespaces) is root in a
container to chroot() for a process in a container to a different
location so it can then intercept the crash dump of a privileged
process within the container - so could run a setuid process in the
container, and when it crashes be able to read it’s crash dump
- TOCCTOU race on PID (like above) but this is in a different code path -
reads the cwd of the crashed process to write out the core dump to this
location - but on process ID reuse this could then be in a different
location - so if a user can race against a privileged process dumping
the crash dump could end up in a location of their choosing
Goings on in Ubuntu Security Community
Joe and Alex discuss what scares them for Halloween [12:38]
Get in contact