AT_SECURE not set to 1 for SUID programs

[fweimer]

• Your Windows build number: [Version 10.0.15063]

• What you're doing and what's happening: The AT_SECURE auxiliary vector entry is not set to 1 when running a SUID program:

  $ LD_SHOW_AUXV=1 /bin/su
  AT_SYSINFO_EHDR: 0x7ffff284f000
  AT_HWCAP:        1f8bfbff
  AT_PAGESZ:       4096
  AT_CLKTCK:       100
  AT_PHDR:         0x400040
  AT_PHENT:        56
  AT_PHNUM:        9
  AT_BASE:         0x7fda1ba00000
  AT_FLAGS:        0x0
  AT_ENTRY:        0x4033e5
  AT_UID:          1000
  AT_EUID:         0
  AT_GID:          1000
  AT_EGID:         1000
  AT_SECURE:       0
  AT_RANDOM:       0x7ffff21d8500
  AT_EXECFN:       /bin/su
  AT_PLATFORM:     x86_64
  Password:
  

• What's wrong / what should be happening instead: Only Password: should be printed because if AT_SECURE is 1, the glibc dynamic linker will ignore most LD_ environment variables because they can be abused for privilege escalation.

• Strace of the failing command, if applicable: This bug occurs before the process starts running, so strace is not applicable.

LD_SHOW_AUXV, as shown in the example, is comparatively harmless (it only leaks load addresses, defeating ASLR), but LD_PRELOAD is not ignored either, and that allows code execution as root. Fixing AT_SECURE will address all these issues at the same time (including the non-working secure_getenv, whose failing test in the glibc testsuite brought the issue to my attention).

[therealkenc]

This bug occurs before the process starts running, so strace is not applicable.

Well of course it's applicable. Fun part is in trying to collect an strace for you, it blue green screens in lxcore.sys. I'll collect the dump and send to Ben.

[benhillis]

Thanks @therealkenc I've got your dump. What were the repro steps to get that green screen of near death?

[therealkenc]

Crap I meant to put that in the email. As root:

LD_SHOW_AUXV=1 strace -ff /bin/su

Which doesn't crash after upgrade to 16184.

[fweimer]

@therealkenc, the auxiliary vector is supplied as part of the original process image and a pointer to it is passed to the startup code. It's not obtained using a system call or anything that would be visible in strace. Furthermore, the interaction of strace and SUID programs is complex and actually makes the bug harder to see.

[stehufntdev]

Thanks for reporting the issue. Marking this as a bug so we can track adding AT_SECURE to auxv.

[fweimer]

Thanks @stehufntdev. To be clear, it is already there, it's just stuck at the constant 0, ignoring the actual execution context.

[stehufntdev]

Understood, we just need to plumb up the logic to set that value.

[benhillis]

@fweimer - I have a fix for this, do you happen to have a link to instructions for running the glibc test suite you mention above? That test suite is something we should definitely add to our regression suite.

[therealkenc]

wget http://ftp.gnu.org/gnu/glibc/glibc-2.23.tar.xz
tar xf glibc-2.23.tar.xz
cd glibc-2.23
mkdir build && cd build
../configure --prefix=/usr   # edited
make -j8
make check

[therealkenc]

Stats for glibc-2.23 on Xenial, FWIW:

[edited: with proper --prefix=/usr, my run, YRMV]

16237:

Summary of test results:
     81 FAIL
   2322 PASS
     84 XFAIL
      2 XPASS

Native:

     29 FAIL
   2365 PASS
     84 XFAIL
      2 XPASS

There's known stuff in there, but also a few nuggets. Interestingly WSL passes some tests that Native fails (🤷). In the other direction, here is the short list. You can see the tst-secure-getenv in there. Those nptl (native posix thread library) fails could explain some stuff. Maybe.

[beevvy]

Another possibly useful test suite:

git clone git://git.musl-libc.org/musl
cd musl
git checkout a08910fc2cc739f631b75b2d09b8d72a0d64d285
./configure
make -j8
sudo make install
git clone git://nsz.repo.hu:45100/repo/libc-test ../libc-test
cd ../libc-test
git checkout defcb8d354e052f2d6ba230e7e2983546429a583
sudo make CC=/usr/local/musl/bin/musl-gcc -j8
egrep -c FAIL src/REPORT

I'm getting 20 failures on native Xenial and 105 failures on Xenial @ WSL build 16232. None of the native failures pass on WSL. Many failures are probably the same issues as in the glibc test suite.

[therealkenc]

Musl is a great test, even if that feels counterintuitive because it isn't common in Ubuntu- or Redhat-land. Musl doesn't pretend to be a replacement for some circa 1997 Unix system libc, or the basis for GNU Hurd. You'll feel a lot closer to home tracking down (say) obscure futex(2) behavioral problems. If you fix the musl test fails, most of the glibc fails will almost certainly fall in line, like Bartosz suggests.

[fweimer]

@benhillis @therealkenc Please configure glibc with --prefix=/usr, otherwise the built glibc isn't ABI-compliant with the real thing. See here for more details:

• https://sourceware.org/glibc/wiki/Testing/Builds

Known test failures are documented on the release pages:

• https://sourceware.org/glibc/wiki/Release/2.23
• https://sourceware.org/glibc/wiki/Release/2.24
• https://sourceware.org/glibc/wiki/Release/2.25
• https://sourceware.org/glibc/wiki/Release/2.26

The math failures you see are likely due to broken long double support (issue #830).

[benhillis]

@beevvy, @therealkenc - I'm a big fan of any tests that we can use to help identify issues with our compatibility layer. Since we're wrapping up the Fall Creators Update release now we're going to start looking at integrating more test suites into our regression test suite. glibc and musl are both great candidates.

[benhillis]

Support for this is added in 16257.