Sudo? More like Su-doh: There's a fun bug that gives restricted sudoers root access (if your config is non-standard)

It's only Monday, and we already have a contender for the bug of the week.

Linux users who are able to run commands as other users, via the sudoer mechanism, though not as the all-powerful root user, can still run commands as root, thanks to a fascinating coding screw-up.

This security vulnerability, assigned CVE-2019-14287, is more interesting than scary: it requires a system to have a non-standard configuration. In other words, Linux computers are not vulnerable by default.

However, if you've set up Sudo in a rather imaginative, and fundamentally insecure, way – letting users run commands as others except root – then you will probably will want to pay attention. Because your users can bypass that non-root restriction using -u#-1 on the command line.

The best way to describe the problem is to use an example. Let's say you've set up the user bob as a sudoer on the server mybox so that they can run the text editor Vi as any user except root. You might trust bob to oversee the files and activities of other users, but they're not allowed any superuser access.

Your sudoers file would have the line:

mybox bob = (ALL, !root) /usr/bin/vi

That should allow bob to run Vi as anyone but root. However, if bob runs this command:

sudo -u#-1 vi

That -u#-1 will bypass the above restriction, and run Vi as root for bob. Now bob can change any file on the system. Oops.

This happens because, say, -u#1234 can be used on the command line with Sudo to run the command, Vi in this case, as user ID 1234. This user ID value is passed to the setresuid and setreuid system calls by Sudo to change the effective user ID of the command.

Thus, -u#-1 passes -1 to those calls to change the effective ID to -1. However, these system calls treat -1 as a special case: it means do not change the user ID. And seeing as Sudo runs as root initially, -1 means continue running as root. So, in the above case, Vi runs as root. Also, amusingly, the user ID 4294967295 will bypass the restrictions because, as a signed 32-bit integer, it equals -1.

The lesson here is: do not pass special values to system calls direct from the user – sanitize inputs first.

This programming gaffe was found and reported by Joe Vennix of Apple security, and fixed today in Sudo 1.8.28. Update your Linux systems as normal to pick up the patch: a fix was already available for your vulture's preferred distro – Debian, naturally – while writing this piece.

If you're interested, to plug the security hole, Sudo was tweaked to block -1 as a user ID. ®