Ubuntu Security Podcast

By Ubuntu Security TeamTechnology

Ubuntu Security Podcast episodes

August 19, 2022Episode 173
Overview
This week we take a look at the recent announcement of .NET 6 for Ubuntu
22.04 LTS, plus we cover security updates for the Linux kernel, Booth,
WebKitGTK, Unbound and more.
This week in Ubuntu Security Updates
24 unique CVEs addressed
[USN-5562-1] Linux kernel vulnerabilities [00:49]
11 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-34918
CVE-2022-28893
CVE-2022-1975
CVE-2022-1974
CVE-2022-1734
CVE-2022-1679
CVE-2022-1652
CVE-2022-1048
CVE-2022-0494
CVE-2022-2586
CVE-2022-2588
5.4 20.04 LTS GA etc + 18.04 HWE etc
3 high priority CVEs
2 of these covered in last week’s episode 1 in netfilter and 1 in
network packet scheduler
New this week is a second CVE in the netfilter subsystem - affects
kernels since 4.1 - type confusion bug leading to a buffer overflow ->
code execution within the kernel and hence privilege escalation -
requires an attacker to gain CAP_NET_ADMIN which is privileged, but
with unprivileged user-namespaces this is trivial - so can mitigate
this by disabling unpriv userns - but this may then affect applications
like Google Chrome and others which use this to setup their sandboxes
etc
sudo sysctl kernel.unprivileged_userns_clone=0
[USN-5564-1] Linux kernel (Intel IoTG) vulnerabilities [02:32]
15 CVEs addressed in Jammy (22.04 LTS)
CVE-2022-34918
CVE-2022-33981
CVE-2022-29901
CVE-2022-29900
CVE-2022-28893
CVE-2022-1975
CVE-2022-1974
CVE-2022-1789
CVE-2022-1734
CVE-2022-1679
CVE-2022-1652
CVE-2022-0500
CVE-2022-2585
CVE-2022-2586
CVE-2022-2588
5.15 Intel IOTG
https://ubuntu.com/download/iot/intel-iotg
Atom x6000E, Pentium, Celeron N and J series processors
Similar to above, but also includes a 4th high priority CVE in the POSIX
timers subsystem - UAF which could be triggered by an unpriv user ->
priv esc - since kernel 5.7 only
[USN-5566-1] Linux kernel vulnerabilities [03:08]
9 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-34918
CVE-2022-29901
CVE-2022-29900
CVE-2022-28893
CVE-2022-1679
CVE-2022-1652
CVE-2022-2585
CVE-2022-2586
CVE-2022-2588
5.15 public cloud optimised kernels (IBM, GCP, AWS, GKE, Azure, Oracle) +
KVM and Raspi
All 4 high priority CVEs mentioned above
[USN-5565-1] Linux kernel vulnerabilities [03:34]
5 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-29901
CVE-2022-29900
CVE-2022-2585
CVE-2022-2586
CVE-2022-2588
5.15 22.04 LTS GA + 20.04 LTS HWE
POSIX timers, netfilter and network scheduler UAFs
[USN-5567-1] Linux kernel (OEM) vulnerabilities [03:48]
3 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-2585
CVE-2022-2586
CVE-2022-2588
5.17 OEM 22.04 LTS, 5.14 OEM 20.04 LTS
POSIX timers, netfilter and network scheduler UAFs
[USN-5563-1] http-parser vulnerability [04:00]
1 CVEs addressed in Bionic (18.04 LTS)
CVE-2020-8287
HTTP parsing library written in C by Joyent (not actively maintained
anymore either) - parses requests & responses without making any
syscalls, memory allocations or buffering of data
Request smuggling vuln - would allow two copies of a particular header
within a HTTP message - ie. 2 Transfer-Encoding - but would only process
the first - could then allow the second to be misinterpreted by other
proxies etc which could then be used for a request smuggling attack
[USN-5556-1] Booth vulnerability [05:20]
1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-2553
Ignored the authfile directive in its config file, allowing sites / nodes
which did not have the correct auth key to communicate with nodes that
did - oops… - upstream refactored code previously which introduced this
vuln - reverted the refactor to fix this
[USN-5568-1] WebKitGTK vulnerabilities [05:57]
3 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-32816
CVE-2022-32792
CVE-2022-2294
Heap buffer overflow in WebRTC, UI spoofing and OOB write - all able to
be triggered by a malicious website -> RCE or other
[USN-5569-1] Unbound vulnerabilities [06:22]
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-30699
CVE-2022-30698
Failed to properly handle delegation caching - an attacker could query
unbound just at the time when the cached delegation info is about to
expire - unbound then queries the upstream nameserver which could then
delay its response until the cache expires in unbound - when receiving
the response unbound would overwrite the now expired one - and so the
attacker can continue to do this and hence keep the rogue delegation
information in the unbound cache
[USN-5526-2] PyJWT regression [07:10]
Affecting Jammy (22.04 LTS)
[USN-5526-1] PyJWT vulnerability [08:58] - upstream patch bumped the
package version to 2.4.0 and so when including this, the internal package
version got bumped even though the deb package version didn’t - so would
get files installed as say 2.4.0 even though the deb is 2.3.0 which could
possibly cause a regression due to a change in path - fixed to revert
this internal package version bump
Goings on in Ubuntu Security Community
.NET 6 now available in Ubuntu 22.04 LTS [07:45]
https://devblogs.microsoft.com/dotnet/dotnet-6-is-now-in-ubuntu-2204/
dotnet6 package in Ubuntu contains the .NET 6 SDK - so can do .NET
development on Ubuntu
In the future, Microsoft will share CVE info ahead of public releases
with Ubuntu so that we can release updates for the package in Ubuntu as
they become publicly known
Also includes new ‘chiseled’ containers - ultra-slimmed down docker
containers to provide just the minimum needed - think of it as the
Canonical version of distroless containers.
results in a 100MB saving in container size whilst still providing
everything that is needed
Similar in size to Alpine containers (Chiseled Ubuntu 22.04 aspnet
104MB cf. apsnet:6.0-alpine 100MB)
Alpine has traditionally been praised for their minimal size, but use a
different libc (musl) and has other differences too
So can now get the benefit of a familiar Ubuntu container environment
that you know and love along with the benefits of a super small
container image (including things like decreased attack surface etc)
Also includes the benefit of a secure supply chain from Canonical direct
to Microsoft so that the provenance of Ubuntu-based .NET images is
known - instead of previously where these were pulled from Dockerhub
And in the future will include signed images as well so that consumers
of these images can also verify them too
Get in contact
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@ubuntu_sec on twitter
12 min
August 12, 2022Episode 172
Overview
Finally, Ubuntu 22.04.1 LTS is released and we look at how best to upgrade,
plus we cover security updates for NVIDIA graphics drivers, OpenJDK,
Django, libxml, the Linux kernel and more.
This week in Ubuntu Security Updates
52 unique CVEs addressed
[USN-5547-1] NVIDIA graphics drivers vulnerabilities [00:43]
3 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-31608
CVE-2022-31615
CVE-2022-31607
Local priv-esc by user with basic capabilities (?) - likely memory
corruption since apparently could also DoS, perform data tampering and
info leaks
Also NULL ptr deref in kernel driver able to be triggered from “local
user with basic capabilities” -> DoS
Also shipped a DBus configuration for the Dynamic Boost component - this
is a system wide power controller which manages CPU and GPU power basd on
overall system workload to get best system performance per watt -
according to upstream documentation. Is only active when on AC power.
Is not enabled by default but shipped a DBus policy file that allowed
any process to communicate with the nvidia-powerd server and hence to
perform privileged actions through it
[USN-5546-1, USN-5546-2] OpenJDK vulnerabilities [03:09]
10 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-34169
CVE-2022-21549
CVE-2022-21541
CVE-2022-21540
CVE-2022-21496
CVE-2022-21476
CVE-2022-21443
CVE-2022-21434
CVE-2022-21426
CVE-2022-21449
openjdk-8,11,17 for Ubuntu 18.04, 20.04 & 22.04 LTS
openjdk-8 for Ubuntu 16.04 ESM
Most interesting is “Psychic Signatures” bug - described even in the
upstream advisory as an “easily exploitable vuln”, where an attacker
could forge certain SSL certificates (ie ones using ECDSA signatures) and
hence allow them to intercept or modify communications without being
detected.
When adding support for validating ECDSA signatures, failed to check the
provided signature values were not zero - a signature consists of two
values, r and s and these are used to then perform a bunch of
calculations to check it is valid - this involves comparing r against r
multiplied by a value derived from s - so if r and s are both zero you
effectively check 0 = 0
Affects anything which uses ECDSA signatures - including signed JWTs,
SAML assertions, WedAuthn messages etc
This only affected openjdk 15 though 18 since this code was rewritten in
native Java (previously was C++ which was not vulnerable) for Java 15 -
so for Ubuntu this is openjdk-17 only which is not the default JRE
(openjdk-11 is)
[USN-5549-1] Django vulnerability [06:16]
1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-36359
Possible “Reflected File Download” attack - attack type first detailed at
BH Euroe in 2014 - causes a web application to “virtually” download a file from a
trusted domain - which then can get executed since is trusted
Usually involves the application failing to validate input such that an
attacker can craft header content to get reflected into the response
body - this is then the contents for a file, as well as get some content
injected in the resulting filename - and then cause the response to be
downloaded which will
In this case, if a Django application was setting the Content-Disposition
header of a FileResponse object based on a filename which is derived from
user input - fixed to escape the filename so can’t then inject content
into the Content-Disposition header
[USN-5550-1] GnuTLS vulnerabilities [07:55]
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-2509
CVE-2021-4209
NULL pointer deref and double-free during verification of pkcs7
signatures -> DoS / RCE
[USN-5551-1] mod-wsgi vulnerability [08:10]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-2255
Would pass through the X-Client-IP header to WSGI applications, even when
it came from an untrusted proxy and hence could allow unintended access
to services
[USN-5548-1] libxml2 vulnerability [08:32]
1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2016-3709
Possible HTML/code injection -> XSS since would fail to properly handle
escape server-side includes
Reported back in 2016 to GNOME project, was seemingly ignored until the
offending commit which introduced the vuln was reverted ~2 years ago
Later versions not affected then
CVE only assigned a few weeks ago
Interestingly the discussion in 2018 included a pointer to three
different CVEs in other XML/HTML parsing and sanitization libraries for
the same type of issue - but in this case was ignored and no CVE assigned
until now
[USN-5552-1] phpLiteAdmin vulnerability [11:29]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2021-46709
XSS through failure to validate the newRows parameter
[USN-5553-1] libjpeg-turbo vulnerabilities [11:42]
4 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2020-17541
CVE-2020-14152
CVE-2018-14498
CVE-2018-11813
Various memory corruption issues -> heap and stack buffer overflows
Logic issue and a failure to limit overall memory consumption during
decompression leading to very large memory usage -> DoS
[USN-5554-1] GDK-PixBuf vulnerability [12:06]
1 CVEs addressed in Focal (20.04 LTS)
CVE-2021-46829
Heap buffer overflow for crafted animated GIFs -> code execution
particularly on 32-bit platforms
[USN-5555-1] GStreamer Good Plugins vulnerabilities [12:29]
7 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-2122
CVE-2022-1925
CVE-2022-1924
CVE-2022-1923
CVE-2022-1922
CVE-2022-1921
CVE-2022-1920
Various integer overflows etc leading to heap buffer overflows in various
video codec handlers -> DoS / RCE
[USN-5558-1] libcdio vulnerabilities [13:00]
2 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2017-18199
CVE-2017-18198
Audio CD read/control library
2 different memory management issues when handling crafted ISO files -
heap buffer over-read and NULL pointer dereference -> DoS
[USN-5557-1] Linux kernel vulnerabilities [13:44]
2 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2022-2586
CVE-2022-2588
4.4
UAF in Network package scheduler - could create a route filter which when
removed would still be referred to by other data structures and then
allow a user to trigger access to this -> DoS / RCE
Similarly in netfilter, could have one nft object be referred to by an
nft set in another table -> UAF
[USN-5560-1, USN-5560-2] Linux kernel vulnerabilities [14:37]
13 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS)
CVE-2022-34918
CVE-2022-33981
CVE-2022-1975
CVE-2022-1974
CVE-2022-1734
CVE-2022-1729
CVE-2022-1679
CVE-2022-1652
CVE-2022-1195
CVE-2022-1048
CVE-2022-0494
CVE-2022-2586
CVE-2022-2588
4.15 GA for 18.04 LTS, HWE etc for 16.04 ESM, Azure for 14.04 ESM
Various vulns plus the 2 network related UAFs above
[USN-5561-1] GNOME Web vulnerabilities [14:58]
4 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-29536
CVE-2021-45087
CVE-2021-45086
CVE-2021-45085
Epiphany web browser
3 different XSS issues, 1 buffer overflow via a very long page title ->
gets ellipsised but UTF-8 length of ellipsis is not properly counted so
then overflows bounds -> DoS/RCE
[USN-5559-1] Moment.js vulnerabilities [15:40]
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-31129
CVE-2022-24785
Date handling library for nodejs applications
Path traversal vuln since could end up using a user provided locale
string to switch the locale which would then result in reading arbitrary
local files
Quadratic complexity algorithm due to use of regexps to parse strings to
dates - in particular rfc2822 formats which are tried by default - ReDoS
-> very large input could result in significant CPU-based DoS
Goings on in Ubuntu Security Community
Ubuntu 22.04.1 LTS released [16:43]
https://lists.ubuntu.com/archives/ubuntu-announce/2022-August/000282.html
https://discourse.ubuntu.com/t/jammy-jellyfish-release-notes/24668
https://www.youtube.com/watch?v=REdxblQpsDE
Includes all the various bug and security fixes that have gone into the
22.04 LTS release so far - if you are already running 22.04 LTS you don’t
have to do anything to get this- just make sure you have been installing
updates 😉
The full list of changes targeted for this release can be found at
https://discourse.ubuntu.com/t/jammy-jellyfish-point-release-changes/29835
Now is when users of 20.04 LTS desktop will start being prompted to
upgrade to 22.04 - I definitely recommend to upgrade, and to make the
process as smooth as possible, do it from a virtual terminal
This is the standard interface used for Ubuntu Server - full-screen
terminal running directly on a console - no graphical environment
as such, has a lot less processes and infrastructure running and so
there is less chance that something may crash during the upgrade
process - since libraries get swapped out from underneath various
running processes etc
Log out of your graphical session, then when at the GDM Greeter / user
chooser log in screen hit CTRL + ALT + F2
You will then be presented with a console prompt - log in with your
username and password, then you can start the upgrade process by running
sudo do-release-upgrade
This is the same way this is done for Ubuntu Server
Get in contact
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@ubuntu_sec on twitter
22 min
August 05, 2022Episode 171
Overview
This week we dig into what community sponsored security updates are all
about, plus Ubuntu 22.04.1 LTS gets delayed by a week and we cover security
updates for MySQL, the Linux kernel, Samba, Net-SNMP and more.
This week in Ubuntu Security Updates
75 unique CVEs addressed
[USN-5535-1] Intel Microcode vulnerabilities [00:43]
10 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2021-33120
CVE-2021-33117
CVE-2022-21166
CVE-2022-21151
CVE-2022-21125
CVE-2022-21127
CVE-2022-21123
CVE-2021-0127
CVE-2021-0146
CVE-2021-0145
Latest upstream release IPU 2022.1
[USN-5486-1] Intel Microcode vulnerabilities
Includes fixes for MMIO stale data which we covered in News on latest Intel security issues in Episode 164
[USN-5537-1, USN-5537-2] MySQL vulnerabilities [01:22]
18 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-21569
CVE-2022-21553
CVE-2022-21547
CVE-2022-21539
CVE-2022-21538
CVE-2022-21537
CVE-2022-21534
CVE-2022-21531
CVE-2022-21530
CVE-2022-21529
CVE-2022-21528
CVE-2022-21527
CVE-2022-21526
CVE-2022-21525
CVE-2022-21522
CVE-2022-21517
CVE-2022-21515
CVE-2022-21509
Latest point releases from Oracle
8.0.30 for 20.04 and 22.04 LTS
5.7.39 for 18.04 LTS and 16.04 ESM
As always - includes both security and bug fixes as well as new features
and possible incompatible changes
[USN-5538-1] libtirpc vulnerability [01:59]
1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2021-46828
Transport independent RPC library - Used by autofs, libvirt, nfs-utils,
python, samba, yp-tools and lots more
Failed to properly handle timeouts from idle clients - would still keep a
file descriptor open and eventually would exhaust available fds so could
then not accept new connections (since it would also not handle the case
of no available fds either and would spin in a busy loop trying to accept
new connections) - CPU-based DoS
[USN-5536-1] Firefox vulnerabilities [02:47]
6 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-36320
CVE-2022-36319
CVE-2022-36318
CVE-2022-36316
CVE-2022-36315
CVE-2022-2505
103.0
Firefox is now a snap on 22.04 LTS so gets updated automatically by
Mozilla
[USN-5544-1] Linux kernel vulnerabilities [03:06]
4 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-1652
CVE-2022-34918
CVE-2022-28893
CVE-2022-1679
5.15 22.04 LTS GA / 20.04 LTS HWE
UAF in Atheros ath9k driver when handling certain error conditions, Sun
RPC and floppy driver
Also a type confusion bug in netfilter - local user who has CAP_NET_ADMIN
(which can be done via mapping to root in an unprivileged user
namespace) -> privesc
[USN-5545-1] Linux kernel (OEM) vulnerability [03:49]
1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-34918
netfilter privesc above for 5.14 and 5.17 OEM kernels in 20.04 and 22.04
LTS respectively
[USN-5539-1] Linux kernel vulnerabilities [04:11]
7 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-33981
CVE-2022-28388
CVE-2022-1789
CVE-2022-1205
CVE-2022-1204
CVE-2022-1199
CVE-2022-1195
5.4 - NVIDIA BlueField on 20.04 LTS and GCP/GKE 18.04 LTS
6 out of 7 are various UAF bugs - 3 in the AX.25 amateur radio protocol
driver, 1 in 6pack and mkiss protocol drivers, 1 in 8 Devices USB2CAN and
1 in floppy driver
KVM hypervisor failed to handle guest TLB invalidations - guest could
then corrupt host memory
Result of all these is memory corruption -> crash / code-execution
[USN-5541-1] Linux kernel (Azure) vulnerabilities [05:04]
11 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-28389
CVE-2022-28388
CVE-2022-2380
CVE-2022-1516
CVE-2022-1353
CVE-2022-1205
CVE-2022-1204
CVE-2022-1199
CVE-2022-1198
CVE-2022-1011
CVE-2021-4197
4.15 azure
Most of the same vulnerabilities mentioned earlier plus some covered in
previous episodes - cgroup process migration privesc, UAF in FUSE etc
[USN-5540-1] Linux kernel vulnerabilities [05:26]
4 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2022-34918
CVE-2022-25375
CVE-2022-25258
CVE-2022-20141
4.4 - 16.04 ESM GA (lowlatency, AWS, KVM etc) + 14.04 ESM
race-condition -> UAF in IGMP protocol impl - local user -> DoS /
code-exec
Memory corruption in USB gadget driver
OOB read in RNDIS driver -> info leak / crash
netfilter privesc
[USN-5542-1] Samba vulnerabilities [06:06]
6 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-32746
CVE-2022-32745
CVE-2022-32744
CVE-2022-32742
CVE-2022-2031
CVE-2021-3670
Didn’t handle MaxQueryDuration as expected
Possible privesc since restrictions were not enforced properly when
changing passwords
Separate password-based privesc since could forge a password request with
your own key that was destined for another user and therefore change
their password (including domain admin)
Memory corruption via crafted LDAP request -> DoS / info leak
Unfortunately due to the large amount of code-churn in samba from the
version used in 18.04 LTS (4.7.6) compared to the current upstream
release (4.16.x) it is not possible to backport these patches without a
reasonable risk of introducing a regression - as such users of samba in
18.04 LTS who are concerned about these vulnerabilities are advised to
upgrade to Ubuntu 20.04 LTS or newer to continue receiving security
support for samba
[USN-5543-1] Net-SNMP vulnerabilities [07:25]
6 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-24810
CVE-2022-24809
CVE-2022-24808
CVE-2022-24807
CVE-2022-24806
CVE-2022-24805
Various memory corruption bugs (OOB reads, NULL ptr derefs, buffer
overflows) which could be triggered via crafted SNMP requests -> crash
(DoS), RCE
[USN-5463-2] NTFS-3G vulnerabilities [07:45]
7 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2022-30787
CVE-2022-30785
CVE-2022-30789
CVE-2022-30788
CVE-2022-30786
CVE-2022-30784
CVE-2022-30783
[USN-5463-1] NTFS-3G vulnerabilities - Episode 163
DoS / RCE via mounting crafted disk image, mishandling of file handles -
arbitrary memory R/W, intercept traffic between FUSE and kernel -> info
leak etc
Goings on in Ubuntu Security Community
An overview of the community security updates sponsoring process [08:20]
Ubuntu Security team supports packages in main+restricted as per standard support
Universe (and multiverse) components are supported by the community
The ideal process here is a community member files a bug on LP,
subscribes the Ubuntu Security Sponsors team and attaches a debdiff
What is a debdiff?
A debdiff is a diff of the source package between the current version
in the Ubuntu archive and the new updated version being proposed
What should the debdiff contain?
The bare minimum of changes required to patch the vulnerability
ie. a patch file derived from the original upstream project’s patch
which fixed the vulnerability, as well as a new changelog entry
describing this update
In general even though an upstream project may release a new version
of their software when patching security vulnerabilies, in Ubuntu we
will not just upgrade to this new version (in the lifetime of a
stable release) to fix the vulnerability - instead we will just
cherry-pick the minimal change required to fix the issue and apply
this ontop of the older version of the software which is maintained
for the life a given Ubuntu release
This reduces the chance of introducing a regression due to new
upstream features getting introduced etc
https://wiki.ubuntu.com/SecurityTeam/FAQ#Versions
https://wiki.ubuntu.com/StableReleaseUpdates#Why
Regarding patches - most packages use Quilt to manage the set of
patches that get applied ontop of the upstream source tarball within a
debian package
Therefore the debdiff should likely be a new patch file within the
debian/patches directory as well as a corresponding entry for it in the
debian/patches/series file, and then a new debian/changelog entry
Sometimes to backport a fix other supporting commits from the upstream
project may be needed - these can then be included as additional patch
files too
What happens next?
Ubuntu Security team member reviews the debiff to make sure it conforms
to the above - in particular to check that the original upstream patch
was used and no other changes were introduced (again to make sure we
keep the risk of regression low and so we have provenance of the code
which has been introduced)
Will usually do a local build of the package and then upload it to the
Ubuntu Security Proposed PPA - this is a publicly accessible PPA which
allows the resulting candidate packages to be tested by the Security
Team member as well as the community member
Once testing looks good, the package can be published to the Ubuntu
archive along with an associated USN
A recent examples of this is in
https://bugs.launchpad.net/ubuntu/+source/spip/+bug/1971185 which
corresponded to USN-5482-1 - SPIP for bionic
The team maintains a lot of documentation on how we set up our local
build and testing environments to make the process a lot easier - in
particular the umt tool which can be used for managing most of these
steps (ie. downloading source packages, adding a new changelog entry,
building the package locally in a schroot, testing the package locally in
a VM etc)
Ubuntu 22.04.1 release delayed [17:00]
https://discourse.ubuntu.com/t/jammy-jellyfish-22-04-1-lts-point-release-status-tracking/29102
Delayed until 11th August - can see test status on the ISO tracker -
essentially was a bug in snapd when being installed in OEM mode
Used by OEMs to install Ubuntu on machines so that when first powered
on by the end user they are offered to setup the machine (create a
local user account, set timezone/language etc)
Bug is that firefox wouldn’t run
As earlier, Firefox is now a snap in 22.04 LTS - and the bug is that all
snaps which are seeded (ie. shipped on the ISO and installed OOTB) would
not run
only 2 applications fit this - firefox and snap-store - but both are
crucial applications (ie web browser and app store)
snaps are squashfs images that get mounted on boot as systemd mount units
like many systemd units, they specify as WantedBy=multi-user.target - ie
the multi-user target wants them which ensures they are mounted during
normal boot (equivalent to runlevel 2 - ie. not a rescue shell or
shutdown etc) - so basically any normal boot of the system and they
should be mounted
During OEM mode though, on that first boot by the user, the OEM installer
has set the boot target to it’s own oem-config.target so it can run first
(to create a new user etc) - and then once it is done it sets the target
to the usual graphical.target which includes multi-user.target
Everything then should work though as we do eventually hit the right target
Current thinking is that the new snapd-desktop-integration which is used
to try and automatically install theme snaps and the like to match the
system theme - gets started as part of the oem-config and it then
pokes the snapd.socket which causes snapd.service to be started - yet the
snap mount units are not in place, so snapd can’t see any of the expected
snaps, as such it fails to correctly generate their state information
when they do go to be run, they have none of their expected interfaces
defined or connected and so cannot access anything and fail - and even a
reboot doesn’t help as the old invalid state is still kept even though
the snaps are now mounted correctly
requires a fix in snapd so that the mount units specify not just
multi-user.target but default.target so they get mounted no matter what
target is being booted into
Get in contact
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@ubuntu_sec on twitter
23 min
July 29, 2022Episode 170
Overview
This week we’re diving down into the depths of binary exploitation and
analysis, looking at a number of recent vulnerability and malware
teardowns, plus we cover security updates for FreeType, PHP, ImageMagick,
protobuf-c and more.
This week in Ubuntu Security Updates
22 unique CVEs addressed
[USN-5528-1] FreeType vulnerabilities [01:03]
4 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-31782
CVE-2022-27406
CVE-2022-27405
CVE-2022-27404
Various heap buffer overflows - all which could be triggered from a
crafted font file
[USN-5529-1] Linux kernel (OEM) vulnerabilities [01:22]
11 CVEs addressed in Jammy (22.04 LTS)
CVE-2022-1652
CVE-2022-34495
CVE-2022-34494
CVE-2022-21166
CVE-2022-21125
CVE-2022-21123
CVE-2022-2078
CVE-2022-1973
CVE-2022-1852
CVE-2022-1789
CVE-2022-1679
5.17 22.04 LTS OEM
[USN-5530-1] PHP vulnerability [01:41]
1 CVEs addressed in Jammy (22.04 LTS)
CVE-2022-31627
php-8.1 in 22.04 LTS - heap buffer overflow in finfo_buffer function -
used to get info etc from a binary string - in the example in the
upstream documentation shows using this function to get the MIME info of
a $_POST parameter - so likely this is being used in a bunch of places on
untrusted data - DoS/RCE
[USN-5532-1] Bottle vulnerability [02:34]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-31799
Python framework for building web-applications
Failed to handle errors properly - could allow a remote request to
trigger an exception -> DoS
[USN-5533-1] Vim vulnerability [02:50]
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-2129
Another OOB write in vim -> crash / RCE
[USN-5534-1] ImageMagick vulnerabilities [02:58]
3 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-32547
CVE-2022-32546
CVE-2022-32545
Someone has been running ImageMagick via UBSAN - found a number of cases
of possible UB - impact is not clear but could be possible to crash/RCE
etc
[USN-5531-1] protobuf-c vulnerability [02:32]
1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-33070
Used to compile protobuf specification to C code along with a library
which is then linked against that generated code to marshal/unmarshal
protobuf’s
Invalid arithmetic shift - previous code would right shift signed values
which is implementation defined - so depending on what compiler was used
could have different behaviour - and thus result in code that would write
outside of memory bounds etc - fixed by converting the code to cast to
unsigned type before shifting so that the behaviour is known
Goings on in Linux Security Community
Introduction to x64 Linux Binary Exploitation by @ch0pin [04:24]
Great series of blog posts from earlier this year
Starts by creating a small program with a basic stack buffer overflow
vulnerability
Then disables all the various hardening features which have been added to
Ubuntu to then allow it to be easily exploited
Along the way explains memory layout, processor architecture etc to help
understand the process of developing exploits
Further blog posts in the series then start to enable the various
hardening features one-by-one and in the process walk through more
detailed and complex techniques for defeating these
Great insight to the process - also includes good references along the
way to other sources of documentation / information on related concepts
Part 1 - Basic Buffer Overflow
https://valsamaras.medium.com/introduction-to-x64-linux-binary-exploitation-part-1-14ad4a27aeef
Part 2 - Return into libc
https://valsamaras.medium.com/introduction-to-x64-binary-exploitation-part-2-return-into-libc-c325017f465
Part 3 - RoP gadgets and chain
https://valsamaras.medium.com/introduction-to-x64-linux-binary-exploitation-part-3-rop-chains-3cdcf17e8826
Part 4 - Stack Canaries
https://valsamaras.medium.com/introduction-to-x64-linux-binary-exploitation-part-4-stack-canaries-e9b6dd2c3127
Part 5 - ASLR overview and bypass technique
https://valsamaras.medium.com/introduction-to-x64-linux-binary-exploitation-part-5-aslr-394d0dc8e4fb
CVE-2022-20186 vulnerability + exploit walkthrough by Github [07:04]
https://github.blog/2022-07-27-corrupting-memory-without-memory-corruption/
Vulnerability in the ARM Mali GPU driver in the Android kernel
Walks through the code to give a good understanding of how memory pages
are handled by the driver and then eventually how this can be exploited
from userspace to overwrite arbitrary kernel memory due to an integer
overflow bug
Even includes an exploit for Pixel 6 (patched with the June Pixel update
from Google)
Interesting footnote about how the patch for the vuln was visible in the
Android tree 2 weeks before the vulnerability was disclosed
A detailed technical teardown of Symbiote by @GeeksCyber [08:49]
https://cybergeeks.tech/how-to-analyze-linux-malware-a-case-study-of-symbiote/
We covered a different teardown of Symbiote back in Episode 163 - this
one has a fair bit more technical details along with disassembled code
sections - good chance to put your skills in Linux binary exploitation to
the test to follow along with the analysis
The Utopic Tale of Ubuntu by the Linux User Space podcast [09:31]
https://www.linuxuserspace.show/302
Starts around 9:45 - covers every year of Ubuntu from 2004 through to now
along with the major developments / highlights and some low-lights along
the way
Great walk down memory lane / background for those new to Ubuntu
Not really security specific but is a great listen (beware goes for over
1.5 hours)
Get in contact
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@ubuntu_sec on twitter
12 min
July 22, 2022Episode 169
Overview
It’s the 22.10 mid-cycle roadmap sprint at Canonical this week plus we look
at security updates for Git, the Linux kernel, Vim, Python, PyJWT and more.
This week in Ubuntu Security Updates
58 unique CVEs addressed
[USN-5511-1] Git vulnerabilities [00:45]
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-29187
CVE-2022-24765
Related to CVE-2022-24765 which we covered back in Episode 157 - this was
a vuln in Git for Windows which could allow a local user who could write
to C:\ to create a gitconfig that would contain commands that may then
get executed by other users when running git themselves
Is an issue for Ubuntu since with WSL you can now run git as shipped in
Ubuntu on Windows which then would be vulnerable (or at least it was
until we fixed it 😁)
[USN-5473-2] ca-certificates update [01:41]
Affecting Xenial ESM (16.04 ESM)
Episode 164
[USN-5513-1] Linux kernel (AWS) vulnerabilities [01:53]
19 CVEs addressed in Trusty ESM (14.04 ESM)
CVE-2022-28388
CVE-2022-28356
CVE-2022-24958
CVE-2022-21166
CVE-2022-21125
CVE-2022-21123
CVE-2022-1734
CVE-2022-1679
CVE-2022-1652
CVE-2022-1419
CVE-2022-1353
CVE-2022-0330
CVE-2021-4202
CVE-2021-4197
CVE-2021-39714
CVE-2021-39685
CVE-2021-3760
CVE-2021-3752
CVE-2021-3609
4.4 kernel for 14.04 ESM machines on AWS
Most interesting vulnerablity is a race condition in the CAN BCM
networking protocol which then results in multiple possible UAFs - the
use of unprivileged user namespaces allows a local unprivileged user to
exploit this and then gain root priviliges in the root namespace - PoC on
github along with a very detailed write-up, hence the high priority
rating given to this vulnerability
Various other similar vulns (race conditions and the like which can then
allow a local user to possibly escalate privileges to root) - but the
others don’t have public exploits, hence the medium priority rating
[USN-5514-1] Linux kernel vulnerabilities [03:11]
6 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-33981
CVE-2022-1789
CVE-2022-1205
CVE-2022-1204
CVE-2022-1199
CVE-2022-1195
5.4 GA / HWE for 18.04 LTS as well as various kernels optimised for the
different public clouds
Bunch of vulns in AX.25 amateur radio protocol implementation - local
attacker could possibly crash kernel or privesc - would likely need a
custom H/W device to do this though
Race condition in the floppy driver -> UAF etc
[USN-5515-1] Linux kernel vulnerabilities [03:41]
10 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS)
CVE-2022-28389
CVE-2022-2380
CVE-2022-1516
CVE-2022-1353
CVE-2022-1205
CVE-2022-1204
CVE-2022-1199
CVE-2022-1198
CVE-2022-1011
CVE-2021-4197
4.15 18.04 LTS GA + clouds + devices (raspi, snapdragon etc), 16.04 ESM
HWE + clouds etc
[USN-5517-1] Linux kernel (OEM) vulnerabilities [04:04]
2 CVEs addressed in Focal (20.04 LTS)
CVE-2022-34494
CVE-2022-1679
5.14 OEM
OEM kernel contains various hardware enablement features for the
different OEM platforms which Ubuntu comes pre-installed on, these
eventually find they way back to the GA/HWE kernels
[USN-5518-1] Linux kernel vulnerabilities
6 CVEs addressed in Jammy (22.04 LTS)
CVE-2022-33981
CVE-2022-1975
CVE-2022-1974
CVE-2022-1789
CVE-2022-1734
CVE-2022-0500
5.15 GA + clouds, devices, lowlatency etc
[USN-5516-1] Vim vulnerabilities [04:18]
3 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-2210
CVE-2022-2207
CVE-2022-2000
vim is definitely fast becoming one of our most updated packages -
particularly in 16.04 ESM
More bugs found via fuzzing - shows what having a bug bounty can do to
shine a light on possible vulnerabilities (or does it just attract
shallow bug hunters…) - it’s hard to say for certain how much of a
security impact these different vulnerabilities have
OOB write + 2 heap buffer overflows - all classified as high priority on
the bounty platform ($95 reward apparently for each)
[USN-5520-1, USN-5520-2] HTTP-Daemon vulnerability [05:18]
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-31081
Perl library implementing a simple HTTP server - not often used in
production (since would then use nginx or apache)
Request smuggling vuln through a crafted Content-Length parameter - could
then allow requests that would otherwise be rejected
[USN-5519-1] Python vulnerability [05:54]
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2015-20107
Oldest vuln patched this week - fix and CVE were disclosed back in April
this year but the bug was first reported back in 2015 - at that time
there was disagreement between the reporter and the upstream developers
as to whether this was a real vuln or not - this is a bug in handling of
mailcap entries - and mailcap is designed to execute arbitrary commands -
but those defined by the user - whereas in this case, if it was used to
launch a command on a crafted filename, the filename itself could specify
the command to be executed, not what the user had thought that they had
configured via their mailcap entry
Fixed to appropriately quote the arguments
[USN-5522-1] WebKitGTK vulnerabilities [07:19]
2 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-26710
CVE-2022-22677
Speaking of one of the most updated packages ;)
WebKitGTK sees regular upstream security releases (similar to Firefox)
and we publish these as they are released
UAF via crafted malcious web content -> RCE
[USN-5523-1] LibTIFF vulnerabilities [08:02]
7 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2022-22844
CVE-2020-19144
CVE-2020-19131
CVE-2022-0924
CVE-2022-0909
CVE-2022-0908
CVE-2022-0907
NULL ptr deref, div by zero -> DoS
various OOB reads -> info leak / DoS
[USN-5524-1] HarfBuzz vulnerability [08:37]
1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-33068
Integer overflow discovered via in-built fuzzer within HarrBuzz combined
with running HB with UBSan to detect memory corruption
Likely heap buffer overflow -> RCE / crash
[USN-5526-1] PyJWT vulnerability [08:58]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-29217
JSON web token implementation in python
Supports using various crypto algorithms for signing / validation including SSH public keys etc
Turns out an attacker could “sign” a JWT with the public half of an SSH
key pair as the key for one of the HMAC algorithms - as far as an API
user of PyJWT would see, the token would then validate the same as if it
had been actually signed by the private key of the same SSH public key
pair
Fixed to disallow the use of SSH public keys as inputs for signing keys
[USN-5527-1] Checkmk vulnerabilities [09:43]
5 CVEs addressed in Bionic (18.04 LTS)
CVE-2022-24565
CVE-2021-40906
CVE-2021-36563
CVE-2017-9781
CVE-2017-14955
system monitoring system / framework
various XSS vulns in web console, ability to read sensitive info from GUI
crash report
[USN-5525-1] Apache XML Security for Java vulnerability [09:56]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2021-40690
Vuln in handling of crafted XPath transform, where an attacker could read
arbitrary local XML files
Goings on in Ubuntu Security Community
22.10 mid-cycle product roadmap sprint [10:13]
This week is the 22.10 mid-cycle product roadmap sprint at Canonical
Engineering teams at Canonical work on a 6-month development cycle,
in-line with the Ubuntu release cycle - even though not all teams work on
Ubuntu
Each 6 month cycle consists of 3 week-long sprint sessions - 2 product
roadmap sprints, and 1 engineering sprint
At the start of each cycle there is an initial product roadmap sprint to
review the progress / achievements etc of the previous 6 month
development cycle and set the goals for the coming development cycle.
At the approximate mid-point of that new development cycle, 3 months
later, there is the mid-cycle product roadmap sprint to review progress
etc along the way
Generally consists of managers and senior technical team members from
each team presenting on their progress etc and reviews it with the other
teams, plus there many cross-team meetings etc
Traditionally these were in-person events but with COVID etc they all
moved to being virtual - this year has seen the resumption of in-person
sprints for the start-of-roadmap sprints but the mid-cycle ones are still
virtual
As far as the security team is concerned, we talked over various topics
like progress on FIPS certification for 22.04 LTS, as well as various
AppArmor enhancements, as well as customer specific work-items and
general progress on maintenence tasks like CVE patching, MIR security
reviews and more.
Next roadmap sprint will be at the end of October to review how this
cycle went and to set the goals for 23.04 cycle - this will also be
followed by an engineering sprint, where all members of the engineering
sprint get together for a week in-person to collaborate and hack on
whatever their team needs
That will then also be followed by a new revived Ubuntu Summit (modeled
somewhat like the old Ubuntu Developer Summits) - a chance for folks from
the community to gather in person alongside folks from Canonical to
discuss and drive forwards various features for Ubuntu and the like.
Exciting times ahead!
Get in contact
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@ubuntu_sec on twitter
15 min
July 15, 2022Episode 168
Overview
This week we rocket back into your podcast feed with a look at the OrBit
Linux malware teardown from Intezer, plus we cover security updates for
cloud-init, Vim, the Linux kernel, GnuPG, Dovecot and more.
This week in Ubuntu Security Updates
52 unique CVEs addressed
[USN-5496-1] cloud-init vulnerability
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-2084
cloud-init was originally a Canonical developed project but is now widely
used by many of the public clouds for configuring cloud images on first
boot
When validating configuration, would log invalid entries - if one of
those was a password then the password would get logged in the clear -
and cloud init logs are world readable by default
Fixed to instead log a generic error message with details on how to
obtain the actual invalid entries via a privileged command
[USN-5497-1] Libjpeg6b vulnerabilities [01:54]
5 CVEs addressed in Trusty ESM (14.04 ESM)
CVE-2018-11214
CVE-2018-11213
CVE-2020-14152
CVE-2018-11813
CVE-2018-11212
Various DoS via crafted JPEG,PPM or Targa image files
OOB read, excessive memory consumption etc
[USN-5498-1] Vim vulnerabilities [02:16]
8 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-1898
CVE-2022-1851
CVE-2022-1796
CVE-2022-1785
CVE-2022-1735
CVE-2022-1733
CVE-2022-1629
CVE-2022-0413
vim is fast becoming one of our most updated packages for security vulns
More instances of DoS or possible RCE attacks via crafted input files
found via fuzzing
[USN-5499-1] curl vulnerabilities [02:44]
2 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2022-32208
CVE-2022-27781
Episode 166
[USN-5485-2] Linux kernel (OEM) vulnerabilities [02:53]
3 CVEs addressed in Focal (20.04 LTS)
CVE-2022-21166
CVE-2022-21125
CVE-2022-21123
5.14 OEM kernel
MMIO stale data vulns (Episode 165)
[USN-5493-2] Linux kernel (HWE) vulnerability [03:03]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS),
CVE-2022-28388
5.4 and 5.13 HWE kernels respectively
8 Devices USB2CAN driver -> double free -> crash (DoS)
[USN-5500-1] Linux kernel vulnerabilities [03:21]
8 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-28356
CVE-2022-1734
CVE-2022-1679
CVE-2022-1652
CVE-2022-1419
CVE-2022-1353
CVE-2021-4202
CVE-2021-4197
4.4 GA + AWS
Usual mix of issues in various drivers -> UAFs due to various race
conditions, information leak (uninitialised memory) etc -> DoS or
possible code execution
[USN-5501-1] Django vulnerability [03:47]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-34265
Possible SQL injection if used the Trunc() or Extract() DB functions with
untrusted data
[USN-5479-2] PHP vulnerabilities [04:05]
2 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-31626
CVE-2022-31625
Episode 164
[USN-5479-3] PHP regression
2 CVEs addressed in Bionic (18.04 LTS)
CVE-2022-31626
CVE-2022-31625
[USN-5502-1] OpenSSL vulnerability [04:21]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-2097
Mishandled AES OCB (offset cookbook) mode - combines authentication with
encryption - on 32-bit x86 platforms that support AES-NI hardware
optimised instructions - would possibly miss one block of data and leave
it unencrypted
[USN-5503-1, USN-5503-2] GnuPG vulnerability [05:11]
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-34903
Possible to craft signed data such that on attempted verification GPG
would display output that appeared to show the message was correctly
signed when infact it would fail - so could possibly trick user /
application
[USN-5488-2] OpenSSL vulnerability [05:37]
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-2068
Episode 165
[USN-5505-1] Linux kernel vulnerabilities [05:46]
19 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2022-28388
CVE-2022-28356
CVE-2022-24958
CVE-2022-21166
CVE-2022-21125
CVE-2022-21123
CVE-2022-1734
CVE-2022-1679
CVE-2022-1652
CVE-2022-1419
CVE-2022-1353
CVE-2022-0330
CVE-2021-4202
CVE-2021-4197
CVE-2021-39714
CVE-2021-39685
CVE-2021-3760
CVE-2021-3752
CVE-2021-3609
4.4 - 16.04 ESM kvm kernel + 14.04 ESM HWE kernel
MMIO stale data plus various other kernel issues that have been covered
in recent episodes
[USN-5506-1] NSS vulnerabilities [06:24]
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-34480
CVE-2022-22747
Crash on empty pkcs7 sequence -> DoS
Possible free of invalid pointer -> likely crash -> DoS or possible RCE
[USN-5507-1] Vim vulnerabilities [06:48]
3 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-1942
CVE-2022-1897
CVE-2022-1968
Moar vim CVEs
[USN-5509-1] Dovecot vulnerability [06:57]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-30550
Possible privilege escalation when using similar primary and non-primary
passdb configuration entries - unlikely configuration to use in practice
but could then result in the non-primary config allowing users to access
as the primary config
[USN-5508-1] Python LDAP vulnerability [07:30]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2021-46823
ReDoS when using ldap.schema to validate untrusted schemas - DoS via
excessive CPU/memory usage
[USN-5510-1, USN-5510-2] X.Org X Server vulnerabilities [07:51]
2 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-2320
CVE-2022-2319
2 different OOB reads via various X server methods - untrusted client
could use this to crash X server or expose sensitive info
[USN-5256-1] uriparser vulnerabilities [08:07]
2 CVEs addressed in Bionic (18.04 LTS)
CVE-2021-46142
CVE-2021-46141
C library for parsing RFC 3986 compliant URIs
Not surprisingly, since C is memory unsafe, contained 2 different issue
with invalid memory management which could be triggered via crafted input
-> both resulting in UAF -> DoS / RCE
Goings on in Ubuntu Security Community
OrBit malware analysis [08:44]
https://www.intezer.com/blog/incident-response/orbit-new-undetected-linux-threat/
Similar to Symbiote which we covered in Episode 163 - Intezer has
detailed another Linux malware sample
Like Symbiote, the dropper component for OrBit targets arbitrary binaries
via the linker - however, unlike Symbiote, doesn’t use LD_PRELOAD
environment variable but instead instructs the dynamic linker via
/etc/ld.so.preload - this has benefits for the malware since the use of
the LD_PRELOAD env var has various restrictions around setuid binaries
etc - but this is not the case of /etc/ld.so.preload meaning all binaries
including setuid root ones are also “infected” via this technique and the
malware payload gets loaded for all
Then payload then hooks functions from libc, libpcap and libpam so that
all other binaries on the system which use these libraries then use the
payloads malicious variants of these functions
Allows it to then harvest credentials (via pam), evade detection (via
libpcap) and gain persistence and remote access
By hooking libc it can then also hide in plain sight by making sure when
other binaries call functions like readdir() the presence of the malware
itself is omitted - same for even execve() so that if say a binary like
ip, iptables or even strace is then executed, it can modify the output
which is returned to omit its own details
As we discussed with Symbiote, even though it goes to great lengths to
hide in plain sight, could still be detected via offline forensic
analysis etc
Interesting to see similar techniques used across the various malware
samples
No info on how initial compromise / privesc is achieved since this is
required to allow the malware to use /etc/ld.so.preload - but likely is
via vulnerabilities in privileged internet facing applications - as such,
MAC systems like AppArmor then become very useful for confining these
services so they cannot arbitrarily write to these quite privileged files
etc
POLA is one of the basic tenets of good security
Ubuntu 21.10 (Impish Indri) EOL [12:40]
Officially EOL yesterday (14th July 2022)
Will no longer receive security or bug fix updates etc
Upgrade to Ubuntu 22.04 LTS - 5 years of standard support plus 5 years of
ESM (free for personal use on up to 3 machines) - 10 years total of
support
Get in contact
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@ubuntu_sec on twitter
14 min
July 11, 2022Episode 167
Overview
This week we bring you part 3 of Camila’s cybersecurity buzzwords series -
looking at blockchain, zero trust and quantum / post-quantum security.
Decoding cybersecurity buzzwords (part 3) [00:10]
Hello listener! Hopefully I set the stage well enough last time that you
are back here today for more after getting excited about ending our cyber
security buzzword journey with a bang! A journey where we try to understand
the meaning of the word behind the buzz in order to better navigate this
crazy world of ours! A little bit of an exaggerated description, some might
say, but definitely not lacking in inspiration! If you haven’t listened to
our previous episodes I highly recommend you do so before proceeding with
this one, as preparation will be key to digest what is to come. Oh yes,
today is going to be a good one. So let’s get buzzing and let’s get into
it, shall we?
Buzzword #7 - which is the first buzzword of today: blockchain. Ah…this
one I had to do some serious research on, because even though I hear about
it all the time, as you probably do to, I didn’t really know the specifics
of how it worked. Anyway, one thing I did know is that this is DEFINITELY a
buzzword, one that started trending and gaining traction together with all
of the crypto currencies that started showing up out there. And now, I
can’t even see a job listing without the good old Blockchain developer
position included within the various openings. So, what is the notorious
blockchain afterall? Even after researching about this and learning more,
it is still a very complicated thing to explain, so please be patient with
me if I don’t get all the details right, although I will attempt to be as
accurate as possible. Well, let’s board this train and use crypto
currencies to explain how blockchains work from a HIGH LEVEL point of view,
shall we? Please do note, however, that I did say HIGH LEVEL! I am by no
means a block chain/crypto currency expert, as I previously mentioned, and
I will only share with you the basics of how this thing works, so that we
can really get past the buzzword point of the word, even though we might
not reach the true connoseuir point of it. Anyway! Let’s get to it!
Think about a blockchain as being a distributed ledger, which as per
dictionary definition is a “a book or other collection of financial
accounts of a particular type”. So, this applies to our cryptocurrency
example here, and to blockchains being applied to crypto currencies. Just
to make that very clear. Each block in the blockchain is like a page of
this ledger. What about the chain? We will get to that part soon
enough. For our cryptocurrency situation here, let’s consider that each
block in our blockchain will contain three important groups of information:
data regarding transactions that have been happening for a specific
cryptocurrency, a hash for this data and the hash of the block that was
generated before it, or, if you’d rather think of it in analogy terms, the
hash of the “page” that comes before it. What is a hash, you might ask? To
keep it simple, since our topic for today is not hashing, a hash is a fixed
size data output that is generated after the processing of some kind of
input of variable length. So, for example, a number generated as output for
the input data that is a word, which can have from 1 to…a lot of
letters. The word is processed such that the position of each letter in the
alphabet is used in a sum that starts with value 0. Word ‘blockchain’, in
this case, would have a hash of…uh, I don’t want to calculate that, so
let’s choose a simpler example. Word ‘aaa’ would have a hash of 3. There,
nice and easy…and lazy. Anyway, with a good hash function - a
cryptographic hash function - different input data, after processed by a
specific hash algorithm, will 99% of the time generate different outputs
(which is not the case for our earlier example. You can try to figure out
different words that would have the same hash. I’ll leave that as an
exercise for you). All of the outputs will possess the same format, which
is usually a fixed size sequence of alphanumeric characters, but, more than
that, for our case, predicting changes in the hash by analyzing changes in
the data is not something easy to do, that is how powerful out
cryptographic hash algorithm is. Therefore, we can look at our hashes as if
it were the fingerprint of the data it is connected to, if said data were a
person able to have fingerprints. Different data equals different
fingerprints, and forging a fingerprint, or, in other words, changing your
own, is not something you can easily or seamlessly do. Ok…that being
said, can you start seeing how our blocks actually constitute a chain? We
have various sets of data containing information about financial
transactions that are happening. Connected to each set is the hash for that
specific set, as is the hash of the set that came before it! So block n
will always know who n-1 is, n-1 will know who n-2 is, and so on and so
forth. Therefore, if I am an attacker and I want to tamper with the data in
the blockchain and say…add a transaction in which I make my worst enemy
transfer all of their funds to my account, I can’t just change the data of
a block in the middle of the chain without causing havoc for all of the
blocks that follow it. To be able to sneakily add my fake transaction into
the blockchain, not only would I need to change the data segment of the
block which will contain the transaction, I will also need to change the
“hash of the previous block” segment for all blocks that come after this
block. If I am able to do this instantaneously, say…using a computer,
then the problem is solved. But of course it wouldn’t be that easy, or else
I don’t think everyone and their mother would be freaking out about how
awesome or how safe blockchain is. What is the catch then? The blockchain
protocol forces you to provide a proof-of-work every time you wish to add a
block to the chain. What exactly does this mean? The blockchain challenges
you. It tells you: you cannot add a page to the ledger that is myself
unless you solve this very hard puzzle that even a computer will take a
humanly noticeable time to solve. This puzzle could be, for example,
discovering which set of 100 characters you need to add at the end of the
data set to force the block’s hash to start with 10 consecutive zeros. As I
previously said, it is not easy to predict what is the output of a hash
function given an input when you have a good hash function, so the easiest
way to achieve this is by brute forcing it: testing all possibilities until
you find something that matches that which you are looking for. Therefore,
to add a block to the chain, you must waste some time solving the puzzle,
which in turn means that changes made to the middle of the chain cannot
propagate instantaneously throughout the tail of the chain. You change a
block and you need to change all that follow, but for each block you will
take some time solving the puzzle before adding it to the chain. If I were
the one listening to this podcast and not the one doing the explaining, at
this point I would have two questions: (1) why does this matter if I have
full control of the blockchain? (2) Why not add your malicious transaction
to the last block instead of adding it to a block in the middle and solve
this whole ‘having to update subsequent blocks’ in order to achieve lots of
money in your bank account? I don’t know if you have these questions as
well, or started asking them after I mentioned it, but what I do know and
what I can tell you is that the same answer applies to both of these:
blockchain does not rely on a centralized entity to manage it, it is
instead distributed. Why should we care? Because then there is never only
one person that is in full control of the blockchain (the ledger). Everyone
is able to grab a copy of this blockchain, follow which transactions are
happening, and include them into a new block. If more than 50% of the peers
which participate in building the ledger agree on the new block to be
added, meaning, if more than 50% has the same resulting block after
including transactions broadcasted and gathered, then this block is
officially added to the chain and considered the last block of said
chain. Therefore, if I plan to include a fake transaction to the new block
that will be added to the chain, I need 50% of the peers that are also
listening to transactions and building this new block to agree to include
my fake transaction, which might seem simple if you have a lot of friends,
but the beauty in having a non-centralized server lies in diversity and on
the fact that most people will probably not want to partake in you shady
activities of tampering with the blockchain. And even if it is technically
possible to do this Mr.Smarty Pants - I see you there in the corner - that
will try to bring the argument down by saying “but what if I am super
powerful and I CAN convince everyone to do it”, see it as one more thing a
potential attacker needs to do, another burdensome task to perform in order
to achieve the desired result: change the block AND convince more than 50%
of the people in the peer network to go along with it. Have you ever been
in any comment section on the Internet? If you have, you know that
‘agreeing on things’ is not something the Internet community does very
well. Anyway…more than preventing you from changing the last block, the
distributed peer network will also enforce the utility of things such as
the proof-of-work. If the blockchain were to be controlled by one single
entity, then it matters less if it takes one nanosecond to perform the
proof-of-work or if it takes a few minutes. You are a single entity in
control of the data, you can eventually catch up with the new blocks that
will be added to the chain. Maybe you have 1000 super computers on the side
to calculate the blocks that will follow your tampered one, and then the
proof-of-work is rendered kind of useless. However, with a distributed
network, each peer is trying to solve the puzzle to add the next block to
the chain, and once again, you can create however many blocks with fake
data you want, if the entire peer-to-peer network disagrees with you on
what that block should be, it won’t be added to the chain…and you will
need to ask that for each new block you want to add. Other people, some of
which might not have been bribed by Mr. Smarty Pants, may end up obtaining
the next block in the chain first, and then all of your super computers
will have worked for naught, and you would need to start all over
again. It’s like participating in an auction…you can make a very high
bid…but other people can also do the same. Plus, it’s even worse because
everyone participating in the auction is actually checking your bank
account to see if you really have the money you claim to have, and if you
make a false bid…they can call you out on your lies if they wish to do
so. The last question I think remains is: what would make people want to
participate in the creation of a blockchain? Seems like too much work and
no fun, and choosing people for the job defeats the purpose of not having a
centralized entity to manage the ledger, because then, as the verb implies,
you get to CHOOSE who will participate, and you can choose whoever you
want, and maybe these will be people that will side with you. Well, for
crypto currencies I can tell you that the bang is in the buck. The person
that is the first to solve the puzzle which allows for inclusion of a new
block in the chain is rewarded with a certain amount of crypto
currency. Therefore, people want to participate in the blockchain creation
and make sure to check that all is well because they will gain something
from it. This is what we know as crypto mining. Someone who is crypto
mining is trying to earn some digital cash by adding a new block to the
crypto currency ledger before other people, and that is how the problem is
solved. Give the people something that they want and they shall follow!
Well…I think that is enough talk about blockchain, am I right? This is so
long that it has almost become a mini-episode inside of a bigger one! So
let’s move on and actually go to our next and almost last buzzword of this
series of episodes!
Next buzzword, suggested by our one and only Alex Murray, buzzword #8, is
zero trust. This one is a hard one for me to explain and I will tell you
why: I already have kinf of a zero trust mentality, or at least I have only
heard of the “zero trust way” ever since I started studying cyber
security. Or maybe it is because the term zero trust was coined very close
to the time I was born. Baby me didn’t even have to know the non-zero trust
model, because at that time the “never trust, always verify” slogan for
this model was already something people were considering. So what is zero
trust after all? I think I will begin defining it by saying it is a
model. A set of rules, frameworks and principles to take into consideration
when setting up your IT infrastructure, one that, as the slogan itself
says, trusts no one. Trusts zero persons…zero trust. Get the origin of
the name now? As a second way to define it, or as a way to compliment the
definition, let us go back and understand what is a non-zero trust model
and why the zero trust model was created. A time where the Internet was
simpler, and networks were a lot more self contained than they are
today. The clouds were only the ones you could see flying around in the sky
and WiFi was probably just a weird name someone would give to their
pet. When your entire infrastructure is restricted to one single area and
your network can only be accessed by those physically present where devices
of that network are also physically present at, it is easy to define your
headquarters and whoever is in it as being a safe space, with safe
people. You only let in people who are allowed to be in there, and people
who are allowed to be in there won’t cause any harm to the infrastructure
because they are friends, and not foes. Right? In comes the insider threat,
that disgruntled employee that decides to do malicious things to the
company’s resources and has the means to do so exactly because they are
trusted. In comes more technology that allows your infrastructure to exist
in more than one physical location, and that allows people to access
company resources from areas outside the supposed trusted security
perimeter. In come new business models for software products where third
party companies are responsible for managing resource from your own company
as part of a service provided by them together with their own software. And
then the castle walls are no longer enough to protect the kingdom, because
the kingdom is no longer just within the castle walls. Zero trust is the
model that starts to consider security when the castle walls are no longer
enough to prevent the occurrence of cyber attacks, exactly because we can
have foes which are inside our own network and because we are expanding our
own network and letting it exist beyond what would be a trusted physical
location. To mention a few exampĺes…remember our previous buzzword
‘phishing’ from a few episodes back? Well imagine that you have an attacker
which is able to successfully trick one of your employees in a phishing
campaign they are running. This employee clicks a malicious link and gives
this attacker access to the target company’s internal network with their
own set of credentials. In a model that is not zero trust, this employee’s
user might have a lot of privileges inside the network. Why not let them
access the database containing sensitive data? They work for the company,
they must be trustworthy! …and yet…now our attacker has access to that
same database because they were able to trick someone we trust into giving
them privileged information. Notice how we don’t even need to have a
disgruntled employee to have an insider threat. It can be the happiest
company in the world! All people who work for this company love it and
would never harm it…but one of its employees just became an unknowing
insider threat because they fell for the tricks of an attacker well trained
in the arts of social engineering. Attacks have evolved, so the security
model needs to evolve with it, and that is one of the advantages of
considering the zero trust model. Another example of a situation where you
might need to consider this model: nowadays we can access our work
environments from anywhere, so long as anywhere has an available WiFi
password for you to use. Maybe you work from home but you are tired of
looking at the same boring old view from outside your window. You decide to
go work at a local sweets shop for a change of scenery and a change in your
lunch menu for that day. The shop has a delightful atmosphere and also has
free WiFi. You connect to their network and start working, filled with new
energy and joy while you drink a cup of coffee and eat some delicious
‘insert any type of food that you love here’. And yet…ah, once again I
say ‘and yet’, and by now you must know some bad news is coming: and yet,
this is a free network, meaning that anyone, including attackers can
connect to it. You might use a VPN to access your company’s internal
network, which encrypts data you are sending through the public network to
it, however, you also end up using some applications without connecting to
a VPN and sometimes without even having to use encryption. An attacker is
sniffing for data, searching for gold, in this sweets shop’s local network,
and ends up running across your network traffic and is able to extract some
juicy information from it. And once again assets and resources are not kept
safe because not enough is being considered when establishing processes and
permissions for a company’s network. Yes, you are a trusted user and your
device SHOULD be trustworthy, but as many times we have seen, it is not
always that theory and practice shake hands and call it a day. IT
infrastructures have evolved, so the security model needs to evolve with
it, and that is one of the advantages of considering the zero trust
model. Oh…wait? Am I repeating myself? Then it must mean I really want
you to remember that, don’t you think? Anyway, to close this topic off, I
will say that one of the most important principles in the zero trust model
is the principle of least privilege, which is a good place to start from if
you intend to implement this model in your own environment. The principle
of least privilege states that you should only allow a user to have access
to resources that they will actually need…no less and no more. No less
because otherwise they won’t be able to do their jobs. No more because if
you give them more, you are UNNECESSARILY increasing the attack surface for
your network. If something does not exist, it cannot be taken advantage
of. And that is where I’ll leave it…so you can think about this a little
more while drinking your coffee and connecting to that free WiFi network in
a sweets shop. Careful!
Give it up to buzzword #9, our last buzzword in the list! Quantum and post
quantum security! Let’s finish this off with a big bang, pun intended for
the physics lovers out there, and talk about the eerie and wacky thing that
is quantum computing. Not really though, because I can definitely assure
you that physics is not my jam, and as the name suggests, quantum computing
is related to physics and, surprise, surprise, the quantum theory! So…I
could say that the next generation of computers will arise in quantum
computers, however, it is a little bit more complicated than that, as the
quantum computer will be useful to solve a specific set of problems, mainly
the ones it was conceptualized to solve. As a bonus, some problems it will
be able to solve include a few well known ones which we still can’t
efficiently solve with our old regular computers today. However, at the
same time problems solved by quantum computers also do not include some of
the problems which we already can solve with our old regular computers
today. Quantum computers, for example, are not too big on big data, and are
limited in their I/O capabilities…so we can keep using regular computers
for that. It also wouldn’t be very interesting to use a quantum computer to
write blog posts, or create internet memes or even use an app to listen to
this awesome podcast: shameless plug. The point is, the quantum computer
will not substitute our well known 0s and 1s calculator, it will instead be
useful, to solve a few sets of complex problems which require small data
sets as input and to model quantum systems…hence the name quantum
computers. All of that being said, instead of a son of what we know as the
current computer, we could see the quantum computer as a young cousin of
our well known 64bit friend. Quantum computing, to perform calculations,
instead of simply using the regular transistors which represent a 0 or a 1
at a certain point in time, tries to consider the collective properties of
quantum states, such as superposition, interference, and entanglement, to
obtain results we wouldn’t be able to with the technology we currently
have. Wow, so many complicated words in one sentence! I won’t explain any
of those today though, sorry about that. However, what I will explain is
that instead of bits, quantum computers use qubits. Qubits can have more
than just a 0 or 1 state at a given instant, and this state is actually
based on probabilities of results you might have for a certain task. When
solving a specific problem, a regular computer needs to test all
possibilities individually since bits can only have one state at a given
time, while a quantum computer, due to the nature of qubits, is able to go
down various paths at once since qubits are able to exist in more than one
state at a given time. Of course, to extract useful data from such a
different base unit, you need to create algorithms that will appropriately
use them and extract results from them, so quantum computer algorithms are
not the same as our regular and well known 0 and 1 logic gate
algorithms. Yes, I know…I explained a lot of stuff without actually
explaining it, and unfortunately…I can’t offer you much more. Even
scientists say they don’t fully understand quantum theory, so I can assure
that lil’ old me will not be the one to crack that code before
them. However, what I can offer you an explanation on why this has become a
CYBER SECURITY buzzword. Out of physics and back into cyber security! We
might not be using quantum computers to write blog posts about quantum
computing itself, however, we CAN use quantum computers to easily and
quickly solve problems which would kind of render our current cryptographic
algorithms useless! So, the current asymmetric cryptographic algorithms
that we use are based on mathematical premises which the quantum computer
aims to quickly ignore. One example of that is the ever difficult problem
of obtaining the prime factors for very large numbers. Being able to factor
a number and extract its prime factors might seem like something simple: 6
equals to 2 times 3. 51 equals 3 times 17, 100 equals 2 times 2 times 5
times 5…and so on. Start actually putting in some large numbers over
there and then ask yourself the same question: what are the prime factors
of 589.450.367.123.907? Now imagine that with a decimal number that has 617
digits. You might want to buy a lot of pens if you plan on doing that by
hand, because I can tell you not even your computer can do that in a viable
time frame. You will be living your billionth next life when the computer
beeps reminding you that one of your past incarnations wanted to crack that
key. The point here is, this is a difficult problem to solve and that is
why these algorithms are considered safe and are widely used in encryption
protocols for various software out there. In come quantum computers and
actually make this an easy and quick problem to solve. Yeah…I know what
you are thinking…now what? Now my friends, it is time to focus our
efforts on developing post-quantum cryptographic algorithms! And there it
is, our actual last buzzword! Have you ever heard the saying “if it ain’t
broke, don’t fix it”? Well, in this case, it will be broken, repeatedly, so
we do need to fix it! We need to find new ways to encrypt our data, and
evolve cryptographic algorithms in order to maintain confidentiality of
this data when faced with possible future quantum computer attacks. And
yes, I know that quantum computers will not be easily accessible to every
single person on the planet, at least in the beginning, as I also know that
quantum attacks won’t be your everyday script-kiddie daily attack of
choice. That does not mean, however, that we shouldn’t be preparing for a
reality we are certain will exist in the future. Better safe than
sorry. Better still encrypted than sorry!
Well friends, those are the buzzwords I have for you. I created this list
based on words I know and am quite tired of seeing everywhere, and also
based on suggestions given to me by the Ubuntu Security team! However, I do
know that these are not the only ones, and that these will definitely not
be the last words we extensively overhear regarding the cyber security
world. As we all know, technology is ever changing and ever evolving, and
in suit, the buzzwords shall follow. Maybe in a few years you can do a
check-in, go back to this episode and see what has changed and how you
might see some of these buzzwords in a different light once they have lost
their buzz and new queen bees have arrived to torment us in every cyber
security advertisement ever! Feel free to share your thoughts and share
words I might have missed that you think are cyber security buzzwords in
any of our social media channels! I hope you enjoyed this series, for now,
I bid you all farewell, and until next time! Bye!
Get in contact
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@ubuntu_sec on twitter
33 min
July 02, 2022Episode 166
Overview
From the deep-web to encryption we decode more cybersecurity buzzwords,
plus we cover security updates for Squid, Vim, the Linux kernel, curl and
more.
This week in Ubuntu Security Updates
16 unique CVEs addressed
[USN-5491-1] Squid vulnerability [00:29]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2021-46784
Possible DoS when handling Gopher protocol (early alternative to HTTP)
[USN-5487-2, USN-5487-3] Apache HTTP Server regression [01:09]
7 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS)
CVE-2022-31813
CVE-2022-30556
CVE-2022-30522
CVE-2022-29404
CVE-2022-28615
CVE-2022-28614
CVE-2022-26377
Episode 165
[USN-5492-1] Vim vulnerability [01:25]
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-2042
UAF which could be triggered when opening and then searching through a
crafted file -> crash -> DoS / RCE
[USN-5493-1] Linux kernel vulnerability [01:54]
1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-28388
GA kernels (5.13 for 21.10, 5.4 for 20.04 LTS, 4.15 for 18.04 LTS and 4.15 HWE for 16.04 ESM)
8 Devices USB2CAN driver - double-free in error scenario - local attacker
could use a crafted device to trigger -> DoS
[USN-5494-1] SpiderMonkey JavaScript Library vulnerabilities [02:47]
2 CVEs addressed in Jammy (22.04 LTS)
CVE-2022-31740
CVE-2022-28285
aka libmozjs-91 - 91.10
Jeremy Bicha from Ubuntu Desktop team
Not easy to identify security issues in mozjs - Jeremy had to search
through the list of commits in mozjs and search for bug numbers in
upsteam mozilla bug tracker which were then referenced by the various
Mozilla security advisories
also incidentally fixes a FTBFS with vendored ICU (test failure during
build)
[USN-5495-1] curl vulnerabilities [04:19]
4 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-32208
CVE-2022-32207
CVE-2022-32206
CVE-2022-32205
All 4 issues identified by Harry Sintonen
Mishandling of Set-Cookies header - crash -> DoS
mishandling of chained HTTP compression algorithms - a server which
compressed a response with a huge number of repeated steps could result
in a malloc bomb during decompression -> OOM -> DoS
Failed to properly set permissions when downloading cookies or other
files so they could possibly by read by other users - can mitigate by
making sure you use a strict umask locally (but that can have other
unintended consequences for other applications)
FTP xfer secured by krb5 - fails to properly verify messages - could
then have a MiTM inject data etc
Decoding cybersecurity buzzwords (part 2) [06:07]
From encryption to the deep/dark web Camila continues the journey into
demystifying some more of the most popular buzzwords in cybersecurity
Transcript
Hello listener! Welcome to part 2 of our cyber security buzzword series!
Last episode we talked about ransomwares, botnets and phishing attacks!
Let’s keep the bees happy and continue on in this buzzing journey of better
understanding what is the meaning behind the word and turning the
“bzzzzzzzzzz” into an “aaaaah, I see” instead! 039 If you haven’t listened
to the last episode I highly recommend you do it before you proceed with
this one, but hey, that is your choice. I don’t want to take too long with
this introduction, so, for those who are already in for this ride, without
further ado, let’s jump in! Our first word of today and the fourth
overall…we’ve talked about it before, and we are talking about it now
once again… buzzword #4 is the one and only firewall! If you listened to
the episodes involving the Ubuntu hardening topic, you already know that
our dearest friend firewall is one way to keep your network safe because it
allows you to filter and possibly block incoming and outgoing traffic in
your network. Through use of a firewall you can define that users in your
network can’t access a specific website, or you can keep connections coming
from a specific IP address from ever being established with these same
users. It’s an important job the one done by a firewall, however, it is not
100% hacker proof. A firewall does what it needs to do well, but it won’t
save you from yourself, for example, if you decide to become the victim of
every phishing campaign happening out there. So…do you see that buzzword
right there: “phishing”? That is why I recommended you listen to the last
episode, because I explain what is phishing THERE. Moving on, if e-mail
service is allowed by the firewall, a hacker can try to get to the network
through it, and in that case, my friend, you are the weakest link, as said
hacker is expecting you to make the mistake that will allow them passage
when the firewall will not do so through other ports or services in the
network. Don’t expect a wall to protect your network if your staff is
handing out keys to the building’s backdoor to anyone that mentions that
they work there!!! I am adding firewalls here on this list because ever
since the dawn of time…or at least the dawn of my time…I see the word
firewall being thrown around in television shows, in presentations that
want to nudge cyber security a little bit, and even on the thoughts of
people who are wondering “How did I get infected with malware, I have a
firewall!!!”. So…yeah. Unfortunately the buzzword became a universal term
used to describe all software and defensive techniques, even if they are
not all the same. To make an analogy, a firewall is one fruit amongst the
huge selection of different fruits that exist in this beautiful world, but
people insist on calling all fruits ‘firewalls’. I am sure you can imagine
a situation where I give you a lime and call it an apple, and I am sure
that in your imagination you are not too pleased about the result once you
bite into that fruit expecting one thing and instead getting another. You
might feel a little ‘sour’ should I decide to do such a thing. Haha, get
it? Bad jokes aside, it’s important to understand what a firewall really is
and what it can actually do for you in terms of protecting your
network. Not all attacks are the same, so not all attacks will be stopped
by a firewall. If you go beyond the buzzword and beyond the beautiful wall
and fire icon - which at this point could be called a buzzicon - you start
to actually build a defense strategy that makes sense and is efficient for
your network, one that will include a firewall, BUT will not expect it to
defend the network, cook and wash your clothes all at the same
time. Therefore, the next time your hear someone in a show mentioning that
they have breached 50% of the firewall, remember your training, remember
what a firewall actually is, and remember that if you are able to bypass
the firewall, you either did it 100% or you simply didn’t, and then relax
and laugh a little, because you used your knowledge to actually build a
defense strategy that even if an attacker bypasses the firewall by 100%,
you are able to prevent an attack from actually being successful with the
help of your other layers of defense. You fought valiantly firewall friend,
but not all threats are avoidable by you, and we know that now. We also
know now that movie security in movie networks are probably awful, because
they seem to only use a firewall to defend very important data, and the
firewall is most likely broken, being only 50% bypassed and all…geez, get a
grip, hollywood, or hacking might become TOO easy for those imaginary
hackers.
Buzzword #5: encryption…encrypting…encrypted…encrypt. This buzzword
is also one that I think can be considered a long-living buzzword. Data
encryption suffers from the same problem as firewalls in the sense that
people see it as a solution to all of their problems. Oh…and movies also
like to use the word a lot. “If my data is encrypted it is completely
safe”. Right? Wrong. What is encryption then, and what purpose does it
serve? When you encrypt your data, you are actually just encoding
it. Transforming it in such a way that whatever information is actually
imbued within it cannot be extracted because the data no longer represents
something that can be understood by a potential snooper of that data. One
encrypted character a day keeps the snooper away, or at least that is the
goal anyway. The main purpose of encryption is to maintain data
confidentiality, or, in other words, to prevent an unauthorized party from
getting access to the data that is going to be encrypted. Therefore,
encryption is a technique that will serve the purpose of encoding data in
such a way that it loses its meaning to whoever is not authorized to know
it. Who are the ones authorized? Those that have the decryption key…and
if that key is stolen or shared with someone it shouldn’t be…well then
you can say goodbye to your expected confidentiality, as this new someone
can now decode the data and interpret it as you would. I guess what annoys
me a little bit about this buzzword is the fact that it is used to make
people feel completely safe even when the situation does not necessarily
guarantee this. The most simple example I can think of is VPNs. I see
advertisements for those all the time, and in these advertisements people
mention how VPNs will help you stay safe from hackers when you are browsing
online…and that is not completely true. It depends on what the hacker is
doing. If a hacker is trying to track you and figure out what you are doing
in the internet, that is, they are trying to snoop on your browsing
activities, then yes, a VPN, which will help you mask your tracks by adding
a layer of encryption to your traffic and acting as a middle man in your
communication with your destination, will indeed protect you. Think of it
as sending an encrypted letter to an intermediary courier. Only you and the
courier know the decryption key and so anyone that tries to intercept the
letter and does not have this key will be unable to do anything about
it. They don’t know who is the actual destination of the letter nor do they
know what is the purpose of the letter, all they know is that the courier
will receive it and send it to the actual destination. Encryption keeps
your communication confidential. Once it gets to the courier, the courier
decrypts it and then sends it to the actual destination and your snooper
can’t know it is from you because the courier is also sending and receiving
data from a bunch of people, and that courier has promised secrecy to you,
meaning, it promised it won’t tell others which is your letter. Anyway, now
think about the situation where you willingly decide to access a malicious
website through a VPN. There is no encryption that will save you from your
bad choices here. An encrypted conversation with an attacker is still a
conversation with an attacker, and an encrypted malware sent to you through
your VPN tunnel will still execute in your machine should you tell it
to. So once again I tell you, use encryption but know its purpose! It is
not because a website is HTTPS, or, in other words, it is not because a
website has that little lock in the top left corner, that you are protected
from all evil lurking on the internet. All it means is that data you send
to that website’s server will be sent to it encrypted. This in turn means
that your login credentials won’t be out in the open, being sent in clear
text through the network, free to be accessed by anyone that chooses to
sniff the data in any point of the path from source to destination. They
will be encrypted, and whoever comes across this data in transit won’t be
able to know the true contents unless they have the decryption key, which
is shared between you and the server only. However, you can decide to send
encrypted credentials to an attacker as well. Malicious websites can be
HTTPS. In fact, attackers take advantage of the fact that people blindly
trust HTTPS websites because they are “encrypted” and make fake HTTPS bank
pages in order to steal credentials. Phishing attacks, remember those? So
here we have a situation where the buzz in the word is being harmful for
those that don’t actually try to understand the meaning behind it. When you
want to make sure a website is safe, not only check for the tiny lock in
the top-left corner of the browser, also do check if the website’s
certificate actually identifies that page as being authentic, as being
owned and provided by the entity that you believe it to be. So…yeah. I
guess final thoughts on this once again are: encryption is fine when you
don’t forget to combine….it with other security measures. I wanted to make
a cool rhyme, but that didn’t work out. Oh well…onto the next buzzword!
Buzzword #6: the deep web. Ooooh, spooky! Once again we are in “buzzword
because of the movies” territory. Hacker, firewall, encrypted data, network
breach, deep web. Oh, and a guy wearing a black hoodie. The cliché buzzword
we see getting thrown around every time someone wants to talk about cyber
security and sound mysterious while doing it. I mean…I can’t really blame
them, as it is human nature to enjoy mysteries and to want to solve
them. So, I guess if you are in the entertainment industry, throwing out
the word “deep web” around is indeed one of the ways to go. However, if you
are an IT professional, blindly trusting that what you see in movies is how
things actually work is definitely not. Does the deep web contain
mysterious websites and crazy mind bending information? Yes. Is it a
blackhole where only the most courageous may enter and the most bizarre may
stay? No. No! A bunch of the websites you have in the surface web also
exist in the deep web! If you want, you can do your regular browsing but
using the roads - let’s call them that for now - of the deep web
instead. All you have to do is download the software tool that will allow
you to access it. The most well known tool to do so is the Tor browser,
which will give you access to the Tor network, where lot’s of deep web
websites are hosted. So let’s talk a little bit about the Tor network and
try to understand what is the oh-so-mysterious deep web and why you can’t
access it by simply typing “Take me to the deep web” on a search engine in
your regular browser. Think about the Internet as being the entire
planet. Earth as you know it. Everyone and everything we know and can
access is inside the planet…and for the smarty pants that will try to say
“but what about space travel???”, don’t be a downer and destroy my
analogy. Use your imagination and PRETEND like all we know is inside the
planet only, which is the ONLY thing we have access to. The planet is like
the entire Internet. Now imagine all of the roads on the planet. You can
drive through them and go anywhere you want, the same way your data can
flow through the Internet and reach several destinations which will provide
you with services such as web browsing and e-mail sending. Consider now,
however, that a group of servers, or, to stick to the analogy, a group of
destinations for road trips, decide to bundle together and create their own
underground secret routes and make themselves and their services accessible
only to travelers which use those secret routes. The regular roads that
would lead you to them are destroyed and there are now a few single regular
roads that lead to the entry-points of the underground tunnels. Anyone can
enter the underground tunnels if they wish to and use the tunnels to reach
those “secret” destinations, as can anyone download a Tor browser and find
websites which are deb web or even darknet services. However, if you want
to reach your destination you must use the tunnel, and you can no longer
use maps to reach this destination, since in the underground tunnels they
provide you with no maps as they do in the surface roads. No maps so that
the destinations remain well hidden within this secret underground road
network, and so that they can “change their location” or “stop existing”
whenever they wish to do so. No records means no tracking. When entering
the underground tunnels you set up three intermediate tunnel only
destinations that will help you reach your desired end point, let’s
consider those toll booths. The first one is where you will always stop at
the beginning of your journey, the second one will connect you to the last
one, which in turn will be the one that will finally tell you which road to
follow to access the destination which will provide you with the service
you wish to access. Think now that these intermediate points recognize you
by your car color. A very specific color you and each toll booth attendant
have previously decided on, the moment you knew they would be your
intermediate stops. So the first point recognizes a red car, the second a
blue car, and the last a green car. I am using simple colors here, but to
amuse your own imagination, you can think of it as a very specific shade of
red that cannot be replicated by anyone else, meaning it will identify you
uniquely to that specific toll booth. Same goes to the blue and to the
green. Before passing through your underground toll booths you paint your
car green, then blue and then red. When you get to the first mark, the toll
booth guard recognizes the red hue of your car and identifies you as a
valid passenger. It removes the red hue and you tell it your next toll
booth stop. It forwards you in that direction, meaning it shows you the way
to the blue toll booth. You go to the blue tollbooth and the same thing
happens. It recognizes the blue hue, removes it and sees that you are going
to the green toll booth, and it directs you there. Finally, when you reach
green they do the same, but they finally send you to your final
destination. Notice that this allows you to stay anonymous because you got
in in a red car and got to your destination in a green colored car. The red
toll booth does not know your final tollbooth was green, knowing only you
went to blue, and the green does not know your starting point was red,
knowing only you came from blue. Blue does not know your starting point nor
you final destination, knowing only that you came from red and left for
green. Going back to that final destination: your final destination can be
outside of the underground tunnels and back on the main roads. You used the
underground tunnels just so that people who see you get in through the
tunnels in a red car don’t follow you and don’t know where you got
out. Your final destination, however, can also be inside the tunnel
network. If that is the case, you will never go to the actual destination,
because underground tunnel services establish an intermediate rendezvous
point for communication and service offering instead of letting you reach
them at their actual location. Knowing the secret name of the service, you
are able to obtain information on what places are set as these rendezvous
points. So…leaving the analogy for a little bit…this is basically what
the Tor network is and what at least part of the deep web is. The Tor
network is an established network inside the internet. The secret
underground roads inside of the planet’s entire road network. It still uses
roads, meaning, it still uses IP addresses and establishes communication
between devices using regular means in layers under the application layer
itself. However, it defines a private communication method within the
public internet. Anyone can download a Tor browser and access Tor websites,
which would be part of the deep web websites, however, to do so, you need
to know the website’s address in the format that will be recognized in the
Tor network. Unlike the surface web where you register the mapping of your
website name and the IP address of the server that will host that website
in order for people to be able to find it without having to memorize a
complex number to do so - thank you DNS -, in the Tor network what you will
know is the name of the onion service and the location where this service
meets clients wishing to access it. Tor nodes, our toll booths, can then
route you to this destination, where you can introduce yourself to the
server and then set a rendezvous point which is where the rest of the
communication between you will actually happen. In the Tor network, it is
not as simple as the definition of an explicit mapping that says “oh, you
want to get to this place? Here is the address!”. Nope. Here, everything is
done covertly and secretly. You have a meeting place to define the
definitive meeting place. So maybe it is a little bit mysterious after
all. I’ll give the movies that. Of course you can use the Tor network, our
secret underground tunnels, to access a regular surface web website if you
want to. It is not necessary, but a lot of people do it because it allows
for anonymous browsing. Our underground tunnels won’t allow for
identification of who sent a message that is reaching a specific
destination, remember the whole car painting process and the colorful toll
booths? Well, in technical terms, Tor uses layers of encryption and
intermediate proxy nodes in order to stop someone snooping from knowing who
is the original sender of a message arriving at a certain
destination. ENCRYPTION being used to assist in keeping anonymity and to
maintain confidentiality of the data that is being transferred by whoever
is using the Tor network. So yeah…kind of a long explanation, but
demystifying it, this is what the deep web is: encryption, intermediary
nodes, regular websites, creepy websites, and lots of bureaucracy to get
you to your final destination. Oh, wait…that’s just part of it, since Tor
is only one of the many underground tunnel networks that exists out
there. There are others with different rules, different entry regulations
and different functionalities and purposes in general. I decided to tell
you about how the most famous one of these secret networks within the
network works so that you can get the genral iceberg idea of it. However,
lady Internet is a vast place, filled with opportunity to create and embed,
so secret networks which can not have their services accessed through the
regular WWW URL are plenty out there, all you need is the will and the
knowledge of the way to explore it! Oh, and the permission as well. I am
not condoning you committing a crime here.
Anyway, I think that is enough of me talking for one episode. Tune in for
next time where we will talk about our last three buzzwords for this
series, which I might add, are three giants…all of them suggested by my
Ubuntu Security Team peers of course! Feel free to share your thoughts on
today’s episode and buzzwords in any of our social media channels, I would
love to hear what you have to say about it! For now, I bid you all farewell
and until next time! Bye!
Get in contact
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@ubuntu_sec on twitter
32 min
June 24, 2022Episode 165
Overview
This week Camila dives into the details on some of the most prolific
buzzwords flying around the cybersecurity community, plus we cover security
updates for BlueZ, the Linux kernel, Intel Microcode, QEMU, Apache and
more.
This week in Ubuntu Security Updates
58 unique CVEs addressed
[USN-5481-1] BlueZ vulnerabilities [00:38]
Affecting Bionic (18.04 LTS), Focal (20.04 LTS)
Not all vulnerabilities / security issues get CVEs ;)
Possible OOB read in A/V Remote Control Protocol profile
Possible OOB write and a possible 1-byte buffer overflow in A/V
Distribution Transport Protocol profile
[LSN-0087-1] Linux kernel vulnerability [01:20]
2 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS)
CVE-2022-1972
CVE-2022-1966
2 different netfilter issues
OOB write (can be mitigated by disabling unprivileged user namespaces)
UAF
Kernel type
22.04
20.04
18.04
16.04
14.04
aws
—
87.1
87.2
87.1
—
aws-5.4
—
—
87.1
—
—
aws-hwe
—
—
—
87.2
—
azure
—
87.1
—
87.1
—
azure-4.15
—
—
87.1
—
—
azure-5.4
—
—
87.1
—
—
gcp
87.1
87.1
—
87.1
—
gcp-4.15
—
—
87.1
—
—
gcp-5.4
—
—
87.1
—
—
generic-4.15
—
—
87.1
87.1
—
generic-4.4
—
—
—
87.1
87.1
generic-5.4
—
87.1
87.1
—
—
gke
87.1
87.1
—
—
—
gke-4.15
—
—
87.1
—
—
gke-5.4
—
—
87.1
—
—
gkeop
—
87.1
—
—
—
gkeop-5.4
—
—
87.1
—
—
ibm
87.1
87.1
—
—
—
linux
87.1
—
—
—
—
lowlatency
87.1
—
—
—
—
lowlatency-4.15
—
—
87.1
87.1
—
lowlatency-4.4
—
—
—
87.1
87.1
lowlatency-5.4
—
87.1
87.1
—
—
oem
—
—
87.1
—
—
canonical-livepatch status
[USN-5485-1] Linux kernel vulnerabilities [02:14]
3 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-21166
CVE-2022-21125
CVE-2022-21123
All GA and some HWE kernels
Intel MMIO stale data
Mentioned in passing in last week’s episode - kernels are now available
as well as microcode to mitigate these issues - once have installed the
new kernel can see if vulnerable via a new sysfs file:
cat /sys/devices/system/cpu/vulnerabilities/mmio_stale_data
Will display either Not affected, Vulnerable (no mitigation),
Vulnerable: Clear CPU buffers attempted, no microcode or Mitigation: Clear CPU buffers if have mitigation enabled and microcode to support
it
Will also display info on SMT since if vulnerable then need to disable
SMT to be completely protected
Mitigation comes with a performance hit so if not doing untrusted
virtualisation can perhaps disable it (but please do your own research
as needed 😉) via kernel command-line option:
mmio_stale_data=full # or 'full,nosmt' or 'off'
To have complete mitigation need to enable clear buffers and disable
SMT on affected CPUs
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst
[USN-5484-1] Linux kernel vulnerabilities [05:22]
5 CVEs addressed in Trusty ESM (14.04 ESM)
CVE-2022-21166
CVE-2022-21125
CVE-2022-21123
CVE-2021-39713
CVE-2022-21499
3.13 GA kernel for 14.04 ESM
2 recent high priority kernel vulns:
UAF due to race condition in network packet scheduler
Secure boot bypass through kgdb
Intel MMIO stale data
[USN-5486-1] Intel Microcode vulnerabilities [06:01]
9 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-21166
CVE-2022-21151
CVE-2022-21127
CVE-2022-21123
CVE-2021-33120
CVE-2021-33117
CVE-2021-0146
CVE-2021-0145
CVE-2021-0127
Latest intel-microcode release (20220510 / SPU 2022.1)
Originally mentioned 3 CVEs at release back in May
Now Intel have mentioned this is also required for mitigation of the MMIO
stale data issues as well
[USN-5483-1] Exempi vulnerabilities [07:08]
22 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2021-42532
CVE-2021-42531
CVE-2021-42530
CVE-2021-42529
CVE-2021-42528
CVE-2021-40732
CVE-2021-40716
CVE-2021-39847
CVE-2021-36064
CVE-2021-36058
CVE-2021-36056
CVE-2021-36055
CVE-2021-36054
CVE-2021-36053
CVE-2021-36052
CVE-2021-36051
CVE-2021-36050
CVE-2021-36048
CVE-2021-36047
CVE-2021-36046
CVE-2021-36045
CVE-2018-12648
xmp metadata parsing library
used by EOG, tracker, nemo and others
Usual mix of issues from memory unsafe languages - Stack and heap-based
OOB reads / writes, integer overflows etc
RCE / DoS
[USN-5482-1] SPIP vulnerabilities [07:55]
7 CVEs addressed in Bionic (18.04 LTS), Impish (21.10)
CVE-2022-26847
CVE-2022-26846
CVE-2021-44123
CVE-2021-44122
CVE-2021-44120
CVE-2021-44118
CVE-2020-28984
Thanks again to Luís Infante da Câmara for preparing the update for
bionic
website engine
CSRF, XSS, info disclosure, RCE
[USN-5487-1] Apache HTTP Server vulnerabilities [08:28]
7 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-31813
CVE-2022-30556
CVE-2022-30522
CVE-2022-29404
CVE-2022-28615
CVE-2022-28614
CVE-2022-26377
Request smuggling, RCE, DoS, expose sensitive info etc
[USN-5488-1] OpenSSL vulnerability [08:53]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-2068
c_rehash - very similar to CVE-2022-1292 (Episode 159) - possible code
execution if running it against certificates with crafted file names -
unlikely anyone is doing this in practice, plus upstream say this is
deprecated and instead should just use openssl rehash instead
[USN-5489-1] QEMU vulnerabilities [09:57]
7 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-26354
CVE-2022-26353
CVE-2022-0358
CVE-2021-4207
CVE-2021-4206
CVE-2021-3929
CVE-2021-3507
Various guest -> host issues via emulation drivers for various devices
(floppy disk, NVME controller, QXL display device, virtio-net,
vhost-vsock etc)
crash host QEMU, code execution, change file ownership
Decoding cybersecurity buzzwords (part 1) [10:45]
From ransomware to botnets and phishing, Camila dives into the details on
some of the most prolific buzzwords flying around the cybersecurity
community
Transcript
Hello listener! Welcome to another segment o’mine in the Ubuntu Security
Podcast! It’s been a while, but I have returned to bring some real buzz
into today’s episode! How, you might ask? The buzz will come from the
buzzwords we will be exploring…cyber security buzzwords to be more
specific. Let’s start by defining what a buzzword is, for those who might
not know this term: a buzzword is a word - or a term - that, as the name
suggests, is currently buzzing. It’s a word that is popular within the
scope of its usage. Everyone says it all the time, and it seems like you
can’t escape it. The most popular articles about topics in a specific field
use it every other sentence, people put them in big, bold and shiny letters
right there on the title of their scientific papers, and even your baby’s
first words end up being that buzzword because they end up hearing it more
than the eternal and classic infant buzz phrase “Say mama!”. A buzzword is,
therefore, a fashionable word at a specific point in time. Every field has
its own, and cyber security is not exempt from them. Today, I want to
actually explore some of the cyber security buzzwords we have and actually
try to demystify them, as buzzwords can become something much more absurd
or grandiose than they actually are just because everyone is choosing to
use them. I think we all remember the era of the super low-rise jeans and
can agree (or maybe agree to disagree) that just because something is being
used by everyone out there, it does not mean it deserves all the hype…of
course that is my own opinion on the subject matter that is low-rise
jeans. As for the buzzwords, the statement stands! So, let’s bring up some
of these super duper amazingly popular buzzwords in to play here, let’s
actually define what they are for the ones out there that might not be
cyber-security wizards, and let’s remove the buzzing that these buzzwords
might have brought into our minds, shall we?
Buzzword #1: ransomware. Aaah, ransomware. You see this simple and yet
deadly word everywhere. “Defend yourself against ransomware!”, “Ransomware
might be just around the corner!”, “No need to fear ransomware
anymore!”. It was the dawn of 2017 when ransomware became a thing to people
outside of the cyber security community because of the infamous WannaCry
malware. That picture with a red pop-up window telling you that all of your
files had been encrypted and could only be recovered after some type of
crypto currency payment was made to the attackers was absolutely
everywhere! And after that, the ransomware wave only got stronger, with new
and improved types showing up all the time, an honorable mention being the
Petya variants. Anyway, since WannaCry was such a big deal at the time, and
people were so scared of it after it left behind its trail of mayhem and
huge amounts of lost data, ransomware became THE word chosen by various
cybersecurity companies to describe that which is your main enemy in the
digital world, the supervillain in this installment of the cyber security
movie series that is actually our real lives. All defense tools now
implement some type of measure against ransomware, because if they don’t,
you know that clients of said tool will ask “but what about defending
against ransomware?”, because that, my friends, is the buzzword that comes
to their minds. Like the word “computer virus” in the early 2000s. Computer
viruses still exist, but you don’t see people freaking out about it
anymore, because now we have the “antivirus”. Phew, problem solved, right?
So no need to have this as a buzzword anymore. However, just like computer
viruses existed before the 2000s and still exist to this day, ransomware
also existed before WannaCry and much worse versions of it will continue to
exist while there still are vulnerabilities and hackers out there, which is
to say…probably forever. The only difference is, we now live in a time
where people seem to care about it a little bit more, maybe because they
are not implementing security measures to be safe against it, or at least
they are not doing it very well. But I am getting ahead of myself
here. Let’s first talk about what ransomware really is, which is actually
something very simple to do: a ransomware is a malware, as a computer virus
is also a malware. A malware is a ‘malicious software’, or, in other words,
a software that executes in a computing device and that does things that
the owner of the device might not want it to do, like…for example,
encrypt all of your files and not allow you to access them. That is what
ransomware does, in most cases. The main idea is, a ransomware will be a
malicious software that will prevent you from accessing your files until
you pay some amount of money to the malicious entity that was able to get
that ransomware to run in your network devices in the first place…so,
until you pay a ransom to the kidnapper of your data. Of course this only
works if you have someone on the other side waiting to exchange the money
for the key that will decrypt your files, or else, you could simply have a
very destructive trojan, or worm, or whatever other malware that is
combined with the file encrypting functionality in order for the malicious
software itself to spread through the network before actually causing the
data harm it does. The question now is, whatever is the ransomware-hybrid
malware that targeted you and your network, the only way to recover the
data you lost, the data as it was during the time of total encryption, is
to pay the ransom. Should you? Cyber security professionals usually
recommend against paying ransom, as it only shows hackers that they can
continue launching ransomware attacks to get what they want. The correct
way to avoid your files from being forever lost after your network has been
infected by one of these nasty malwares is to recover data from the backup
server you set up…you did set up a backup server to store the backup for
all of your company data, right? I know, I know…not always it will be the
case that people will be able to set backups, and then, recovering all that
is lost might be a much more difficult task if you decide to not pay the
ransom. But come on…we live at a time where cyber security should no
longer be put in the benches, and you should be highly concerned about
possible attacks, especially attacks related to the ever popular buzzword
ransomware. Save some of your budget for backups, you won’t regret it.
Buzzword #2: botnets. ‘Botnet’ is an interesting buzzword because it opens
the door to many other tech buzzwords that are in everyone’s minds out
there right now…like crypto mining, for example. Why? Because you can use
botnets to perform crypto mining…you can also use botnets to spread
malware, including ransomware. Oh…and botnets…their participants
usually include lots of IoT devices! BAM, another buzzword right there! Now
would you look at that! Seems like instead of a buzzword, we actually have
a buzzword magnet in our hands ladies and gentlemen. So…yes, maybe
‘botnet’ is not the hottest buzzword out there right now, but I decided to
include it in the list because I feel like it is a disguised buzzword. What
do I mean by disguised? It’s the word that is in the subtitle for an
article named “CRYPTO MINING HACKER GANG CAUSES DAMAGES TO COMPANY X”, or
the word that is implied in a video that is named “IoT DEVICE Y SECURITY
VULNERABILITY ONCE AGAIN EXPOSED BY MASSIVE DENIAL OF SERVICE ATTACK”, or
even the word that is a part of a title or a conversation about cyber
security, cyber attacks and vulnerabilities, but it might not be the one in
big bold flashy fonts, like it was the case for our dearest friend
ransomware. But it all comes back to the botnets eventually. So what is a
botnet? As the name suggests, it is a network of bots! Wooow, could I get a
round of applause for that definition, please and thank you very much! When
we think about a robot, we think about a technological humanoid that speaks
in a digitalized voice and obeys commands without question, unless they are
actually trying to take over the planet and overthrow human supremacy…but
that is a topic for another podcast to maybe discuss. The point here is:
what is a computer if not a robot? No, it does not possess humanoid form
most of the time, but it does communicate with us through a digital screen
and it will execute commands that the software it is running tells it to,
this software being created and programmed by a human
being. So…yes…robots are computers, computers are robots, or at
least…fancy humanoid robots and even cute round cleaning robots need
computers to exist and computers are the basis to create a robot. So when
we say botnet, we are actually referring to a network of computers. A
network of computers, or a group of computers, which are all performing
some type of common activity, executing software with the same purpose… and
unfortunately for us, in this case it is a malicious purpose. Botnets are
created through the infection of computing devices. A hacker releases
malware on the Internet and this malware is able to propagate, infecting
various devices connected to our fairest of ladies, usually devices that
are vulnerable to some type of specific vulnerability. So, yes, once again
we have malwares being a problem and ruining our days…surprise,
surprise. Once infected, the device becomes a robot, a “mindless” soldier
in an army of many that will respond to a hacker, most likely the one that
created the malware. It connects back to this hacker, usually sending some
type of short and sweet - bitter sweet for us, that is - message to a
command and control server, which we can see as an HQ, but is actually
nothing more than an attacker controlled device. And then…it waits. It
continuously calls home to indicate that it is a part of the malicious
group of infected devices that are “at the hacker’s service”, and it
expects to eventually receive a message that will contain instructions
which will give it an attack target and an attack to launch on that
target. The malware that is running on the infected device, our bot, will
contain the code or will receive and process the code that will allow this
attack to be carried out, and then we have a huge amount of possibilities
that we can consider for this attack, one of them being: the bots could be
instructed to send absurd amounts of data through the network to a specific
target. The target device gets overwhelmed and the service it provides
through the network can no longer be accessed by legitimate users because
the device crashes. This is a denial of service attack, which is very hard
to stop at the source, as you have thousands of sources, most of which the
device owners don’t even have malicious intent. The devices got hacked and
are secretly and mercilessly being used to the advantage of the
attacker. Granted…the reason for the infection, the presence of the
vulnerability that initially caused this could be the owner’s fault. Maybe
they wouldn’t have been unwillingly attacking the server of their favorite
website had they applied that patch that recently came out for a critical
vulnerability, however, you can’t really call them the mastermind of it all
when all they did was keep a vulnerable computer, can you? Anyway, I might
leave that philosophical question for a later time…for now, another well
known use for botnets is crypto mining. Infect, divide and profit! Why use
your own computer and your own resources to mine crypto currency when you
have hundreds of thousands of unpatched IoT devices at your disposal to
mine for you? That’s what the hackers think…not me….just to be veeeery
clear. A botnet can also be used to spread ransomware. The bots worry about
creating other bots as well as infecting devices in their own local
networks that might make a hacker profit from a ransomware attack. And it
all ties in beautifully to create the most amazing of buzzword sentences:
Phishing campaign allows for creation of ransomware botnet!
Oh…wait…there is a buzzword in there we have yet to talk about…
Buzzword #3: phishing! Did you like how I introduced this one by just
name-dropping it previously? Since I gave it such a direct introduction,
let’s also give it a direct definition. Phishing is a type of social
engineering attack where an attacker throws what we can only call as the
equivalent to “bait” into the Internet “ocean” in hopes of hooking some
“fish”, in their fishing rods. So…the “fish” are like the victims of the
attack, if that wasn’t clear enough for you… Our situation therefore, is
kind of like real fishing, but in a different context, because here we are
looking at people getting fooled into clicking on links that will cause
them to access malicious websites, and then share sensitive information
like passwords and credit card numbers through that website, all because
they get fooled into doing it by a very clever attacker which is using of
their social engineering skills achieve this. They could also simply get
fooled into responding directly to a well crafted message with sensitive
information they wouldn’t even share with their own diaries! Or maybe just
with their diaries, but not other people. The question which remains is:
what is social engineering? To put it simply, a social engineer is someone
that knows how to “hack” the human psyche. To put it not so simply, it is
the art - can I call it that? - of manipulating other people into doing
something they might not want to have done in the first place. So, every
spy movie when you see the almighty main character get into a building they
shouldn’t by fooling the guard and making them believe they actually work
there because they are wearing a fancy suit and spilling out complex terms
to a phone…well that is social engineering. The super spy plays the part
and gives no time for the guard to think too much about whether they are
actually a legitimate authorized person or not, because when the guard
starts questioning it, they emphatically say something in the lines of “Oh
my god…I am going to be late to my meeting and you do not want
Mr. Whatever to hear about this’. Mr. Whatever is an actual big boss around
the place and Mr. Guard worries he will get fired if he doesn’t comply
immediately, so just this time, he skips the ID checking phase of the
process to let super spy waltz into the building unscathed. His fear of
getting fired was used against him in order to make him do something he
wouldn’t do were he thinking clearly, not affected by emotion: skip a part
of the identification process of a person wanting to access the
building. When we talk about spy movies of course we have a much more
interesting example than when we are talking about actual phishing
campaigns, but the underlying idea is the same in both. The difference is,
in phishing attacks, a hacker will usually send an e-mail or a text message
to a bunch of random people with a message that will toy with their
emotions somehow. They focus on quantity instead of quality because
eventually someone is bound to be freaked out by the email they get saying
that their bank account will be closed if they don’t immediately click the
link in the message and change their password using the form provided. They
click the link without paying attention to the website URL, which is not at
all related to the one of their bank’s actual website, and are redirected
to a webpage which looks exactly like the password changing page you would
get had you accessed this legitimate bank website. They input their data,
which is quickly sent to the attacker, because they are the actual entity
controlling the device behind said website, and now, this attacker has the
password to this person’s bank account. Fishing rod: fake email sent to
thousands of people saying the bank will close accounts that don’t change
their passwords. Bait: the human feeling of desperation one might get when
thinking about having their bank account suddenly be inaccessible, caused
by the wording and official looking appearance of the email message that
was sent. Fish who bite on that bait: people who believe this message and
don’t pay too much attention to the signs that indicate that it is
fake. Most times, people who are not that tech savvy and don’t even know
how it is possible that a fake website could have the same appearance as
the one from the actual bank. If it looks like the bank webpage, it can
only be the bank webpage…right? So…yes, I am unfortunately talking about
all of the grandmas out there, which end up being a very common victim of
these types of attacks. But do not get me wrong. I am not saying here that
if you are not a grandma that you are unaffected by phishing
attacks. Social engineering techniques go way beyond fear or desperation,
and anyone can be a target should a hacker strike the correct emotions on
this target. Remember a certain Nigerian prince who was asking for a small
sum of money only to return 10 times this amount to you as soon as their
investment worked? Greed can also be your downfall. So the main tip for
those that are worried about falling for phishing scams is simple: if
something looks like it is too good to be true, it probably is. Also…if
something seems too crazy to be true, maybe ask trustworthy people related
to the craziness in question if that message you are receiving is indeed
legitimate. So…for our bank situation, call your bank manager! Have more
than one information source and breathe before making any harsh decisions
and clicking the link that will ask you for your credentials or for any
kind of sensitive information for absolutely no reason! I mean…why do you
need my credit card number if I am not actually buying anything? Think
before you type! That is the best way to not be that sad struggling fish at
the mercy of some hook.
Well friends, sadly, we have reached that point of the episode which will
actually transform this into a series instead of leaving it as a single
episode, since I am unable to write a small script. Oops, sorry about that!
We will continue on this journey next week, where I will talk about some
other interesting buzzwords you might have heard when out and about. No
spoilers though, as it might ruin the fun of it! I await you all in the
next episode of this series. For now, feel free to share any of your
thoughts on this episode in any of our social media channels! I bid you all
farewell and until next time! Bye!
Get in contact
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@ubuntu_sec on twitter
35 min
June 17, 2022Episode 164
Overview
More Intel CPU issues, including Hertzbleed and MMIO stale data, plus we
cover security vulnerabilities and updates for ca-certificates, Varnish
Cache, FFmpeg, Firefox, PHP and more.
This week in Ubuntu Security Updates
64 unique CVEs addressed
[USN-5473-1] ca-certificates update [00:41]
Affecting Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
Updates to the latest 2.50 version of the Mozilla CA bundle - in
particular this removes a bunch of expired certs plus an old (but still
valid) GeoTrust certificate and others - also adds some new CA certs from
GlobalTrust, Certum, GlobalSign too
[USN-5396-2] Ghostscript vulnerability [01:30]
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2019-25059
Episode 158
[USN-5474-1] Varnish Cache vulnerabilities [01:41]
4 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-23959
CVE-2021-36740
CVE-2020-11653
CVE-2019-20637
Thanks to Luís Infante da Câmara for preparing, testing and providing the
debdiff’s for these updates
Possible HTTP/1 and HTTP/2 request smuggling attacks
DoS via triggering an assertion failure
Pointer of one client reused on the next if both share the same
connection - can expose info from the old client to the new one
[USN-5472-1] FFmpeg vulnerabilities [02:30]
35 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2021-38291
CVE-2020-22025
CVE-2022-1475
CVE-2021-38171
CVE-2021-38114
CVE-2020-35965
CVE-2020-22037
CVE-2020-22035
CVE-2020-22030
CVE-2020-22029
CVE-2020-22027
CVE-2020-22033
CVE-2020-22021
CVE-2020-22019
CVE-2020-22042
CVE-2020-22036
CVE-2020-22034
CVE-2020-22032
CVE-2020-22031
CVE-2020-22028
CVE-2020-22026
CVE-2022-22025
CVE-2020-22023
CVE-2020-22022
CVE-2020-22020
CVE-2020-22017
CVE-2020-22016
CVE-2020-22015
CVE-2020-21697
CVE-2020-21688
CVE-2020-21041
CVE-2020-20450
CVE-2020-20453
CVE-2020-20446
CVE-2020-20445
Thanks to Luís Infante da Câmara for preparing, testing and providing the
debdiff’s for these updates
Updates ffmpeg to latest upstream bug-fix releases
4.4.2 for 21.10, 22.04 LTS
4.2.7 for 20.04 LTS
3.4.11 for 18.04 LTS
[USN-5475-1] Firefox vulnerabilities [03:04]
12 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-31748
CVE-2022-31747
CVE-2022-31745
CVE-2022-31744
CVE-2022-31743
CVE-2022-31742
CVE-2022-31741
CVE-2022-31740
CVE-2022-31738
CVE-2022-31737
CVE-2022-31736
CVE-2022-1919
101.0.1
Usual mix of web browser / framework issues fixed - specially crafted
website -> could exploit to cause DoS, info leak, spoof the browser UI,
conduct XSS attacks, bypass content security policy (CSP) restrictions,
or execute arbitrary code
[USN-5476-1] Liblouis vulnerabilities [03:54]
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-31783
CVE-2022-26981
Braille translation library + utils
Buffer overflow -> crash -> DoS
OOB write -> crash -> DoS / RCE
[USN-5359-2] rsync vulnerability [04:27]
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2018-25032
Episode 156 (zlib memory corruption issue when compressing input data)
[USN-5477-1] ncurses vulnerabilities [04:54]
6 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2022-29458
CVE-2021-39537
CVE-2019-17595
CVE-2019-17594
CVE-2018-19211
CVE-2017-16879
Various memory corruption vulns fixed - requires to process crafted input
files (e.g. termcap - but this is usually trusted so hence negligible
rating for most of these CVEs)
[USN-5478-1] util-linux vulnerability [05:28]
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2016-5011
Memory leak in libblkid when parsing crafted MSDOS partition table
[USN-5479-1] PHP vulnerabilities [05:40]
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-31626
CVE-2022-31625
both issues in handling of crafted inputs into database drivers - 1 for
postgres and 1 for mysql
uninitialised var in pg driver -> UAF in certain error scenario -> RCE
buffer overflow in password handler for mysqlnd (native driver) - rogue
MySQL server could trigger this to get RCE
Goings on in Ubuntu Security Community
News on latest Intel security issues [06:33]
Hertzbleed & MMIO stale data both disclosed this week
Hertzbleed - interesting new crypto side-channel attack demonstrated
against SIKE (Supersingular Isogeny Key Encapsulation - post-quantum key
encapsulation mechanism)
Turns a frequency side-channel into a timing side-channel such that
code which was previously assumed to be constant time can still leak
information about the key, allowing it to be recovered by mounting a
chosen cipher-text attack from a client, observing the timing response
of the server and then inferring the secret key as a result
Acknowledged by both Intel and AMD but likely all modern processors
which employ dynamic voltage and frequency scaling are affected
Intel have released guidance for how to harden crypto implementations
against this attack
No changes/fixes for this in kernel/microcode/toolchain etc - instead
will be up to individual libraries to assess if they may be affected
and then refactor accordindly
MMIO stale-data
Vulns in memory mapped I/O - generally only applicable to
virtualisation when untrusted guest have access to MMIO
not transient execution attacks themselves but since these vulns
allow stale data to persist, can then be inferred by a TEA (think
Spectre etc)
consists of a series of different issues for various microarchitectural
buffers / registers where stale data is left after being copied /
moved - then can be sampled via a TEA to infer the value
different processor models have different microarchitectural buffers so
some may or may not be affected
3 separate vulns (CVEs) identified based on the microarchitectural
buffer affected and the technique used to read from it
Fixes required in both kernel and intel-microcode packages
Kernels will have already been released by the time you hear this
Microcode is currently being released via the -updates pocket of the
archive - will then publish to -security once fully phased to all
users
Likely early on Monday next week
More details in next week’s episode
Get in contact
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@ubuntu_sec on twitter
12 min

About Ubuntu Security Podcast

From the publisher's feed

A fortnightly podcast talking about the latest developments and updates from the Ubuntu Security team, including a summary of recent security vulnerabilities and fixes as well as a discussion on some…

Share Ubuntu Security Podcast

Sign up to save your podcasts

Ubuntu Security Podcast

Ubuntu Security Podcast episodes

About Ubuntu Security Podcast