Sign up to save your podcasts
Or
Share Episode 159
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
Episode 159
Overview
This week we bring you part 2 of our look at the new Ubuntu 22.04 LTS
release and what’s in it for security, plus we cover security updates for
DPDK, OpenSSL, Cron, RSyslog, Curl and more.
This week in Ubuntu Security Updates
37 unique CVEs addressed
[USN-5401-1] DPDK vulnerabilities [00:54]
accelerate package processing workloads)
allow a malicious guest to crash or get code execution on the host
and secondary where the primary can spam the secondary with with a huge
number of open file-descriptors which eventually leads the secondary to
exhaust it’s fd limit and hence DoS
[USN-5402-1] OpenSSL vulnerabilities [01:36]
case if running 22.04, exposed to 4 vulns whilst for the older releases
only 1
lifetime of a piece of software - if always running the latest version
do you get exposed to more and more CVEs each time you upgrade? Is it
better to stick with older software since the rate of vulns found over
time likely decreases as it gets older…
which could usually affect something like an TLS server which uses client
certs for authentication, plus a possible MiTM attack against RC4-MD5,
incorrect return code when validating OCSP messages which could cause a
user / application to believe was valid when in fact was not plus
possible code execution via the c_rehash script through
shell-metacharacters - but no privilege escalation so only get whatever
privileges the script is executing under (c_rehash is used to create
symlinks named as the hashes of certs etc when importing a cert into a
cert store so it can then easily be looked up via it’s hash value as the
filename)
[USN-5395-2] networkd-dispatcher regression [03:44]
would be encountered under certain situations
[USN-5354-2] Twisted vulnerability [04:06]
[USN-5403-1] SQLite vulnerability [04:20]
query - upstream dispute this as an actual vuln since if can execute
sqlite cli then can already execute arbitrary commands
[USN-5405-1] jbig2dec vulnerabilities [04:40]
[USN-5259-2] Cron vulnerabilities [04:58]
when the crontab package is upgraded via a symlink attack - so in general
was a dormant / latent vuln that would only be able to be triggered if a
sysadmin manually reinstalled cron or we released a new update 😁 - so
fixed now
[USN-5259-3] Cron regression [05:47]
possibly scary looking error messages would be printed when cron was
upgraded - fixed with this further update
[USN-5404-1] Rsyslog vulnerability [05:57]
host which is logging to a centralized syslog server could possibly crash
or get code execution on the server (as the syslog user only)
[USN-5244-2] DBus vulnerability [06:18]
to the same UID - if policy references these usernames, may free it via
one username whilst it is still being accessed by the other
[USN-5179-2] BusyBox vulnerability [07:03]
[USN-5407-1] Cairo vulnerabilities [07:10]
crafted image / font files
[USN-5408-1] Dnsmasq vulnerability [07:24]
[USN-5409-1] libsndfile vulnerability [07:46]
[USN-5410-1] NSS vulnerability [07:54]
crash a server by sending multiple of these
[USN-5411-1] Firefox vulnerabilities [08:06]
DoS, bypass permission checks etc)
[USN-5412-1] curl vulnerabilities [08:24]
fuzzing?
parameters had been changed
DoS
wrongly and so end up visiting wrong URL or bypassing access checks /
filters etc
which are due to C mistakes vs general programming logic mistakes -
general mistakes higher so I assume this is used as an argument as to why
implementing such a ubiquitous piece of software in such an unsafe
language is “ok” - can’t say I agree
mistakes - non-C mistakes take longer to find, presumably due to lack of
good tools for finding them (compared to say UBSan, Coverity etc for
finding C specific mistakes)
Goings on in Ubuntu Security Community
What’s new in security in Ubuntu 22.04 LTS (part 2) [11:35]
migration guide which explains the main changes from 1.1.1 as well
as how to enable the legacy provider if you still require access to
them
protocols (and below)
improved handling of FIDO/U2F hardware tokens - openssh in 20.04 LTS
first introduced support for FIDO/U2F tokens as 2FA for remote SSH
logins - basically would generate a new openssh key where the private
half of the key is only accessible with the FIDO/U2F token - this new
release brings support for using a PIN with the token and much better
improved UX so that users don’t have to keep getting prompted for
their PIN each time. Plus supports verifying WebAuthn signatures
userspace tooling to control that
implement network packet classification and handling - aka firewalling
etc
xtables and nftables (nft) for nftables
users would be switched to that automatically - so can still use
traditional iptables command to configure firewall rules etc but they
will then be loaded into the kernel’s nft backend rather than xtables
backend which supports more advanced rule types
the same backend in the kernel otherwise they may conflict and get
weird results
deref, unsafe calls within signal handlers and more
hence is deterministic based on the original seed value
reproducible / deterministic - ie. is actually more truly random
Get in contact
View all episodes
By Ubuntu Security Team
4.8
1010 ratings
Overview
This week we bring you part 2 of our look at the new Ubuntu 22.04 LTS
release and what’s in it for security, plus we cover security updates for
DPDK, OpenSSL, Cron, RSyslog, Curl and more.
This week in Ubuntu Security Updates
37 unique CVEs addressed
[USN-5401-1] DPDK vulnerabilities [00:54]
accelerate package processing workloads)
allow a malicious guest to crash or get code execution on the host
and secondary where the primary can spam the secondary with with a huge
number of open file-descriptors which eventually leads the secondary to
exhaust it’s fd limit and hence DoS
[USN-5402-1] OpenSSL vulnerabilities [01:36]
case if running 22.04, exposed to 4 vulns whilst for the older releases
only 1
lifetime of a piece of software - if always running the latest version
do you get exposed to more and more CVEs each time you upgrade? Is it
better to stick with older software since the rate of vulns found over
time likely decreases as it gets older…
which could usually affect something like an TLS server which uses client
certs for authentication, plus a possible MiTM attack against RC4-MD5,
incorrect return code when validating OCSP messages which could cause a
user / application to believe was valid when in fact was not plus
possible code execution via the c_rehash script through
shell-metacharacters - but no privilege escalation so only get whatever
privileges the script is executing under (c_rehash is used to create
symlinks named as the hashes of certs etc when importing a cert into a
cert store so it can then easily be looked up via it’s hash value as the
filename)
[USN-5395-2] networkd-dispatcher regression [03:44]
would be encountered under certain situations
[USN-5354-2] Twisted vulnerability [04:06]
[USN-5403-1] SQLite vulnerability [04:20]
query - upstream dispute this as an actual vuln since if can execute
sqlite cli then can already execute arbitrary commands
[USN-5405-1] jbig2dec vulnerabilities [04:40]
[USN-5259-2] Cron vulnerabilities [04:58]
when the crontab package is upgraded via a symlink attack - so in general
was a dormant / latent vuln that would only be able to be triggered if a
sysadmin manually reinstalled cron or we released a new update 😁 - so
fixed now
[USN-5259-3] Cron regression [05:47]
possibly scary looking error messages would be printed when cron was
upgraded - fixed with this further update
[USN-5404-1] Rsyslog vulnerability [05:57]
host which is logging to a centralized syslog server could possibly crash
or get code execution on the server (as the syslog user only)
[USN-5244-2] DBus vulnerability [06:18]
to the same UID - if policy references these usernames, may free it via
one username whilst it is still being accessed by the other
[USN-5179-2] BusyBox vulnerability [07:03]
[USN-5407-1] Cairo vulnerabilities [07:10]
crafted image / font files
[USN-5408-1] Dnsmasq vulnerability [07:24]
[USN-5409-1] libsndfile vulnerability [07:46]
[USN-5410-1] NSS vulnerability [07:54]
crash a server by sending multiple of these
[USN-5411-1] Firefox vulnerabilities [08:06]
DoS, bypass permission checks etc)
[USN-5412-1] curl vulnerabilities [08:24]
fuzzing?
parameters had been changed
DoS
wrongly and so end up visiting wrong URL or bypassing access checks /
filters etc
which are due to C mistakes vs general programming logic mistakes -
general mistakes higher so I assume this is used as an argument as to why
implementing such a ubiquitous piece of software in such an unsafe
language is “ok” - can’t say I agree
mistakes - non-C mistakes take longer to find, presumably due to lack of
good tools for finding them (compared to say UBSan, Coverity etc for
finding C specific mistakes)
Goings on in Ubuntu Security Community
What’s new in security in Ubuntu 22.04 LTS (part 2) [11:35]
migration guide which explains the main changes from 1.1.1 as well
as how to enable the legacy provider if you still require access to
them
protocols (and below)
improved handling of FIDO/U2F hardware tokens - openssh in 20.04 LTS
first introduced support for FIDO/U2F tokens as 2FA for remote SSH
logins - basically would generate a new openssh key where the private
half of the key is only accessible with the FIDO/U2F token - this new
release brings support for using a PIN with the token and much better
improved UX so that users don’t have to keep getting prompted for
their PIN each time. Plus supports verifying WebAuthn signatures
userspace tooling to control that
implement network packet classification and handling - aka firewalling
etc
xtables and nftables (nft) for nftables
users would be switched to that automatically - so can still use
traditional iptables command to configure firewall rules etc but they
will then be loaded into the kernel’s nft backend rather than xtables
backend which supports more advanced rule types
the same backend in the kernel otherwise they may conflict and get
weird results
deref, unsafe calls within signal handlers and more
hence is deterministic based on the original seed value
reproducible / deterministic - ie. is actually more truly random
Get in contact