Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
From: FreeBSD Security Advisories (security-advisoriesfreebsd.org)
Date: Mon Apr 22 2002 - 13:01:35 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]


    FreeBSD-SA-02:23.stdio Security Advisory
                                                              The FreeBSD Project

    Topic: insecure handling of stdio file descriptors

    Category: core
    Module: kernel
    Announced: 2002-04-22
    Credits: Joost Pol <joostpine.nl>
    Affects: All releases of FreeBSD up to and including 4.5-RELEASE
                    4.5-STABLE prior to the correction date
    Corrected: 2002-04-21 13:06:45 UTC (RELENG_4)
                    2002-04-21 13:08:57 UTC (RELENG_4_5)
                    2002-04-21 13:10:51 UTC (RELENG_4_4)
    FreeBSD only: NO

    I. Background

    By convention, POSIX systems associate file descriptors 0, 1, and 2
    with standard input, standard output, and standard error,
    respectively. Almost all applications give these stdio file
    descriptors special significance, such as writing error messages to
    standard error (file descriptor 2).

    In new processes, all file descriptors are duplicated from the parent
    process. Unless these descriptors are marked close-on-exec, they
    retain their state during an exec.

    All POSIX systems assign file descriptors in sequential order,
    starting with the lowest unused file descriptor. For example, if a
    newly exec'd process has file descriptors 0 and 1 open, but file
    descriptor 2 closed, and then opens a file, the new file descriptor is
    guaranteed to be 2 (standard error).

    II. Problem Description

    Some programs are set-user-id or set-group-id, and therefore run with
    increased privileges. If such a program is started with some of the
    stdio file descriptors closed, the program may open a file and
    inadvertently associate it with standard input, standard output, or
    standard error. The program may then read data from or write data to
    the file inappropriately. If the file is one that the user would
    normally not have privileges to open, this may result in an
    opportunity for privilege escalation.

    III. Impact

    Local users may gain superuser privileges. It is known that the
    `keyinit' set-user-id program is exploitable using this method. There
    may be other programs that are exploitable.

    IV. Workaround

    None. The set-user-id bit may be removed from `keyinit' using the
    following command, but note that there may be other programs that can
    be exploited.

    # chmod 0555 /usr/bin/keyinit

    V. Solution

    1) Upgrade your vulnerable system to 4.5-STABLE; or to either of the
    RELENG_4_5 (4.5-RELEASE-p4) or RELENG_4_4 (4.4-RELEASE-p11) security
    branches dated after the respective correction dates.

    2) To patch your present system:

    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-02:23/stdio.patch
    # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-02:23/stdio.patch.asc

    b) Execute the following commands as root:

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

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

    VI. Correction details

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

    Path Revision
    - -------------------------------------------------------------------------
    - -------------------------------------------------------------------------

    VII. References

    PINE-CERT-20020401 <URL:http://www.pine.nl/advisories/pine-cert-20020401.txt>
    Version: GnuPG v1.0.6 (FreeBSD)
    Comment: For info see http://www.gnupg.org

    -----END PGP SIGNATURE-----

    To Unsubscribe: send mail to majordomoFreeBSD.org
    with "unsubscribe freebsd-security" in the body of the message