Episode 130
Posted on Friday, Sep 10, 2021
This week we discuss compiler warnings as build errors in the Linux kernel,
plus we look at security updates for HAProxy, GNU cpio, PySAML2,
mod-auth-mellon and more.
Show Notes
Overview
This week we discuss compiler warnings as build errors in the Linux kernel, plus we look at security updates for HAProxy, GNU cpio, PySAML2, mod-auth-mellon and more.
This week in Ubuntu Security Updates
15 unique CVEs addressed
[USN-5051-4] OpenSSL regression [00:51]
- 1 CVEs addressed in Trusty ESM (14.04 ESM)
- Episode 129
- Original backport of patch contained a typo which introduced a regression where ASN1_STRINGs would fail to print in some cases
[USN-5062-1] Linux kernel vulnerability [01:20]
- 1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
- AMD specific issue in KVM subsystem with nested virtualisation - would fail to validate particular operations which could be performed by a guest VM - in this case would allow a guest to enable the Advanced Virtual Interrupt Controller for a nested VM (ie L2 VM) - this would then allow the L2 VM to write to host memory -> code execution on the host
[USN-5063-1] HAProxy vulnerabilities [02:40]
- 1 CVEs addressed in Focal (20.04 LTS), Hirsute (21.04)
- Integer overflow in handling of header name lengths - most significant bit of header name length could slip into the LSB of header value length - could then craft a valid request that would inject a dummy content-length on input, this would then be reproduced on the output as well as the original correct header length - can then get a “blind” request smuggling attack since the extra request bypasses ACL checking etc
[USN-5064-1] GNU cpio vulnerability [04:13]
- 1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Hirsute (21.04)
- Integer overflow -> heap buffer overflow in the handling of pattern files - this allows to specify a file which contains a list of patterns to match against filenames in the cpio archive which should be extracted - is not clear if can easily abuse this as a remote attacker since would need to be able to supply a crafted pattern file and have this get used but these are not often used in practice
[USN-5065-1] Open vSwitch vulnerability [05:08]
- 1 CVEs addressed in Focal (20.04 LTS), Hirsute (21.04)
- UAF in decoding of RAW_ENCAP actions - remote attacker could craft one -> crash / RCE..?
[USN-5066-1, USN-5066-2] PySAML2 vulnerability [05:39]
- 1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Hirsute (21.04)
- pysaml2 uses xmlsec1 binary to validate cryptographic signatures on SAML documents
- By default xmlsec will accept any type of key found in the document to verify the signature - so an attacker could embed their own signature using just a HMAC and this would get validated as correct without even consulting the X509 cert which should be used to validate the document - simple fix to just change the CLI arguments to xmlsec1 to specify that it should validate based on x509 certs
[USN-5067-1] SSSD vulnerabilities [07:06]
- 4 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Hirsute (21.04)
- Possible shell command injection via the sssctl binary using the logs-fetch and cache-expire subcommands - if could trick root into running crafted commands could then get root… - was as a result of using the system() syscall which evaluates a string to the shell - so allows shell command injection directly - was fixed to instead use fork() + execvp() on an array of arguments - which doesn’t go via the shell to run the specified subcommand
- common pattern for security vulns, something we specifically look for when auditing packages as part of the security review for MIRs
[USN-5069-1] mod-auth-mellon vulnerability [08:54]
- 1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
- SAML2 auth module for Apache
- Failed to filter URLS that start with
///- an attacker could craft a URL that specified a particular URL via theReturnToparameter and this would then automatically redirect the user to that crafted URL - so could be used for phishing attacks that look more trustworthy. ie. an attacker creates a phishing site that copies the victim site at their own domain. they then send an email to a user asking them to login and they specify a URL to the real victim site but with theReturnToparameter set to their own site - a user looking at this URL will see it specifies the real site so won’t be concerned - when they visit it they get automatically redirected to the victim site - so if they don’t then check the URL they will start logging into the fake phishing site and not the real one - fixed to just reject these URLs so they don’t get abused by the redirect process
[USN-5068-1] GD library vulnerabilities [10:24]
- 4 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Hirsute (21.04)
- Crafted image files -> OOB read / write - crash / code exec
- One in TGA handling but others in the proprietary GD/GD2 formats which upstream say is now deprecated so shouldn’t get a CVE - recommend if you are processing GD/GD2 image files from untrusted sources that you stop as upstream may stop issuing updates for these / may not get CVEs
Goings on in Ubuntu Security Community
Linux kernel enables -Werror [11:33]
- Initially enabled by default, in response to patches from Kees Cook @ Google which introduced a bunch of new warnings - Linus wants a clean build
- Lots of push back since this then immediately broke a heap of CI systems as there a lots of existing bits of kernel code that generates warnings - and depending on what config options you enable you compile different bits of code so can see or not see various warnings - and hence different architectures etc - even having a different locale / LANG setting can result in different compiler warnings as Kees found due to the nature of some of the tests
- Given the huge codebase with so many different configurations is almost impossible to test them all and find all the various warnings, let alone actually fix them
- For years folks have been trying to drive down the warnings but is still a hard and ongoing effort
- As such, ended up changing this to a suggestion from Marco Elver (also at
Google) to enable this when
COMPILE_TESTis enabled - this used as a flag to tell the kernel to compile everything even if it is not being used - and is then often used by CI systems / developers which explicitly want to compile everything who work on detecting new warnings - Is a lofty goal and is very useful from a security PoV and is illustrative of many real world efforts that try and introduce static analysis etc for an existing codebase
- Immediately get a high number of ’errors’ now that need to be addressed - was fine before? - so how to introduce these in a way that doesn’t impose a huge upfront cost but still incentivizes fixing them over time and allows to detect new issues
- Is good to see a focus on this in a more tangible way from upstream as compiler warnings are there for a reason and should not be ignored