This week Joe talks Linux Security Modules stacking with John Johansen and
Steve Beattie plus Alex looks at security updates for snapd, the Linux
kernel and more.
Show Notes
Overview
This week Joe talks Linux Security Modules stacking with John Johansen and
Steve Beattie plus Alex looks at security updates for snapd, the Linux
kernel and more.
snapd sandbox for strict mode snaps - within sandbox provides xdg-open
implementation which can forward to the real xdg-open outside the
sandbox - but would use XDG_DATA_DIRS env from the snap when launching
xdg-open outside of the snap - XDG_DATA_DIRS could then contain a
directory which the snap itself controls - allows to launch arbitrary
binaries from the snap outside of confinement
Fixed to not incorporate XDG_DATA_DIRS from the snap
cloud-init would run on every boot without restriction - supports the
concept of loading meta-data from an external disk - so a local attacker
with physical access could alter the boot sequence - would be an issue
with FDE since could intercept the disk encryption key etc - fixed via
snapd to disable cloud-init after the first boot since cloud-init is
managed by snapd
Is only an issue for Ubuntu Core 16/18 devices which employed FDE
Possible bypass of Secure Boot lockdown protections via loading of ACPI
tables via configs - provides a means of arbitrary memory write - allows
root user to bypass lockdown
Second lockdown bypass via loading of ACPI tables via the SSDT EFI
variable similar to above
DAX (direct access to files in persistent memory arrays) huge pages
support - abuse mremap() to gain root privileges - requires the system to
make use of DAX storage to be able to exploit
Would read extra data after clear-text “begin TLS” when initiating
STARTTLS - would allow an untrusted attacker who could intercept and
modify traffic to inject arbitrary responses that then get processed
later as though they had come from the trusted, encrypted connection to
the server - fixed in same way as mutt by clearing buffered content when
starting TLS