This week we discuss new kernel memory hardening and security development
proposals from Ubuntu Security Alumnus Kees Cook, plus we look at details
of security updates for WebKitGTK, libsndfile, GnuTLS, exiv2 and more.
Show Notes
Overview
This week we discuss new kernel memory hardening and security development
proposals from Ubuntu Security Alumnus Kees Cook, plus we look at details
of security updates for WebKitGTK, libsndfile, GnuTLS, exiv2 and more.
Update announced back in Episode 115 - MariaDB intends to be compatible
with MySQL but failed to include the caching_sha2_password.so module
which is the standard module used to authenticate in MySQL - as such
clients would not be able to connect since they expect to use this method
to authenticate by default. Upstream MariaDB fixed this in newer versions
and this update backports that fix to the version in Ubuntu 20.04
DoS due to recursive parsing in the face of errors - fixed to instead
bail out if encounters too many successive errors as PDF is damaged in
this case anyway
Heap buffer overflow from crafted PDF - also found by OSSFuzz
Symlink path traversal in handling of tar archives in the Archive_Tar
module - since PEAR uses this directly when handling archives, it was
also vulnerable so could be made to overwrite arbitrary local files on
archive extraction and hence get code execution
2 possible UAF in certain scenarious - hard to exploit as need to be able
to predict the behaviour of glibc’s memory allocator as well as GnuTLS’s
own internal allocator but could possibly be used for RCE
Incomplete fix for previous Perl DBI CVE-2014-10401 - would allow access
to files outside the original data source directory - was still
potentially vulnerable - fixed to parse attributes more strictly to avoid
this
Possible stack buffer overflow if using a really long perl package name
as a database driver - unlikely to actually be triggered in practice -
used a fixed size stack buffer and memcpy()’d into it without checking
bounds - fixed to allocate the buffer on the heap to the exact required
size
Aiming to make memcpy() within the kernel detect when
overwriting following structure members
Current kernel memcpy() is able to already detect when writing outside
the bounds of a given structure (when the structure size can be known at
either compile or run-time) - but can’t handle detecting overwriting of
extra members within a structure
Uses the built-in features of GCC plus some C macro smarts to actually
allow this to be done in certain circumstances without triggering
warnigns - ie in some cases want to actually overwrite following
structure members like when handling network packets etc
Most cases are only able to be detected at runtime and since it is not
easy to statically determine all these call sites, for now this proposal
is warn-only - but in the future the hope is to make it enforcing so it
can actually stop possible buffer overflows
Also had this been present it would have detected the 11 previously known
memcpy() overflows so shows likely real-world promise as an extra
defensive measure
Makes a strong case for having vendors track either latest released
kernel or one of the stable trees - instead of each manually backporting
patches etc - duplicated work
Then could devote engineers to working more upstream on testing,
hardening etc - which benefit everyone - ie by working upstream on a
common platform this reduces duplicated efforts and gains many
efficiencies