FreeBSD Security Advisory FreeBSD-SA-04:02.shmat

From: FreeBSD Security Advisories (security-advisories_at_freebsd.org)
Date: 02/05/04

  • Next message: Colin Percival: "Re: FreeBSD Security Advisory FreeBSD-SA-04:02.shmat"
    Date: Thu, 5 Feb 2004 10:40:35 -0800 (PST)
    To: FreeBSD Security Advisories <security-advisories@freebsd.org>
    
    

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    =============================================================================
    FreeBSD-SA-04:02.shmat Security Advisory
                                                              The FreeBSD Project

    Topic: shmat reference counting bug

    Category: core
    Module: kernel
    Announced: 2004-02-05
    Credits: Joost Pol <joost@pine.nl>
    Affects: All FreeBSD releases
    Corrected: 2004-02-04 18:00:40 UTC (RELENG_4)
                    2004-02-04 18:00:47 UTC (RELENG_5_2, 5.2-RELEASE-p2)
                    2004-02-04 18:00:55 UTC (RELENG_5_1, 5.1-RELEASE-p14)
                    2004-02-04 18:01:03 UTC (RELENG_5_0, 5.0-RELEASE-p20)
                    2004-02-04 18:01:10 UTC (RELENG_4_9, 4.9-RELEASE-p2)
                    2004-02-04 18:01:18 UTC (RELENG_4_8, 4.8-RELEASE-p15)
                    2004-02-04 18:01:25 UTC (RELENG_4_7, 4.7-RELEASE-p25)
    CVE Name: CAN-2004-0114
    FreeBSD only: NO

    I. Background

    The System V Shared Memory interface provides primitives for sharing
    memory segments between separate processes. FreeBSD supports this
    interface when the kernel is built with SYSVSHM option, or the sysvshm
    module is loaded. By default, the FreeBSD kernel is built with the
    SYSVSHM option.

    The shmat(2) system call, which is part of the System V Shared Memory
    interface, is used to attach a shared memory segment to the calling
    process's address space.

    II. Problem Description

    A programming error in the shmat(2) system call can result in a shared
    memory segment's reference count being erroneously incremented.

    III. Impact

    It may be possible to cause a shared memory segment to reference
    unallocated kernel memory, but remain valid. This could allow a local
    attacker to gain read or write access to a portion of kernel memory,
    resulting in sensitive information disclosure, bypass of access
    control mechanisms, or privilege escalation.

    IV. Workaround

    NOTE: These workarounds could cause applications that use shared
    memory, such as the X Window System, to exhibit erratic behavior or to
    fail completely.

    Do one of the following:

    1) Disable the System V Shared Memory interface entirely by following
    these steps:

       - Remove or comment out any lines mentioning `SYSVSHM' from your
         kernel configuration file, and recompile your kernel as described
         in <URL:http://www.freebsd.org/handbook/kernelconfig.html>.

       - Remove or comment out any lines mentioning `sysvshm' from
         /boot/loader.conf and /etc/rc.conf.

       - On FreeBSD 5.x systems only , System V Shared Memory support may
         be provided as a kld(4). To be absolutely safe, remove any files
         named `sysvshm.ko' in /modules, /boot, and any subdirectories.

       - Finally, reboot your system.

    OR

    2) Configure the System V Shared Memory parameters so that no new
    shared memory segments may be created, terminate all processes using
    shared memory, and delete all existing shared memory segments. Run
    the following commands as root:

       # sysctl -w kern.ipc.shmmax=0
       # echo 'kern.ipc.shmmax=0' >> /etc/sysctl.conf
       # ipcs | awk '/^m/ { print $2 }' | xargs -n 1 ipcrm -m

    V. Solution

    Do one of the following:

    1) Upgrade your vulnerable system to 4-STABLE, or to the RELENG_5_2,
    RELENG_5_1, RELENG_4_9, or RELENG_4_8 security branch dated after the
    correction date.

    NOTE WELL: Due to release engineering in progress at the time of this
               writing, the RELENG_5_2 security branch (5.2-RELEASE-p2)
               also includes numerous other critical bug fixes, most of
               which are not security related. Please read src/UPDATING
               for details on these changes.

    OR

    2) Patch your present system:

    The following patch has been verified to apply to FreeBSD 4.x and 5.x
    systems.

    a) Download the relevant patch from the location below, and verify the
    detached PGP signature using your PGP utility.

    # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:02/shmat.patch
    # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:02/shmat.patch.asc

    b) Apply the patch.

    # cd /usr/src
    # patch < /path/to/patch

    c) Recompile your kernel as described in
    <URL:http://www.freebsd.org/handbook/kernelconfig.html> and reboot the
    system.

    VI. Correction details

    The following list contains the revision numbers of each file that was
    corrected in FreeBSD.

    Path Revision
      Branch
    - -------------------------------------------------------------------------
    RELENG_4
      src/sys/kern/sysv_shm.c 1.45.2.8
    RELENG_5_2
      src/UPDATING 1.282.2.5
      src/sys/conf/newvers.sh 1.56.2.5
      src/sys/kern/sysv_shm.c 1.89.2.1
    RELENG_5_1
      src/UPDATING 1.251.2.15
      src/sys/conf/newvers.sh 1.50.2.15
      src/sys/kern/sysv_shm.c 1.83.2.1
    RELENG_5_0
      src/UPDATING 1.229.2.26
      src/sys/conf/newvers.sh 1.48.2.21
      src/sys/kern/sysv_shm.c 1.74.2.1
    RELENG_4_9
      src/UPDATING 1.73.2.89.2.3
      src/sys/conf/newvers.sh 1.44.2.32.2.3
      src/sys/kern/sysv_shm.c 1.45.2.6.4.1
    RELENG_4_8
      src/UPDATING 1.73.2.80.2.18
      src/sys/conf/newvers.sh 1.44.2.29.2.16
      src/sys/kern/sysv_shm.c 1.45.2.6.2.1
    RELENG_4_7
      src/UPDATING 1.73.2.74.2.29
      src/sys/conf/newvers.sh 1.44.2.26.2.27
      src/sys/kern/sysv_shm.c 1.45.2.5.6.1
    - -------------------------------------------------------------------------

    VII. References

    <URL:http://www.pine.nl/press/pine-cert-20040201.txt>
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.4 (FreeBSD)

    iD8DBQFAIocaFdaIBMps37IRAtO8AJ9pP86snAwE67qdkwsat1CoJ+gFGACeJLtU
    PjD0jexX+1QaN7q2JvgVXmc=
    =IEvj
    -----END PGP SIGNATURE-----
    _______________________________________________
    freebsd-security@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-security
    To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"


  • Next message: Colin Percival: "Re: FreeBSD Security Advisory FreeBSD-SA-04:02.shmat"

    Relevant Pages

    • [Full-Disclosure] FreeBSD Security Advisory FreeBSD-SA-04:02.shmat
      ... FreeBSD only: NO ... the FreeBSD kernel is built with the ... which is part of the System V Shared Memory ... shared memory segments may be created, ...
      (Full-Disclosure)
    • [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-04:02.shmat
      ... FreeBSD only: NO ... the FreeBSD kernel is built with the ... which is part of the System V Shared Memory ... shared memory segments may be created, ...
      (freebsd-announce)
    • FreeBSD Security Advisory FreeBSD-SA-04:02.shmat
      ... FreeBSD only: NO ... the FreeBSD kernel is built with the ... which is part of the System V Shared Memory ... shared memory segments may be created, ...
      (Bugtraq)
    • Kernel [memory] tweaking question
      ... I'm doing some tweaking on my kernel tonight (FreeBSD 5.3) and I'm trying to get ... I understand these control shared memory and how many semaphores the kernel can ... In other words, for something like Apache, how much shared ...
      (freebsd-hackers)
    • Re: semaphores between processes
      ... We're designing some software which has to lock access to ... shared memory pages between several processes, ... run on Linux, Solaris, and FreeBSD. ... We then moved on to posix semaphores. ...
      (freebsd-hackers)