Ubuntu Security Podcast

By Ubuntu Security TeamTechnology

Ubuntu Security Podcast episodes

June 10, 2022Episode 163
Overview
This week we dig into some of the details of another recent Linux malware
sample called Symbiote, plus we cover security updates for the Linux
kernel, vim, FreeRDP, NTFS-3G and more.
This week in Ubuntu Security Updates
82 unique CVEs addressed
[USN-5456-1] ImageMagick vulnerability [00:36]
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS)
CVE-2022-28463
Heap UAF found by oss-fuzz
[LSN-0086-1] Linux kernel vulnerability [00:51]
7 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-30594
CVE-2022-29581
CVE-2022-21499
CVE-2022-1116
CVE-2022-1055
CVE-2022-0492
CVE-2021-39713
Various recent local privesc vulns:
cgroups v1 release_agent
UAF in network scheduling subsystem
UAF in network traffic control subsystem
integer overflow in io_uring
seccomp restrictions bypass
UAF in network queuing and scheduling subsystem
Secure boot bypass through kgdb
canonical-livepatch status
Kernel type
22.04
20.04
18.04
16.04
14.04
aws
—
86.3
86.3
86.3
—
aws-5.4
—
—
86.3
—
—
aws-hwe
—
—
—
86.3
—
azure
—
86.3
—
86.3
—
azure-4.15
—
—
86.3
—
—
azure-5.4
—
—
86.3
—
—
gcp
86.4
86.3
—
86.3
—
gcp-4.15
—
—
86.3
—
—
gcp-5.4
—
—
86.3
—
—
generic-4.15
—
—
86.3
86.3
—
generic-4.4
—
—
—
86.3
86.3
generic-5.4
—
86.3
86.3
—
—
gke
86.4
86.3
—
—
—
gke-4.15
—
—
86.3
—
—
gke-5.4
—
—
86.3
—
—
gkeop
—
86.3
—
—
—
gkeop-5.4
—
—
86.3
—
—
ibm
86.4
86.3
—
—
—
ibm-5.4
—
—
86.3
—
—
linux
86.4
—
—
—
—
lowlatency
86.4
—
—
—
—
lowlatency-4.15
—
—
86.3
86.3
—
lowlatency-4.4
—
—
—
86.3
86.3
lowlatency-5.4
—
86.3
86.3
—
—
oem
—
—
86.3
—
—
[USN-5465-1] Linux kernel vulnerabilities [02:02]
3 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2022-30594
CVE-2022-1966
CVE-2022-21499
secure boot bypass via kgdb
UAF in netfliter -> privesc
seccomp restrictions bypass
[USN-5466-1] Linux kernel vulnerabilities
8 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS)
CVE-2022-28390
CVE-2022-28356
CVE-2022-1419
CVE-2022-1016
CVE-2021-4149
CVE-2021-3772
CVE-2022-1966
CVE-2022-21499
secure boot bypass, netfilter UAF plus btrfs deadlock, infoleak in
netfilter + virtual graphics manager, double free in 802.2 LLC driver and
EMS CAN/USB drivers
[USN-5467-1] Linux kernel vulnerabilities [02:29]
21 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-28390
CVE-2022-28389
CVE-2022-28356
CVE-2022-26966
CVE-2022-24958
CVE-2022-23042
CVE-2022-23041
CVE-2022-23040
CVE-2022-23039
CVE-2022-23038
CVE-2022-23037
CVE-2022-23036
CVE-2022-1516
CVE-2022-1353
CVE-2022-1198
CVE-2022-1158
CVE-2022-1011
CVE-2021-4197
CVE-2021-3772
CVE-2022-1966
CVE-2022-21499
Most of the above plus privesc via mishandling of permission checks when
migrating processes across cgroups, KVM page table handling -> host crash
(DoS), UAF in USB-Gadget, Microchip CAN BUS Analyzer, 6pack protocol
driver and more
[USN-5468-1] Linux kernel vulnerabilities
6 CVEs addressed in Focal (20.04 LTS), Impish (21.10)
CVE-2022-28390
CVE-2022-24958
CVE-2022-1972
CVE-2022-1158
CVE-2022-1966
CVE-2022-21499
Subset of the above
[USN-5469-1] Linux kernel vulnerabilities
20 CVEs addressed in Jammy (22.04 LTS)
CVE-2022-28390
CVE-2022-28389
CVE-2022-28388
CVE-2022-28356
CVE-2022-1972
CVE-2022-1671
CVE-2022-1651
CVE-2022-1516
CVE-2022-1353
CVE-2022-1263
CVE-2022-1205
CVE-2022-1204
CVE-2022-1199
CVE-2022-1198
CVE-2022-1195
CVE-2022-1158
CVE-2022-1048
CVE-2022-0168
CVE-2022-1966
CVE-2022-21499
More of the same
[USN-5470-1] Linux kernel (OEM) vulnerabilities
4 CVEs addressed in Focal (20.04 LTS)
CVE-2022-1972
CVE-2022-1836
CVE-2022-1966
CVE-2022-21499
[USN-5471-1] Linux kernel (OEM) vulnerabilities
8 CVEs addressed in Jammy (22.04 LTS)
CVE-2022-29968
CVE-2022-1972
CVE-2022-1836
CVE-2022-1734
CVE-2022-1205
CVE-2022-1012
CVE-2022-1966
CVE-2022-21499
[USN-5458-1] Vim vulnerabilities [03:17]
9 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-0443
CVE-2022-0408
CVE-2022-0368
CVE-2022-0361
CVE-2022-0359
CVE-2022-0351
CVE-2022-0319
CVE-2022-0213
CVE-2021-4193
OOB reads, heap buffer overflows, stack buffer overflows, UAFs etc via
crafted input files
[USN-5460-1] Vim vulnerabilities
10 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-1621
CVE-2022-1620
CVE-2022-1619
CVE-2022-1616
CVE-2022-0943
CVE-2022-0729
CVE-2022-0714
CVE-2022-0685
CVE-2022-0572
CVE-2022-0554
[USN-5459-1] cifs-utils vulnerabilities [03:49]
4 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-29869
CVE-2022-27239
CVE-2021-20208
CVE-2020-14342
Tools for managing cifs mounts etc
Privesc via stack buffer overflow in mount.cifs via crafted command-line
arguments - used strcpy() to copy the provided IP address after first
checking length - but did comparison using strnlen() which returns the
max length even if the string is longer - so subsequent strcpy() would
then overflow
Possible shell command injection into mount.cifs when it spawns a
subshell for password input
Exposure of host kerberos credentials when mounting a CIFS share using
kerberos authentication within a container
[USN-5461-1] FreeRDP vulnerabilities [05:21]
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-24883
CVE-2022-24882
Episode 162 - Last week we talked about a couple different packages that
mishandled empty password to then improperly authenticate a user
Similar vuln in FreeRDP when using NTLM authentication - allows a
client to authenticate to the server with an empty NTLM password
[USN-5462-1, USN-5462-2] Ruby vulnerabilities [06:11]
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-28739
CVE-2022-28738
Double free in regexp compiler when handling a crafted regex as input -
so if allow attackers to provide regex which will then get compiled could
abuse this to gain code execution as the ruby interpreter
[USN-5463-1] NTFS-3G vulnerabilities [06:41]
8 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-30787
CVE-2022-30785
CVE-2022-30789
CVE-2022-30788
CVE-2022-30786
CVE-2022-30784
CVE-2022-30783
CVE-2021-46790
ntfsck code execution via crafted disk images (Episode 162)
Incorrect handling of crafted disk images during mounting etc -> various
heap buffer overflows -> code execution
Logic error exposes a user to intercept the FUSE protocol traffic between
nfts-3g and the kernel
[USN-5464-1] E2fsprogs vulnerability [07:17]
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-1304
Similarly, OOB R/W in e2fsprogs -> used when doing fsck, mkfs, resizefs,
badblocks etc on crafted file system image -> code execution
Goings on in Ubuntu Security Community
Symbiote Linux malware analysis [07:58]
https://www.intezer.com/blog/research/new-linux-threat-symbiote/
Research from Intezer and Blackberry
Found targeting financial sector in Latin America
Described as ’nearly impossible’ to detect
Uses LD_PRELOAD to ‘infect’ binaries on system
Evades detection by then hooking various functions in libc, libpcap etc
to change their behaviour and alter their output so that when running
tools like ls, ps etc they don’t show evidence of infection
Also loads BPF filter to hide it’s own network traffic from being seen
when say running a local tcpdump etc
‘Nearly impossible to detect’ claim
Indeed, is going to be very hard to detect it from the machine itself
which is compromised
If an attacker has control over the machine they can clearly influence
that environment to hide themselves
Reminds of a recent twitter thread involving halvarflake, Mathias Krause
and others, and then a follow-up blog post from Brad Spengler from
grsecurity looking at Tetragon eBPF Security Observability and Runtime
Environment
eBPF based system which allows sysadmins to develop policy to detect
and kill exploits
Runs on the system itself in kernel-space and tries to detect once a
user has elevated privileges etc
e.g. kernel memory corruption to set their own uid as 0
But since the attacker has already got code execution in the kernel to
be able to achieve this they can just as easily first disable Tetragon
and then go and elevate privileges and hence not be detected
Basically if you are trying to detect compromise from within the
environment itself the attacker is always at an advantage and can change
the environment to evade detection and make everything look normal /
disable checks etc
Instead need to be at a higher level of abstraction
In the case of detecting Symbiote - would need to say take a disk image
and analyse it offline from another machine so that the analysis
environment can’t be influenced by the malware itself
Ubuntu 21.10 (Impish Indri) reaches End of Life on July 14 2022 [12:45]
https://lists.ubuntu.com/archives/ubuntu-announce/2022-May/000280.html
Hiring [13:16]
Security Engineer - Ubuntu
https://canonical.com/careers/2925180/security-engineer-ubuntu-remote
Security Certifications Product Manager - CIS, FIPS, FedRAMP and more
https://canonical.com/careers/3781589/security-certifications-product-manager-cis-fips-fedramp-and-more-remote
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
June 03, 2022Episode 162
Overview
This week we cover security updates for dpkg, logrotate, GnuPG, CUPS,
InfluxDB and more, plus we take a quick look at some open positions on the
team - come join us!
This week in Ubuntu Security Updates
31 unique CVEs addressed
[USN-5446-1, USN-5446-2] dpkg vulnerability [00:42]
1 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-1664
Directory traversal vulnerability when extracting untrusted source packages
debian source packages consist of two tarballs - orig and debian
orig is unpacked and then debian in unpacked on top of that - if orig
is crafted to contain a symlink which pointed to a file outside of the
source code, then when unpacking debian it will follow that symlink and
hence would overwrite arbitrary files outside the source directory
Only really a problem for debian/ubuntu developers
[USN-5447-1] logrotate vulnerability [02:58]
1 CVEs addressed in Impish (21.10), Jammy (22.04 LTS)
CVE-2022-1348
logrotate creates a ‘state’ file to avoid parallel executions of itself -
each instance locks this file as a mutex mechanism
if this doesn’t exist, it gets created - but is created world readable -
which allows unprivileged users to take the lock on this file
as such the real logrotate will fail to run since it can’t get the lock
-> DoS
[USN-5402-2] OpenSSL vulnerabilities [04:13]
2 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-1473
CVE-2022-1292
Episode 159
[USN-5448-1] ncurses vulnerabilities [04:21]
11 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2017-13728
CVE-2017-11113
CVE-2017-13734
CVE-2017-13733
CVE-2017-13732
CVE-2017-13731
CVE-2017-13730
CVE-2017-13729
CVE-2017-11112
CVE-2017-10685
CVE-2017-10684
Crafted inputs could cause ncurses to crash - most of these were found
via fuzzing and are stack buffer overflows - these are generally
mitigated via stack-protector, others are NULL ptr deref, but again same
outcome (crash -> DoS)
Possible infinite loop as well -> cpu based DoS
[USN-5449-1] libXv vulnerability [04:58]
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2016-5407
Remove X server could trigger OOB read in the X client via crafted
response -> crash -> DoS
[USN-5431-1] GnuPG vulnerability [04:24]
1 CVEs addressed in Bionic (18.04 LTS)
CVE-2019-13050
Weakness in PGP/SKS keyserver design - if a key/certificate has many
signatures, GnuPG will take an inordinate amount of time to process these
when downloading the key from the keyserver -> DoS
Certificate spamming attack - anyone can sign someone else’s cert
thereby attaching another signature to it on the SKS keyserver network
The OpenPGP spec doesn’t limit the number of signatures (but SKS
keyserver network does - 150k)
So anyone can poison someone else’s cert by attaching a large number of
signatures to it
GnuPG would download all of these signatures when importing a key and
then proceed to validate them all
Also would do this when say validating a signature from that poisoned
cert
Fixed to not import key signatures by default anymore and to then
fallback to only import self-signatures on large keyblocks
[USN-5452-1] NTFS-3G vulnerability [07:55]
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2021-46790
ntfsck tool failed to perform proper bounds checking on filesystem
metadata - if could trick a user into running it on an untrusted
filesystem image could then possibly get code execution
Upstream have deprecated this tool and it is only present in the
ntfs-3g-dev package which is not installed by default
[USN-5453-1] FreeType vulnerability [08:38]
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-27406
OOB read when processing a crafted font file -> DoS
[USN-5454-1, USN-5454-2] CUPS vulnerabilities [08:50]
3 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2020-10001
CVE-2019-8842
CVE-2022-26691
Upstream Apple advisory describes this as:
“Logic issue addressed with improved state management… An application
may be able to gain elevated privileges”
Looks like it was discovered by Mandiant
CUPS provides the ability to authenticate via Basic Web Authentication
or through a 32-byte randomly generated token created at runtime
Comparison function would only compare the supplied token value against
the real one based on the length of the shortest input - so if supplied
an empty string then would compare 0 bytes of the two and return
success!
Other two issues were memory handling issues in IPP printing - could
submit a print job which would cause an OOB read in CUPS -> crash -> DoS
[USN-5451-1] InfluxDB vulnerability [10:39]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2019-20933
Similar authentication bug in InfluxDB - could bypass authentication by
supplying a JWT token with an empty SharedSecret
[USN-5442-2] Linux kernel vulnerabilities [11:06]
3 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-30594
CVE-2022-1116
CVE-2022-29581
5.4 - GCP/GKE/IBM/Oracle/Raspi
Bing-Jhong Billy Jheng found integer overflow in io_uring - an
unprivileged user can spam requests which would eventually overflow
counter and then could be used to trigger an OOB write -> controlled
memory corruption -> privesc
Not the first bug in io_uring found by this researcher -
https://seclists.org/oss-sec/2021/q2/127
Similarly, Jann Horn (GPZ) found kernel didn’t properly check privileges
of a process when allowing it to set a flag which would then disable
seccomp filters on another process or itself
Could then allow an unprivileged process to turn of seccomp for itself
/ other processes and allow them to bypass intended access restrictions
Regular kernel security bug - ref count issue in network queueing
subsystem -> UAF - able to be triggered by a local attacker -> crash /
code execution
[USN-5443-2] Linux kernel vulnerabilities [12:47]
2 CVEs addressed in Focal (20.04 LTS), Impish (21.10)
CVE-2022-30594
CVE-2022-29581
5.13 Oracle/GCP
[USN-5457-1] WebKitGTK vulnerabilities [12:58]
5 CVEs addressed in Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-26719
CVE-2022-26717
CVE-2022-26716
CVE-2022-26709
CVE-2022-26700
Latest webkit point release - usual mix of issues fixed - XSS, DoS, RCE
etc
Goings on in Ubuntu Security Community
Hiring
Security Engineer - Ubuntu [13:25]
https://canonical.com/careers/2925180/security-engineer-ubuntu-remote
Security Certifications Product Manager - CIS, FIPS, FedRAMP and more [14:24]
https://canonical.com/careers/3781589/security-certifications-product-manager-cis-fips-fedramp-and-more-remote
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
16 min
May 27, 2022Episode 161
Overview
This week we take a look into BPFDoor, a newsworthy backdoor piece of
malware which has been targeting Linux machines, plus we cover security
updates for Bind, Vim, Firefox, PostgreSQL and more.
This week in Ubuntu Security Updates
32 unique CVEs addressed
[USN-5429-1] Bind vulnerability [00:38]
1 CVEs addressed in Jammy (22.04 LTS)
CVE-2022-1183
Only affects most recent releases
When using bind configured with DNS over HTTPS (DoH) possible for a
client to cause the server to terminate a TLS connection early and hence
trigger an assertion failure within Bind -> terminates -> DoS
[USN-5430-1] GNOME Settings vulnerability [01:18]
1 CVEs addressed in Jammy (22.04 LTS)
CVE-2022-1736
GNOME includes support for desktop sharing via RDP + VNC
By default in Ubuntu we have a no open ports policy)
However, GNOME settings daemon contained a logic flaw where when
disabling the remote desktop service via the gnome-control-center UI it
would then automatically get re-enabled on next login
[USN-5424-2] OpenLDAP vulnerability [01:57]
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2022-29155
Episode 160
SQL injection in the sql backend of slapd via an SQL statement within a LDAP query
[USN-5433-1] Vim vulnerabilities [02:20]
9 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-1154
CVE-2022-0318
CVE-2022-0261
CVE-2021-4192
CVE-2021-4069
CVE-2021-4019
CVE-2021-3984
CVE-2021-3974
CVE-2021-3973
All various instances of memory corruption vulnerabilities, where if a
user was tricked into opening a specially crafted file, could then either
crash Vim or possibly get code execution as the user
Whilst a lot of regular desktop users may not use Vim, is still often
used by sysadmins to edit config files / inspect other files which they
find on the machine - and in that case, this can then be a good privesc
target
[USN-5432-1] libpng vulnerabilities [03:01]
2 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2018-14048
CVE-2017-12652
Speaking of specially crafted files :) - same for libpng - is used by
many other higher level libraries / applications
[USN-5434-1] Firefox vulnerabilities [03:20]
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-1802
CVE-2022-1529
100.0.2
2 vulns courtesy of ZDIs Pwn2Own - Manfred Paul - achieved code execution
within the privileged component of Firefox thereby escaping Firefox’s
internal sandbox - awarded $100k USD
[USN-5435-1] Thunderbird vulnerabilities [03:57]
11 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-19916
CVE-2022-1802
CVE-2022-1529
CVE-2022-1520
CVE-2022-29917
CVE-2022-29916
CVE-2022-29914
CVE-2022-29913
CVE-2022-29912
CVE-2022-29911
CVE-2022-29909
91.9.1
Same as above plus a bunch of other recent vulns in Firefox which also
apply to TB as well as a TB specific issue where it would show the wrong
security status for a signed/encrypted attached message and hence could
allow an attacker to trick the user into thinking the message was
trustworthy
[USN-5436-1] libXrender vulnerabilities [04:28]
2 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2016-7950
CVE-2016-7949
Remote X server could trigger OOB write -> memory corruption -> code
execution
[USN-5437-1] libXfixes vulnerability
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2016-7944
32-bit platform specific issue - but roughly same as above
[USN-5438-1] HTMLDOC vulnerability [04:46]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2021-23165
Used to covert HTML/Markdown files to generate EPUB/HTML/PS/PDF with ToC
etc
Crafted HTML file could trigger a heap buffer overflow -> crash/code
execution
[USN-5439-1] AccountsService vulnerability [05:06]
1 CVEs addressed in Jammy (22.04 LTS)
CVE-2022-1804
Old CVE-2020-16126 was inadvertently reintroduced as the patch which
fixed it got dropped accidentally
Episode 95
[USN-5440-1] PostgreSQL vulnerability [05:36]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-1552
Possible for an attacker who is able to create non-temp objects could
then achieve SQL code execution as the superuser
[USN-5404-2] Rsyslog vulnerability [05:51]
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-24903
Episode 159
Goings on in Linux Security Community
BPFDoor malware targeting Linux and Solaris [06:08]
https://www.pwc.com/gx/en/issues/cybersecurity/cyber-threat-intelligence/cyber-year-in-retrospect/yir-cyber-threats-report-download.pdf
https://doublepulsar.com/bpfdoor-an-active-chinese-global-surveillance-tool-54b078f1a896
https://www.sandflysecurity.com/blog/bpfdoor-an-evasive-linux-backdoor-technical-analysis/
Malware that has been in the wild for a while (over 5 years)
Reported on by PwC in their Cyber Threats 2021: A year in Retrospect report
Attribute it to a Chinese threat actor which they call Red Menshen
Observed targeting telco providers and govt, education and logistics
via custom backdoor ‘BPFDoor’
Stealthy - allows to backdoor a system for RCE but without opening any
new network ports or firewall rules by piggy-backing on existing network
facing applications
Uses BPF filter to watching incoming packets and activate accordingly
Earlier versions are on VT - with lots of other variants too
Even source code too - https://pastebin.com/kmmJuuQP
As I said - stealthy
deletes itself from the filesystem and renames its processes to look
innocent so can hide in plain sight
loads BPF filter to sniff traffic
upon activation then will modify firewall to allow attacker direct
access
In more detail:
Copies itself to /dev/shm/kdmtmpflush and then forks to clean itself up
to alter timestamps (timestomp) to a specific timestamp (7:17pm
Thursday October 30th 2008)
Drops a file at /bar/run/haldrund.pid to prevent further copies of
itself from running
Deletes itself from the /dev/shm/ ramdisk and then exits to leave the
forked copy running resident in memory and then use BPF filter to watch
for incoming traffic to activate
Doesn’t appear to have any particular persistence mechanism but some
reports suggest use of crontab or rc/init scripts
By deleting itself from the ramdisk this avoids detection from filesystem
scanners (although processes running from since deleted binaries are a
suspicious sign themselves and can be easily detected since once the
binary is removed the kernel notes this in /proc/self/exe for the
process)
Renames its argv[0] so that it looks like other commonly found processes
like dbus-daemon / udevd / auditd etc
Also wipes its environ too to try and help hide it’s activities, however
this again is another suspicious activity and can easily be detected
(e.g. strings on /proc/$PID/environ will show as empty which is basically
never normally the case for normal processes)
BPF filter inspects either ICMP, TCP or UDP packets and then if it has a
special magic value in the first couple bytes it passes into the main
packet processing routine
This then looks for a couple specific passwords (encrypted via RC4) -
if found then sets up either a local bindshell for the attacker to
connect to OR connects back to the attacker via a reverse bindshell
Then sets up an iptables rule to redirect traffic from the original
port to the port of the bindshell on the localhost
bindshell masquerades its process name to look like postfix as well as
setting a specific environment too (including HISTFILE=/dev/null)
Then attacker has full access to the machine (as the user)
Reasonably advanced malware
What is not clear is what is the initial compromise vector and then how
to privesc from that to give privileges to load BPF filter on a raw socket
Crowdstrike blog post mentions that on Solaris CVE-2019-3010 is used to
privesc via xscreensaver but this vuln is specific to Solaris platforms
Why it is important to keep systems updated with latest patches etc.
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
May 20, 2022Episode 160
Overview
Ubuntu get’s pwned again at Pwn2Own Vancouver 2022, plus we look at
security updates for the Linux kernel, RSyslog, ClamAV, Apport and more.
This week in Ubuntu Security Updates
57 unique CVEs addressed
[USN-5413-1] Linux kernel vulnerabilities [01:06]
6 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2022-28390
CVE-2022-27223
CVE-2022-26490
CVE-2021-4157
CVE-2021-39713
CVE-2020-27820
4.4 - 16.04 ESM GA + 14.04 ESM
UAF in nouveau driver when device is removed - external NVIDIA GPU? or
local user unbinding the driver?
UAF due to race condition in network packet scheduler
OOB write in NFS - user who had access to an NFS mount could possibly
exploit this
Buffer overflow in ST Micro NFC driver - failed to validate parameters
from NFC device - physically approximate attacker could possibly exploit
this but would need custom hw/sw
Similarly, Xilinx USB2 gadget driver failed to validate USB endpoints
ESM CAN/USB double-free
[USN-5415-1] Linux kernel vulnerabilities [02:27]
8 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-27223
CVE-2022-26490
CVE-2022-25375
CVE-2022-25258
CVE-2022-20008
CVE-2022-1016
CVE-2021-26401
CVE-2020-27820
5.4 - 20.04 LTS GA + 18.04 LTS HWE + clouds
Above vulns plus:
AMD specific issue around insufficient mitigations for Spectre v2
attacks
OOB read -> info leak through mishandling of MMC/SD read errors
[USN-5417-1] Linux kernel vulnerabilities [03:07]
8 CVEs addressed in Focal (20.04 LTS), Impish (21.10)
CVE-2022-29156
CVE-2022-27223
CVE-2022-26966
CVE-2022-26490
CVE-2022-25375
CVE-2022-25258
CVE-2022-20008
CVE-2021-26401
5.13 - 21.10, 20.04 LTS HWE + some clouds
~ same as above
[USN-5418-1] Linux kernel vulnerabilities [03:19]
13 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS)
CVE-2022-27223
CVE-2022-26966
CVE-2022-26490
CVE-2022-25375
CVE-2022-25258
CVE-2022-24958
CVE-2022-23042
CVE-2022-23040
CVE-2022-23039
CVE-2022-23038
CVE-2022-23037
CVE-2022-23036
CVE-2021-26401
4.15 - 18.04 LTS GA, 16.04 ESM HWE + clouds + OEM, 14.04 ESM azure
~ same as above
[USN-5416-1] Linux kernel (OEM) vulnerabilities [03:26]
5 CVEs addressed in Focal (20.04 LTS)
CVE-2022-28390
CVE-2022-28389
CVE-2022-28388
CVE-2022-1516
CVE-2022-1158
5.14 - 20.04 LTS OEM
KVM mishandled guest page table updates -> guest VM crash host OS
2 similar issues in CAN bus drivers - 8 Devices USB2CAN and Microchip CAN
Bus analyzer both had double-free on error paths - local attacker could
crash -> DoS
Plus ESM CAN/USB issue from above
[USN-5419-1] Rsyslog vulnerabilities [04:26]
3 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2019-17042
CVE-2019-17041
CVE-2018-16881
2 issues in handling of various message types (AIX + Cisco log messages
failed to properly validate contents and so could result in heap buffer overflow)
1 in handling of plain TCP socket comms - but this module is not enabled
in the default rsyslog configuration for Ubuntu
[USN-5420-1] Vorbis vulnerabilities [05:01]
3 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2018-10393
CVE-2018-10392
CVE-2017-14160
heap buffer overflow, OOB read + stack buffer overflow via crafted input
files - DoS / RCE
[USN-5421-1] LibTIFF vulnerabilities [05:16]
5 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-0865
CVE-2022-0891
CVE-2022-0562
CVE-2022-0561
CVE-2020-35522
Similar types of issues in libtiff - OOB reads / writes
[USN-5422-1] libxml2 vulnerabilities [05:32]
2 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-29824
CVE-2022-23308
UAF plus possible integer overflows -> unspec impact (but requires victim
to process a multiGB XML file)
[USN-5311-2] containerd regression [06:03]
1 CVEs addressed in Focal (20.04 LTS), Impish (21.10)
CVE-2022-23648
Episode 152 - subsequent update to containerd by different team reverted
the CVE fix accidentally - reinstated it
[USN-5423-1, USN-5423-2] ClamAV vulnerabilities [06:24]
5 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-20796
CVE-2022-20792
CVE-2022-20785
CVE-2022-20771
CVE-2022-20770
0.103.6
Various infinite loops in different parsers (CPU-based DoS), memory leaks
plus a couple OOB writes
[USN-5424-1] OpenLDAP vulnerability [06:53]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-29155
SQL injection in the sql backend of slapd via an SQL statement within a LDAP query
[USN-5425-1] PCRE vulnerabilities [07:09]
2 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-2020-14155
CVE-2019-20838
OOB read -> info leak
integer overflow -> buffer overflow? -> crash / code execution
[USN-5426-1] needrestart vulnerability [07:20]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-30688
detects daemons that need to be restarted after libraries are upgraded
uses various regex’s to detect scripting languages - but since these were
not specific enough, it could allow a user to get their own script
executed in the context of the user which is running needrestart - which
could be root
[USN-5427-1] Apport vulnerabilities [08:08]
8 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-28658
CVE-2022-28657
CVE-2022-28656
CVE-2022-28655
CVE-2022-28654
CVE-2022-28652
CVE-2022-1242
CVE-2021-3899
Gerrit Venema reported a heap of issues in Apport - thanks to Marc
Deslauriers on our team for working on these
Crash handler in Ubuntu - is invoked by the kernel when an application
crashes to collect various data to then upload to Ubuntu developers
Runs as root but can be invoked as a regular user so has been a target
for privesc vulns in the past
Has various code to drop privileges etc but these were found to be
incomplete
Impacts of these issues range from DoS by crashing Apport through to
local privesc to root
[USN-5428-1] libXrandr vulnerabilities [09:14]
2 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2016-7948
CVE-2016-7947
Integer overflows -> OOB write plus another different OOB write - all
able to be triggered by a malicious remote X server
Goings on in Ubuntu Security Community
Ubuntu in Pwn2Own Vancouver 2022 [09:39]
15 year anniversary of Pwn2Own
17 teams attempting to exploit 21 targets - including Ubuntu Desktop for EoP
https://www.zerodayinitiative.com/blog/2022/5/17/pwn2own-vancouver-2022-the-schedule
5 different teams targeting Ubuntu Desktop - Ubuntu 22.04 LTS fully
up-to-date
Prize of $40k USD
2 on day 1, 2 on day 2, 1 on day 3 (tomorrow)
https://www.zerodayinitiative.com/blog/2022/5/18/pwn2own-vancouver-2022-the-results
So far all 4 have been successful:
Team Orca of Sea Security (not live streamed)
OOBW + UAF
Keith Yeo
UAF
Bien Pham
UAF
Zhenpeng Lin (@Markak_), Yueqi Chen (@Lewis_Chen_), and Xinyu Xing (@xingxinyu) of Team TUTELARY
UAF
Lots of great new bugs - expect to hear more about these in the coming weeks
Past episodes covering Ubuntu @ Pwn2Own over previous years Episode 111
and Episode 71 - in particular has a great interview with Steve and Marc
from our team who cover what it is like as a vendor
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
May 15, 2022Episode 159
Overview
This week we bring you part 2 of our look at the new Ubuntu 22.04 LTS
release and what’s in it for security, plus we cover security updates for
DPDK, OpenSSL, Cron, RSyslog, Curl and more.
This week in Ubuntu Security Updates
37 unique CVEs addressed
[USN-5401-1] DPDK vulnerabilities [00:54]
2 CVEs addressed in Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-0669
CVE-2021-3839
Data-plane development kit (provides TCP offloading to userspace to
accelerate package processing workloads)
Used by openvswitch for OpenStack software defined networking
OOB write due to missing check on queue length in vhost comms - could
allow a malicious guest to crash or get code execution on the host
Also fixed a possible DoS attack between a malicious vhost-user primary
and secondary where the primary can spam the secondary with with a huge
number of open file-descriptors which eventually leads the secondary to
exhaust it’s fd limit and hence DoS
[USN-5402-1] OpenSSL vulnerabilities [01:36]
4 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-1473
CVE-2022-1434
CVE-2022-1343
CVE-2022-1292
All 4 affect 22.04 whilst only one affects the older releases - in this
case if running 22.04, exposed to 4 vulns whilst for the older releases
only 1
Would be interesting to try and compare number of CVEs over the
lifetime of a piece of software - if always running the latest version
do you get exposed to more and more CVEs each time you upgrade? Is it
better to stick with older software since the rate of vulns found over
time likely decreases as it gets older…
Anyway, of these vulns 1 is a memory leak during certificate decoding
which could usually affect something like an TLS server which uses client
certs for authentication, plus a possible MiTM attack against RC4-MD5,
incorrect return code when validating OCSP messages which could cause a
user / application to believe was valid when in fact was not plus
possible code execution via the c_rehash script through
shell-metacharacters - but no privilege escalation so only get whatever
privileges the script is executing under (c_rehash is used to create
symlinks named as the hashes of certs etc when importing a cert into a
cert store so it can then easily be looked up via it’s hash value as the
filename)
[USN-5395-2] networkd-dispatcher regression [03:44]
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-29800
CVE-2022-29799
Episode 158 - upstream fix contained a small regression where an error
would be encountered under certain situations
[USN-5354-2] Twisted vulnerability [04:06]
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Jammy (22.04 LTS)
CVE-2022-21716
Episode 156 - Equivalent update for ESM releases plus latest Ubuntu LTS release
[USN-5403-1] SQLite vulnerability [04:20]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2021-36690
Crash / possible code execution in CLI client when using a crafted
query - upstream dispute this as an actual vuln since if can execute
sqlite cli then can already execute arbitrary commands
[USN-5405-1] jbig2dec vulnerabilities [04:40]
2 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2020-12268
CVE-2017-9216
used in ghostscript, mupdf and others for handling JBIG2 files
NULL ptr dereference -> crash -> DoS
Heap buffer overflow -> crash / code execution
[USN-5259-2] Cron vulnerabilities [04:58]
4 CVEs addressed in Bionic (18.04 LTS)
CVE-2019-9706
CVE-2019-9705
CVE-2019-9704
CVE-2017-9525
DoS via a very large crontab file with many many lines or very long lines
Ubuntu specific vuln allowing possible privesc from crontab group to root
when the crontab package is upgraded via a symlink attack - so in general
was a dormant / latent vuln that would only be able to be triggered if a
sysadmin manually reinstalled cron or we released a new update 😁 - so
fixed now
[USN-5259-3] Cron regression [05:47]
4 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS)
CVE-2019-9706
CVE-2019-9705
CVE-2019-9704
CVE-2017-9525
but unfortunately caused a minor regression where some harmless but
possibly scary looking error messages would be printed when cron was
upgraded - fixed with this further update
[USN-5404-1] Rsyslog vulnerability [05:57]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-24903
Potential heap buffer overflow in TCP syslog reception - so a malicious
host which is logging to a centralized syslog server could possibly crash
or get code execution on the server (as the syslog user only)
[USN-5244-2] DBus vulnerability [06:18]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2020-35512
Possible UAF when running on a system where multiple usernames are mapped
to the same UID - if policy references these usernames, may free it via
one username whilst it is still being accessed by the other
Not really likely to encounter this setup or be able to easily exploit it
[USN-5179-2] BusyBox vulnerability [07:03]
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2021-28831
Episode 141
[USN-5407-1] Cairo vulnerabilities [07:10]
4 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2020-35492
CVE-2019-6462
CVE-2017-9814
CVE-2016-9082
2 OOB reads, stack buffer overflow and infinite loop in handling of
crafted image / font files
[USN-5408-1] Dnsmasq vulnerability [07:24]
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-0934
Heap-based UAF found by oss-fuzz when handling malicious DHCPv6 requests
[USN-5409-1] libsndfile vulnerability [07:46]
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2021-4156
OOB read in FLAC codec -> crash / possible info leak
[USN-5410-1] NSS vulnerability [07:54]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2020-25648
Mishandled ChangeCipherSpec messages in TLS 1.3 - remote client could
crash a server by sending multiple of these
[USN-5411-1] Firefox vulnerabilities [08:06]
8 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-29918
CVE-2022-29917
CVE-2022-29916
CVE-2022-29915
CVE-2022-29914
CVE-2022-29912
CVE-2022-29911
CVE-2022-29909
100.0 - usual mix of issues for web browsers/rendering engines (XSS, RCE,
DoS, bypass permission checks etc)
[USN-5412-1] curl vulnerabilities [08:24]
3 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-27782
CVE-2022-27781
CVE-2022-27780
More curl vulns - seems to be more every 5-10 weeks or so lately -
fuzzing?
logic error on connection reuse could reuse an old connection after
parameters had been changed
Possible infinite loop when constructing a server’s TLS cert chain ->
DoS
incorrect handling of %-encoded URL separators - could parse URL
wrongly and so end up visiting wrong URL or bypassing access checks /
filters etc
curl is part of hackerone and has so far paid out $17k USD in bounties
Whilst preparing this week’s episode 6 more vulns were announced in curl
Interesting twitter thread from curl maintainer on the ratio of vulns
which are due to C mistakes vs general programming logic mistakes -
general mistakes higher so I assume this is used as an argument as to why
implementing such a ubiquitous piece of software in such an unsafe
language is “ok” - can’t say I agree
Also compared how long it takes to find vulns from C mistakes vs non-C
mistakes - non-C mistakes take longer to find, presumably due to lack of
good tools for finding them (compared to say UBSan, Coverity etc for
finding C specific mistakes)
Goings on in Ubuntu Security Community
What’s new in security in Ubuntu 22.04 LTS (part 2) [11:35]
In part 1 we covered new security features in the kernel
This week we look at userspace security improvements
OpenSSL 3
disables a lot of legacy algorithms by default, upstream have a
migration guide which explains the main changes from 1.1.1 as well
as how to enable the legacy provider if you still require access to
them
Default security level is still 2 but it now disables (D)TLS 1.2
protocols (and below)
openssh 8.9
Lots of changes since 8.2 in 20.04 LTS, but in particular has
improved handling of FIDO/U2F hardware tokens - openssh in 20.04 LTS
first introduced support for FIDO/U2F tokens as 2FA for remote SSH
logins - basically would generate a new openssh key where the private
half of the key is only accessible with the FIDO/U2F token - this new
release brings support for using a PIN with the token and much better
improved UX so that users don’t have to keep getting prompted for
their PIN each time. Plus supports verifying WebAuthn signatures
nftables as default firewall backend
firewalling on Linux has 2 components - kernel-space mechanism and
userspace tooling to control that
traditionally kernel supported iptables (aka xtables - ip,ip6,arp,eb -tables)
nftables as introduced into the kernel in 3.13 as a new mechanism to
implement network packet classification and handling - aka firewalling
etc
kernel has 2 mechanisms then - xtables and nftables
userspace then has 2 primary tools for handling these - iptables for
xtables and nftables (nft) for nftables
iptables userspace added a nft backend so existing iptables rules and
users would be switched to that automatically - so can still use
traditional iptables command to configure firewall rules etc but they
will then be loaded into the kernel’s nft backend rather than xtables
also has a separate userspace command nft to directly configure nft
backend which supports more advanced rule types
Need to be careful that all tools which configure firewall rules use
the same backend in the kernel otherwise they may conflict and get
weird results
gcc 11 with improved static analysis via -fanalyzer
Double free, UAF, free of non-heap memory, malloc leak, NULL ptr
deref, unsafe calls within signal handlers and more
bash 5.1 - $SRANDOM vs $RANDOM
RANDOM is a psuedo-random number which comes internally from bash and
hence is deterministic based on the original seed value
SRANDOM is derived from the kernel’s /dev/urandom and hence is not
reproducible / deterministic - ie. is actually more truly random
Private home directories by default
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
20 min
May 06, 2022Episode 158
Overview
Microsoft’s Nimbuspwn sets the Linux security media ablaze but where
there’s smoke there’s not always fire, plus we bring you the first part of
a 2 part series looking at some of the security features in the latest
Ubuntu 22.04 LTS release.
This week in Ubuntu Security Updates
92 unique CVEs addressed
[USN-5381-1] Linux kernel (OEM) vulnerabilities
11 CVEs addressed in Focal (20.04 LTS)
CVE-2022-28356
CVE-2022-27223
CVE-2022-26966
CVE-2022-26490
CVE-2022-24958
CVE-2022-1048
CVE-2022-1016
CVE-2022-1011
CVE-2022-0854
CVE-2022-0494
CVE-2022-1015
[USN-5383-1] Linux kernel vulnerabilities
8 CVEs addressed in Focal (20.04 LTS), Impish (21.10)
CVE-2022-24959
CVE-2022-26878
CVE-2022-24448
CVE-2022-1016
CVE-2022-0617
CVE-2021-44879
CVE-2021-43976
CVE-2022-1015
[USN-5384-1] Linux kernel vulnerabilities
3 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-24959
CVE-2022-24448
CVE-2022-0617
[USN-5385-1] Linux kernel vulnerabilities
4 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS)
CVE-2022-24959
CVE-2022-24448
CVE-2022-0617
CVE-2021-43975
[USN-5387-1] Barbican vulnerabilities
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-23452
CVE-2022-23451
[USN-5376-2] Git vulnerability
1 CVEs addressed in Jammy (22.04 LTS)
CVE-2022-24765
[USN-5388-1] OpenJDK vulnerabilities
5 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-21496
CVE-2022-21476
CVE-2022-21443
CVE-2022-21434
CVE-2022-21426
[USN-5388-2] OpenJDK vulnerabilities
6 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-21496
CVE-2022-21476
CVE-2022-21443
CVE-2022-21434
CVE-2022-21426
CVE-2022-21449
[USN-5389-1] Libcroco vulnerabilities
4 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2020-12825
CVE-2017-8871
CVE-2017-8834
CVE-2017-7960
[USN-5390-1] Linux kernel vulnerabilities
3 CVEs addressed in Jammy (22.04 LTS)
CVE-2022-26490
CVE-2022-1016
CVE-2022-1015
[USN-5376-3] Git regression
Affecting Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
[USN-5391-1] libsepol vulnerabilities
4 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2021-36087
CVE-2021-36086
CVE-2021-36085
CVE-2021-36084
[USN-5366-2] FriBidi vulnerabilities
3 CVEs addressed in Jammy (22.04 LTS)
CVE-2022-25310
CVE-2022-25309
CVE-2022-25308
[USN-5393-1] Thunderbird vulnerabilities
8 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-1197
CVE-2022-28289
CVE-2022-28286
CVE-2022-28285
CVE-2022-28282
CVE-2022-28281
CVE-2022-1196
CVE-2022-1097
[USN-5371-2] nginx vulnerability
3 CVEs addressed in Jammy (22.04 LTS)
CVE-2020-36309
CVE-2020-11724
CVE-2021-3618
[USN-5394-1] WebKitGTK vulnerabilities
4 CVEs addressed in Focal (20.04 LTS), Impish (21.10)
CVE-2022-22637
CVE-2022-22629
CVE-2022-22628
CVE-2022-22624
[USN-5392-1] Mutt vulnerabilities
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-1328
CVE-2021-32055
[USN-5395-1] networkd-dispatcher vulnerabilities
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-29800
CVE-2022-29799
[USN-5396-1] Ghostscript vulnerability
1 CVEs addressed in Bionic (18.04 LTS)
CVE-2019-25059
[USN-5397-1] curl vulnerabilities
4 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-27776
CVE-2022-27775
CVE-2022-27774
CVE-2022-22576
[USN-5398-1] Simple DirectMedia Layer vulnerability
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Impish (21.10)
CVE-2021-33657
[USN-5399-1] libvirt vulnerabilities
6 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2021-3631
CVE-2020-25637
CVE-2022-0897
CVE-2021-4147
CVE-2021-3975
CVE-2021-3667
[USN-5400-1] MySQL vulnerabilities
23 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10), Jammy (22.04 LTS)
CVE-2022-21478
CVE-2022-21462
CVE-2022-21460
CVE-2022-21459
CVE-2022-21457
CVE-2022-21454
CVE-2022-21452
CVE-2022-21451
CVE-2022-21444
CVE-2022-21440
CVE-2022-21438
CVE-2022-21437
CVE-2022-21436
CVE-2022-21435
CVE-2022-21427
CVE-2022-21425
CVE-2022-21423
CVE-2022-21418
CVE-2022-21417
CVE-2022-21415
CVE-2022-21414
CVE-2022-21413
CVE-2022-21412
[USN-5400-2] MySQL vulnerabilities
6 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-21460
CVE-2022-21454
CVE-2022-21451
CVE-2022-21444
CVE-2022-21427
CVE-2022-21417
[USN-5390-2] Linux kernel (Raspberry Pi) vulnerabilities
3 CVEs addressed in Jammy (22.04 LTS)
CVE-2022-26490
CVE-2022-1016
CVE-2022-1015
Goings on in Ubuntu Security Community
Nimbuspwn [01:46]
Nimbuspwn -
https://www.microsoft.com/security/blog/2022/04/26/microsoft-finds-new-elevation-of-privilege-linux-vulnerability-nimbuspwn/
At the end of April Microsoft disclosed some vulnerabilities which
gathered a lot of media attention, leading to a lot of outlets seemingly
claiming most Linux systems were affected and that this was a high
severity issue
Describes a number of issues in networkd-dispatcher which could be used
to get RCE
directory traversal
symlink race
TOCTOU permissions check race condition
However, all relies on being able to have an arbitrary process run under
the systemd-network user (since this user is the only one which can bind
to the right dbus name org.freedesktop.network1)
Originally they provided some vague mentions of gpgv plugins and epmd
running under this user.
gpgv plugins are launched by apt=/=apt-get during package install /
upgrade so this sounds like a common scenario that would affect most
users (instead of say epmd which is the erlang port mapper daemon, so
unless you are running erland applications you would not be affected by
that)
Looking again though at these gpg plugins running as the systemd-network
user - this is definitely not the case for standard Ubuntu - since apt is
very clear to run them under the _apt user account purposefully to
restrict their privileges
After we questioned Microsoft about this, they amended the blog post to
then just say they were able to detect several instances of other
processes running under this user in various customer environments but
then state that some of these were due to customer
misconfigurations.
So there is no real evidence here that in general Ubuntu / Linux users
would be affected as all the original media reporting suggested
Perhaps these customers were using containers and running processes in
those where the UID mapped back to the systemd-network user ID on the
host? This is a common pitfall with containers and something which users
need to be aware of when deploying containers
As such, what appeared to be quite a high priority and high profile
vulnerability in fact is likely more of a bit of a non-issue - whilst it
could be argued that these are real issues in networkd-dispatcher since
they are not able to be exploited in standard configurations they are not
a real threat to most users
Interesting to note while the blog post has been
amended, all the various media articles which cited the original report
have not been updated and still seem to claim that Ubuntu and other
distros would be affected by this
Also interesting to note, Microsoft worked directly with the upstream
maintainer of networkd-dispatcher but didn’t involve any downstream
distros - as suggested by Julian Andres Klode from the Ubuntu Foundations
team (and upstream apt maintainer) - perhaps Microsoft should have
pre-disclosed this issue to the linux-distros mailing list - if they had
done so this likely would have been assessed and clarified earlier so
that Microsoft could have more properly understood the extent of the
vulnerabilities which they discovered the internet could have avoided
another brief panic scenario
What’s new in security in Ubuntu 22.04 LTS (part 1) [08:05]
Preview of the first half of blog post which will be published in the
coming weeks on the various security features which are included in
Ubuntu 22.04 LTS. This week we will look at enhancements provided by the
Linux kernel whilst next week we will look at features provided by other
parts of the distribution.
22.04 LTS latest long term support release - 5 years of standard support
plus 5 years of ESM - total 10 years of support via Ubuntu Advantage
(free for personal use)
Great foundation to use then to deploy services / applications etc and
know they will be supported for a long time to come
Has been 2 years since the last LTS so there are lots of features to
cover - I will only touch on some of them - if you want a more deep dive,
check out the blog posts we published for the interim releases
Optimised kernels for different platforms
OEM desktops - 5.17
Desktop & server - 5.15
Desktop will get HWE stack by default so in future will get kernel
version upgrades bringing new features etc whilst server will stick
with GA kernel for stability
Clouds have their own optimised kernels
Hardware specific enhancements
SGX on Intel for secure enclaves
Memory tagging on ARM64 to protect against memory corruption attacks
AMD SEV for KVM to protect guest VM registers from the host
Generic kernel improvements
Core scheduling to provide a means to use SMT in the face of various
hardware microarchitectural side-channel attacks like L1TF and the like
(this was only partially mitigated in SW/microcode and could still
potentially affect VMs running across SMT siblings) - so in past had to
disable SMT to be fully certain were protected - now can use core
scheduling to specify to the kernel which processes should not be
scheduled on sibling HTs to avoid these sorts of attack
Kernel stack offset randomisation across system calls
BPF improvements - one of the most popular subsystems in the kernel,
used not just for tracing and packet filtering but also now BPF LSM and
more use-cases. However, has also caused a number of security vulns as
covered previously - now disabled unprivileged BPF by default. Also
work has been done to try and support signed BPF programs to ensure
only trusted code is executed as well.
Landlock LSM for application-level sandboxing - like seccomp, Landlock
allows a process to specify it’s own policy so can sandbox itself -
rather than say traditional MAC systems of AppArmor/SELinux where the
system admin configures the policy
LSM stacking allows Landlock to be used in conjunction with AppArmor
for a more defense-in-depth approach
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
19 min
April 22, 2022Episode 157
Overview
Ubuntu 22.04 LTS (Jammy Jellyfish) is officially released 🎉 and so this
week we take a quick look at the new features and enhancements, with a
particular focus on security, plus we cover security updates for the Linux
kernel, Firefox, Django, Git, Gzip and more.
This week in Ubuntu Security Updates
58 unique CVEs addressed
[USN-5368-1] Linux kernel vulnerabilities [00:51]
23 CVEs addressed in Focal (20.04 LTS)
CVE-2022-27666
CVE-2022-0742
CVE-2022-0516
CVE-2022-0435
CVE-2022-0382
CVE-2022-0264
CVE-2021-45480
CVE-2021-45402
CVE-2021-45095
CVE-2021-44733
CVE-2021-43975
CVE-2021-4197
CVE-2021-4135
CVE-2021-39698
CVE-2021-39685
CVE-2021-28715
CVE-2021-28714
CVE-2021-28713
CVE-2021-28712
CVE-2021-28711
CVE-2022-0492
CVE-2022-1055
CVE-2022-23222
5.13 azure/oracle for 20.04 LTS
BPF verifier could possibly allow pointer arithmetic in BPF operations -
OOB read / write -> crash (DoS) or privesc
cgroups v1 release_agent not properly restricted -> privesc
UAF in network traffic control - DoS/crash
[USN-5377-1] Linux kernel (BlueField) vulnerabilities [01:52]
15 CVEs addressed in Focal (20.04 LTS)
CVE-2022-27666
CVE-2022-0435
CVE-2021-45480
CVE-2021-45469
CVE-2021-45095
CVE-2021-44733
CVE-2021-43976
CVE-2021-4135
CVE-2021-28715
CVE-2021-28714
CVE-2021-28713
CVE-2021-28712
CVE-2021-28711
CVE-2022-0492
CVE-2022-1055
BPF verifier could possibly allow pointer arithmetic in BPF operations -
OOB read / write -> crash (DoS) or privesc
cgroups v1 release_agent not properly restricted -> privesc
[USN-5366-1] FriBidi vulnerabilities [02:07]
3 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-25310
CVE-2022-25309
CVE-2022-25308
Various memory corruption vulns in library for handling unicode
bidirectional text
[USN-5369-1] oslo.utils vulnerability [02:21]
1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-0718
Python utility functions for OpenStack
Passwords which contained a double-quote would not be properly masked in
debug logs in which case the part of the password following the double
quote would be exposed
[USN-5370-1] Firefox vulnerabilities [02:50]
11 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-28287
CVE-2022-28283
CVE-2022-28289
CVE-2022-28288
CVE-2022-28286
CVE-2022-28285
CVE-2022-28284
CVE-2022-28282
CVE-2022-28281
CVE-2022-24713
CVE-2022-1097
99.0
Including an issue where just selecting text could be enough to cause a
memory corruption in text selection cache and cause firefox to crash
[USN-5331-2] tcpdump vulnerabilities [03:34]
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2020-8037
CVE-2018-16301
Episode 153 for xenial - now same updates for bionic + focal
[USN-5373-1, USN-5373-2] Django vulnerabilities [03:47]
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)
CVE-2021-32052
CVE-2022-28347
CVE-2022-28346
2 different SQL injection attacks and 1 header in injection attack
[USN-5374-1] libarchive vulnerability [04:07]
1 CVEs addressed in Focal (20.04 LTS), Impish (21.10)
CVE-2022-26280
OOB when handling crafted LZMA archives -> DoS
[USN-5372-1] Subversion vulnerabilities [04:24]
2 CVEs addressed in Focal (20.04 LTS), Impish (21.10)
CVE-2022-24070
CVE-2021-28544
2 vulns in svn server - both in handling of path based auth rules - 1 as
logic error could then allow an attacker to bypass these and info about
private paths
other as a UAF -> crash/RCE
[USN-5376-1] Git vulnerability [05:13]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-24765
Possible local RCE if another user creates a .git directory in the system
root and specifies arbitrary commands in that git config
[USN-5371-1] nginx vulnerabilities [05:55]
3 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2021-3618
CVE-2020-36309
CVE-2020-11724
HTTP req smuggling
[USN-5378-1, USN-5378-2, USN-5378-3, USN-5378-4] Gzip & XZ Utils vulnerability [06:05]
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)
CVE-2022-1271
xzgrep/zgrep with crafted filenames -> local file overwrite
[USN-5379-1] klibc vulnerabilities [06:27]
4 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2021-31873
CVE-2021-31872
CVE-2021-31871
CVE-2021-31870
Various integer overflows and other bugs leading to memory corruption ->
RCE in these low-level tools (designed for use in initramfs/embedded
systems etc - cat/dd/dmesg/gzip/ipconfig/mv/readlink and more)
[USN-5380-1] Bash vulnerability [07:12]
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2019-18276
Incorrect handling of setuid binaries - didn’t drop privileges correctly,
so could allow a user who could cause bash to load their own crafted
builtin module to then escalate privileges by then restoring the saved
UID
Goings on in Ubuntu Security Community
Ubuntu 22.04 LTS Release! [08:02]
By the time you read / hear this will likely already be out
LTS - 5 years of standard support, plus 5 years of ESM support - 10 years
of security support in total
https://discourse.ubuntu.com/t/jammy-jellyfish-release-notes/24668
Multiple kernels depending on which product you install
Desktop
5.17 on OEM certified devices
Rolling HWE kernel for other hardware (currently 5.15)
Server
Non-rolling LTS kernel (5.15)
Cloud
Use optimised kernels in collaboration with partners (currently 5.15+
with additional backports / features)
As always these are just the defaults and you can change as you desired
(ie could enable rolling HWE kernel on server if required)
UDP disabled for NFS mounts
Toolchain upgrades
GCC 11.2.0, Python 3.10 (with PIE🥧), LLVM 14, Golang 1.18.x, rustc 1.58
OpenJDK 18 provided (but not default and not in main, still default to
openjdk-11 in main and supported)
systemd-oomd enabled by default on Ubuntu desktop
OpenSSL 3.0
Disables various legacy algorithms (SHA1/MD5 for certificate hashes)
nftables default backend for firewall
Still ship legacy iptables tools which will use the xtables backend but
not by default - sysadmins need to ensure all applications which
configure firewall rules use the same backend (e.g. if using docker
snap need to switch to legacy xtables backend until the snap is updated
to detect and use the new nftables backend)
ssh-rsa with sha-1 signatures disabled by default in openssh
scp supports a new -s option to use sftp instead of scp which is safer
(see USN-3885-1 etc)
Firefox is a snap
Maintained and published directly by Mozilla - faster access to newer
versions
Sandboxed for improved security hardening
Lots of changes for server too (new BIND, Apache, PostgreSQL, Django,
MySQL, Samba)
Qemu 6.2.0 (massively improved RISC-V support)
Libvirt + swtpm for TPM emulation
virt-manager will then enable a TPM OOTB for UEFI boot of VMs
wireguard is now in main \o/
First LTS release for Ubuntu Desktop on RPi
Ubuntu Security Podcast on break for 1 week
Returning end of the first week of May 2022
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
19 min
April 08, 2022Episode 156
Overview
This week we bring you the TL;DL (too-long, didn’t listen 😉) version of
Camila’s recent 4-part Ubuntu hardening series, plus we look at security
updates for Twisted, rsync, the Linux kernel, DOSBox, Tomcat and more.
This week in Ubuntu Security Updates
48 unique CVEs addressed
[USN-5354-1] Twisted vulnerabilities [00:47]
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-21716
CVE-2022-21712
No limit to the amount of memory consumed when parsing the SSH version
string from a client/server - malicious client/server could then send an
infinite length version and crash the corresponding server/client -
limited to 4KB
Cookies and auth headers exposed in cross-origin redirects - leak
sensitive info
[USN-5355-1, USN-5355-2] zlib vulnerability [01:34]
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)
CVE-2018-25032
Announced by Tavis Ormandy on oss-security in last week of March -
reproducible crash when compressing certain inputs
Reported upstream only to be told was already fixed upstream back in 2018
but no CVE was ever assigned and since no release had been made since
then no distros had picked it up
Shows the importance of CVEs to distros security patching workflows - in
general no CVE, no patch
New upstream release has now been made as well
[USN-5359-1] rsync vulnerability [03:09]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2018-25032
Same as above - rsync contains a vendored copy of zlib code
[USN-5357-1, USN-5357-2] Linux kernel vulnerability [03:24]
1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS)
CVE-2022-27666
4.15 18.04 LTS, 16.04 ESM
Episode 155 - heap buffer overflow in handling IPsec ESP transformations
-> local user crash / codeexec
UAF in network traffic control subsystem - requires an attacker to be
root OR to be able to use unprivileged user namespaces - which is the
default for Ubuntu (but it is often suggested to disable this in most
hardening guides)
[USN-5358-1, USN-5358-2] Linux kernel vulnerabilities [04:45]
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-27666
CVE-2022-1055
5.13 (21.10), 5.4 (20.04 LTS, 18.04 LTS HWE)
[USN-5356-1] DOSBox vulnerabilities [05:01]
2 CVEs addressed in Bionic (18.04 LTS)
CVE-2019-12594
CVE-2019-7165
Heap buffer overflow when parsing BAT files with very long lines
Incorrectly would allow access to files under /proc
(e.g. /proc/self/mem) - could then allow an application to get code
execution - added checks on file access to prevent this
[USN-5360-1] Tomcat vulnerabilities [05:47]
9 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2021-41079
CVE-2021-25329
CVE-2020-9494
CVE-2021-33037
CVE-2020-9484
CVE-2021-30640
CVE-2021-25122
CVE-2020-17527
CVE-2020-13943
Thanks to Evren Yurtesen for providing the patches (from Debian) for
20.04 LTS
Various deserialisation issues -> RCE
Input length validation -> infinite loop -> CPU DoS
HTTP/2 issues on request header handling -> expose requests of one
connection to a different one -> info leak
[USN-5361-1] Linux kernel vulnerabilities [06:46]
14 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2021-45486
CVE-2021-43976
CVE-2021-42739
CVE-2021-4083
CVE-2021-39636
CVE-2021-37159
CVE-2021-31916
CVE-2021-28964
CVE-2021-0935
CVE-2021-0920
CVE-2020-3702
CVE-2020-26145
CVE-2020-26141
CVE-2020-12888
4.4
Various issues from previous episodes
[USN-5362-1] Linux kernel (Intel IOTG) vulnerabilities [07:03]
16 CVEs addressed in Focal (20.04 LTS)
CVE-2022-22942
CVE-2022-0742
CVE-2022-0516
CVE-2022-0435
CVE-2022-0330
CVE-2021-42327
CVE-2021-4155
CVE-2021-4090
CVE-2021-4083
CVE-2022-0001
CVE-2022-0185
CVE-2022-0492
CVE-2022-0847
CVE-2022-23222
CVE-2022-23960
CVE-2022-25636
5.13 kernel targetted to intel IoT platforms
Again includes fixes for various vulns discussed in past episodes
[USN-5364-1] Waitress vulnerability [07:17]
1 CVEs addressed in Focal (20.04 LTS), Impish (21.10)
CVE-2022-24761
Pure python impl of Webserver Gateway Interface (WSGI) standard -
interface spec on how server an application communicate
Request smuggling vuln due to differences in how waitress and a possible
frontend proxy interpret HTTP requests
[USN-5365-1] H2 vulnerabilities [07:47]
2 CVEs addressed in Focal (20.04 LTS), Impish (21.10)
CVE-2022-23221
CVE-2021-42392
Database engine
Deserialisation of untrusted data -> code execution
Crafted connection URLS -> code execution
Goings on in Ubuntu Security Community
TL;DL of recent series on Ubuntu hardening [08:11]
Various listener requests for a summary on the recent series of episodes
discussing Ubuntu hardening
Transcript
Hello listener! This is going to be a quick episode and so I will make a
quick introduction for it. During our last four episodes we talked about
how to harden our Ubuntu systems, making it more robust…and dare I say
it? More secure! However, four episodes is quite a lot, and not everyone is
willing to listen to several minutes of my awesome voice, so I am here
today to fix that and give you an episode that is a summary, a “Too Long,
Didn’t Listen” if you will, of those previous four episodes. So let’s get
going because today is no day for delays, and let’s talk, shortly and
succinctly, about things you can do to harden your Ubuntu system.
Let’s start with hardening measures you can apply to your system whilst
installing it:
(1) Encrypt your disk. Input and output operations might take a little
while longer to happen, but if your hardware can take it, that might not
even be an issue. Do remember though that everytime the device is shutdown,
when you turn it on, you will have to decrypt the disk before using the
operating system, which in turn means: inputting a password to get things
going. So maybe only do this if you have a system where this won’t be a
hindrance. Oh, and don’t lose your password, or else, you’ll end up with a
disk full of pretty, but uninterpretable, characters and no functional
operating system at all!
(2) Create a swap partition or a swap file to get the most out of your
RAM. Availability is also a cyber security concern you should have, and
providing your system with some swap space not only buffs it by giving it
more RAM memory to work with - even it if is only a wannabe RAM - but it
also allows you, as a system administrator, to be better prepared to face
memory issues that might come to haunt your system, since you can monitor
your swap space usage and use this as reference to know if your system
might be feeling a little bit overloaded. Avoiding unnecessary crashes just
got a whole lot easier. Choo OOM manager! A side note, though: check your
system requirements so that you setup swap in a way that fits your system’s
needs, or else, instead of making your device work better, you will only
make it work harder.
(3) Partition your system! Put /var and /home in different disk partitions
and avoid all that log file backup or those kitty videos from flooding your
disk space and forcing your critical processes to stop execution because
there is no space left in the system. Ooops. Maybe we should also take some
time to update the log backup script and to remind users that the server is
no place to store videos…even if they are adorable. And while you are at
it, maybe also add /tmp to its own partition. World writable /tmp is a well
known attacker target and grounding it and sending it to the corner to
think about its bad behavior might be a good way to avoid possible
attacks. Especially considering that different partitions can be set to
have different permissions.
(4) Strong passwords. This shouldn’t even be in this list because you
already use strong passwords when setting up your users during install,
right? What? I’m not nervous because I definitely need to change my
password from ‘security2022’ to something a lot better, you are!
With an installed system, our hardening journey is far from over, as we now
need to set everything up securely before getting our service and its
related applications running. How to proceed?
(1) Ubuntu does not enable a password for the ‘root’ user for a reason, and
so, recommendation number one is: just leave ‘root’ and its password
alone. Leave it there hibernating with all of its amazing and yet
destructive power over the system. No ‘root’ user password, no successful
brute force attacks, not even through SSH. An attacker in a regular user
shell is a lot less scary than an attacker in a ‘root’ shell. Use ‘sudo’
instead, and configure ‘sudo’ permissions for your users appropriately in
the /etc/sudoers file. YOU get to CHOOSE what commands each user can run as
the superuser, so take your time to set these up. Give each user the least
they need to perform their tasks, and stay safe. I know…it’s
amazing…you get to CONTROL what your users are allowed to do in your
system. “What? Has this always existed?” Yes, my friend, yes it has, so
it’s about time you start configuring it properly.
(2) Use SSH instead of Telnet for remote login, because you are NOT a
caveman that requires your data to be transmitted over the network in plain
text. Yes, cavemen knew not to use Telnet and they also knew that even when
using SSH they had to properly configure it before using it, or else, not
even encryption would save them. If you doubt me, go do your
research…this is 100% historically accurate, my fingers are definitely
not crossed behind my back as I say this. Disable root access through SSH,
use SSH2 instead of SSH1, setup allowlists and denylists for users and IP
addresses, and set a maximum number of login attempts were all of the basic
things cavemen in our planet did when setting up their SSH servers whilst
sitting around their very cozy and newly discovered fires. Plus, they also
setup private key login for their SSH servers, not because they were too
lazy to type in their passwords - …nooooo, they had passphrases for their
keys - but instead because it is a well-known and trusted way to verify the
identity of whoever is trying to connect to the server. Passwords by
themselves sometimes just aren’t enough. So…if cavemen were able to
discover fire AND properly set up their SSH servers…then it is more than
your obligation to at least do the same, if not more. Oh, and don’t forget
to properly set permissions in the ‘authorized_keys’ file…I mean…come on
guys…properly setting permissions in a very important file in your OS is
a lot easier than hunting, foraging, surviving in the menacing prehistoric
Earth environments, and that’s why cavemen did it as well.
(3) Can we really call it hardening of the system if we don’t consider
hardening of the one and only, the star of the show, the kernel itself? The
‘sysctl’ command in your Ubuntu system is there to attend to all of your
kernel hardening needs, allowing you to define kernel configurations, but
not requiring you to reboot the machine to get them to stick. With ‘sysctl’
you can do so many things that I wouldn’t be able to summarize it all here,
and I am already in a pinch because I am very bad at making my scripts
short, and I need to keep this one short. So, for now, I will give you a
little taste of what ‘sysctl’ can do to get those curiosity juices flowing!
Restrict users allowed to read kernel logs and block IP packet forwarding
for devices that are not routers. Was I able to make you interested? Well,
I know I wont get the answer to that, but what I do know is that both those
measures I mentioned can already take you a long way when you think of
hardening your system, and they are two amongst many available…sooo, get
those fingers typing and those kernel options researched and you, my
friend, are in the right path to get your system hardened!
(4) Setup a host based firewall. They are efficient in blocking unwanted
network traffic, they can be configured to your host’s specific needs and
they are portable, since, when the host migrates, its firewall goes with
it. Plus, it’s very easy to set up, you can use the Ubuntu tool known as
the Uncomplicated Firewall (‘ufw’) to help you, and it gets you started on
protecting yourself against the harsh, harsh Internet ecosystem that lies
out there. Oh, and don’t even try to argue with me and tell me about your
network based firewall and how it already does the job for you, because I
just discussed it in the long version of this series, so to make it short,
I will say one simple word to get my point across once again: layers!
(5) Remember when we were talking about partitioning your disk/filesystem?
Well, let’s kick that up a notch and configure each partition individually,
setting permissions and defining usage configurations for each one of the
different partitions in our disks. We are all unique in this huge world we
live in, and so are our partitions. Treat them with the love, care and
individuality that they deserve and they shall return all of your efforts
in the form of a more secure system. If you have a network shared
partition, for example, why not set the ’noexec’ option for this partition,
and avoid executables to be run from an area in your device that could be
considered untrustworthy at best and devastatingly dangerous at worst?
Don’t trust users, I always say, specifically when they come for your files
through the network. Another good option would be to set a partition as
read-only, if it is a partition that requires no more permissions than
this. The /etc/fstab file is the one you can go to in order to set all of
these configurations, which will be applied at mount time, exactly during
system boot.
(6) Don’t ignore your logs. Setup a nice logging system for your
device. Use syslog or journal to do so, and yeah…sure…thank me later, I
won’t complain if you do. But seriously though, how can you expect to
maintain and troubleshoot a device if you don’t know what is happening with
that device? And how do you expect to keep a system secure if you can’t
maintain and troubleshoot it? Yes, logs can be annoying to look at and
analyze sometimes, but that is why utilities such as ‘syslogd’ and
‘journald’ exist to help you search through those logs. Syslog even allows
you to send all of your data to a centralized server, which can then focus
exclusively on processing log data that it gets from various network
devices. You have all of that goldmine of data at your feet and all you
need to do now is use it. Ubuntu has the tools that allow you to do that,
but it doesn’t have the will…that, my friend, needs to come from you. So
to show how important it is to set up and use logs, I will end this
suggestion with a quote, because everything that includes quotes is usually
considered important, right? “Knowing yourself is the beginning of all
wisdom” - Aristotle. There, now go get some logging setup.
Ok. Next step is installing your applications so that you can get your
service up and running. I am not even going to go into detail about using
secure software, setting up this software including security
configurations, and using encryption when sending data through the network,
because that is obvious enough, right? If not…then I am sorry to tell
you, you might need to listen to the long version of this. I will go into
detail though, not much, but a little bit (if you want ‘much’, go listen to
parts 1, 2, 3 and 4), on what you can do after you set up your service, and
on what you can do until forever to keep your hardened system from going
soft on you. So let’s jump in.
(1) One or two network services per device!!! Don’t make your server a jack
of all trades, because that is a recipe for a hack of all spaces. If you
are going to use the network to expose your service, maybe incorporate it
as a part of the service’s architecture as well. Have more than one device
running server software which makes up a part of the entire provided
service, and have those devices communicate with each other through the
network. Different server applications in different devices will isolate
each relevant component and avoid a complete meltdown of the service in
general, in case something is compromised. Divide and conquer. It’s like we
don’t say this enough.
(2) Close unused ports in your system and disable unnecessary services and
daemons. By not doing so you are only increasing the attack surface for
your system, meaning, you are giving more possibilities for an attacker on
how to attack you. Less is more, and the bare minimum should be enough. Be
sure new installs and new updates don’t open up ports you don’t want to be
opened and don’t bring in new files, scripts or executables that might
compromise you. Keep a continuous eye on everything that is running in the
background. Just because you can’t see it, it does not mean it can’t be
hacked.
(3) Check your file permissions and change them if necessary! Defaults were
made to be overwritten and you don’t need 777 files lying around in your
system anymore, do you? Know your resources and set permissions
accordingly. Correctly setting up users and groups is implied here,
especially considering that users and groups will define who can and can’t
access a file in the system. Plus, disable the setuid and the setgid bit
for executables that don’t need it. When researching for privilege
escalation techniques in Linux, “Find setuid binaries in the system” is the
first technique to show up, so that should be enough of a warning to you
that an executable should only be allowed to run as another user in case it
is extremely…and let me say that again with emphasis: EXTREMELY
necessary, or else, it might just be another day, another root shell for
some random attacker.
(4) Install some third party software to help you keep your system
safe. “We are all in this together”, a quote from a song in a teen musical
I am totally not ashamed to admit I watched too much when I was a bit
younger, used to say, and that applies for the cyber security
community. Software that can help you better the security in your devices
is plenty out there, and here, today, I will mention a few of them that you
can check out and possibly use in order to harden your Ubuntu OS even
more. Obviously, since this is a summary, we are doing this the fast way,
so let’s get listing: Fail2ban, Snort and Suricata for intrusion detection
and prevention; the Google PAM package, which allows implementation of
2-factor-authentication for your Ubuntu users; ClamAV, for malware
detection; the Mozilla TLS configuration generator, to help you securely
generate configuration files for well known applications; and finally,
AppArmor, or possibly SELinux, for Mandatory Access Control that will
complement the Discretionary Access Control you already set up with your
file permissions earlier.
To finish this all off, don’t forget to keep your packages up-to-date, to
use shred instead of remove to get rid of files containing sensitive data
in your system, and to continuously go back and reconsider all of the
previously mentioned points, so that your system can securely keep up with
changes that are being made around it. The world won’t stop spinning and
technology won’t stop evolving, so your server cannot afford to not be
maintained and updated on a regular basis, or else, all of your initial
hardening will be for naught.
That is all for today friends, and I hope you enjoyed it. It was a quick
one, but it was an episode made with love. Feel free to share your thoughts
on any of our social media platforms and for now I bid you 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
27 min
April 01, 2022Episode 155
Overview
It’s an off-by-one error in the podcast this week as we bring you part 4 of
Camila’s 3-part Ubuntu hardening series, plus we look at security updates
for Thunderbird, OpenVPN, Python, Paramiko and more.
This week in Ubuntu Security Updates
47 unique CVEs addressed
[USN-5345-1] Thunderbird vulnerabilities [00:45]
13 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-0566
CVE-2022-26387
CVE-2022-26386
CVE-2022-22756
CVE-2022-22754
CVE-2022-26384
CVE-2022-26383
CVE-2022-26381
CVE-2022-22764
CVE-2022-22763
CVE-2022-22761
CVE-2022-22760
CVE-2022-22759
91.7.0
Long wait times for TB updates raised as an issue in Ubuntu Discourse
[USN-5346-1] Linux kernel (OEM) vulnerability [01:21]
1 CVEs addressed in Focal (20.04 LTS)
CVE-2022-0742
ICMPv6 memory leak - DoS via remote unauthenticated user
[USN-5353-1] Linux kernel (OEM) vulnerability
1 CVEs addressed in Focal (20.04 LTS)
CVE-2022-27666
Heap buffer overflow in IPsec when doing ESP transformations - not
remotely triggerable, requires local user -> DoS/privesc
[USN-5347-1] OpenVPN vulnerability [02:00]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-0547
Possible authentication bypass through only partially correct credentials
due to use of multiple plugins which do deferred authentication - updated
to only allow one plugin to do deferred auth
[USN-5321-3] Firefox regressions [02:42]
7 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-26387
CVE-2022-26385
CVE-2022-26384
CVE-2022-26383
CVE-2022-26382
CVE-2022-26381
CVE-2022-0843
98.0.2
[USN-5342-1] Python vulnerabilities [02:54]
3 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-0391
CVE-2021-4189
CVE-2021-3426
pydoc server could disclose other files - shouldn’t be exposed to
untrusted users
Mishandling of FTP requests (could be tricked into connecting to wrong
server)
urllib.parse mishandled URLs with embedded newlines - possible to bypass
regular checks leading to possible URL/request injection etc
[USN-5348-1] Smarty vulnerabilities [03:42]
6 CVEs addressed in Bionic (18.04 LTS), Impish (21.10)
CVE-2021-29454
CVE-2021-26120
CVE-2021-26119
CVE-2021-21408
CVE-2018-16831
CVE-2018-13982
PHP templating engine
Failed to validate paths in templates - attacker controlled template
could then get arbitrary file read
Various code execution vulns affecting applications that use Smarty
[USN-5349-1] GNU binutils vulnerability [04:17]
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2019-1010204
gold linker - not the default linker in Ubuntu (would have to specify it
manually via -fuse-ld=gold to gcc)
OOB read when handling a crafted ELF file
[USN-5352-1] Libtasn1 vulnerability [04:42]
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2018-1000654
CPU based DoS on crafted ASN.1 input
[USN-5351-1, USN-5351-2] Paramiko vulnerability [05:11]
1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-24302
Race condition between creating a then setting permissions on the private
key file allows a local attacker to possibly read the private key - fixed
to simply create the file with the restricted permissions in the first
place
[USN-5313-2] OpenJDK 11 regression [05:55]
15 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-21365
CVE-2022-21366
CVE-2022-21360
CVE-2022-21341
CVE-2022-21340
CVE-2022-21305
CVE-2022-21299
CVE-2022-21296
CVE-2022-21294
CVE-2022-21293
CVE-2022-21291
CVE-2022-21283
CVE-2022-21282
CVE-2022-21277
CVE-2022-21248
OpenJDK 11 specific regression in handling of HTTP/2 - upstream -
11.0.14.1
[USN-5350-1] Chromium vulnerability [06:17]
1 CVEs addressed in Bionic (18.04 LTS)
CVE-2022-1096
Thanks to Olivier Tilloy (oSoMoN) from Desktop team
Goings on in Ubuntu Security Community
Camila discusses Ubuntu hardening (part 4 / follow-up) [06:43]
Follow-up to the previous 3 part series on Ubuntu hardening (Episode 154,
Episode 153, Episode 152)
Minor improvements and corrections to the various tips presented over the
past few episodes
Transcript
Hello listener! Welcome back to our Ubuntu hardening journey in the Ubuntu
Security Podcast. Hey! I know what you’re thinking: I can’t count. I said
this would be a three part series…and well…here I am in a fourth
episode talking about this again. You could also be thinking “Hey, you’ve
got the wrong title there…what’s the new topic for this episode?”, and
should this be any other situation, I might’ve said you are right to either
one of these two assumptions because I can be a bit of a scatterbrain
sometimes. But not this time! I am here today once again talking about
Ubuntu hardening because, hey…cyber security is a continuous
effort. Remember that? And you know what also is a continuous effort?
Learning and becoming wiser, and in our journey to do so, it is very likely
that we will make a few mistakes here and there, myself included. Ok, ok,
I’ll stop rambling and saying pretty words to distract you from the real
deal here: I might’ve made some mistakes…Ooops! I apologize. Because yes,
I do know about cyber security, but I am definitely not the master of all
when it comes to it. So, in the past three episodes there were some
sentences here and there that might have been a little bit incorrect, and
some other sentences that might have been forgotten to be said. BUT WORRY
NOT! I am here today to fix this. I got a review on my script for the last
three episodes made by another one of the security team members, and they
gave me a lot of helpful feedback on what I said and on what I suggested to
you all. Since I had already recorded the other episodes and my laziness
spoke a little higher than my willingness to spend the day re-editing audio
files, I decided to instead bring a new episode to you. Coincidentally,
recording a part 4 to a previously established 3 part series really
resonates with the vibe that is the hardening process of an operating
system: we want to always review our work, and fix mistakes whenever
possible. Maintain and evolve, even if we do hit a few bumps on the road
and make some mistakes along the way. We are human after all, and even if
the computer isn’t, all that it does is do what we ask of it, so…yeah!
Enough introductions, let’s move on to the meat and potatoes of this
episode and right some wrongs! Oh…actually…I don’t think it is really
necessary to mention this…but there is always that one person, so: listen
to the other episodes if you haven’t yet. I can’t really fix something that
you don’t even know is broken.
Ok, point number one that was brought to my attention: remember when we
were talking about the swap partition in part 1? Well, it is a valid
solution for all the reasons that I mentioned there, but it is not the only
one. Drumroll please, as I introduce you all, if you don’t already know it,
to the swap file. TADA! The swap file, as the name suggests, is a file in
your system that will serve the same purpose as a swap partition. However,
instead of being configured as a separate partition of your disk, a swap
file is created under the root partition in your system and you simply
nudge the OS to remind it that that specific file should be used as swap
whenever necessary. Neat, right? Specially because resizing swap files is a
lot easier than resizing an entire swap partition. A LOT easier. Using
command ‘fallocate’ or command ‘dd ‘will help you get a swap file ready in
case you wish to use this method of swapping instead of creating an entire
new partition during install, or in case you forgot about it during
install. Use the ‘mkswap’ tool to tell Ubuntu that the new file is a swap
space and enable the swap file with ‘swapon’. To finish it off, and make
changes permanent, add information on the swapfile to ‘fstab’. Remember to
correctly set permissions in this swap file, as, even though it is a swap
entity, it is still a file. Only the root user should be able to write to
that file or read from it, so get your ‘chmod 600’ ready for that. The
conclusion here is: both a swap partition and a swap file will serve the
same purpose, and they are both located on disk, so not much to compare on
that front. However, if you are looking for something more flexible,
stretchy, if you will, consider using the swap file. It will help you out
with your maintainability needs, and with adjusting to changes in the
future, especially if these changes involve increasing the size of the
swap, or decreasing it due to hardware changes applied to your device, or
any other type of related changes. I do stress though, hopefully enough
that you are just being reminded of this here: do this if it suits YOUR
needs. Maybe you already have a swap partition, and it is ok to you for it
to have an immutable size until the end of eternity, and that is great! You
do you. What is important for you to takeaway here is that I am giving you
another option, one that might better suit your needs, or not, but I am not
the one to decide that for you.
Next up, let’s talk about that ‘hidepid=2’ suggestion I made in part 2,
shall we? This suggestion came up when we were talking about fstab, and I
was telling you about ways to protect your /proc directory from the prying
eyes of possibly malicious users. Well, it unfortunately doesn’t work when
you have systemd installed, which is the case for Ubuntu. Whewhe. So yes,
blame me for relaying possibly incorrect information to you. I am deeply
sorry…but please don’t cancel me for it. There are a few bug threads that
mention this error and a lot of proposed solutions given by the community
can be found in the various comments. I will not go into too much detail on
those here because it might be a bit difficult to get the actual solution
through without any visual aid, but I do encourage you to do some research
on this, and maybe apply one of the suggested alternatives should it be
adequate for your system. Sorry once again for giving you a hardening tip
that would cause an error in your system, but hopefully the solutions out
there will allow you to get right what I initially got wrong. I’ll try to
get some links containing some of these solutions added to the podcast
notes in order to help you out, and in order to atone for my mistakes. I’m
sorry, I’m sorry once again. Ok, I’ll stop now.
Point number three: I told you to love your logs and embrace your logs
during part 2 of this series. The computer pours out its innermost secrets
to you and you decide to ignore it? Well…I kind of ignored it a little
bit as well, because I talked so much about ‘syslog’ and all of its log
files that I forgot about another oh so very important member of the
logging squad: ‘journald’. If your Linux system has ‘systemd’, it does have
‘journald’, and therefore, if you are using Ubuntu, you most likely have it
too. Since ‘journald’ stores data in binary format, the usual way of
accessing the data it collects is not recommended here, as our brains have
still not yet evolved to immediately read and process unreadable characters
when looking at a sequence of those characters. There are no plain text log
files here. Instead, if you want to check out all of the logging goodness
that ‘journald’ can provide, and expose all of your device’s secrets, you
have to use the ‘journalctl’ utility. I am pretty sure this name is
familiar to you, as most times when you have a service issue in Ubuntu or a
system issue in general, it recommends you check out the output of
‘journald’ by typing in a shell ‘journalctl -x’. ‘Journald’ is a very
interesting logging tool and it can allow you to troubleshoot your system
very efficiently. It tracks each log to a specific system boot, for
example, and this means that you can check logs considering only data
connected to a specific boot instance when using the ‘-b’ option. So, if
you have a situation where you know that the issue happened the last time
you turned on your computer, instead of checking all of the log, you can
narrow it down and try to find your problem in fewer lines of log data
instead. You can also filter log data based on a time range, based on a
specific service, based on a specific user or based on message priority
level. Which one is better to use between ‘syslog’ and ‘journald’, you ask?
It depends on your needs. Advantages of using ‘journald’ include the fact
that it structures data in such a way that searches can be optimized, plus,
it indexes data, meaning that lookup operations of the log files will
happen in a much faster manner than they would when searching for
information in plain text files. Filtering is also easier with ‘journald’,
as seen by all of the options I mentioned previously that you can use
together with ‘journalctl’. With ‘syslog’ and all its different plain text
log files, it might be a little bit more difficult or troublesome to find
exactly what you are looking for, and even correlate log information
without having a third party software to maybe assist you with this
job. When searching through ‘syslog’ logs we usually end up using ‘grep’,
our handy-dandy text file search tool, but unfortunately, ‘grep’ will not
take into account the context of a situation. So, when searching through
‘syslog’ logs, instead of a simple one line command you would type if using
‘journalctl’, you create a huge multiline beast with a lot of pipes to get
a coherent and valuable result out of the many ‘syslog’ files you wish to
have analyzed. Another advantage of ‘journald’ is that ‘journald’ has
permissions associated to its log files, so every user is able to see their
own log without actually being able to see output that would be exclusive
only to root, for example, said users needing to prove their privileged
identity before accessing this other sensitive data about the
system. Therefore, regular users are able to troubleshoot using ‘journald’
logs, but at the same time, information that should not be exposed to
regular users for one reason or another is protected. With ‘syslog’ it will
all depend on permissions associated to the log text files, and these will
include ALL of the information for one specific log source, so it won’t be
every random user that will have the opportunity to possibly use log data
to solve their issues, unless you allow said random user to actually read
logs in their entirety. Talking a bit about possible disadvantages related
to ‘journald’: ‘journald’ does not include a well-defined remote logging
implementation and, therefore, is not the best option to consider when you
need to build a central logging server, whereas ‘syslog’ allows that to
happen very well, since there is even a same name protocol which is used to
send messages to a main log server running a ‘syslog’ instance. Plus,
‘journald’ considers only information of Linux systems, while ‘syslog’
encopasses more, such as logs generated by firewall devices and
routers. This means that correlation between the logs of the different
devices in your infrastructure might be made more efficient when you indeed
have a centralized ‘syslog’ server to gather all of that information,
especially considering that it is possible to send ‘journald’ data to an
already existing ‘syslog’ implementation, as ‘journald’ retains full
‘syslog’ compatibility. One of the issues we find with this though, is that
most advantages that come with ‘journald’ are lost when such messages are
sent to the centralized ‘syslog’ server, as this server, as the name
implies, will include a ‘syslog’ implementation instead of a ‘journald’
one, this ‘syslog’ implementation recovering, storing and processing
messages as a regular ‘syslog’ instance would…so, no indexing and no
optimized data reading and filtering. The other possible issue is that
‘journald’ needs to send its data to a local ‘syslog’ server, and this
server will then send that data to the remote one. Having two tools doing
the same logging work might not be the most ideal thing for you or your
infrastructure, so do take that into account when setting up your logs and
your whole logging system. For this reason and the other reasons mentioned
we have that ‘journald’ ends up being more “host-based” than
‘syslog’. Therefore, I once again ask the question: which one is better to
use? Maybe it’s ‘journald’ in case you have one host only, maybe it’s
‘syslog’ if you have an entire infrastructure and a centralized log server
with third party software that processes all information it gets, or maybe
it’s even both, since, as we already discussed in previous episodes, an
extra layer of protection is what will help you build up your cyber
security walls of defense more efficiently, especially when you consider
that you already have ‘journald’ installed by default in your system.
Going on to point number four: when installing tools such as Rootkit
Hunter, be aware of possible false positives. It is always useful to have
tools that scan your system for you, and point you towards the direction
issues might be, however, it is interesting to confirm that the issue
database used by such programs is updated and well matched to your system
in order for results to be actually useful. So keep two things in mind:
that tools such as Rootkit Hunter exist and can be very helpful, and that,
even though they can be helpful, they can also not be if they are
out-of-date and just end up flooding you with false positives that will
then lead you on a wild goose chase that generates nothing of value to you
or your system. Also, do be careful about installing programs such as
vulnerability scanners that can be later on used by attackers themselves to
find flaws in your system. If you’ve used it and no longer need it
installed, maybe remove it until it is once again necessary…after all,
even security tools increase the attack surface of your system, and they
themselves might have vulnerabilities related to them that could be
exploited by someone with enough knowledge of it. Finally - and me saying
this might sound unnecessary because it should be obvious, but I do say it
because there is always that someone out there…right? - don’t think that
a scan performed by ONE single scanning tool is enough to guarantee
security of a device, especially when we consider tools that do need to
rely on previously known hashes, or rules, or sets of steps, in order to
identify a possibly malicious entity in a system. That is because attackers
are always trying to circumvent these tools by using digital fake
mustaches, and, sometimes, these disguises are enough, as is a certain
superhero’s glasses. I mean…how can people not know they are the same
person? Unfortunately, this major oversight might happen sometimes with
your security tools as well, so knowing this is key in order to actually
build a truly secure system. By knowing, you also know that said tools
should only be a part of a bigger, LAYERED strategy you use to harden your
system. Agreed?
Time to dive into point number five. I was asked a question: is ‘ping’
still ‘setuid’ root? And the answer is actually “no”. Oh, well! Remember
when we were talking about the dangers of the ‘setuid’ binaries and I used
‘ping’ as an example to show the issues that might arrive when you set that
sneaky permission bit to 1? Well, it turns out that my example was a little
bit outdated, since ‘setuid ping’ was already put in the WANTED list for
“causing too many security issues” and was therefore demoted to
non-‘setuid’ status. So, if you are using Ubuntu 20.04 LTS, for example,
you can run an ’ls -la /usr/bin/ping’ and you will see permissions set to
755 instead of 4755. How is the privileged socket access performed in this
case? Ah…well, that might be a discussion for a future podcast episode,
especially since a little bird told me that the solution for that might
have caused an even bigger issue than the ‘setuid’ bit when changes to
remove it were initially being made. For now, I’ll just leave you to wonder
a little bit more about this, and reinforce that, even if ‘ping’ is no
longer ‘setuid’, the example stands to show the dangers of having this bit
set, be it ‘ping’, be it any other executable in your system that might
allow for malicious tampering. Consider the ‘ping’ example a template of
what COULD happen should you decide to maybe set its ‘setuid’ bit. Don’t
actually do that though, please.
Point number six is as simple as: ’netstat’ has been replaced with ‘ss’. I
mentioned using ’netstat’ to check open ports in your system because that
is what I have been using since forever. Old habits die hard, I guess…and
that, my friends, is definitely something I shouldn’t be saying here,
because old habits will also compromise you, since it is always important
to keep up-to-date with recent software if you plan on being secure. So
yes, forgive me for I have been a hypocrite. Information on ’netstat’ being
deprecated is even in the ‘man’ page for netstat. Oof…hurts to see my own
mistakes. Read your manuals people, their existence is not trivial. But,
you know what? You live and you learn. I know better now, and you do
too. So let’s be better together, friends, and use ‘ss’ instead of the
obsolete ’netstat’ to find open ports in our system that are open for
absolutely no reason! The good thing to come out of this mistake is that we
get to once again remember the importance of updating and maintaining
systems in order to actually keep them secure, and this also includes the
system that is our own minds.
Ok, now that we have tackled the ahem minor errors I made in the last few
episodes, and honorably mentioned applications I forgot about, let’s bring
up a few other hardening suggestions made by the Ubuntu Security Team so
that you can harden your system even more!
Let’s start with the Mozilla TLS configuration generator: this tool which
can be accessed through the “https://ssl-config.mozilla.org/” URL can be
used to generate configuration files for various server programs, Apache
and Nginx included, and it considers three different security levels!
Pretty nifty, and gives you the opportunity to maybe learn more about
application settings you might not have known all that much about in the
first place, and how they can help you when you wish to do hardening for
applications you use.
Let’s Encrypt is in this list as suggestion number two, and it is a tool
that allows you to get certificates and renew them often enough that you
can’t have expired certificates ruin your day. Let’s Encrypt is a CA, or,
expanding on the acronym, a Certificate Authority, which is an entity you
will need if you plan on using TLS to encrypt your web server’s
communications, for example. You can use Let’s Encrypt to create your
certificates and then configure the tool to automatically update these
certificates whenever they are close to expiring. Phew! No need to worry
about unintentionally sending unencrypted data over the wire because of a
missed expired certificate! Give those attackers NO windows of opportunity!
AppArmor is installed in Ubuntu by default, and we already talked about it
in the last episode, but I am here to ensure that you remember that it does
exist, and, even better, you don’t even have to install it in your Ubuntu
system to start using it. Take advantage of its existence and don’t forget
to profile applications running in your system! Profile ’til you can’t no
more and get that metaphorical armor polished and ready to take on
everything and everyone, just because you can.
And last but not least, I can’t NOT reinforce this, as I am in the security
team and this is what we do for you: always install your updates. Always!
It might seem annoying, it might take some of your time, it might even be a
little bit angering…but isn’t making changes for the better what life is
all about? Update and live to see your server survive another day! Update
and sleep peacefully knowing that you are doing the best you can for that
server you care about! Update and be ready! Some updates will require the
restarting of services, so that those actually start using patched versions
of recently changed libraries, and, when we are talking about the kernel,
reboots might be necessary, so include restarting and rebooting in your
update plans as well, or else the patching done by the security team won’t
be effective in your system. If you are having trouble with
this…shameless plug: consider using Ubuntu Livepatch in order to get
those kernel security-critical updates installed into your system without
having to reboot the machine! It’s free for personal use on up to three
computers, and it is easy to set up through your Ubuntu system with your
Ubuntu One account.
And that is it! An extra episode to patch my previous mistakes, and to
deliver to you updates on some previously incomplete information! An
episode that mirrors the work done by the Ubuntu Team on its packages, and
that hopefully brings you as many benefits as those patches do! Keep your
patches up to date, keep your hardening up to date, keep your knowledge up
to date, and I am sure you will be ready to face a lot more than you
expect! Thank you all for listening to this extra episode of the Ubuntu
hardening series on the Ubuntu Security Podcast. Feel free to share your
thoughts on this subject and on this series in any of our social media
channels! I hope to talk to you all once again in the future, but for now,
I bid you farewell and until next time! Bye!
Ubuntu 22.04 Beta Released
https://lists.ubuntu.com/archives/ubuntu-announce/2022-March/000278.html
https://help.ubuntu.com/community/JammyUpgrades
https://discourse.ubuntu.com/t/jammy-jellyfish-release-notes/24668
https://www.omgubuntu.co.uk/2022/03/ubuntu-22-04-beta-is-now-available-download
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
34 min
March 25, 2022Episode 154
Overview
It’s PIE🥧 for everyone this week as Python finally becomes a position
independent executable for Ubuntu 22.04, plus Camila brings you the third
part in her Ubuntu server hardening guide and we cover security updates for
FUSE, Bind, Apache, the Linux kernel and more.
This week in Ubuntu Security Updates
105 unique CVEs addressed
[USN-5326-1] FUSE vulnerability [00:49]
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2018-10906
When using SELinux on Ubuntu, possible to bypass regular restrictions
that would normally prevent non-root users from mounting a FUSE fs with
the allow_other mount option - this option specifies all users can access
files from the FUSE fs whereas normally FUSE enforces on the user which
mounted the file has access
Could trick another user into then accessing files from the FUSE fs
[USN-5334-1] man-db vulnerability [02:22]
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2015-1336
daily cron job could allow a local user to access the man user account
[USN-5321-2] Firefox vulnerabilities [02:57]
7 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-26387
CVE-2022-26385
CVE-2022-26384
CVE-2022-26383
CVE-2022-26382
CVE-2022-26381
CVE-2022-0843
arm64 binaries for Firefox 98.0.1 Episode 153
[USN-5332-1, USN-5332-2] Bind vulnerabilities [03:25]
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-0396
CVE-2021-25220
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2021-25220
Possible cache poisoning attack via forwarded NS records
fd exhaustion if client could trick bind into keeping connection in
CLOSE_WAIT status for an indefinite period, after connection was closed -
DoS
[USN-5333-1, USN-5333-2] Apache HTTP Server vulnerabilities [04:11]
4 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-23943
CVE-2022-22721
CVE-2022-22720
CVE-2022-22719
heap OOB r/w via mod_sed -> crash, RCE
OOB read from crafted request via mod_lua - crash -> DoS
Possible HTTP request smuggling attack since failed to close an inbound
connection when an error was encountered which caused the request body to
be discarded
Possible integer overflow on 32-bit systems if had changed default
LimitXMLRequestBody to > 350MB (is 1MB by default) -> OOB write -> crash,
RCE
[USN-5335-1] ImageMagick vulnerabilities [05:51]
15 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2021-20243
CVE-2021-20241
CVE-2021-20176
CVE-2020-27770
CVE-2020-27766
CVE-2020-27762
CVE-2020-27760
CVE-2020-27750
CVE-2020-25676
CVE-2020-27753
CVE-2020-25674
CVE-2020-25665
CVE-2020-25664
CVE-2017-13144
CVE-2020-19667
OOB read/write/NULL ptr deref, div by 0 etc when processing crafted image
files
[USN-5337-1] Linux kernel vulnerabilities [06:23]
21 CVEs addressed in Focal (20.04 LTS), Impish (21.10)
CVE-2022-0742
CVE-2022-0516
CVE-2022-0435
CVE-2022-0382
CVE-2022-0264
CVE-2021-45480
CVE-2021-45402
CVE-2021-45095
CVE-2021-44733
CVE-2021-43975
CVE-2021-4197
CVE-2021-4135
CVE-2021-39698
CVE-2021-39685
CVE-2021-28715
CVE-2021-28714
CVE-2021-28713
CVE-2021-28712
CVE-2021-28711
CVE-2022-0492
CVE-2022-23222
5.13 (impish, 20.04 HWE)
BPF verifier could possibly allow pointer arithmetic in BPF operations -
OOB read / write -> crash (DoS) or privesc
cgroups v1 release_agent not properly restricted -> privesc
[USN-5338-1] Linux kernel vulnerabilities [07:31]
13 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-0516
CVE-2022-0435
CVE-2021-45480
CVE-2021-45095
CVE-2021-44733
CVE-2021-43976
CVE-2021-4135
CVE-2021-28715
CVE-2021-28714
CVE-2021-28713
CVE-2021-28712
CVE-2021-28711
CVE-2022-0492
5.4 (focal, bionic HWE)
[USN-5339-1] Linux kernel vulnerabilities [07:43]
6 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS)
CVE-2022-0435
CVE-2021-45095
CVE-2021-44733
CVE-2021-43976
CVE-2021-3506
CVE-2022-0492
4.15 (bionic, xenial ESM, trusty ESM - azure)
[USN-5343-1] Linux kernel vulnerabilities [08:00]
45 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2018-5995
CVE-2021-45485
CVE-2021-45469
CVE-2021-45095
CVE-2021-43389
CVE-2021-42008
CVE-2021-40490
CVE-2021-39648
CVE-2021-38208
CVE-2021-38204
CVE-2021-38198
CVE-2021-38160
CVE-2021-3679
CVE-2021-3612
CVE-2021-3573
CVE-2021-3564
CVE-2021-3506
CVE-2021-3483
CVE-2021-34693
CVE-2021-33098
CVE-2021-33034
CVE-2021-33033
CVE-2021-32399
CVE-2021-29650
CVE-2021-28972
CVE-2021-28688
CVE-2021-23134
CVE-2021-20317
CVE-2021-20292
CVE-2020-36385
CVE-2020-36322
CVE-2021-0129
CVE-2020-26558
CVE-2020-26555
CVE-2020-26147
CVE-2020-26139
CVE-2020-25673
CVE-2020-25672
CVE-2020-25671
CVE-2020-25670
CVE-2020-12655
CVE-2019-19449
CVE-2016-2854
CVE-2016-2853
CVE-2022-0492
4.4 (xenial ESM, trusty ESM)
[LSN-0085-1] Linux kernel vulnerability [08:15]
2 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-25636
CVE-2022-0492
Livepatch
KERNEL TYPE
20.04
18.04
16.04
14.04
aws
85.1
85.1
85.1
—
azure
85.1
—
85.1
—
azure-4.15
—
85.1
—
—
gcp
85.1
—
—
—
generic-4.15
—
85.1
85.1
—
generic-4.4
—
—
85.1
85.1
generic-5.4
85.2
85.2
—
—
gke
85.1
—
—
—
gke-4.15
—
85.1
—
—
gke-5.4
—
85.1
—
—
gkeop
85.1
—
—
—
gkeop-5.4
—
85.1
—
—
ibm
85.1
—
—
—
ibm-5.4
—
85.1
—
—
lowlatency-4.15
—
85.1
85.1
—
lowlatency-4.4
—
—
85.1
85.1
lowlatency-5.4
85.2
85.2
—
—
oem
—
85.1
—
—
[USN-5341-1] GNU binutils vulnerabilities [09:04]
3 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2021-45078
CVE-2021-3487
CVE-2017-17122
OOB read, OOB write and memory leak when handling crafted files -
binutils is not generally expected to operate on untrusted data so
upstream and our team do not usually consider vulns in binutils to be
high impact
[USN-5340-1] CKEditor vulnerabilities [09:50]
6 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2021-37695
CVE-2021-33829
CVE-2021-32809
CVE-2021-32808
CVE-2020-9281
CVE-2018-9861
JS rich text editor to be embedded in web pages - often used by django
and other projects
3x XSS, 3xJS RCE
Goings on in Ubuntu Security Community
Camila discusses Ubuntu hardening (part 3) [10:23]
In the third part of this series on hardening a Ubuntu machine against
external attack, Camila looks at steps you can take to secure your
applications once deployed on your hardened Ubuntu system. This includes
steps towards reducing your attack surface, using MAC to provide POLA and
other good security hygiene practices. Listen on to find out more.
Hello listener! Welcome back to our Ubuntu hardening podcast mini-series,
where in three episodes, released across several weeks, we have been
discussing how to build a network service in an Ubuntu operating system,
but not just any Ubuntu operating system, and instead, a HARDENED one. Up
until this point, we went from nothing to digital big bang, which was the
equivalent of our system install; to years of chemical, geological, and
climatic transformations, which were actually a few weeks maybe of setting
up basic security measures after our initial install; to, at last, the
point where we are ready to finally have our server be born, just as life
once did in our beautiful planet Earth. We reach the next stage in our
evolution and prepare ourselves to now finally install our server. Don’t be
a cheater though, and don’t skip any steps: if you haven’t listened to the
other episodes, go do that before you move on here. Earth did not become
what it did in a day, so…you can spare a few minutes to listen to the
other episodes before continuing with this one. Other listeners might have
waited a few weeks, and poor Earth waited billions of years! Lucky you that
hardening your Ubuntu system is slightly easier than creating an entire
planet, and even an entire universe from scratch. Introductions made, lets
jump right in to finally getting our service and all related software up
and running in our already hardened machine. And let’s harden it even more,
shall we?
I will start this off by just saying: no installing of services that don’t
use cryptography. HTTP? Gone! FTP? Next! Telnet? Please no. Don’t even joke
about that. Just don’t, or I might actually just start crying unencrypted
tears of anger. Encryption technology should be here to stay, and if you
are sending sensitive data over the wire, give that data a reason to feel
safe and protected during its digital travel. Add that S to the end of the
network protocol names. Level up your HTTP and make it HTTPS. Configure
your Apache or Nginx server to use TLS. Not SSL. SSL is deprecated. TLS
version 1.2 or above. Another important thing to consider when installing
the entire stack of applications, libraries and frameworks you might need
to run your system: less is more. I actually saw this in a cooking show,
and I agree with this statement. I know we sometimes might get amazed at
the huge amount of possibilities we have whenever installing software. The
human mind has created the most incredible utilities, and we have the power
to simply install all of them with one simple command. But just because you
have a wide variety of ingredients, it doesn’t mean you have to use
them. Some people might like french fries with ice cream. That does not
imply you need a french fry library to get your sundae application to be
delicious. Sometimes a little chocolate sauce drizzle is all you
need. Chef’s kiss! The point here is: install the minimum necessary to run
your application. Don’t increase the attack surface. The more you have
running in your system, the more possibilities of entry an attacker will
have. Keep it short and sweet and avoid getting lost in a sea of files,
users and processes that you don’t know how they really work or what they
really do. And while we are at it…if you do have the chance, try to
install only one or two network services per system/device. Don’t have your
server simultaneously be a web server, a mail server, a file server, a
database server, and an ice cream server, because why not, right? Don’t,
though. This limits the number of services that can be compromised if a
compromise ends up happening. It limits the exposure for a single
device. Plus, when installing the applications necessary to run these
services, remember that a lot of applications like Apache, Nginx, MySQL,
PHP…they all have security settings. They know they are the regular targets
of attacks, so they provide the user with the tools to perform a secure
install or set secure post install configuration values. If it is provided
to you, use it! Harden your application as well, after all, it is this
application that will most likely be the point of entry into your
system. So divide, secure and conquer!
We did it, friends. We have a device providing a service over the
network. One would think that after 6 days of work creating a digital
ecosystem we would be able to rest on the 7th day, as done by some mighty
entities before us, however…people concerned with cyber security don’t
sleep. Or stop. Ever! Cyber security is a continuous effort, so post
application setup measures must be taken as well if you want your server to
keep securely thriving. We have got to ensure the evolution of the species
and keep our metaphorical Earth safe and in tiptop shape in order to
guarantee the best chances of, not only, survival, but growth and
prosperity. Who needs sleep when you can have the joy of knowing that you
set up your device for execution success and longevity in the grueling
environment that is the Internet! Let’s start then by disabling unnecessary
open ports and stopping the execution of unwanted services. You set up your
application using the minimum necessary, which is great. Sometimes,
however, during install, or even during configuration, applications will
open ports and setup services you might not need. Heck, we are talking
about this in the post application install and setup phase of our process,
however, this could also be done in the post installation of the operating
system phase of the process. Checking out which ports are unnecessarily
open, and closing these ports will reduce the attack surface area in your
system, as an attacker has less points of entry to choose from. A house
with one door and one door only provides one single point of entry to an
external entity. Of course this external entity could manufacture a new
entry point using mechanical tools, but I then digress from the real
intention of this analogy, so let’s stick to the basics of the idea here,
shall we? An example of an unnecessary open port might be a database
port. Sure, you have set up a host based firewall as we have already
suggested, and no internet traffic which would have this service as a
destination is allowed through, but still…layers!!! When we talk about
security we talk about having various and various layers that will protect
you in case the previous one has somehow been cracked. So…trust your
firewall without trusting it completely. If you don’t need the database
port open to the entire Internet, only to localhost, then leave it open
just for localhost. If you don’t want to do it for yourself, then do it for
me? Please? It makes me a lot less nervous knowing that a multitude of
unused open ports are being closed and removed from harm’s way. The
Internet can be a brutal place, you know? Use a tool such as ’netstat’,
check your open ports and disable Internet access for those that don’t need
it through the related application’s configuration file or other available
resources. It’ll be quicker than you think, and will provide you with long
term peace of mind. Bonus points for the fact that you will know something
weird might be happening when you see that some port that should not be
accessible through cyberspace is being used to send some data to some shady
IP address in a remote country. Syslog mail incoming!
This same idea applies to unwanted services or unwanted daemons. Check out
what is set to run automatically or in the background of your system, check
your ‘cron’ files, and make sure that these background programs that might
be a risk are not just there executing with the sole purpose of being
exploited. Only the bare minimum necessary! Let’s not be digital gluttons
here, after all, gluttony is one of the seven deadly sins. Deadly for your
poor server which will have that background daemon cleaning files in a
directory that did exist in the system, but doesn’t anymore, and is now
completely useless. Yeah, that server gets exploited by an attacker that
was able to leverage an unpatched zero-day in your Internet facing
application. No, you might not have been able to defend yourself against
the zero-day, but you definitely would’ve been able to avoid a more
sophisticated attack against your device had you not let an unnecessary
vulnerability prone daemon execute in your system just for the fun of
it. The attacker gets in through an issue that is not your fault, but gets
to stay and cause more problems because you were too software hungry to
delete something that was no longer needed by the system. More software,
more vulnerabilities. Another important thing to note here: this is a
continuous effort, remember? Yes, we are talking about post application
installation and setup security measures that be applied to your system in
order for it to be hardened, however, since the application environment
will change together with the application, it is necessary to maintain the
system and reanalyze all that has been setup in order to update the
hardening in case it is necessary. Your hardening needs to evolve together
with your software and your application.
We haven’t yet talked about or dove deep into the elephant in the room
subject that is system files. We surrounded the subject, got close to it
here and there, but we still have not faced it head on, so let’s go for it
now. Files contain the data which we analyze, which we process, which we
use to perform our computing, since even execution of a program begins with
the file containing the code that is to be executed. In Linux, and
consequently in Ubuntu, everything is a file. This essentially means files
will contain everything an attacker needs to compromise a system. They
might want to just read a file and steal its data, they might want to edit
a text configuration file and change the behavior of an application, or
they might want to create a file from scratch which will be a program that,
when run, will do malicious things in the system. The possibilities with
files are endless, and that is why file permissions must be treated with
the utmost care. We must protect the bricks that make up our operating
system. You have your server running. You have everything you need on the
system and you won’t be performing any further install or making any
further changes critical to the service any time in the near future. So why
not spend some time checking your application files and your system files
to make sure they do not have any suspicious or possibly harmful
permissions? What files in the system contain sensitive data that shouldn’t
be accessed by every user? Which files can be read by all, but should have
their editing permissions restricted only to the system administrator?
Which executables are allowed to be executed by a specific group of users
but not by any other user in the system due to dangerous commands being a
part of the compiled code? This analysis must be made and sometimes default
permissions must be questioned, since the idea is that you tailor your
environment to your needs. Use ‘chmod’ and ‘chown’ to get your permissions
right and protect your files.
An additional point of concern: ‘suid’ and ‘sgid’ binaries that might be
available in the system. It is interesting to disable files for which this
permission is unwanted, possibly because it can easily be exploited by an
attacker for privilege escalation or even worse. For those unaware, a
‘setuid’ or ‘setgid’ binary will allow a user to execute the program that
is this binary considering privileges that are not necessarily the ones set
for this user. The execution will happen with the privileges of the file
owner or the file group instead. Think about the ‘ping’ program, for
example. Our old friend, ‘ping’. ‘Ping’ is a ‘setuid’ binary owned by
‘root’. Whenever a user executes the ‘ping’ program, they run it with
‘root’ privileges, and this is generally necessary, since ‘ping’ requires
the opening of a socket and this is not an operation that can be initiated
by any random user in the system. However, since ‘ping’, IN THEORY, is
pretty harmless, letting a user acquire the temporary privilege to open the
socket and get ‘ping’ to run is a solution. Let’s consider, however, a
situation where the ‘ping’ file’s permissions are changed to allow any user
to edit it, so, writing to the file is available to everyone who wishes to
do it. Makes me nervous just thinking about it…A user with little
privileges in the system is then able to edit the file and change its
contents to that of a program that runs ‘ping’, but at the end also opens a
new shell. When this new ‘ping’ is executed with ‘root’ privileges, the new
shell that is opened can be opened with ‘root’ privileges as well. See the
problem here? Of course this is an example, and default permissions for the
‘ping’ executable do not allow any user to write to the file, the only user
allowed to do that being ‘root’. The point here is to show the dangers of
the ‘setuid’ and ‘setgid’ binaries and encourage you to look at your system
and disable these permission bits for files where this is not necessary,
where setting them is not needed. Maybe you don’t need your users to run
‘ping’ at all, so why not let just those with ‘sudo’ privileges involving
network access be allowed to actually run it? Disable the ‘setuid’ bit and
limit usage of ‘ping’ to those who really need it. The same goes to any
other ‘setuid’ binary any fresh software install might have created. Or
even files you have created and set permissions to yourself. ‘Setuid’ and
‘setgid’ binaries are very commonly leveraged by attackers to exploit a
system, so having less of them is a good measure to apply in order to
reduce your attack surface. Also…let’s continue doing continuous work
here, and always check permissions and ‘suid’ or ‘sgid’ for new files that
are welcomed into our system, or old ones that are updated.
What’s next then? We seem to have covered all of our bases, securing every
part of our system. Go us! However, some say that teamwork is the best kind
of work, so let’s increase our hardening by going beyond our lonely manual
configurations and implementations and use some security software to help
us. You are not alone in the digital world. You are not the only one trying
to make your device more secure and trying to protect it against Internet
predators. A lot of people have developed a lot of software to help us
strengthen our defenses and better manage security in our devices. So here
are a few to consider: ‘fail2ban’, which is an intrusion detection and
prevention system that will analyze your log files and block suspicious
activity through your firewall should any suspicious activity be
detected. Other open source software out there like Snort and Suricata can
also be used to achieve similar things to this; also consider installing
malware detecting software with ClamAV or exploit detecting software with
RootkitHunter; 2FA is highly recommended nowadays to anyone that wishes to
use authentication in a secure manner, so why not implement it directly in
your Ubuntu OS? Through Google’s PAM package, for example, it is possible
to set 2FA for users logging into your machine, using ‘sudo’, doing
everything in the system that requires a password! NO, don’t even think
about considering the use of a less strong password because of this, but do
see it as another layer added to the various others we have been building
up here to keep your system secure; another authentication alternative is
considering the usage of a centralized authentication system, where your
users are not authenticated locally, but instead in a remote server
dedicated to this type of service. Of course, do not forget that usually, a
service providing device, such as your own server, will have local
application-only users that do not need to be authenticated with this other
centralized authentication unit in order to run their activities in the
device, so do configure those properly. However, for users that are a part
of your organization layout, it might be interesting to consider
outsourcing your authentication needs to this extra server. Keep in mind,
however, that this increases the attack surface for your infrastructure in
general, since you add to it an entirely new service device, and apply it
only if the pay-off is worth it to you and you entire structure; and last
but not least, do consider using software that enforces Mandatory Access
Control, such as SELinux, and of course, the one and only AppArmor.
Mandatory Access Control, or MAC, for short, is the counterpart to DAC, or
Discretionary Access Control. In DAC we have that access control is
performed in such a way that access is allowed to resources based on the
identity of a user and what the resource owners allow or not for that user
in that resource. Here, all the OS can do is enforce permissions based on
identity limits set by this resource owner. On the other hand, MAC is the
type of access control where a policy administrator, which is usually the
‘root’ user, but can be another administrative user, is the one to
establish access permissions to a resource, no matter the owner of that
resource. The policy administrator is able to make such choices not only
based on the resource but also based on the entity which will access it as
well, this entity possibly being a user, or even a program, and resources
being files, network devices and other programs. The operating system can
then enforce access beyond the one set by the resource owner and
considering more than just the identity of the entity that wishes to access
the resource. In DAC, permissions for a specific resource can be easily
changed by the user that owns it. The Linux file system permissions are an
example of DAC. Changes to these permissions, as simple as they may be, can
result in programs or users being able to interact with resources they
normally shouldn’t, and the ever untrustworthy user is the only one
standing in the way of that. On the other hand, in MAC, with permissions or
sets of permissions being defined by a policy administrator only, a random
user can no longer change the ones associated with a resource just because
they own it. Well, they can, through DAC, but changing overall resource
permissions will no longer be as easy as just running ‘chmod’. That is
because, as an additional layer to the checks performed to the DAC set, MAC
will give more granularity to the access control process, and, based on the
rules set by the policy administrator, define in an owner independent
manner, what users or programs can access in the system based on who they
are, and based on what permissions they have assigned to them regarding
each specific resource. And if some shady entity wants to maybe bypass
that, they will have to go through the dead body of the kernel of the
operating system, which is a much harder beast to face. Even though DAC
might be a more flexible way to set resource permissions, MAC is usually
considered the more secure alternative and it can even be used as a
complimentary measure on top of DAC to add more security to your
system. You can do this, for example, by activating the AppArmor kernel
security model in your Ubuntu OS, and it will allow you to restrict actions
that running processes can take and resources they can access. AppArmor,
therefore, will bind programs, and confine them, reducing the range of
harmful operations a program might be able to execute in your system. Each
program will have a profile associated with it, and these will contain
access rules which, when broken, can have the related attempt simply
reported, or instead blocked. An example would be disallowing access to a
certain directory for the process that is your web server. The web server
should only access web server related directories and files and AppArmor
can be set up to guarantee that. Joining DAC and MAC in your system will
allow you to build up your security layers very efficiently, so do consider
learning more about software that allows this to happen, as it will bring
you closer to the hardened utopia we all look forward to achieving.
We did it. We created an inhabitable and secure ecosystem. Just like Earth
after the many, many, MANY years that came after the big bang. Thankfully
it didn’t take us that long, although it wasn’t a walk in the park getting
all that hardening done. Our job, however, is never complete, as cyber
security is a continuous effort. Have I already mentioned this? I can’t
remember. Anyway, the idea is to keep hardening even after all is set and
done to run your service. How can this be achieved?
Well, for starters, keep your Ubuntu system updated and install patched
package versions when possible. Yes, sometimes updating breaks the system,
but between spending time to maybe adjust to changes, and spending a lot of
nights awake having to choo away an attacker instead, which one would you
rather do? Another thing that needs to be done, always, is maintenance of
users, groups and files in the system. I already mentioned this, but I am
bringing it up again because it is very important. Your server is now a
living entity, working to provide data and utilities to users all across
the Internet. Seasons will change, updates will happen, files will
transform, users will come and go, but you will stay. You will stay and
update user and file permissions according to what is applicable to your
ever changing system for that point in time. Don’t assume that your initial
configuration of users and files will apply forever. What is forever though
is your effort to monitor and manage this system you have brought to
life. Pretty words to live by, and what we should actually be doing with
our planet, you know…taking care of it…but I once again digress. And
just as a last tip…to end this suggestion list in a very random and
abrupt manner: shred your files, don’t just remove them from a
system. Deleting a file simply removes the reference to it in a filesystem,
meaning someone can still dig it up from the disk should they be determined
enough to do it. Get rid of sensitive data the correct way and overwrite in
disk that which will no longer be used in your server.
We finally reach the end my friends, and the key takeaway here is: every
system is unique, and every service will have its own infrastructure and
needs. Do not apply all of the changes suggested here if they don’t bring
any benefits to you. Mom used to tell you to eat your vegetables, but if
you are allergic to one of them, I am sure she wouldn’t encourage you to do
it, especially if you don’t like eating it! What I mean here is: all we
have here are suggestions, some which might be amazing and super useful to
you, some that won’t work. Know your system and you will definitely know
what will work best for you. This might even be my actual last tip, if I
haven’t made this clear enough with all I have said previously: know your
IT infrastructure well, and you will better know how to manage it and how
to defend it. Hardening might prevent a lot from happening, keeping you
safe from various intended attacks, however, creativity has always been the
evolution of man, and creative hackers are plenty out there, so it might be
that your hardening sometimes might fail you. If you know your system well,
though, you might just be the last layer of hardening the system needs to
kick out that hacker that was able to worm their way into the network. Keep
your planet orbiting around the sun, keep your ecosystem alive and well,
and do it by knowing how it works and by taking care of it when what used
to work might not anymore.
That is all for today’s listeners! I hope you enjoyed all of the hardening
suggestions we had for you in this and in the two previous episodes, and I
hope you get to use them in your own systems to make them more secure! As
always, do feel free to share your thoughts in our social media channels,
and for now, I bid you all farewell and until next time! Bye!
Python3.10 has PIE enabled for Ubuntu 22.04 LTS (🥧) [38:16]
Episode 151
Thanks to Foundations team, in particular Matthias Klose (doko)
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1452115
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
41 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