Show notes
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 c…
Full show notes at the publisher 
Our TOPPODCAST Picks 
Stay Connected
