what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

Libc sigqueue() Function TGKILL si_code Spoof

Libc sigqueue() Function TGKILL si_code Spoof
Posted Mar 23, 2011
Authored by Julien Tinnes

Libc's sigqueue() function has not been updated to mitigate spoofing of the TGKILL si_code. Because of this, userland is unable to trust the pid and uid information of a TKILL signal.

tags | advisory, spoof
SHA-256 | da60bcd9f8399fae09da3a1f99b2b0a7f2508fe1068f4bbb527f9eba681e9a05

Libc sigqueue() Function TGKILL si_code Spoof

Change Mirror Download
The libc' sigqueue() function allows to queue a signal, as well as some
accompanying data to a process.

The kernel's interface that is used to implement this function is known
as rt_sigqueueinfo(). It has been added in Linux 2.2.

This system call is interesting from a security perspective, because it
allows userland to compeletely specify the siginfo_t structure. This
structure is normally typically almost entirely written by the kernel
when a signal is delivered.

Since at least Linux 2.4.0, most abuses of the kernel interface have
been prevented with a simple check:

/* Not even root can pretend to send signals from the kernel.
Nor can they impersonate a kill(), which adds source info. */
if (info.si_code >= 0)
return -EPERM;

This check made sure that rt_sigqueueinfo() could not spoof a signal
whose SI_CODE would be SI_KERNEL or SI_USER. As the comment indicates, a
process receiving a signal should be able to trust its source pid or uid
if its si_code matches SI_USER.

Unfortunately, a couple of years later, when tgkill() and tkill() were
added, this check was forgotten and was not updated to prevent the
spoofing of a TGKILL si_code. Because of this, userland is unable to
trust the pid and uid information of a TKILL signal.

This is bad, because it is a useful feature in a scenario where a
process which cannot ptrace you can send you signals. This includes at
least the startup code of setuid binaries.

Meanwhile, userland and libc writers still assumed that they could trust
the origin of a SI_TKILL signal. Glibc authors too [1]. Worse: they
even silently patched SI_TKILL with SI_USER [2], [3]. So even a userland
application that (righfully so) only trusts SI_USER signals will be
vulnerable.

A tentative patch for this vulnerability has been committed to Linus'
kernel tree [4].

In this patch, we prevent rt_sigqueueinfo() from specifying any si_code
!= SI_QUEUE. While we believe it to be very unlikley, this could in
theory break userland in some older Linux distributions, so we may
have to revert to a more concervative patch and prevent ( (si_code ==
SI_TKILL) || (si_code >= SI_QUEUE) ) instead.

Please credit "Julien Tinnes, Google security team" in any related advisory.

Julien

[1]: http://codesearch.google.com/codesearch/p?hl=en#xy1xtVWIKOQ/pub/glibc/snapshots/glibc-latest.tar.bz2%7CXP6Z3zoy3dk/glibc-20090518/nptl/init.c&l=175
[2]: http://codesearch.google.com/codesearch/p?hl=en#xy1xtVWIKOQ/pub/glibc/snapshots/glibc-latest.tar.bz2%7CXP6Z3zoy3dk/glibc-20090518/sysdeps/unix/sysv/linux/sigwaitinfo.c&l=63
[3]: http://codesearch.google.com/codesearch/p?hl=en#xy1xtVWIKOQ/pub/glibc/snapshots/glibc-latest.tar.bz2%7CXP6Z3zoy3dk/glibc-20090518/sysdeps/unix/sysv/linux/sigtimedwait.c&l=62
[4]: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=da48524eb20662618854bb3df2db01fc65f3070c

Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close