CVE-2021-3156 - sudo vulnerability

Discussion
1

Just patched about 90+ something Linux servers (and a few desktops) across Ubuntu 16.04 LTS (Armbian), 18.04 LTS and 20.04 LTS, Debian Stretch and Buster, RHEL 7, Oracle Linux 7, CentOS 7 :

RPM family : “sudo yum -y check-update && sudo yum -y install sudo”
DEB family : “sudo apt update && sudo apt -y --reinstall install sudo”

Don’t have any Debian Jessie to test on…

No updates for sudo in RHEL 6 or Orrible [sic] (OEL) 6 - given both are end of life - I’m not surprised…

Easy enough to test :

If good : then (Debian Buster) :

╭─x@beere253 ~/.ssh  
╰─➤  sudoedit -s /      
 usage: sudoedit [-AknS] [-r role] [-t type] [-C num] [-g group] [-h host] [-p prompt] [-T timeout] [-u user] file ...

If bad : then (RHEL 6) :

[root@redacted ~]# sudoedit -s /
sudoedit: /: not a regular file

If your machine’s not directly on the intert00bs - you probably don’t have much to worry about… my personal ones are not “really” on the intert00bs (the one that is - doesn’t listen for SSH on port 22 - and I am the only user in sudoers file) - and by and large I’m the only user - but among those 90 something servers I mentioned at the start - many of them are “servers” with multiple users with multiple forms of egress and some level of sudo access granted to them…

Got some ~140 or so Linux servers at another customer, some of which are running Debian 3 (and 4) and RHEL 4 - good luck with those (and also Debian 6 and 7 and 8!).

And then there’s another customer with some 600-900 NIX servers (some are Solaris 10 or 11, some are Oracle or RHEL 5 or 6 or 7 [and 8 I think]) - that’s gonna be tricky…
– edit: forgot the dang link –

3 Likes
2

Holy shit, this is something!

I had to patch roughly 20 Kubernetes Clusters, equaling to roughly more than 180 nodes. My number is bigger than yours, so for the first time I am cooler in something, than you. :laughing:

That said, you had a much bigger variety of Linux distributions, than me. I only had to patch Ubuntu 16.04 LTS and 18.04 LTS machines.

I used

apt-get install -y --only-upgrade sudo

Good to know, I just checked if the new versions installed are confirmed to be in the list of patched/backported sudos.

If anyone wants to upgrade sudo on all their nodes simultaneously, here are the papers:

apiVersion: v1
kind: ConfigMap
metadata:
  name: update-sudo
  namespace: kube-system
data:
  run.sh: |-
    #!/bin/bash
    cp /hostroot/etc/resolv.conf /hostroot/etc/resolv.conf.bk
    cp /etc/resolv.conf /hostroot/etc/resolv.conf
    chroot /hostroot /bin/bash <<"EOF"
    { sudo --version | head -1; } || true
    apt-get update
    apt-get install -y --only-upgrade sudo
    { sudo --version | head -1; } || true
    EOF
    cp /hostroot/etc/resolv.conf.bk /hostroot/etc/resolv.conf
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: update-sudo
  namespace: kube-system
  labels:
    name: update-sudo
spec:
  selector:
    matchLabels:
      name: update-sudo
  template:
    metadata:
      labels:
        name: update-sudo
    spec:
      containers:
        - name: update-sudo
          image: ubuntu:18.04
          command: ["/run.sh"]
          securityContext:
            privileged: true
          volumeMounts:
            - name: hostroot
              mountPath: /hostroot
            - mountPath: /run.sh
              subPath: run.sh
              name: update-sudo
              readOnly: true
      volumes:
        - name: hostroot
          hostPath:
            path: /
            type: Directory
        - name: update-sudo
          configMap:
            name: update-sudo
            defaultMode: 0755

Damn, you beat my number…

If you have a company and do this shit, you should be straight up sent to the chopping block. No excuses for such behaviour.

Okay, okay, I get it, you win the number competition. :laughing:

2 Likes
3

My strategy to do those 90 something servers (all VM’s running in VMware ESX / vSphere) was to
for SH in $(cat list-of-servers) ; do echo ---- $SH ---- ; ssh $SH "sudo package-manager update && sudo package-manager install sudo" ; done
(depending on whether they’re RPM or DEB distros)…

Much as I don’t personally run any RPM distros - I kinda prefer the simplicity of yum (or dnf, for that matter).

Next time I do this on a DEB based distro I’ll use your :

Note : all those servers I patched (with a for loop) have my user account registered in sudoers with NOPASSWD - because NOBODY’S got time to do this stuff interactively - and we don’t have Ansible in place (I’ve been pushing for Puppet for 2 years now - keeps starting and stopping in coughs and splurts - but there’s money / budget allocated to do it on that customer site with 600-900 NIX servers).

1 Like
4

Such people just don’t get it. I understand the “don’t fix it, if it ain’t broken” mentality to a certain degree, only. If the technology you use for 10 years is getting old and creates more problems than benefits, then I personally would start ditching it, even if it is not yet(!) entirely broken…

I hope there are more people reading this, besides me, who get the joke. :grinning_face_with_smiling_eyes:

2 Likes
5

I just think, it is almost incredible that this issue hasn’t been spotted before.

2 Likes
6

Literally what everyone said about Dirty Cow, as well. :laughing:

2 Likes
7

At the time of Dirty Cow - I had a Puppet Enterprise system (that I built myself, with some help from a company called ICE in Sydney Australia to develop some manifests) - so managed it across some 160 NIX boxen, mostly Orrible [sic] Linux 5 and 6, some Solaris, Oracle VM for x86, Solaris x86 on ZFS Appliances (much as I hate Oracle - those things run rings around NetApp bang for buck) and ExaData - then they wanted me to fix it on ~35 Mac OS desktop machines - had to get desktop support to allow me SSH access to each one with “root” - and sorted (with a for loop)… yeah Macs got Dirty Cow too - but : piece of cake…

