Linux and Mac OS X users and system administrators, and long before them, Unix users and sysadmins, have used sudo as an essential computer management tool. With it, users are given the power to make essential, but sometimes dangerous, changes to their systems. Recently a fundamental security bug in sudo was discovered, In some network this security hole could allow a cracker unlimited control of Linux, Mac OS X, and Unix systems. Fortunately, the bug has now been fixed.
Sudo, which system operators (sysops) use all the time, has been around for almost as long as Unix has been. People often think sudo stands for “do as superuser.” That’s because it’s most commonly used by trusted ordinary users to run a single command as if they were the “superuser” aka the root user or system administrator. Actually, it stands for “substitute user identity and do.” It’s commonly used to let an ordinary users do extraordinary things like call the shots with your Web server or database with the powers of the appropriate management account.
The idea in all cases is to keep people from, during their ordinary run of the mill work, mistakebly make fundamental changes to the system or core services. Of course, any problem with sudo can easily lead to an escalation-of-privilege exploit. If you can break into sudo there’s really very little you can’t do to a system.
Of course, as powerful as sudo it is, it’s much better than simply allowing users to use the root account all the time for all their work. That way leads to almost certain disaster.
For years, decades, sudo has been used with little trouble. Recently, however, it was found that on a networked system that uses both IPv4 and IPv6-which is becoming increasingly common-it was found that if you also used a sudo configuration file, sudoers, on a network that used LDAP (Lightweight Directory Access Protocol) to manage sudo accounts sudo accounts weren’t being properly regulated. What was happening was that, if sudo use was managed by their network addresses and network masks, a user with an invalid IPv4 Internet address would still be passed through to the IPv6 check… which would then approve them automatically. Whoops!
The problem, which existed in sudo versions 1.6.9p3 through 1.8.4p4, has since been fixed. System administrators should upgrade to 1.8.4p5 or higher as soon as possible.
To exploit the bug, a would-be cracker needs to be in the sudoers file (or sudoers LDAP data) and be granted access to commands on hosts on one or more IPv4 networks. If sudoers doesn’t include IP networks in the host specification portion of the sudoers rules, the bug has no effect. So, if for some reason you can’t fix the problem immediately, you can still block it by removing IP network addresses from your sudoers rules host specification settings.
To my knowledge, no one has exploited this bug yet. Still, any bug that has the potential to give untrusted users absolute power over a system has to be taken seriously and eradicated as soon as possible.