Ubuntu Security Podcast

By Ubuntu Security TeamTechnology

Ubuntu Security Podcast episodes

March 18, 2022Episode 153
Overview
This week we bring you part 2 of Camila’s guide on Ubuntu server hardening,
plus we cover vulnerabilities and updates in Expat, Firefox, OpenSSL,
LibreOffice and more.
This week in Ubuntu Security Updates
22 unique CVEs addressed
[USN-5320-1] Expat vulnerabilities and regression [00:45]
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-25315
CVE-2022-25314
CVE-2022-25313
CVE-2022-25236
Includes a fix for a regression from the previous Expat update in
USN-5288-1 (Episode 150) (CVE-2022-25236) - plus fixes for 3 additional
CVEs
stack overrun through a deeply nested DTD
2 different integer overflows on crafted contents as well
∴ buffer overflow → DoS / RCE
[USN-5321-1] Firefox vulnerabilities [01:45]
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 - usual web issues plus possible signature verification bypass when
installing addons / extensions - TOCTOU issue allowing a local user to
trick another user into installing an addon with an invalid signature -
prompts user after verifying signature - so whilst the user is
acknowledging / accepting the prompt could swap out the extension on disk
with a different one
[USN-5323-1] NBD vulnerabilities [02:59]
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-26496
CVE-2022-26495
Stack buffer overflow in nbd-server via a crafted message with a large
name value - crash / RCE?
[USN-5324-1] libxml2 vulnerability [03:33]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-23308
UAF depending on semantics of application using libxml2 - xmlGetID()
returns a pointer to just-freed memory - so if application has not done
other memory modification etc then likely is fine - although is UB and
other applications may not be so mundane so still worth patching
[USN-5325-1] Zsh vulnerabilities [04:28]
2 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2021-45444
CVE-2019-20044
Possible to regain privileges even after zsh has dropped privileges (via
the --no-privileged option) by loading a crafted module that then calls
setuid()
Possible code execution if can control the output of a command used
inside the prompt - since would recursively evaluate format directives
from the output as well as the original prompt specification
[USN-5327-1] rsh vulnerability [05:31]
1 CVEs addressed in Bionic (18.04 LTS)
CVE-2019-7282
Possible for a malicious server to bypass intended access restrictions in
a client through a crafted filename - can then get the client to modify
permissions of a target directory on the client
Why are you still using rsh in 2022? Please switch to ssh
[USN-5328-1, USN-5328-2] OpenSSL vulnerability [06:20]
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-0778
taviso - possible infinite loop when parsing crafted cerificates - can
allow a malicious client/server to DoS the other side
[USN-5330-1] LibreOffice vulnerability [06:56]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2021-25636
Crafted document could cause Libreoffice to be confused and to present UI
to the user indicating a document was correctly signed and had not been
altered when in fact this was not the case - essentially 2 related fields
can exist in the document and it would use the wrong one to show
signature state
[USN-5329-1] tar vulnerability [07:42]
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2021-20193
Crafted tar file could cause tar to consume an unbounded amount of memory
-> crash -> DoS
[USN-5331-1] tcpdump vulnerabilities [08:12]
2 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2020-8037
CVE-2018-16301
Buffer overflow in command-line argument parser - local attacker who can
create a 4GB file and cause tcpdump to use this via the -F argument could
cause a possible crash / RCE
Large memory allocation in PPP decapsulator -> crash -> DoS
Goings on in Ubuntu Security Community
Camila discusses Ubuntu hardening (part 2) [08:58]
In the second part of this series on hardening a Ubuntu machine against
external attack, Camila looks at steps you can take post-install to
secure your machine. See below for a full transcript.
Transcript
Hello listener! I have returned with the second part of our Ubuntu
hardening podcast episode. You asked for it, and you’ve been waiting for
more, and I am here to oblige. We were last seen concluding our Ubuntu
install, bringing into fruition our digital big bang, which would then
allow us to start setting up our galaxy, preparing our Earth-server
environment to receive life in the form of code. Today, we dive into the
hardening measures we can apply to our Ubuntu system right after a fresh
install, but right before a server application setup. However, stop here
and go listen to the last episode if you haven’t yet, or else you might be
a little bit lost among the metaphorical stars. I’ll pause here so you can
pause as well and go check that out. Back already? I will trust you, and
believe that you now know how to harden your Ubuntu system during install,
so let’s get moving and talk about what’s next!
Usually when you install an operating system you define the super user’s
password during install…a ahem strong password. Right? Why am I talking
about this in the post install section then? Because Ubuntu does not
encourage usage of the ‘root’ user. If you remember correctly, or if you
don’t, but you decide to do an install right now, you will remember/notice
that during install you create a new user for the Ubuntu system that is not
‘root’. As previously defined, this user will have a strong password -
RIGHT? - and by default, this user will also have full ‘sudo’ capabilities,
and the idea is to use this user account instead of the root account to
perform all necessary operations in the system. ‘Root’ will exist in the
system but it has no password set, meaning that ‘root’ login is also
disabled by default. This is actually a good thing, considering that you
shouldn’t be using the ‘root’ user to perform basic activities in your
system. ‘Root’ is just too powerful and your Ubuntu system knows that. That
is why it creates a new user that has as much and enough power in the
system, but that can be controlled through the appropriate configuration of
‘sudo’. To run a privileged command through use of ‘sudo’, a user will need
to know the ‘sudo’ user’s password, so that is an extra layer of protection
added to privileged commands in the system, as well as an extra layer of
protection that prevents you from destroying everything after you decide to
drink and type. Additionally, ‘sudo’ calls result in the inclusion of
information regarding such a call into a log file, which can be used for
auditing and for threat analysis in your system through usage of other
installed tools. ‘Sudo’, if configured correctly, will allow you to have
more control over a user’s privileges in your system. By editing the
/etc/sudoers file , you can define which groups in the system have which
‘sudo’ privileges, meaning, which users are allowed to run specific
commands with the privileges of another user, which is usually ‘root’. As a
result, you don’t have to worry about coming across a situation where
someone logs in directly as ‘root’ and starts wreaking havoc in your
system. You have created the appropriate users and groups, and have
attributed the appropriate privileges to each when editing the ‘sudoers’
file. All users have strong passwords, and whenever they need to execute
privileged commands, they have to enter this password, which makes it
harder for an attacker that happens to get a shell to type away in their
keyboards and, with no obstacles to hinder them, read the /etc/shadow file,
for example. Granted, if attackers have a password for a user that has all
‘sudo’ privileges set, this is the equivalent of being ‘root’ on a
system. But you’re better than that. You configured things in order to
avoid all power to be held by one single user and ‘sudo’ allowed you to do
that. ‘Root’ cannot be restricted in any way, while ‘sudo’ users can, and
that is why using ‘sudo’, even if you can have pseudo-root users through
it, is a better call. And yes, I know it’s not pronounced p-seudo…but if
I pronounced it correctly, as simply pseudo-root users…it would have been
kind of confusing. So sorry about the mispronunciation, but I had to get
that silent P across. Maybe it’s intentional though, since a ‘sudo’ user is
a pseudo-root user and a pseudo-root user or a pseudo-sudo user is the end
goal for an attacker hacking into a system. Guess how many times it took me
to record that? Anyway, getting back on topic here…just remember to
properly configure your ‘sudoers’ file. More than just defining what a user
can and cannot run with ‘sudo’, you can also use ‘sudo’ itself to configure
a secure path for users when they run commands through ‘sudo’. The
‘secure_path’ value can be set in the ‘sudo’ configuration file, and then,
whenever a user runs a ‘sudo’ command, only values set in this parameter
will be considered as being part of a user’s regular ‘PATH’ environment
variable. In this way, you are able to delimit an even more specific
working area for a user that is given ‘sudo’ privileges. Be careful though,
and always edit the /etc/sudoers file with ‘visudo’, in order to avoid
getting locked out from your own system due to syntax errors when editing
this file. Do be bold, however, and go beyond the regular ‘sudo’ usage,
where you create a new user that has all ‘sudo’ privileges, and instead
correctly configure ‘sudo’ for your users, groups and system! It might seem
like something simple, but it could make a huge difference in the long run.
So, in our Ubuntu OS here, step number one post installation to keep our
system safe is to create new users and assign them to appropriate groups,
which will have super user privileges and permissions set according to the
minimum necessary they need to run their tasks in the system. Remember:
when it comes to security, if it’s not necessary, then don’t include
it. Plus, as a final bonus to not having a root user configured, not having
a root password makes brute forcing the root account impossible. Well,
that’s enough of using the word ‘sudo’ for one podcast episode, am I right?
Let’s jump into our next hardening measure and not use the word ‘sudo’
anymore. This was the last time! I promise. Sudo! Ok, ok, it’s out of my
system now! Moving on!
So I hear you have your users properly set up in your system. You now want
to login to this system through the network, using one of the good old
remote shell programs. It is very likely this will be configured by you, so
let’s talk about how we should set this up in a secure manner. For
starters, let’s not ever, ever, EVER - pleaaaase…- use unencrypted remote
shells such as the ones provided by applications/protocols such as
Telnet. I mean…why? Just…why? Forget about Telnet, it has broken our
hearts far too much that we no longer can trust it. We know better than to
let data be sent through the network in clear text, right everyone? Ok,
that being said, SSH is our best and likely most used candidate here. There
is a package for it in the Ubuntu main component, meaning: it is receiving
support from the Canonical team, including the security team, which will
patch it whenever dangerous security vulnerabilities in the software show
up. Bonus points! Just installing SSH and using it will not be enough if we
are truly looking for a hardened system, so, after install, there are a few
configurations we must make, through the SSH configuration file, to
guarantee a more secure environment. Starting off with locking SSH access
for the ‘root’ user. If you didn’t enable ‘root’ user password in your
system, then this is already applied by default in your Ubuntu OS, however,
it is always nice to have a backup plan and be 200% sure that external
users will not be able to remotely access your machine with the ‘root’
user. There could always be a blessed individual lurking around the corner
waiting to set ‘root’ password because “Sudo ‘wasn’t working’ when I needed
it to, so I just enabled root”. Yeesh. In the SSH server configuration file
there is a variable ‘PermitRootLogin’ which can be set to ’no’, and then
you avoid the risk of having an attacker directly connect to your system
through the Internet with the most powerful user there is. Brute force
attacks targeting this user will also always fail, but you shouldn’t worry
about that if you set strong passwords, right? We also want to configure
our system to use SSH2 instead of SSH1, which is the protocol version which
is considered best from a security point of view. The SSH configuration
file can also be used to create lists for users with allowed access and
users with denied access. It’s always easier to set up the allow list,
because it’s easier to define what we want. Setting up a deny list by
itself could be dangerous, as new possibilities of what is considered
invalid may arise every second. That being said though, being safe and
setting up both is always good. You should define who is allowed to access
the system remotely if you plan on implementing a secure
server. Organization and maintenance is also part of the security process,
so defining such things will lead to a more secure environment. The same
can be done to IP addresses. It is possible to define in the SSH
configuration file which IP addresses are allowed to access a device
remotely. Other settings such as session timeout, the number of concurrent
SSH connections, and the allowed number of authentication attempts, can all
be set in the SSH configuration file as well. However, I will not dive into
details for those cases since more pressing matters must be discussed here:
disallow access through password authentication for your SSH server. Use
private keys instead. The private-public key system is used and has its use
suggested because it works, and it is an efficient way to identify and
authenticate a user trying to connect. However, do not treat this as a
panacea that will solve all of your problems, since, yes, using private
keys to connect through SSH is the better option, but it will not be if
implemented carelessly. It is well known that you can use private keys as a
login mechanism to avoid having to type passwords. Don’t adopt SSH private
key login if that is your only reason for it. Set a private key login for a
more secure authentication process, and not because you might be too lazy
to type in your long and non-obvious password. Setup a private key with a
passphrase, because then there is an additional security layer enveloping
the authentication process that SSH will be performing. Generate private
keys securely, going for at least 2048 bit keys, and store them securely as
well. No use implementing this kind of authentication if you are going to
leave the private key file accessible to everyone, with ‘777’ permissions
in your filesystem. Another important thing to note: correctly configure
the ‘authorized_keys’ file in your server, such that it isn’t writable by
any user accessing the system. The same goes for the ssh configuration
file. Authorized keys should be defined by the system administrator and SSH
configurations should only be changed by the system administrator, so
adjust your permissions in files that record this information accordingly.
Wow. That was a lot, and we aren’t even getting started! Oh man! This is
exciting, and it goes to show that hardening a system is hard work. Pun
completely intended. It also goes to show that it requires
organization. This might be off-putting to most, but can we really give
ourselves the luxury of not caring about such configurations considering
that attackers nowadays are getting smarter and more resourceful? With all
the technology out there which allows us to automate processes, we should
be measuring up to sophisticated attackers, and doing the bare minimum
shouldn’t even be a consideration, but instead a certainty. That’s why we
are going beyond here and we are implementing kernel hardening measures as
well.
The ‘sysctl’ command, present in the Ubuntu system, can be used to modify
and set kernel parameters without having to recompile the kernel and reboot
the machine. Such a useful tool, so why not take advantage of the ease
brought by it and harden your system kernel as well? With ‘sysctl’ it is
possible to do things such as tell a device to ignore PING requests, which
can be used by an attacker during a reconnaissance operation. Sure, this is
not the most secure and groundbreaking measure of all time, however, there
are other things that can be set through ‘sysctl’, this was just an
introductory example, you impatient you! The reading of data in kernel logs
can be restricted to a certain set of users in order to avoid sensitive
information leaks that can be used against the kernel itself during
attacks, when you configure ‘sysctl’ parameters to do so. So, there you go,
another example. It is also possible to increase entropy bits used in ASLR,
which increases its effectiveness. IP packet forwarding can be disabled for
devices that are not routers; reverse path filtering can be set in order to
make the system drop packets that wouldn’t be sent out through the
interface they came in, common when we have spoofing attacks; Exec-Shield
protection and SYN flood protection, which can help prevent worm attacks
and DoS attacks, can also be set through ‘sysctl’ parameters, as well as
logging of martian packets, packets that specify a source or destination
address that is reserved for special use by IANA and cannot be delivered by
a device. Therefore, directly through kernel parameter settings you have a
variety of options, that go beyond the ones mentioned here, of course, and
that will allow you to harden your system as soon as after you finish your
install.
So, we’ve talked about the users, we’ve talked about SSH, we’ve talked
about the kernel, and we have yet to pronounce that word that is a cyber
security symbol, the icon, used in every presentation whenever we wish to
talk about secure systems or, by adding a huge X on top of it, breached
networks. The brick wall with the little flame in front of it. The one, the
only, the legendary and beloved firewall. No, firewalls are not the
solution to all security problems, but if it became such an important
symbol, one that carries the flag for cyber security measures most of the
time, it must be useful for something, right? Well, let me be the bearer of
good news and tell you that it is! Firewalls will help you filter your
network traffic, letting in only that which you allow and letting
out…only that which you allow. Amazing! If you have a server and you know
what ports this server will be using, which specific devices it will be
connecting to and which data it can retrieve from the Internet and from
whom, then, you can set up your firewall very efficiently. In Ubuntu, you
can use ‘ufw’, the Uncomplicated Firewall, to help you set up an efficient
host based firewall with ‘iptables’. “Why would I need a host based
firewall if I have a firewall in my network, though?”, you might ask. Well,
for starters, having a backup firewall to protect your host directly is one
more protection layer you can add to your device, so why NOT configure it?
Second of all, think about a host based firewall as serving the specific
needs of your host. You can set detailed rules according to the way the
device in question specifically works, whereas on a network based firewall,
rules might need to be a little more open and inclusive to all devices that
are a part of the network. Plus, you get to set rules that limit traffic
inside the perimeter that the network firewall limits, giving you an
increased radius of protection for the specific device we are considering
here. Another advantage, if the various mentioned here are not enough: if
your server is running on a virtual machine, then when this machine is
migrated, that firewall goes with it! Portability for the win! If you are
not convinced yet, I don’t know what to say other than: have you seen the
amazing firewall logo? Putting that cute little representation of cyber
security in the host diagrams in your service organization files will
definitely bring you joy, guaranteed.
Next in configuring our still waiting to become a full-fledged server
system is ‘fstab’. The ‘fstab’ file is a system configuration file in
Ubuntu which is used to define how disk partitions and other block devices
will be mounted into the system, meaning, defining where in the Linux
directory tree will these devices be accessible from when you are using the
operating system. Therefore, everytime you boot your computer, the device
which contains the data that you expect to use needs to be mounted into the
filesystem. ‘Fstab’ does that for you during the boot process, and what is
even better: it allows you to set options for each partition that you will
mount, options that change how the system views and treats data in each of
these partitions. Remember eons ago when we were talking about disk
partitioning and I said there was more to it than just isolating /tmp from
everything? Well, the time has finally come to talk about it. So, even
though it’s not Thursday let’s go for the throwback and keep the /tmp
example alive shall we? If during install you separated your partitions and
put /tmp in its own separate area, you can use ‘fstab’ when mounting the
partition that will be represented by the /tmp directory and set it as a
’noexec’ partition. This is an option that tells the system that no
binaries in this partition are allowed to be executed. You couldn’t have
done this if your entire system was structured to be under one single
partition, or else the entire partition would be non-executable, and then
you could not have a server running on that device. You could also go one
step further and make the partition read-only, although for /tmp that might
not be the best choice given the reason for its existence. Applying this to
another situation though, if you have a network shared directory with its
own partition, for example, it is possible to make this partition
read-only, and avoid consequences that might arise from having users over
the internet being able to write to it. Another suggestion: setting up the
/proc directory with the ‘hidepid=2, gid=proc’ mount options as well as the
’nosuid’, ’noexec’ and ’nodev’ options. The /proc directory is a
pseudo-filesystem in Linux operating systems that will contain information
on running processes of the device. It is accessible to all users, meaning
information on processes running in the system can be accessed by all
users. We don’t necessarily want all that juicy data about our processes to
be available out there for anyone to see, so setting the ‘hidepid’ and
‘gid’ parameters to the previously mentioned values will make it that users
will only be able to get information on their own processes and not on all
processes running in the server, unless they are part of the ‘proc’
group. The ’noexec’, ’nosuid’ and ’nodev’ options will make this part of
the filesystem non-executable, block the operation of ‘suid’ and ‘sgid’
bits set in file permissions and ignore device files, respectively, in this
file system. So…more hardening for the partition. A simple one line
change in the /etc/fstab file that can make a very big difference when
considering the protection of your server. Though, once again, I stress
that all of these are possibilities and, considering our main example here,
if you do have software that requires execution /tmp, which is a
possibility when we consider that there are packages that execute files
from /tmp during install, please do not follow the suggestions here
directly, but instead adapt them to your environment and your
needs. Listener discretion is therefore advised.
Our last post install tip comes in the shape of a file…a file filled with
lines and more lines of information about your system. Use your logs! Take
care of your logs! Embrace your logs. Ignorance might be bliss in a lot of
situations, but when it comes to a computing device, going that extra mile
to understand it might be what saves you from the future robotic takeover a
lot of people are expecting to happen. Why? Because if you know the logs,
you know the system, what is happening, where are the issues! And then when
the robots conquer, you will be the one that knows how it feels, it’s
innermost secrets. The connection you build with that single computer might
save the world from AI takeover. Victory through empathy. Ok, seriously
though, I continue dramatic as ever, but do not let my exaggeration stir
you away from the most important takeaway here. Most of the logging
information in an Ubuntu system will be found under the /var/log directory,
with logging being performed primarily by ‘syslog’. The ‘syslog’ daemon
will generate all kinds of log files, from authorization logs, to kernel
logs to application logs. Apache, for example, has a log file entry under
/var/log, considering you have it installed in your system. You can
configure your device to use the syslog daemon to send log data to a syslog
server, which will centralize log data that can then be processed by
another application in a faster and more automated manner. Do remember to
transfer your logs through the network in a secure, preferably encrypted
fashion though, or else you are just leaving sensitive data about your
server and everything in it out there for the taking. That being said,
here, your configuration file of choice will be /etc/syslog.conf. In this
file, you will tell the ‘syslog’ daemon what it should do with all that
data gold it’s collecting from your system. You can set what is the minimum
severity level for messages that will be logged, as well as set what will
be done to these log messages once they are captured. These can be piped
into a program, for example, which can then process the message further and
take some kind of action based on the outcome, like sending the message via
e-mail to a desired mailbox, or, as previously mentioned, they can be sent
directly to a centralized server that will perform further analysis of the
information through another third party software. With the data and the
means to send it to a place where it can be properly processed, you have
all that is necessary to appropriately and securely understand what is
happening to your system. You can then follow up on issues quickly enough
whenever you have one that is a threat to your server’s security. Reaction
measures are also a part of the hardening process, since we can have
situations where prevention is just not enough.
Billions of theoretical years have passed so far for our ever expanding and
evolving digital galaxy…and I am sure it actually feels like that after all
the talking I have done, but please bear with me for a little while
longer. Earth is finally ready to have its first living creature be born!
It is finally time to install the software needed to transform this, up
until this point, regular device, into a mighty Internet connected
server. It is time to get our applications running, our ports open, and our
data flowing. Let’s do this securely, however, shall we? Wait. Not yet
though. Earth was able to wait a billion years, so you might just be able
to wait another week! I know. I am being mean. Anyway, not much I can do
about it now! Don’t forget to share your thoughts with us on our social
media platforms and I will see you all next week for the grand finale! Bye!
Hiring
Ubuntu Security Engineer [36:12]
https://canonical.com/careers/2925180/security-engineer-ubuntu-remote
Home based, worldwide
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
38 min
March 11, 2022Episode 152
Overview
It’s a big week for kernel security vulnerabilities - we cover Dirty Pipe
and fixes for the latest microarchitectural side channel issues, plus we
bring you the first in a 3 part series on hardening your Ubuntu systems
against malicious attackers.
This week in Ubuntu Security Updates
34 unique CVEs addressed
[USN-5312-1] HAProxy vulnerability [00:46]
1 CVEs addressed in Focal (20.04 LTS), Impish (21.10)
CVE-2022-0711
CPU based DoS via the Set-Cookie2 header - obsolete HTTP response header
used to send cookies from the server to the user - possible infinite loop
when parsing responses which contained this header
[USN-5300-2, USN-5300-3] PHP vulnerabilities [01:24]
6 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2021-21707
CVE-2017-9119
CVE-2017-9120
CVE-2017-9118
CVE-2017-8923
CVE-2015-9253
Episode 150
[USN-5311-1] containerd vulnerability [01:41]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-23648
Able to access read-only copies of files from the host via specially
crafted container image
[USN-5314-1] Firefox vulnerabilities [02:11]
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-26486
CVE-2022-26485
2 critical impact (as defined by Mozilla) vulns - both UAFs
Mozilla reported seeing reports of both being exploited in the wild
[USN-5313-1] OpenJDK vulnerabilities [02:36]
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
Thanks to Matthias Klose from the Ubuntu Foundations team for preparing
these updates - latest upstream point releases
17.0.2 + 11.0.14
[USN-5310-2] GNU C Library vulnerabilities [02:56]
3 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-23219
CVE-2022-23218
CVE-2021-3999
Episode 151 - this update is a subset of those
[USN-5316-1] Redis vulnerability [03:09]
1 CVEs addressed in Focal (20.04 LTS), Impish (21.10)
CVE-2022-0543
Redis contains a scripting interface using Lua and implements a sandbox
for this to try and avoid scripts running arbitrary Lua code
Upstream has a vendored copy of lua but in Ubuntu + Debian the redis
package links against the system installed liblua
this is a good thing as it means that when say a vuln appears in Lua
itself we only have to patch Lua to fix other applications like redis
whereas otherwise we would also have to patch the embedded/vendored
copy of lua in redis and release a redis update for every Lua
vulnerability as well
As such we also want it to use the system lua libs of cjson and bitop
Included a small custom piece of code to have it load those instead of
the ones that would usually be shipped in redis itself
Discovered that this shim code failed to set the package variable and as
such left this global variable uninitialised - an attacker with the
ability to execute a Lua script could then cause Lua to load the full
system liblua unsandboxed and hence then use this to execute other
arbitrary commands on the host
Note in general it doesn’t look like upstream Redis consider the existing
sandbox to be a security boundary so recommend to only give trusted users
the permission to EVAL Lua in redis
[USN-5317-1] Linux kernel vulnerabilities [05:34]
5 CVEs addressed in Focal (20.04 LTS), Impish (21.10)
CVE-2022-0002
CVE-2022-0001
CVE-2022-0847
CVE-2022-23960
CVE-2022-25636
Thanks to Thadeu Cascardo from the kernel team for coordinating all the
work on these fixes
https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/DirtyPipe
https://dirtypipe.cm4all.com/
Similar to “Dirty Cow” but easier to exploit - one of the more high
profile vulnerabilities in recent times - due to mishandling of the
page cache within the Linux kernel, a malicious process could abuse the
pipe and splice system calls to cause the kernel to overwrite contents
of arbitrary files even when a user had no write permission to the
particular file (even on immutable and RO-filesystems)
Very simple error due to the failure to initialize the flags element
within a pipe buffer when handling pipe data within the kernel - fix is
2 lines of code to initialise this to 0
Flaw exists back to 4.9 but this is thought only to be exploitable
since the 5.8 kernel which refactored this code
As such for now have patched for the 5.13 kernels in 21.10 + 20.04 LTS
but will also patch in the future during regular development cycle for
the older kernels like 5.4 in 20.04 LTS as well as an additional
hardening measure
https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/BHI
Latest set of hardware microarchitectural issues - in the same vein as
the original Spectre flaws from Jan 2018 (4 years ago!)
Set of vulnerabilities affecting both Intel and ARM processors which
can allow unprivileged user to leak (read) memory from kernel / other
applications
Requires the ability to execute a “gadget” in the kernel to do the
speculative execution - and the only way known to get one of these is
to inject it as BPF code
As a result this update also disabled unprivileged eBPF loading as well
to close off this attack vector
[USN-5318-1] Linux kernel vulnerabilities
4 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-0002
CVE-2022-0001
CVE-2022-23960
CVE-2022-25636
[USN-5319-1] Linux kernel vulnerabilities
2 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS)
CVE-2022-0002
CVE-2022-0001
Goings on in Ubuntu Security Community
Camila discusses Ubuntu hardening (part 1) [10:20]
In response to a topic on discourse.ubuntu.com re Basic security advice
for running your own server - Camila has prepared a 3 part series on
steps you can take to harden your Ubuntu machines against attack - part 1
focuses on hardening at install time, part 2 is post install steps and
part 3 looks at additional measures you can take once the machine is
deployed - today we bring you the first part in this series
Transcript
Hello listener! Welcome to another episode of the Ubuntu Security Podcast
where I, Camila, will be talking to you all more about one subject or
another involving the Ubuntu Linux distribution and cyber security in
general. Today’s episode is a response to a request. A request from someone
that wants to learn more about how it is possible to create an Ubuntu
system, which will be running some type of service, in a secure
manner. After all, we do live in times where threats that were only
physical have migrated to the digital world as well, so just having a
server set up with all ports open and no access control set is no longer an
option for those that wish to use the almighty Internet to provide some
type of service. Heck! The concern should exist even if you don’t wish to
have an Internet facing server, but simply if you own a computer…or a
smartphone…or a smart TV…or a car. Or anything really. We are all
connected by our WiFis, whether we want it or not, so taking care of our
own digital perimeter has become something essential, and something that we
all should be applying to not get spammed nor scammed in the days of
today. So, since I do love me some lists, let’s talk about, in a
chronological list format, what measures you can apply to your Ubuntu OS
and what tools can you use in this same OS to make it safer, hardened
against the cold and harsh wave of 0’s and 1’s that might be traveling out
there through fiber optics cables just waiting to hack into your system.
Let’s start with the basics and talk about what can be done with the tools
that you already have when you have an Ubuntu Linux coming fresh out of the
bootable USB stick you used to format your computer. Actually, if we are
indeed doing this, let’s do it for real: we will go back even further, and
talk about the basics that can be done not only after a fresh install, but
also, while you are installing your system. Let’s get prepared for the
Ubuntu big bang and talk about what needs to happen before our binary
universe can start to exist and securely function inside our CPUs and hard
drives.
During an Ubuntu install you will make a few choices, such as whether or
not you want to encrypt data in your disk. If you are not the one
installing your own system, and you have an already running basic Ubuntu
system in a cloud service platform, for example, this might not be
something possible for you. However, if you do have the chance to apply
this, it is a hardening measure that can be used to protect all data being
saved in your hard drive. Of course, we need to consider that not all
situations might fit well with this, as, for example, a server that forces
the system to reboot frequently would require a password every time at
system startup, something that one might not want to do, or be available to
do, every single time, specially considering a situation where a completely
automated system is the main goal to be achieved here. It is also important
to consider that encrypting your hard drive might affect general file I/O
performance, since data being read from the disk needs to be decrypted
everytime, before being presented to the user or to the system for further
processing, and data that will be written to the system needs to be
encrypted before it is sent permanently to the hard drive. However, if none
of those cases concerns you at all, the question here might be: why NOT
encrypt your hard drive? If your hardware allows it, making the process
fast, it might even be worth it despite the delay you can have due to the
necessary encryption and decryption operations being performed. Either way,
your data can be protected from those that might want to access it without
authorization. Do not kid yourself by thinking that hackers will always
stay behind a screen, as there are the very bold who might just think that
by stealing your hard drive they will get what they need. Without a
password, though, hackers can connect the disk to whatever computer they
like, but the data will remain encoded and unreadable. Remember though,
full disk encryption will NOT protect data in transit, also known as data
you sent through the wires or through the air, via the World Wide Web, to
other devices around the world. Disk encryption, as the name suggests, is
local to the disk which is associated with your own device. Oh, also do be
aware that the password that is used to encrypt the disk cannot be lost or
else, you might be your own worst enemy and lose your data which becomes
nearly impossible to crack cipher text.
Still talking about disk configurations during the installation process, do
consider creating a swap partition when setting up your system. The swap
partition is essentially used by the Ubuntu System as if it were
RAM. Therefore, if your RAM is filled up completely, the swap partition,
which is actually a part of the hard drive, will be used rather than the
RAM memory space to perform operations. necessary A swap partition can also
be used to make more RAM space available during a certain point in
processing time, said space being provided for data that is more relevant
or is being used more frequently. Data that is being less used, less
referenced, can therefore be moved to swap space instead of being left in
the ever busy, constantly used RAM. The swap will act as an extension of
your RAM, but do note, it is not as efficient as RAM, since it is actually
your hard drive pretending to be something that it is not: a volatile
memory device. Setting up a swap partition, however, can be very useful to
increase performance in your server. As previously mentioned, swap space
can be used to store data that is not all that frequently accessed, opening
up space in RAM for more regularly accessed information. Since data in the
swap is not being used constantly, the delay you would have when performing
I/O operations on it becomes less of an issue, and you essentially gain
more RAM space to process whatever your server needs to process. And, you
know, even if people do forget it sometimes, remembering about it only when
they suffer a massive DoS attack, availability is one of the 3 pillars of
cyber security, so preparing for that in order to guarantee a system with
better performance is valuable. Another big advantage of having swap lies
in the fact that you as a system administrator might have more time to
react to possible memory issues when your server is facing them. When you
run out of memory and you don’t have swap, you risk having your system
suddenly crash and not only losing all data that was in RAM, but having
your service be out of reach for whoever knows how long. You can also have
OOM killer go and kill your most important process because you
are…running out of memory…and it doesn’t even have the courtesy of asking
you if you are ok with it. Just rude! If you set up your swap space to at
least the size of your largest process though and you monitor your system,
you are able to detect possible issues by analyzing swap space usage, and
then you can most likely avoid many undesired service and system
crashes. However, do not forget: setting swap can boost your system
performance, as it can hinder it if you don’t implement things
correctly. Your main volatile memory source should be your RAM, and the
swap partition will not be a substitute for it. Therefore, if you have
little RAM and over encumber your system, you won’t make it any faster by
using swap, as the hard drive will be used to process that overflowing
amount of data that should be being processed primarily by your RAM. The
idea is to use swap as a complimentary performance measure to your
appropriate RAM sized system. If using swap memory, don’t forget to
configure how this extra memory space will be used together with your RAM,
by setting the ‘swapiness’ metric, for example, which will tell the kernel
how aggressively it will swap memory pages in the system when
necessary. Once again, setting too much of a high value might make your
system inefficient as you start making your kernel believe that the
harddrive is actually RAM - the perfect disguise - but setting a low value
might also not give you the best performance possible. Each case will be
its own, so know your system and your needs, and act accordingly.
Our install happens on our disk, so, unfortunately I must tell you that
once again we will be checking out disk settings we can consider when
creating our hardened Ubuntu server. Cheers to our disks! Installing all of
the system in one single partition tends to be a lot easier and a lot
faster. However, we are not looking for easy here, we are looking for
secure, so let’s get out of the one single partition and out of our comfort
zones and possibly separate our system directories into different
partitions. Having /boot in a separate partition is useful to avoid not
being able to log into a system after the current kernel image has run
across issues. The backup kernel images will be available and you might be
able to do a quicker recovery that won’t require connecting an external
device in, or removing your own in order to fix what has been broken in the
OS. In case you encrypt your / (root) partition, you will need to perform
this regardless, or else, your OS won’t boot. Encrypted code might be cool
looking but it’s not exactly functional considering a situation where you
need to know what are the basic instructions that will allow you to get the
operating system up and running. Encrypting /boot together with / (root)
would be the same as hearing the “ready, set, go” at a car race and staying
stuck in place because you just remembered you put a boot in your
wheel. The locked boot is stopping you from moving the car forward and
getting it where you need it to be, and, considering /boot outside of the
analogy, it’s stopping you from getting your computer to execute your
operating system because it’s encrypted. Therefore, if you encrypt your
hard drive, as previously suggested, you already get to escape from the old
boring one partition scheme. That being said with this very convenient
analogy, let’s get back to it and discuss the other partitioning options
you might have and that you can apply to your system in order to make it
more efficient and more secure, options which include, for example, putting
/tmp in a separate partition. This is most likely a good call, especially
considering that world-writable /tmp is a common target for
attackers. Servers that might use /tmp for storage of, as the name
suggests, temporary files could cause a self DoS in case this directory is
filled up with various large files. If the directory is in a different
partition, however, only that specific partition will fill up and not the
entire system storage instead. Other processes using other directories in
your system are unaffected and only the process filling up /tmp is
terminated. It is also a lot easier to manage a filled up /tmp partition
than it is the entire system. Plus, different permissions can be set for
this specific partition later on, but we will discuss this soon enough,
albeit not now. Separating the /home and the /var directories from the rest
of the system also shares these advantages. Leaving these directories in
their own separate “drawers” inside the closet that is our hard drive might
be an interesting choice in order to avoid necessary space to be taken up
by a file that might not be essential for the workings of the server. The
/home directory will contain user files, and we don’t trust users, and the
/var directory might get filled up completely with a huge amount of logs,
for example. Filling up the logs might be an attack of choice made by some
hacker out there, but if you created a separate partition, you were
prepared for it. Having smaller partitions also makes for faster file
searches in the system, which might be a valid performance boost for your
IT infrastructure. If you plan to share resources through the network, have
these resources be connected to a directory mounted in a separate
partition, as you can have more permissive access control rules in the
shared partition, but keep the rigorous one in all others that might
contain sensitive information, which is in itself another advantage:
different partitions, different permissions during mount time. However, we
will go into more detail about this later on, as I already mentioned. The
point here is: separate partitions are separate filesystems, and,
therefore, the OS will not behave in the same way as it would if all data
were to be stored under a single partition…a single filesystem. All of that
being said, it will require more management than a system that has only one
partition, and space usage might not be the most efficient when you
establish limits to each directory. However, if it is feasible for your
needs, it might be a good way to avoid some issues…security issues.
Up next, I say this everytime and I will never get tired of saying it:
strong passwords, people! Strong passwords! Whenever creating the first
user for your Ubuntu system, which will happen during the install process,
do not use your birthday as your password. Or your dog’s name…or any 6
letter word followed by the digits that are the current year. Easy to
remember, easy to hack. The first step to avoid being hacked is not wanting
to be hacked, and forgive you me if I am being too blunt, but setting up
lazy passwords and not expecting it to be a problem is like eating rotten
food and expecting to not get sick: you can wish all you want, but the
outcome will not be positive for you, my friend…and to your closest loved
ones involved. So…strong passwords, please, and non-expired food.
Our system is installed. BIG. BANG. Our Ubuntu OS universe now exists after
we set everything up so that it looks just right for our security
needs. All is not done, however, since after the big-bang, the galaxy and
more specifically Earth, had to go through a lot of steps before it was
ready to host life, which is our main goal here: host life in the form of
executable, network service providing code. We now have galaxies, stars,
planets, and all necessary to maybe create life in the future, but first
things first, we need our huge ball of fire to be tweaked a little bit,
since life as we know it will not be born in such an unsafe, or might I
say, insecure environment. Let’s then make it secure so that we can start
thinking about giving it some life, or, in our case, installing some
software, developing customized code, setting up frameworks, all that good
stuff that makes developers go crazy with excitement.
I will, however, keep you on your toes, and continue talking more about
this subject in another episode only! So stay tuned to the podcast to
continue on this Ubuntu hardening journey with me, and while you wait for
what is to come, feel free to share your thoughts in any of our social
media platforms, as your opinion is always welcome! I await your return to
the podcast in the following weeks so that we can once again share
information, but for now I bid you all farewell and until next time! Bye!
Get in contact
[email protected]
#ubuntu-security on the Libera.Chat IRC network
ubuntu-hardened mailing list
Security section on discourse.ubuntu.com
@ubuntu_sec on twitter
29 min
March 04, 2022Episode 151
Overview
This week we do the usual round-up of security vulnerability fixes for the
various Ubuntu releases, plus we discuss enabling PIE for Python and
preview some upcoming content on Ubuntu system hardening as well.
This week in Ubuntu Security Updates
44 unique CVEs addressed
[USN-5292-4] snapd regression [00:52]
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-2021-44731
CVE-2021-44730
CVE-2021-4120
CVE-2021-3155
Episode 149 - another regression with fish shell
[USN-5303-1] PHP vulnerability [01:20]
1 CVEs addressed in Focal (20.04 LTS), Impish (21.10)
CVE-2021-21708
UAF - PoC exists which shows the ability to crash PHP interpreter via a
crafted database query - possible RCE as well
[USN-5304-1] PolicyKit vulnerability [01:40]
1 CVEs addressed in Focal (20.04 LTS), Impish (21.10)
CVE-2021-4115
fd exhaustion - send 2 requests and cause the first one to fail - leaks
the fd - eventually polkit runs out of fds and crashes - will be
restarted by systemd so impact is low
[USN-5305-1] MariaDB vulnerabilities [02:17]
10 CVEs addressed in Focal (20.04 LTS), Impish (21.10)
CVE-2022-24052
CVE-2022-24051
CVE-2022-24050
CVE-2022-24048
CVE-2021-46668
CVE-2021-46665
CVE-2021-46664
CVE-2021-46663
CVE-2021-46661
CVE-2021-46659
Several security issues - latest upstream point releases
10.3.34 for 20.04 LTS
10.5.15 for 21.10
[USN-5306-1] WebKitGTK vulnerabilities [02:44]
3 CVEs addressed in Focal (20.04 LTS), Impish (21.10)
CVE-2022-22592
CVE-2022-22590
CVE-2022-22589
Various issues in webkit fixed
[USN-5307-1] QEMU vulnerabilities [02:58]
11 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-0358
CVE-2021-4158
CVE-2021-3930
CVE-2021-3748
CVE-2021-3713
CVE-2021-3682
CVE-2021-3546
CVE-2021-3545
CVE-2021-3544
CVE-2021-20203
CVE-2021-20196
Various issues - integer overflow, NULL ptr derefs, memory leaks and
disclosures in vhost-user GPU driver, crash or possible code-exec in USB
redirector device emulation etc
[USN-5309-1] virglrenderer vulnerabilities [03:28]
2 CVEs addressed in Focal (20.04 LTS), Impish (21.10)
CVE-2022-0175
CVE-2022-0135
Virtual GPU for KVM
info leak and possible OOB write
[USN-5310-1] GNU C Library vulnerabilities [03:48]
12 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-23219
CVE-2022-23218
CVE-2021-3999
CVE-2021-3998
CVE-2021-35942
CVE-2021-27645
CVE-2020-6096
CVE-2021-3326
CVE-2020-29562
CVE-2020-27618
CVE-2019-25013
CVE-2016-10228
Usual mix of issues in libc - OOB read / writes - crash / possible code
execution - in various modules - character encoding handling in iconv,
netgroup lookups via nscd daemon, wordexp() / realpath() / getcwd()
functions etc
Goings on in Ubuntu Security Community
Python + PIE? [04:45]
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1452115
Request since 2015 to enable this
When compiled as PIE enables to use exec ASLR which can frustrate ROP
exploits etc
Performance testing shows this to have no impact
Coordinating with foundations team to try and land for Ubuntu 22.04 LTS
as a FFe
Security advice for running your own server [07:02]
https://discourse.ubuntu.com/t/basic-security-advice-for-running-your-own-server/26786
Hiring [07:33]
Ubuntu Security Engineer
https://canonical.com/careers/2925180/security-engineer-ubuntu-remote
Home based, worldwide
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
10 min
February 25, 2022Episode 150
Overview
Ubuntu 20.04.4 LTS is released, plus we talk about Google Project Zero’s
metrics report as well as security updates for the Linux kernel, expat,
c3p0, Cyrus SASL and more.
This week in Ubuntu Security Updates
62 unique CVEs addressed
[USN-5292-2, USN-5292-3] snapd vulnerabilities [00:44]
4 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Focal (20.04 LTS)
CVE-2021-44731
CVE-2021-44730
CVE-2021-4120
CVE-2021-3155
Episode 149
[USN-5294-1, USN-5294-2] Linux kernel vulnerabilities [01:38]
8 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-22942
CVE-2022-0330
CVE-2021-43975
CVE-2021-4202
CVE-2021-4155
CVE-2021-4083
CVE-2021-39685
CVE-2021-22600
5.4 - focal GA + clouds
Usual sorts of issues - double-free (UAF) in packet network protocol, OOB
R/W in USB Gadget, race condition in Unix domain sockets - UAF, XFS info
leak, NFC race -> UAF, Intel GPU TLB flush missing - DoS/RCE, VMWare vGPU
missing cleanup on errors - stale entries in fd table - info leak /
privesc
[USN-5295-1, USN-5295-2] Linux kernel (HWE) vulnerabilities [02:57]
5 CVEs addressed in Impish (21.10), Focal (20.04 LTS)
CVE-2022-22942
CVE-2022-0330
CVE-2021-4155
CVE-2021-4083
CVE-2021-22600
5.13 - impish GA + focal HWE
[USN-5297-1] Linux kernel (GKE) vulnerabilities [03:17]
7 CVEs addressed in Focal (20.04 LTS)
CVE-2022-22942
CVE-2022-0330
CVE-2021-43975
CVE-2021-4202
CVE-2021-4155
CVE-2021-4083
CVE-2021-39685
5.4 gke specific kernel - focal + bionic
[USN-5298-1] Linux kernel vulnerabilities [03:29]
12 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS)
CVE-2022-22942
CVE-2022-0330
CVE-2021-4202
CVE-2021-4155
CVE-2021-4083
CVE-2021-39685
CVE-2021-28715
CVE-2021-28714
CVE-2021-28713
CVE-2021-28712
CVE-2021-28711
CVE-2021-22600
4.15 bionic GA + xenial HWE + trusty azure
[USN-5299-1] Linux kernel vulnerabilities [03:46]
13 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2021-45485
CVE-2021-42008
CVE-2021-38204
CVE-2021-3679
CVE-2021-3612
CVE-2021-3564
CVE-2021-3483
CVE-2021-34693
CVE-2021-33034
CVE-2021-28972
CVE-2021-0129
CVE-2020-26558
CVE-2020-26147
4.4 - xenial GA + trusty ESM
[USN-5302-1] Linux kernel (OEM) vulnerabilities [03:57]
6 CVEs addressed in Focal (20.04 LTS)
CVE-2022-24959
CVE-2022-24448
CVE-2022-0435
CVE-2021-44879
CVE-2021-43976
CVE-2022-0492
5.14 - focal OEM
[USN-5288-1] Expat vulnerabilities [04:12]
12 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-25236
CVE-2022-25235
CVE-2022-23990
CVE-2022-23852
CVE-2022-22827
CVE-2022-22826
CVE-2022-22825
CVE-2022-22824
CVE-2022-22823
CVE-2022-22822
CVE-2021-46143
CVE-2021-45960
XML parser written in C - used by a huge number of other applications
from audacity, avahi, ceph, dbus, gdb, git, fontconfig, python, mesa,
squid and a lot more
2 possible RCE vulns - possible to inject content into XML namespace
tags, and failure to validate encoding e.g. for UTF-8 in particular
contexts
critical severity according to upstream since if expat passes malformed
data back to the application could result in memory corruption etc ->
RCE (thanks to upstream for the heads-up on the possible impact of
these)
Plus a bunch of DoS and other less severe bugs fixed too (stack
exhaustion, integer overflows when multi-gigabyte input is parsed etc)
[USN-5293-1] c3p0 vulnerability [05:41]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2019-5427
JDBC connection pooling library
billion laughs attack (aka XML bomb) when parsing XML config via
recursive XML entity expansion - have one entity defined as 10 of the
previous entity - then do this 10 times - 1 billion copies of the
original entity - memory exhaustion
billion laughs comes from original PoC which used an entity called lol
which was defined as 10 copies of lol8 which was defined as 10 copies of
lol7 etc…
[USN-5301-1, USN-5301-2] Cyrus SASL vulnerability [06:44]
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-24407
SASL implementation for Cyrus IMAP server, used also by exim, ldap-utils,
mutt, php, postfix and others
SQL plugin failed to properly validate input - SQL injection
[USN-5300-1] PHP vulnerabilities [07:23]
6 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2021-21707
CVE-2017-9119
CVE-2017-9120
CVE-2017-9118
CVE-2017-8923
CVE-2015-9253
php 7 - 4 different DoS vulns, 1 memory corruption - crash/RCE and one
info leak
Goings on in Ubuntu Security Community
GPZ report on vulnerability metrics [07:48]
https://googleprojectzero.blogspot.com/2022/02/a-walk-through-project-zero-metrics.html
Looks at vulns which GPZ has reported between Jan 2019 - Dec 2021 and how
fast they get patched
376 vulns
351 (93%) fixed, 14 (4%) wontfix, 11 (3%) unfixed
96 (26%) Microsoft, 85 (23%) Apple, 60 (16%) Google
Strict 90-day deadline to fix and ship (with additional 14-day grace
period)
When looking at vulns, group by Vendor - Apple, MS, Google, Linux
(kernel), Adobe, Mozilla, Samsung, Oracle and Others
Others: includes both vendors: Apache, AWS, Canonical, Intel, Qualcomm,
RedHat etc, but also individual OSS projects: c-ares, git, glibc,
gnupg, libseccomp, systemd and more
Time-to-patch:
Linux - 25 days on average
Google + Others - 44 days
Mozilla - 61
Adobe - 65
Apple - 69
Microsoft - 83
Oracle - 109
If look by year - shows most vendors have gotten faster over time - but
in particular Linux and Others are twice as fast in 2021 cf. 2019
Good news for Ubuntu users as these encompass the Linux relevant vulns
Also look into stats on Phone - comparing iOS, Android (Samsung), Android
(Google) - and all have a TTP of ~70 days
Then also dig into specifics of timelines for OSS projects, focusing on
browsers since can break down the process into 2 discrete steps:
time from report to a public patch being available
time from public patch to release
And compare these across Chrome, WebKit and Firefox
Chrome is fastest overall at 30 days total, Firefox 38 days, WebKit 73
When looking at the two steps:
Chrome has a very short initial patch time - 5 days - but both WebKit
and Firefox are respectible with 12 and 17 days respectively
But release cycle of WebKit is so long (61 days)compared to Chrome
(25) and Firefox (21) that this significantly delays the time to
fixes being available to users
Also puts them at more risk, since once a patch is publicly
available, it is usually not too hard to engineer a PoC for motivated
researchers, so they then have 2 months to use this on average before
it is patched
WebKit is used for all web rendering on iOS so iPhone users are then
vulnerable for quite a while no matter what browser they use -
hopefully Apple get faster at doing WebKit releases
Compared to Firefox and Chrome - both 4 week cycle now
Is not enough to develop fixes - you actually have to get them into
the hands of users to protect them
Ubuntu 20.04.4 LTS Released [15:27]
https://lists.ubuntu.com/archives/ubuntu-announce/2022-February/000277.html
The Ubuntu team is pleased to announce the release of Ubuntu 20.04.4 LTS
(Long-Term Support) for its Desktop, Server, and Cloud products, as well
as other flavours of Ubuntu with long-term support.
Like previous LTS series, 20.04.4 includes hardware enablement stacks
for use on newer hardware. This support is offered on all architectures.
Ubuntu Server defaults to installing the GA kernel; however you may
select the HWE kernel from the installer bootloader.
As usual, this point release includes many updates, and updated
installation media has been provided so that fewer updates will need to
be downloaded after installation. These include security updates and
corrections for other high-impact bugs, with a focus on maintaining
stability and compatibility with Ubuntu 20.04 LTS.
Kubuntu 20.04.4 LTS, Ubuntu Budgie 20.04.4 LTS, Ubuntu MATE 20.04.4 LTS,
Lubuntu 20.04.4 LTS, Ubuntu Kylin 20.04.4 LTS, Ubuntu Studio 20.04.4 LTS,
and Xubuntu 20.04.4 LTS are also now available. More details can be found
in their individual release notes:
https://wiki.ubuntu.com/FocalFossa/ReleaseNotes#Official_flavours
Maintenance updates will be provided for 5 years for Ubuntu Desktop,
Ubuntu Server, Ubuntu Cloud, and Ubuntu Core. All the remaining
flavours will be supported for 3 years. Additional security support is
available with ESM (Extended Security Maintenance).
https://wiki.ubuntu.com/FocalFossa/ReleaseNotes
https://wiki.ubuntu.com/FocalFossa/ReleaseNotes/ChangeSummary/20.04.4
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
February 18, 2022Episode 149
Overview
This week Qualys dominate the week in security updates, disclosing details
of 4 different SUID-root vulnerabilities, including Oh Snap! More Lemmings
(Local Privilege Escalation in snap-confine), plus we look at updates for
Firefox, cryptsetup and more.
This week in Ubuntu Security Updates
23 unique CVEs addressed
[USN-5279-1] util-linux vulnerabilities [00:59]
2 CVEs addressed in Focal (20.04 LTS), Impish (21.10)
CVE-2021-3996
CVE-2021-3995
First 2 of number of vulns discovered by Qualys this week
umount and fusermount are both setuid root
An unprivileged user is allowed to unmount a FUSE filesystem which is
already mounted and which they own
libumount parses /proc/self/mountinfo to validate if is a FUSE fs
When a mount entry is deleted, the kernel appends (deleted) to the name
of it in the mount table
libumount strips this off when parsing mountinfo to get the actual path
so a user could mount a FUSE filesystem at a mountpoint with (deleted) in
the name - and then libumount will strip this off and umount the original
path - ie. could mount at /tmp/ (deleted) then call umount /tmp and this
will succeed
Fixed to drop support for this (deleted) suffix as this has not been used
by the kernel since December 2014
Also when checking the UID of the user (as the owner of the filesystem),
would do a string comparison on the UID of the user against the UID of
the filesystem - but would use the length of the users UID to do this
comparison - which means a user UID of 1000 would then be seen to match
against a file-systems UID of 10000 etc - so would allow a user to umount
filesystems owned by certain other users
Fixed to compare as a numerical value rather than strings
[USN-5280-1] Speex vulnerability [04:41]
1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2020-23903
Divide by zero from a crafted WAV file - trap - crash - DoS
[USN-5284-1] Firefox vulnerabilities [04:56]
9 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-22757
CVE-2022-22756
CVE-2022-22754
CVE-2022-22764
CVE-2022-22761
CVE-2022-22760
CVE-2022-22759
CVE-2022-22755
CVE-2022-0511
97.0
Extensions could bypass update prompt and auto-update itself with extra
permissions
Drag and drop of a crafted image would make the resulting file
executable - could possibly use as RCE
WebDriver (remote control interface for firefox) failed to validate
Host/Origin headers - if visit malicious website with WebDriver enabled
could then allow attacker to connect back to the user’s browser and take
control of it
[USN-5286-1] cryptsetup vulnerability [06:20]
1 CVEs addressed in Focal (20.04 LTS), Impish (21.10)
CVE-2021-4122
Failed to properly validate the device header - local attacker with
physical access could modify this to trick cryptsetup to reencrypt the
device on next mount - but reencrypt it with no encryption enabled -
ie. decrypt it in place
Fixed by disabling the online reencryption feature
[USN-5267-3] Linux kernel (Raspberry Pi) vulnerabilities [07:11]
3 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2021-42739
CVE-2021-3752
CVE-2021-3640
Episode 148 - 2 vulns in bluetooth and one in Firewire subsystems - local
attacker crash / RCE - corresponding fixes for RPi on 20.04 or 18.04 with
HWE
[USN-5291-1] libarchive vulnerabilities [07:36]
3 CVEs addressed in Focal (20.04 LTS), Impish (21.10)
CVE-2021-36976
CVE-2021-31566
CVE-2021-23177
2 issues in symlink handling - would follow symlinks when changing
modes/times/ACLs on files when extracting a crafted archive - could allow
an attacker to modify these attributes on files outside of the archive
Memory corruption when parsing RAR archive - DoS/RCE
[USN-5292-1] snapd vulnerabilities [08:27]
4 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2021-44731
CVE-2021-44730
CVE-2021-4120
CVE-2021-3155
More Qualys issues in setuid root binary - snap-confine - plus 2 issues
discovered by Canonical - 1 from Ian Johnson of the snapd team, and 1
from James Troup of the BootStack team
Oh Snap! More Lemmings (Local Privilege Escalation in snap-confine) [09:01]
https://www.qualys.com/2022/02/17/cve-2021-44731/oh-snap-more-lemmings.txt
Qualys appear to have been auditing various SUID-root binaries - recently
looked at snap-confine - low-level application, written in C, and used by
snapd to setup the execution environment for a snap application - as the
name suggests, it setups up the confinement for an application, creating
a separate mount namespace with own private /tmp and /dev/pts - as well
as any other mounts through content interfaces or layouts etc defined by
the snap, plus loading of seccomp syscall filters for the resulting snap
As such requires root privileges, hence is SUID-root - high value target
Very defensively programmed itself, plus is confined by seccomp and
AppArmor itself
Nonetheless, even the most carefully programmed software can have issues
2 vulns:
hardlink attack (requires a non-standard configuration where system
admin disabled usual hardlink protections)
race-condition when creating mount namespace - allows an unprivileged
user to inject their own malicious libraries into the snap execution
environment and have these get executed by snap-confine itself to gain
root privesc
Qualys liken these vulnerabilities (or the process to finding them) as
like playing the original Lemmings game, due to the complex nature of
steps required to thwart the defense-in-depth construction of
snap-confine
Not the first time snap-confine has been audited - SuSE Security Team
previously audited it in 2019 and found a couple issues, in particular in
some of the same code sections as these
Back to these vulns:
When creating or deleting the mount namespace, snap-confine uses 2
helper programs written in Go - these are installed in the same
location as snap-confine, so it looks them up from the same directory
where it is running itself - however, since (when protected_hardlinks
is disabled) an unprivileged user could hardlink snap-confine into say
/tmp they could also then place their own malicious binary in place of
these helpers and have that get executed by snap-confine instead
NOTE: protected_hardlinks is enabled by default on almost all distros
so unless this has been changed by the system admin, this is unable to
be exploited in reality
Other vuln is a race condition when creating the private mount
namespace for the snap - snap-confine creates a per-snap private
directory under /tmp - this is a known “dangerous” thing to do since
/tmp is world writable so users could easily try and symlink their own
contents into it etc
snap-confine is very careful then to try and ensure this directory is
owned by root and to then avoid following symlinks when traversing this
hierarchy etc
However, when then doing the actual mount() syscall to start setting up
the mount namespace inside this directory, the absolute path of this
directory is given to mount() (since sadly there is no mountat() or
similar syscall) - which then does follow symlinks allowing a user who
an race the creation of this directory with snap-confine to be able to
take control of the contents of it, and hence inject their own
libraries and configuration such that a malicious library can be
preloaded into a subsequent execution of snap-confine - and since
snap-confine will then still run as root, this allows to get root code
execution
In both cases, the use of AppArmor by default tries to isolate
snap-confine - and snap-confine is programmed defensively such that it
will refuse to execute if it is not confined by AppArmor - however, the
checks for this were not strict enough, and Qualys found they could use
aa-exec to execute snap-confine under a separate, more permissive
AppArmor profile to escape these restrictions
Fixes for these issues were numerous - to both add additional hardening
to snap-confine so that it would validate the AppArmor profile it
executes under is the one that is expected - plus the actual fixes for
the vulnerabilities themselves, by checking snap-confine is located where
it expects to be (so it doesn’t execute other arbitrary helpers), and to
also when setting up the mount namespace directory hierarchy, forcefully
try and move aside any existing parts that are not root owned so it can
create them afresh with known ownership/permissions so that unprivileged
users can’t trick it with their own contents
As mentioned, also includes fixes for 2 other issues identified by
Canonical - open permissions on snap per-user HOME/private storage allows
other users to potentially access private info stored by snaps
Plus a more sinister issue in the handling of AppArmor rules for snaps
A snap can define a content interface - way of making files available to
other snaps - snaps can then connect to this to access that content -
often used to implement plugins or other such concepts between snaps
When creating an AppArmor profile for a snap, adds additional rules then
to allow access to these paths within the other snap
Included code to validate that a snap wasn’t trying to expose content it
shouldn’t BUT didn’t validate that these were just paths and nothing else
Since AppArmor policy is human-readable text files, these get generated
by snapd by adding the content interface paths into the policy
Content interface path could then contain additional AppArmor policy
directives and these would get included in the generated profile
Since any snap can specify content interfaces, and they get
auto-connected by snaps from the same publisher, would then just have to
get a user to install 2 malicious snaps from the same publisher where one
declares a malicious interface like this and then the snaps will be able
to escape the usual strict confinement provided by AppArmor
Fixed in snapd to both validate paths more correctly, and to also quote
all file-system paths in the generated AppArmor policies so that
arbitrary rules cannot be specified
Shows that the defence-in-depth approach is still worthwhile - Qualys
mentions they nearly gave up looking for vulns and then on trying to
exploit them due to just how hard the task appeared given all the
defensive measures they would have to overcome
Want to thank Qualys for all their efforts in disclosing vulns and in
providing feedback on proposed fixes etc, and the snapd team for all
their help on finding and remediating the vulnerability with content
interface / layout paths, plus on preparing and delivering this update
Has been in the works for a while, glad it is finally out
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
24 min
February 11, 2022Episode 148
Overview
It’s main vs universe as we take a deep dive into the Ubuntu archive and
look at these components plus what goes into each and how the security team
goes about reviewing software destined for main, plus we cover security
updates for Django, BlueZ, NVIDIA Graphics Drivers and more.
This week in Ubuntu Security Updates
53 unique CVEs addressed
[USN-5265-1] Linux kernel vulnerabilities [01:19]
10 CVEs addressed in Focal (20.04 LTS), Impish (21.10)
CVE-2021-42739
CVE-2021-42327
CVE-2021-4202
CVE-2021-4093
CVE-2021-4090
CVE-2021-4001
CVE-2021-3772
CVE-2021-3752
CVE-2021-3640
CVE-2020-27820
5.13 impish + focal hwe + 5.11 focal cloud kernel (gcp/aws/oracle/azure)
[USN-5266-1] Linux kernel (GKE) vulnerabilities
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2021-42739
CVE-2021-22600
5.4 gke
[USN-5267-1] Linux kernel vulnerabilities
3 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2021-42739
CVE-2021-3752
CVE-2021-3640
5.4 focal + bionic hwe
[USN-5268-1] Linux kernel vulnerabilities
4 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS)
CVE-2021-42739
CVE-2021-3752
CVE-2021-3640
CVE-2021-20322
4.15 bionic + 16.04 hwe + 14.04 azure
[USN-5260-3] Samba vulnerability [02:29]
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2021-44142
Episode 147 - vfs_fruit RCE
[USN-5269-1, USN-5269-2] Django vulnerabilities [03:00]
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)
CVE-2022-23833
CVE-2022-22818
XSS via incorrect handling of the {% debug %} template tag - failed to
properly encode the current context
Possible infinite loop when parsing multipart forms as used when doing
file uploads
[USN-5270-1, USN-5270-2] MySQL vulnerabilities [03:38]
26 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-21379
CVE-2022-21378
CVE-2022-21374
CVE-2022-21372
CVE-2022-21370
CVE-2022-21368
CVE-2022-21367
CVE-2022-21362
CVE-2022-21358
CVE-2022-21351
CVE-2022-21348
CVE-2022-21344
CVE-2022-21342
CVE-2022-21339
CVE-2022-21304
CVE-2022-21303
CVE-2022-21302
CVE-2022-21301
CVE-2022-21270
CVE-2022-21265
CVE-2022-21264
CVE-2022-21256
CVE-2022-21254
CVE-2022-21253
CVE-2022-21249
CVE-2022-21245
6 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2022-21367
CVE-2022-21344
CVE-2022-21304
CVE-2022-21303
CVE-2022-21270
CVE-2022-21245
8.0.23 for Ubuntu 20.04 LTS and 21.10
5.7.37 for Ubuntu 18.04 LTS and Ubuntu 16.04 ESM
[USN-5030-2] Perl DBI module vulnerabilities [04:11]
2 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2020-14393
CVE-2014-10402
Episode 125
[USN-5262-1] GPT fdisk vulnerabilities
2 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2021-0308
CVE-2020-0256
[USN-5264-1] Graphviz vulnerabilities
3 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2020-18032
CVE-2019-11023
CVE-2018-10196
[USN-5275-1] BlueZ vulnerability [04:25]
1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-0204
Heap buffer overflow in gatt-server implementation since failed to check
lengths of incoming packets - could allow a remote attacker to DoS or RCE
[USN-4754-5] Python vulnerability [04:53]
2 CVEs addressed in Trusty ESM (14.04 ESM)
CVE-2020-27619
CVE-2021-3177
Reinstate fix for CVE-2021-3177 which was previously removed due to a
regression
[USN-5276-1] NVIDIA graphics drivers vulnerabilities [05:15]
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-21814
CVE-2022-21813
Various issues around handling of permissions within the kernel - could
allow a local user to write to protected memory in the kernel and DoS
machine
[USN-5267-2] Linux kernel regression [05:52]
3 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2021-42739
CVE-2021-3752
CVE-2021-3640
5.4 focal + bionic hwe
Inadvertent DoS when accessing CIFS shares - kernel hang - fixed by
reverting various CIFS related patches
Goings on in Ubuntu Security Community
Main vs Universe with Camila
Camila discusses the different software repository components in Ubuntu -
what they are, how they compare and what you can expect to find in each,
as well as the process for moving packages from universe to main to be
supported by Canonical, in particular focusing on the security team’s
role in performing security audits of each software package along the
way.
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
1 hr 1 min
February 04, 2022Episode 147
Overview
We’re back after a few weeks off to cover the launch of the Ubuntu Security
Guide for DISA-STIG, plus we detail the latest vulnerabilities and updates
for lxml, PolicyKit, the Linux Kernel, systemd, Samba and more.
This week in Ubuntu Security Updates
100 unique CVEs addressed
[USN-5225-1] lxml vulnerability [00:57]
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Hirsute (21.04), Impish (21.10)
CVE-2021-43818
Python bindings for venerable libxml2 + libxslt - used by many other
python packages for parsing XML etc
HTML cleaner module - designed to clean up HTML by removing embedded
scripts, special tags, CSS style annotations and more.
Would allow crafted scripts to bypass the filter - same for SVG which
could embed scripts via data URIs - code execution as a result -> RCE
[USN-5210-2] Linux kernel regression [02:03]
7 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2021-43389
CVE-2021-43056
CVE-2021-41864
CVE-2021-3760
CVE-2021-20321
CVE-2020-26541
CVE-2021-4002
Episode 136 - [USN-5210-1] - caused boot failure on machines that had AMD
Secure Encrypted Virtualisation enabled
[USN-5223-1] Apache Log4j 1.2 vulnerability [02:21]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Hirsute (21.04), Impish (21.10)
CVE-2021-4104
JMS Appender module in Log4j 1.2 - requires the attacker to be able to
first modify the Log4j config - but can then get code execution - similar
to the original Log4Shell CVE-2021-44228 but not as severe
[USN-5224-2] Ghostscript vulnerabilities [02:57]
2 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2021-45949
CVE-2021-45944
Episode 146
[USN-5227-1, USN-5227-2] Pillow vulnerabilities [03:06]
5 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Hirsute (21.04), Impish (21.10)
CVE-2022-22817
CVE-2022-22816
CVE-2022-22815
CVE-2021-34552
CVE-2021-23437
Various DoS / possible RCE via crafted image files
[USN-5229-1] Firefox vulnerabilities [03:27]
13 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Hirsute (21.04), Impish (21.10)
CVE-2022-22752
CVE-2022-22751
CVE-2022-22748
CVE-2022-22747
CVE-2022-22745
CVE-2022-22743
CVE-2022-22742
CVE-2022-22741
CVE-2022-22740
CVE-2022-22739
CVE-2022-22738
CVE-2022-22737
CVE-2021-4140
96.0
Usual mix of web issues with standard consequences -> DoS / spoof browser
UI, bypass security / content restrictions, info leak, RCE
[USN-5233-1, USN-5233-2] ClamAV vulnerability [03:59]
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Hirsute (21.04), Impish (21.10)
CVE-2022-20698
OOB read when using the CL_SCAN_GENERAL_COLLECT_METADATA option and
handling OOXML files - remote attacker could supply an input file which
could trigger this -> crash
[USN-5235-1] Ruby vulnerabilities [04:24]
3 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Hirsute (21.04), Impish (21.10)
CVE-2021-41819
CVE-2021-41817
CVE-2021-41816
[USN-5234-1] Byobu vulnerability [04:25]
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2019-7306
Apport hook for Byobu would upload the local .screenrc file which could
possibly contain private info
[USN-5240-1] Linux kernel vulnerability [05:09]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Hirsute (21.04), Impish (21.10)
CVE-2022-0185
Integer underflow -> OOB write when parsing file system properties -
possible code execution -> requires root privileges to trigger BUT can
also be done from a user namespace - ie where a local user can masquerade
as root
[LSN-0084-1] Linux kernel vulnerability
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2022-0185
Livepatch for the above issue
[USN-5242-1] Open vSwitch vulnerability [06:16]
1 CVEs addressed in Impish (21.10)
CVE-2021-3905
Memory leak when handling fragmented packets - only affects most recent
versions of Open vSwitch so LTS releases etc not affected
[USN-5243-1, USN-5243-2] AIDE vulnerability [06:34]
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Hirsute (21.04), Impish (21.10)
CVE-2021-45417
Advanced Intrusion Detection Environment
checks integrity of files - common security tool
Heap buffer overflow when performing various base64 operations, as done
when handling XFS extended attributes or tmpfs ACLs - local privesc
[USN-5246-1] Thunderbird vulnerabilities [07:21]
26 CVEs addressed in Impish (21.10)
CVE-2021-43546
CVE-2021-4126
CVE-2021-44538
CVE-2021-43528
CVE-2022-22751
CVE-2022-22748
CVE-2022-22747
CVE-2022-22745
CVE-2022-22743
CVE-2022-22742
CVE-2022-22741
CVE-2022-22740
CVE-2022-22739
CVE-2022-22738
CVE-2022-22737
CVE-2021-43656
CVE-2021-43545
CVE-2021-43543
CVE-2021-43542
CVE-2021-43541
CVE-2021-43539
CVE-2021-43538
CVE-2021-43537
CVE-2021-43536
CVE-2021-4140
CVE-2021-4129
91.5
Usual web framework issues plus some TB specific ones
JS interpreter was enabled in composition window - so if an attacker
could exploit some other vuln to then be able to inject content into
the composition window could get code execution
Buffer overflow in Matrix chat client lib
Mishandling of PGP/MIME - would only look at signature on inner signed
message even if was contained in another signed message - so would show
whole message as valid
[USN-5248-1] Thunderbird vulnerabilities
45 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2021-43546
CVE-2021-4126
CVE-2021-44538
CVE-2021-43528
CVE-2021-38502
CVE-2022-22751
CVE-2022-22748
CVE-2022-22747
CVE-2022-22745
CVE-2022-22743
CVE-2022-22742
CVE-2022-22741
CVE-2022-22740
CVE-2022-22739
CVE-2022-22738
CVE-2022-22737
CVE-2021-43656
CVE-2021-43545
CVE-2021-43543
CVE-2021-43542
CVE-2021-43541
CVE-2021-43539
CVE-2021-43538
CVE-2021-43537
CVE-2021-43536
CVE-2021-43535
CVE-2021-43534
CVE-2021-38509
CVE-2021-38508
CVE-2021-38507
CVE-2021-38506
CVE-2021-38504
CVE-2021-38503
CVE-2021-38501
CVE-2021-38500
CVE-2021-38498
CVE-2021-38497
CVE-2021-38496
CVE-2021-38495
CVE-2021-29991
CVE-2021-29987
CVE-2021-29982
CVE-2021-29981
CVE-2021-4140
CVE-2021-4129
[USN-5249-1] USBView vulnerability [08:52]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2022-23220
Failed to properly configure policykit to enforce proper restrictions -
could allow a local user to execute arbitrary code by causing USBView to
load other modules
Future versions of USBView won’t run as root
[USN-5250-1] strongSwan vulnerability [09:59]
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-2021-45079
[USN-5252-1, USN-5252-2] PolicyKit vulnerability [10:06]
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-2021-4034
Mishandling of argv in pkexec
Normally, when an application runs, gets given argv + argc - argv[0] is
the name of the application and arguments follow that - BUT this is only
a convention - can fork/exec another binary and specify NULL argv
pkexec in that case would then try and parse arguments outside of the
valid argv array - generally env follows argv - so would process env as
argv
since pkexec is setuid root glibc sanitises env - BUT pkexec modifies
it’s own argv when processing arguments - so ends up modifying env - with
a crafted env input can trick pkexec to modify it’s own env to then
inject say a malicious LD_PRELOAD value to cause arbitrary code to be
executed as root
Great find by Qualys
[USN-5226-1] systemd vulnerability [13:50]
1 CVEs addressed in Focal (20.04 LTS), Hirsute (21.04), Impish (21.10)
CVE-2021-3997
Uncontrolled recursion in systemd-tmpfiles - local user could create a
deeply nested directory structure, cause systemd-tmpfiles to overflow
it’s own stack by recursively calling the same function over and over
again -> crash -> DoS
[USN-5193-2] X.Org X Server vulnerabilities [14:58]
3 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2021-4011
CVE-2021-4009
CVE-2021-4008
Episode 142
[USN-5247-1] Vim vulnerabilities [15:07]
5 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Impish (21.10)
CVE-2021-4069
CVE-2021-4019
CVE-2021-3984
CVE-2021-3974
CVE-2021-3973
Various memory corruption vulns when handling different files - DoS /
code execution
All found by fuzzing vim with ASan - participates in bug bounty - want some bug cash?
[USN-5254-1] shadow vulnerabilities [15:54]
2 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS)
CVE-2018-7169
CVE-2017-12424
[USN-5255-1] WebKitGTK vulnerabilities [16:03]
7 CVEs addressed in Focal (20.04 LTS), Impish (21.10)
CVE-2021-30984
CVE-2021-30954
CVE-2021-30953
CVE-2021-30952
CVE-2021-30951
CVE-2021-30936
CVE-2021-30934
[USN-5257-1] ldns vulnerabilities [16:18]
2 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS)
CVE-2020-19861
CVE-2020-19860
[USN-5260-1, USN-5260-2] Samba vulnerabilities [16:19]
3 CVEs addressed in Focal (20.04 LTS), Impish (21.10)
CVE-2022-0336
CVE-2021-43566
CVE-2021-44142
1 CVEs addressed in Bionic (18.04 LTS)
CVE-2021-44142
Most interesting vuln:
Heap OOB read/write in VFS fruit module - codeexec
Used to provide enhanced compatibility with Apple SMB clients and others
Not enabled by default but likely enabled in a bunch of different envs
Occurs when parsing extattr metadata - requires a user to be able to
modify a files xattrs but this is common in lots of envs
[USN-5259-1] Cron vulnerabilities [17:01]
4 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2019-9706
CVE-2019-9705
CVE-2019-9704
CVE-2017-9525
Goings on in Ubuntu Security Community
Ubuntu Security Guide tooling released for DISA-STIG compliance [17:11]
DISA-STIG is a U.S. Department of Defense security configuration standard
consisting of configuration guidelines for hardening systems to improve a
system’s security posture.
It can be seen as a checklist for securing protocols, services, or
servers to improve the overall security by reducing the attack
surface.
The Ubuntu Security Guide (USG) brings simplicity by integrating the
experience of several teams working on compliance. It enables the audit,
fixing, and customisation of a system while enabling a system-wide
configuration for compliance, making management by diverse people in a
DevOps team significantly easier.
The DISA-STIG automated configuration tooling for Ubuntu 20.04 LTS is
available with Ubuntu Advantage subscriptions and Ubuntu Pro, alongside
additional open source security and support services.
https://ubuntu.com/blog/ubuntu-introduces-the-ubuntu-security-guide-to-ease-disa-stig-compliance
https://ubuntu.com/advantage
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
21 min
January 14, 2022Episode 146
Overview
Ubuntu 21.04 goes EOL soon, plus we cover security updates for Django, the Linux kernel, Apache httpd2 + Log4j2, Ghostscript and more.
This week in Ubuntu Security Updates
28 unique CVEs addressed
[USN-5204-1] Django vulnerabilities [00:45]
3 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Hirsute (21.04), Impish (21.10)
CVE-2021-45452
CVE-2021-45116
CVE-2021-45115
Possible to write to arbitrary locations if a plugin etc would call
Storage.save() with crafted file names
Also possible to use the dictsort template filter to disclose info or
make method calls when passing in a crafted key - Django upstream remind
that should always validate user input before use
Possible DoS attack since the password comparison logic would compare
entire submitted password for similarity which (when passed a very long
password) would use a lot of CPU - fixed to discard anything with a
length that was significantly different than the supplied password
[USN-5206-1] Linux kernel (OEM) vulnerability [02:08]
1 CVEs addressed in Focal (20.04 LTS)
CVE-2021-4002
5.14 OEM kernel for Ubuntu 20.04 LTS
hugetlb would not always flush TLBs under certain conditions - since
don’t get flushed, a local attacker could then possibly read or alter
stale data from other processes which are using huge pages
In general most processes don’t use huge pages - have to specifically
opt in by using mmap() or SYSV shmem syscalls with the SHM_HUGETLB flag
But this is often used by applications which have large memory
requirements as they can preallocate memory using much larger page
sizes which gives performance benefits since many less TLB entries for
the same amount of memory compared to using standard size 4K pages
[USN-5207-1] Linux kernel (OEM) vulnerabilities [04:26]
4 CVEs addressed in Focal (20.04 LTS)
CVE-2021-43267
CVE-2021-42739
CVE-2021-4001
CVE-2021-4002
5.10 OEM kernel for Ubuntu 20.04 LTS
huge pages tlb flushing issue above
Race-condition in handling of read-only maps in eBPF - could allow a
privileged attacker to modify maps that were meant to be read-only
2 vulns previously discussed in Episode 140
TIPC + MSG_CRYPTO OOB write, and Firewire OOB write - both can be used
by local unprivileged users to cause DoS / possible code execution
[USN-5208-1] Linux kernel vulnerabilities [06:01]
7 CVEs addressed in Focal (20.04 LTS), Hirsute (21.04), Impish (21.10)
CVE-2021-43389
CVE-2021-43267
CVE-2021-43056
CVE-2021-41864
CVE-2021-3760
CVE-2021-20321
CVE-2021-4002
5.13 kernel series for Ubuntu 21.10, 5.11 kernel series for Ubuntu 21.04,
5.11 HWE kernel series for Ubuntu 20.04 LTS
As above plus
overlayfs race-condition -> DoS
NFS UAF -> crash -> DoS / code-exec
eBPF integer overflow -> OOB write -> crash -> DoS / code-exec
[USN-5209-1] Linux kernel vulnerabilities [06:38]
6 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS)
CVE-2021-43389
CVE-2021-41864
CVE-2021-3760
CVE-2021-20321
CVE-2021-20317
CVE-2021-4002
4.15 kernel series for Ubuntu 20.04 LTS, 4.15 HWE kernel series for
Ubuntu 16.04 ESM, 4.15 kernel for Ubuntu 14.04 ESM on Azure
A bunch of the previously mentioned CVEs, plus:
race condition in timer impl -> DoS from a privileged local users
[USN-5210-1] Linux kernel vulnerabilities
7 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2021-43389
CVE-2021-43056
CVE-2021-41864
CVE-2021-3760
CVE-2021-20321
CVE-2020-26541
CVE-2021-4002
5.4 kernel series for Ubuntu 20.04 LTS, 5.4 HWE kernel series for Ubuntu
18.04 LTS
As above
[USN-5211-1] Linux kernel vulnerability
1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
CVE-2021-4002
4.4 kernel series for Ubuntu 16.04 ESM, 3.13 kernel series for Ubuntu
14.04 ESM
[USN-5219-1] Linux kernel vulnerability
Affecting Focal (20.04 LTS), Hirsute (21.04), Impish (21.10)
5.13 kernel series for Ubuntu 21.10, 5.11 kernel series for Ubuntu 21.04,
5.11 HWE kernel series for Ubuntu 20.04 LTS
eBPF ringbuf OOB write -> local attacker -> DoS / RCE
[USN-5217-1] Linux kernel (OEM) vulnerabilities
1 CVEs addressed in Focal (20.04 LTS)
CVE-2021-4090
NFS OOB write -> local attacker -> DoS / RCE
eBPF ringbuf OOB write
same impact
[USN-5218-1] Linux kernel (OEM) vulnerabilities
7 CVEs addressed in Focal (20.04 LTS)
CVE-2021-43389
CVE-2021-43267
CVE-2021-43056
CVE-2021-41864
CVE-2021-3760
CVE-2021-20321
CVE-2021-4002
5.13 OEM kernel series for Ubuntu 20.04 LTS
[LSN-0083-1] Linux kernel vulnerability [07:33]
5 CVEs addressed in Ubuntu 20.04 LTS, 18.04 LTS and 16.04 ESM
CVE-2021-33909
CVE-2021-22555
CVE-2021-4002
CVE-2021-3653
CVE-2018-25020
Various recent high priority CVEs now available as a livepatch
Including hugepages issue above as well as
eBPF verifier issue
AMD specific issue with KVM -> guest to host memory write
OOB write in netfilter
VFS OOB write
All could lead to code execution by a relatively unprivileged user into
the kernel
[USN-5212-1, USN-5212-2] Apache HTTP Server vulnerabilities [08:54]
2 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Hirsute (21.04), Impish (21.10)
CVE-2021-44790
CVE-2021-44224
Possible NULL ptr deref when configured as a forward proxy (ProxyRequests on)
Possible SSRF when configured as both a forward and reverse proxy
[USN-5213-1] WebKitGTK vulnerabilities [09:37]
2 CVEs addressed in Focal (20.04 LTS), Hirsute (21.04), Impish (21.10)
CVE-2021-30890
CVE-2021-30887
“Universal” XSS and Content Security Policy bypass
both come from upstream webkit
[USN-5043-2] Exiv2 regression [10:10]
1 CVEs addressed in Focal (20.04 LTS), Hirsute (21.04), Impish (21.10)
CVE-2021-37620
Gwenview crash when opening images exported by darktable
gwenview uses exiv2 for metadata handling
recent security update for exiv2 introduced a regression
Thanks Simon Schmeißer from the Ubuntu community for contributing the
debdiff to fix this issue
[USN-5222-1] Apache Log4j 2 vulnerabilities [11:06]
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Hirsute (21.04), Impish (21.10)
CVE-2021-45105
CVE-2021-44832
Moar log4j2
Another instance of JNDI RCE but this time needed to have configured to
use a JDBC appender - ie configured to write event logs to a relational
database table via standard JDBC
Uncontrolled recursion via self-referential lookups - but requires an
attacker to be able to control Thread Context Map data as well as be
able to supply crafted strings to get logged
[USN-5224-1] Ghostscript vulnerabilities [12:21]
2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Hirsute (21.04), Impish (21.10)
CVE-2021-45949
CVE-2021-45944
Hello Ghostscript my old friend!
2 issues discovered by oss-fuzz (used to be all Tavis Ormandy, but those
were more logic bugs in the sandbox etc) - in this case a UAF and a heap
buffer overflow -> crash / RCE
Goings on in Ubuntu Security Community
Ubuntu 21.04 EOL [13:31]
Next week on 20th January Ubuntu 21.04 goes EOL
No more bug fix or security updates from then onwards
Now is the perfect time to upgrade to Ubuntu 21.10 which is supported for
another 6 months more until July 2022
Ubuntu Security Podcast back on break for 2 weeks [14:37]
22.04 mid-cycle sprint week
holiday
back in 3 weeks time (end of first week of February)
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
17 min
January 06, 2022Episode 145
Overview
The Ubuntu Security Podcast is back for 2022 and we’re starting off the
year with a bang💥! This week we bring you a special interview with Kees
Cook of Google and the Linux Kernel Self Protection Project discussing
Linux kernel hardening upstream developments. Plus we look at security
updates for Mumble, Apache Log4j2, OpenJDK and more.
This week in Ubuntu Security Updates
31 unique CVEs addressed
[USN-5195-1] Mumble vulnerability [01:02]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
CVE-2021-27229
Low-latency VoIP client - client / server model
Client picks a server to connect to from public server list
Malicious actor could register a server with a web URL that uses some
other protocol - e.g. smb to then refer to a .desktop file
When user chose the option to ‘Open Webpage’ for that server, would
automatically fetch and execute via underlying Qt framework libraries
QDesktopServices::openUrl function
Fixed to check URI scheme and only open if is http/https
Wonder if this kind of vuln may be seen in other applications?
[USN-5192-2] Apache Log4j 2 vulnerability [02:13]
1 CVEs addressed in Xenial ESM (16.04 ESM)
CVE-2021-44228
Log4j2 update for 16.04 ESM - see Episode 142
[USN-5203-1] Apache Log4j 2 vulnerability
1 CVEs addressed in Focal (20.04 LTS), Hirsute (21.04), Impish (21.10)
CVE-2021-45105
More Log4j2 vulns - possible to crash applications using log4j2 by
specifying a crafted string that would get logged which would then cause
infinite recursion when doing lookup evaluation
https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/Log4Shell
[USN-5202-1] OpenJDK vulnerabilities [03:13]
14 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Hirsute (21.04), Impish (21.10)
CVE-2021-35603
CVE-2021-35588
CVE-2021-35586
CVE-2021-35578
CVE-2021-35567
CVE-2021-35565
CVE-2021-35564
CVE-2021-35561
CVE-2021-35559
CVE-2021-35556
CVE-2021-35550
CVE-2021-2388
CVE-2021-2369
CVE-2021-2341
Mix of issues resolved with this latest point release update for
openjdk-8 and openjdk-11
Info leak via FTP client impl when connecting to malicious FTP server
Mishandling of JARs with multiple manifests -> signature verification bypass
Sandbox escape via crafted Java class
Use of weak crypto ciphers by default -> info leak
DoS via malicious RTF, BMP or class files
and more…
[USN-5199-1, USN-5200-1, USN-5201-1] Python vulnerabilities [04:26]
1 CVEs addressed in Focal (20.04 LTS), Hirsute (21.04) for Python 3.8/3.9
CVE-2021-3737
2 CVEs addressed in Bionic (18.04 LTS) for Python 3.6
CVE-2021-3737
CVE-2021-3733
3 CVEs addressed in Bionic (18.04 LTS) for Python 3.7/3.8
CVE-2021-3737
CVE-2021-3733
CVE-2020-8492
3 different DoS via urllib http client
infinite loop when handling 100 Continue responses - malicious HTTP
server could cause a DoS against clients - affects all
ReDoS due to quadratic complexity regex in basic auth handling - only
affects Python 3.6->3.8 in Ubuntu 18.04
Similar but different ReDos in basic auth handling - only affects
Python 3.7/3.8 in Ubuntu 18.04
[USN-5198-1] HTMLDOC vulnerability [05:37]
1 CVEs addressed in Focal (20.04 LTS), Hirsute (21.04)
CVE-2021-23180
Used to covert HTML/Markdown files to generate EPUB/HTML/PS/PDF with ToC
etc
Through fuzzing a NULL ptr deref was found if given crafted input HTML
file -> crash -> DoS
[USN-5186-2] Firefox regressions [06:06]
10 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Hirsute (21.04), Impish (21.10)
CVE-2021-43540
CVE-2021-43546
CVE-2021-43545
CVE-2021-43543
CVE-2021-43542
CVE-2021-43541
CVE-2021-43539
CVE-2021-43538
CVE-2021-43537
CVE-2021-43536
95.0.1
WebRender crash on some X11 systems
Failure to connect to microsoft.com domains
Goings on in Ubuntu Security Community
Seth and John talk Linux Kernel Security with Kees Cook [06:53]
Seth Arnold and John Johansen from the Ubuntu Security team chat with
Kees Cook from Google (KSPP) about Linux kernel hardening and
self-protection, including KASLR and FGKASLR, delving into the finer
points of linker scripts, kernel address pointer info leaks through debug
logs, detecting possible integer overflows in C by relying on undefined
behaviour of signed integer wraparound, hardware support for detecting
memory corruption and more.
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
57 min
December 31, 2021Episode 144
Overview
Happy holidays! This week we bring you the second part of a special
two-part holiday themed feature by Camila from the Ubuntu Security team
discussing how best to protect yourself and your systems from the top cyber
threats faced during the holidays.
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

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