This page has critical misinformation which has already caused confusion on this thread.

Version number alone cannot tell you if you are vulnerable or patched! Many, many Linux distributions, including (at least) Ubuntu and RHEL "backport" security fixes to older versions of the software. That means you could be using an old version of sudo, but still fully patched and protected from this exploit.

Edit: furthermore, the patching instructions for WSL is completely wrong and should not be followed. The correct procedure is to just get the update from your distro:

sudo apt-get update && sudo apt-get --only-upgrade install sudo

Very good point and I've updated the README.md. I had a typo when I originally ran it and that is why I thought you had to update it manually. Thanks community for helping me.

I don't know much about WSL, but the instructions for this do not look right. Isn't WSL usually just a Linux distribution, so you should also use the package manager?

If you just run ./configure && make && sudo make install, sudo will be installed to /usr/local as prefix. Doesn't this mean the unpatched binary at /usr/bin/sudoedit will still be accessible?

Right, the correct solution here for WSL would also be to run "apt-get upgrade" or whatever your distro uses.

I think you accidentally typoed the first command "apt-get update" as "apt-get upgrade", which is why it didn't work there.

Good spot! AFAIK Ubuntu under WSL(2) uses the same update repository as a non-WSL variants, so you shouldn't get different results.

Correct! Thank you!

Yeah the instructions are poorly written. Also, in my case (ubuntu 20.04) running `sudo apt-get --only-upgrade install sudo` does nothing, the latest version available is 1.8.31-1ubuntu1.2.

That version has the patches for this CVE. https://launchpad.net/ubuntu/+source/sudo/1.8.31-1ubuntu1.2

I had basically the same comment on the first HN posts about it. Just because `sudo -V` doesn't say 1.9.5p2 doesn't mean you're still vulnerable... https://news.ycombinator.com/item?id=25920839

Did you run sudo apt-get update first?

I'm running WSL 2 here with Ubuntu 20.04 LTS and this is what worked for me, without having to install anything from source.

Without doing anything (vulnerable):

    nick:~ $ sudoedit -s '\' `perl -e 'print "A" x 65536'`
    malloc(): corrupted top size
    Aborted

Then I ran this to patch it:

    sudo apt-get update && sudo apt-get --only-upgrade install sudo

And now this is the output (I guess not vulnerable anymore):

    nick:~ $ sudoedit -s '\' `perl -e 'print "A" x 65536'`
    usage: sudoedit [-AknS] [-r role] [-t type] [-C num] [-g group] [-h host] [-p prompt] [-T timeout] [-u user] file ...

After patching it `dpkg -l | grep sudo` reports 1.8.31-1ubuntu1.2. I didn't think to run that before patching it but I'd guess it's going to be different.

macOS doesn't have sudoedit, but you can make a symlink to it, as sudo is effectively a multi-call binary:

   ln -s `which sudo` sudoedit

and then call it:

   ./sudoedit

So don't take the lack of a `sudoedit` command as evidence that a system isn't vulnerable. I don't know if the sudo included with macOS has been exploited though.

  % cd ~ && ln -s /usr/bin/sudo sudoedit && ./sudoedit -s \\
  sudoedit(75875,0x109abbdc0) malloc: Incorrect checksum for freed object 0x7fcf2fc06bf8: probably modified after being freed.
  Corrupt value: 0x737666635f343332
  sudoedit(75875,0x109abbdc0) malloc: *** set a breakpoint in malloc_error_break to debug
  zsh: abort      ./sudoedit -s \\

Doesn't bode well at all for it being non exploitable (due to ASLR sometimes it doesn't crash tho)

What is the simplest way to upgrade on macOS?

No simple way because Apple is sitting on its ass.

I was initially confused if this was just WSL as "WSL and Linux" could be interpreted that way.

It's not just WSL. It would appear to be sudo, wherever it runs. I didn't see anything Linux specific about the CVE, other than maybe there are platforms that are better about heap-based buffer overflows.

It is sudo. It affects Linux, WSL, etc.

Sudo also runs, for example, on OpenBSD. Solaris, MacOS, etc.

