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

Chris Evans Security Advisory 2009.1

Chris Evans Security Advisory 2009.1
Posted Jan 24, 2009
Authored by Chris Evans

There is a trick which may permit the bypassing of policies in technologies which do syscall filtering on the Linux x86_64 kernel. The trick is made possible by the fact that the 32-bit and 64-bit kernel tables are different, combined with the fact that a 64-bit process can make a 32-bit syscall and visa versa. The syscall "number" check can get confused and permit a syscall it did not intend to.

tags | advisory, kernel
systems | linux
SHA-256 | 71f9f1ada6ae634228b54736464e7a4841b30f48b31c56977488fe81bf3eae53

Chris Evans Security Advisory 2009.1

Change Mirror Download
CESA-2009-001 - rev 1


[See all my vulnerabilities at http://scary.beasts.org/security]

[Blog if you want to subscribe to new findings is at http://scarybeastsecurity.blogspot.com/]

Linux syscall interception technologies partial bypass

Programs affected: Probably many; for example systrace with ptrace() backend.
Fixed: Systrace 1.6f for 32-bit build (but you are cautioned that ptrace() is not a security technology).
Severity: Syscall policy violation.

Various security technologies make use of syscall filtering. Such technologies are very powerful because they restrict a compromise not just in terms of access to files, networks and processes -- but also access to the rich kernel API (a great source of ring 0 bugs).

Syscall filtering technologies typically make an allow / deny decision based on the syscall (identified by a number) and sometimes also the exact arguments to the syscall. A vulnerability exists due to the identification of syscall by number. On 64-bit aware Linux kernels (x86_64), the syscall number can map to either the 32-bit or 64-bit syscall table. Since the syscall tables are different for 32-bit vs. 64-bit, and the user space process gets to control which table it hits, the syscall number check can often be fooled.

For example, a syscall filter technology might be monitoring a 64-bit process, and configured to allow some subset of the very common open() syscall. That's syscall number 2 in 64-bit land. However, the monitored process can switch to 32-bit mode and issue syscall 2. That appears to be open() to the monitor but will execute as fork() in the kernel - possibly leading to an unmonitored process.

Here is a sample piece of code which does a 32-bit syscall:

int
main(int argc, const char* argv[])
{
/* Syscall 1 is exit on i386 but write on x86_64. */
asm volatile("movl $1, %eax\n"
"int $0x80\n");
for (;;);
}

When built 64-bit, and run under strace on my 64-bit machine, the difference in opinion on the syscall is apparent:

write(1, "\370V\355\365\377\177", 140737319359320 <unfinished ... exit status 208>

The monitor sees write() but the kernel sees (and executes!) exit().

Detecting this situation has some subtleties. Which syscall table the kernel hits depends on both the instruction used to trap into the kernel, and also the "long mode" bit in the current descriptor referred to by the code segment (CS) register. int80 and sysenter always cause a 32-bit syscall, but syscall looks at the descriptor. Therefore, to securely monitor a 32-bit process, it is sufficient just to validate that the CS register references a privileged 32-bit descriptor. Unfortunately, to securely monitor a 64-bit process, not only must the CS register be checked, but the instruction initiating the syscall must be checked. This involves reading user-space which is of course is subject to well-documented lethal race conditions when other processes which share writeable address space.


CESA-2009-001 - rev 1
Chris Evans
scarybeasts@gmail.com

Login or Register to add favorites

File Archive:

May 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    May 1st
    44 Files
  • 2
    May 2nd
    5 Files
  • 3
    May 3rd
    11 Files
  • 4
    May 4th
    0 Files
  • 5
    May 5th
    0 Files
  • 6
    May 6th
    28 Files
  • 7
    May 7th
    3 Files
  • 8
    May 8th
    4 Files
  • 9
    May 9th
    54 Files
  • 10
    May 10th
    12 Files
  • 11
    May 11th
    0 Files
  • 12
    May 12th
    0 Files
  • 13
    May 13th
    17 Files
  • 14
    May 14th
    11 Files
  • 15
    May 15th
    17 Files
  • 16
    May 16th
    13 Files
  • 17
    May 17th
    22 Files
  • 18
    May 18th
    0 Files
  • 19
    May 19th
    0 Files
  • 20
    May 20th
    0 Files
  • 21
    May 21st
    0 Files
  • 22
    May 22nd
    0 Files
  • 23
    May 23rd
    0 Files
  • 24
    May 24th
    0 Files
  • 25
    May 25th
    0 Files
  • 26
    May 26th
    0 Files
  • 27
    May 27th
    0 Files
  • 28
    May 28th
    0 Files
  • 29
    May 29th
    0 Files
  • 30
    May 30th
    0 Files
  • 31
    May 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