Spectre/Meltdown still haunts me - 'cause most of the NIX boxes I managed for multiple customers, haven’t been patched, 'cause the customer won’t let me patch…

The customer still running Debian 3 is an “academic” institution trying to run themselves as an Enterprise (insert sardonic laugh)… one of those Debian 3 boxes triggers our alerting system every F–KING night!

2 Likes
8

But what if I get:

me@laptop:~> sudoedit -s /
sudoedit: /usr/bin/vi: Command not found
?

PS: Just joking. Everything’s patched here.

2 Likes
9

means you’re still broken - you should get a usage reminder like :

╭─x@fuglpige ~/bin  ‹master*› 
╰─➤  sudoedit -s /
usage: sudoedit [-AknS] [-r role] [-t type] [-C num] [-g group] [-h host] [-p prompt] [-T timeout] [-u user] file ...

Getting “sudoedit: [anything]” means you’re not patched, yet…

10

Sure? Because after, sudo ln -s /usr/bin/nano /usr/bin/vi, I get exactly what you posted. (usage: ... ).

[UPDATE/EDIT]

In the end, you were probably right @daniel.m.tripp: I had started quite some updates in the background and I had seen beforehand that sudo was included. I then did some other stuff and then tried what you suggested.

However, the updates took longer than expected and finished just a couple of minutes ago, so probably, at my first attempt, it wasn’t patched yet, but at the second yes. The masquerading for vi probably did exactly nothing.

1 Like
11

Just did another 25 or so machines (same customer as the “90” originally mentioned) - these servers are under pretty stringent “change control” regime - so had to submit them to CAB (change advisory board) and get approval, with hideous things like “change risk survey” and implementation plan, and backout plan…

Biggest PITA were a bunch of Red Hat 6 boxes that were not subscribed to RHN, nor did they even have internet access - and wouldn’t let me install the RPM… so I have to remove the sudo binaries, install the RPM file, then restore the sudoers file (/etc/sudoers.rpmsave)…

And a few ugly OEL (Orrible [sic] Enterprise Linux) 6 boxes (running Oracle RDMS database server instances)… updated to the sudo version that oracle recommended - but they still fail the “sudoedit -s /” test - but given the sudo package version on ALL of them is the one that Oracle says has fixed it - we can tell that to the customer…

1 Like
12

So much to the argument: “We need to buy from a big company in order to get professional support.”

3 Likes
13

essentially Orrible Linux is free, and to be fair - I actually kinda prefer it to RedHat*… It’s only not free if you want to do other stuff like log support calls - or - build internal yum repositories, and even then - it’s considerably cheaper than RHEL (which is kinda cheeky as they use RHEL source code as their base)…

and one thing I kinda liked last time I worked for a big Oracle shop, if you run Oracle Linux on Oracle x86 hardware and / or on Oracle VM for X86 (licensed) - you get support and can log support tickets - but - Oracle’s support page called “MOS” (My Oracle Support) is such a pig to use, it’s an active discouragement to actually log support calls :smiley: …

Note : the CVE-2021-3156 page, at Oracle, for Oracle OEL 6, says they based the patched version of sudo in OEL 6 on the version they built for OEL 7 - but - in OEL 7 the patched sudo package does PASS the “sudoedit -s /” test!

what I really hate about Oracle is Larry Ellison, whose idea of philanthropy is to invest millions into cryotherapy so he can get resurrected at some time in the future (and he owns a tropical Island - he sounds like a Bond villain!) - and I HATE what Oracle did to Sun Microsystems (and Solaris and Sparc) when they bought it…

*RedHat : when I was having to mitigate for Spectre/Meltdown circa 2018 - in my experience OEL 7 had mitigated kernels quite a bit of time before RedHat 7 and Centos 7 (in 2019 to get CentOS 7 mitigated, even though OEL was already mostly sorted, you had to actually add a third party YUM repo!).

2 Likes
14

Not to mention MySQL…

1 Like
15

Note : the CVE-2021-3156 page, at Oracle, for Oracle OEL 6, says they based the patched version of sudo in OEL 6 on the version they built for OEL 7 - but - in OEL 7 the patched sudo package does PASS the “sudoedit -s /” test!

That’s what’s strange. I patched a server with the sudo OEL6 latest rpm but it does not pass the “sudoedit -s /” test. Does it mean this patch does not work?

1 Like
16

“We” (the company I work for) are going to use this URL, as a reference, as Oracle “certify” (sort/kinda) this package revision fixes the vulnerability :

when we tell our customers we’ve fixed it “everywhere”…

1 Like
17

Hello

I’m aware of that URL but I’m wondering if it really has been fixed with that rpm.
I’m thinking about updating with the rpm available for Centos6 on the sudo website.

18

I don’t support any CentOS 6 boxes (got a few prod CentOS 7 machines -they’re all good from public repo updates) - but - I do support some RHEL 6 - the RHEL 6 RPM with updated sudo binaries DOES pass that “sudoedit -s /” test…

So can’t really compare OEL with RHEL… sorry…

Not prepared to gamble / test and see if that RHEL 6 RPM will install on OEL 6…

19

I know

but I don’t have a RHEL6 ELS subscription

20

I’m not actually suggesting you install RHEL “official” RPM of sudo onto Oracle Linux - in fact I’d strongly recommend AGAINST it. :smiley:

Note : one of my main customers runs Rapid 7 Insight security scanner.

There’s four Oracle Linux 6 server machines I patched last week (they all run Oracle software / database) were not on the list Rapid 7 SIEM reported (despite failing the “sudoedit -s /” test) back on CVE-2021-3156