exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

pine-cert-20040201.txt

pine-cert-20040201.txt
Posted Feb 4, 2004
Authored by Joost Pol | Site pine.nl

Pine Digital Security Advisory PINE-CERT-20040201 - The shmat(2) function has a flaw that allows local users to achieve escalated privileges. Vulnerable systems: FreeBSD versions 2.2.0 and greater, NetBSD versions 1.3 and greater, and OpenBSD versions 2.6 and greater.

tags | advisory, local
systems | netbsd, freebsd, openbsd
SHA-256 | a574248c2ca40bfc4b92b9ac9a645d17d7ca2b2477dbce0dd28b3dd3e9b6ce84

pine-cert-20040201.txt

Change Mirror Download
-------------------------------------------------------------------------------
Pine Digital Security Advisory
-------------------------------------------------------------------------------
Advisory ID : PINE-CERT-20040201 (CAN-2004-0114)
Authors : Joost Pol
Vendor Informed : 2004-02-01
Issue date : 2004-02-05
Application : kernel / sysv shared memory
Platforms : FreeBSD, NetBSD and OpenBSD
Availability : http://www.pine.nl/press/pine-cert-20040201.txt
-------------------------------------------------------------------------------

Synopsis

While gathering material for a security training Pine
Digital Security encountered a reference count overflow
condition which could lead to privilege escalation.

Versions

Vulnerable versions include:

FreeBSD >= 2.2.0, NetBSD >= 1.3 and OpenBSD >= 2.6

Impact

Serious.

Local users can elevate their privileges.

Description

The shmat(2) function maps a shared memory segment, previously
created with the shmget(2) function, into the address space of
the calling process.

This function is implemented in the sysv_shm.c file:

-- sysv_shm.c lines 317-322 --


vm_object_reference(shm_handle->shm_object);

rv = vm_map_find(&p->p_vmspace->vm_map,
shm_handle->shm_object,
0, &attach_va, size,
(flags & MAP_FIXED) ? 0 : 1,
prot, prot, 0);

if (rv != KERN_SUCCESS) return ENOMEM;


-- end of code snippet --

The shmat(2) function first increases the reference count on
the underlying vm_object and then attempts to insert the
vm_object into the process address space.

The vulnerability occurs because the shmat(2) function forgets
to decrease the reference count when the vm_map_find function
returns failure.

Since the caller of shmat(2) can specify the address at which
the segment should be mapped it is possible to have vm_map_find
return failure and thus end up with stale references.

Exploitability

This vulnerability can exploited (reliably) by local users:

One would first create a shared memory segment using the shmget(2)
function and create two seperate mappings at different locations
in the process address space using the shmat(2) function.

After making around 2^32-2 (invalid) calls to the shmat(2)
function the reference count of the underlying vm_object
will wraparound to 1.

After deleting one of our mappings using the shmdt(2) function
the underlying vm_object will be freed and we will still have
one (extranous) mapping hanging around.

One would then invoke some magic trickery and execute a suid
binary which will reuse the freed vm_object for its stack
segment.

At this point one could write directly into the stack segment
of the suid binary (using the extranous mapping) and thus
escalate ones privileges easily.

Disclaimer

Pine Digital Security does not release exploits.

Patches

The various CVS repositories should be updated.

References

FreeBSD-SA-04:02.shmat.asc

http://www.pine.nl/press/pine-cert-20040201.txt

http://cve.mitre.org/cgi-bin/cvename.cgi?name=can-2004-0114

file://usr/src/sys/kern/sysv_shm.c
file://usr/src/sys/vm/vm_object.c
file://usr/src/sys/vm/vm_map.c
Login or Register to add favorites

File Archive:

April 2024

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