Episode 51
Posted on Thursday, Oct 31, 2019
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.
Show Notes
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),
[USN-4166-1, USN-4166-2] PHP vulnerability [02:10]
- 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
[USN-4167-1, USN-4167-2] Samba vulnerabilities [03:11]
- 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