I think OpenBSD stopped shipping `sudo` in the base system in favor of `doas`.

There is a blog on how to detect this CVE using Falco that goes into more detail.

https://sysdig.com/blog/cve-2021-3156-sudo-falco/

If anyone needs to patch CentOS 6 like I had to (I know, I know..), it's possible.

You'll need to install gcc, pam-devel and openldap-devel if you need it. Then you can build from source using ./configure --prefix=/usr && make && make install

Oh and remember to switch your repos to CentOS Vault instead of the default mirrorlist if you need the packages mentioned above.

Normally you should use the source packages available to you. If you run configure and make on the upstream package, you will not only lose the patches CentOS normally applies to the package to integrate it better with the system, but your patch will also be untracked by the package manager.

Building a source package is trivial. Just download the srpm, run rpm -i just like you normally would. This will extract the package. Look at rpmbuild/SPECS directory. There is your "spec file" which is a list of patches to apply and the exact commands used to build the package.

Add the upstream patch that fixes the security problem and step the least significant version number. Run rpmbuild -ba on the spec file. A binary rpm will now be built that can be installed in the normal way. This may sound intimidating at first, but it is really very simple. Also, congratulations on your first step on maintaining a package.

Alternatively, you can also grab the latest version from Rawhide if it has the fix. This will often have the patch and you can lift it straight out and use on the old version. Or you could just build the new version, but there can be hard dependencies on newer libraries which may not be easily available to you.

Not sure what you're on about. CentOS 6 doesn't receive updates anymore. It's EOL. Why go through all that effort if nothing will ever replace the package I compiled from source and installed?

Because there may be another security patch after this one. Because otherwise it is easy to lose track of which hosts have the patch. Because it integrates well with configuration management systems. Because you want to keep whatever other patches Red Hat has applied.

Related - I would have thought more people than were, would have been interested in this thread about how 'obvious' this exploit was -

https://news.ycombinator.com/item?id=25950976

How long it would have taken to fuzz recent buffer overflow in sudo? https://milek7.pl/howlongsudofuzz/

Afflicts distros after 2011 I believe, so quite widespread

Google Cloud SQL is suffering degraded service. Hopefully they patched their servers against that vulnerability.

Discussed here https://news.ycombinator.com/item?id=25962057

Been waiting for a WSL thread. Does WSL have a performance hit on Windows 10?

I sometimes can't decide if I want to use a familiar linux version of a program or a Windows version, but I like how WSL lets you access the windows file system

In my experience there's a performance hit in filesystem-heavy work like opening and closing a lot of small files.

Still, its more than offset by the convenience of performing bash operations on Windows; remembering `du -csh ./* | sort -h` (sort directories by size) is easier than whatever Powershell would have me type.

There's WSL1 and WSL2. Both have areas where performance isn't great, but the areas are different for each. Most of the issues are filesystem related, especially cross Win/Linux.

Try a 'git clone' of a reasonably large remote repo to see what it's like. Into both the windows fs and the Linux one.

WSL2 is what I’m wondering about

Should I submit hashes with geth linux on wsl2 or geth windows native

I guess I could just benchmark it, havent gotten around to it.

WSL2 has reasonable performance inside the Linux filesystem, but is very slow (slower than WSL1) if you're in /mnt/c, for example. https://github.com/microsoft/WSL/issues/4197

Getting X11 up and running is a little tricky also, because localhost is not the same as localhost on the Windows box. You have to set DISPLAY to the external IP on the Windows box.

Not only that, but it lets you launch windows executables too.

Hey, I just want to apologize for my reply here [1]. Looking back I realize it was rude and simply incorrect, and I regret sending it.

Sorry to intrude on this unrelated thread but it's the only way to get in touch with you.

[1] https://news.ycombinator.com/item?id=25828810

For the perl based check, what does it mean if you get a seg fault?

Also for the `sudoedit -s /` check what does it mean if you get a "sorry, user X is not allowed to execute BLAH BLAH"?

If you segfault, you are vulnerable.

Original thread on this issue: https://news.ycombinator.com/item?id=25919235