[UNIX] Multiple Vulnerabilities in Old Releases of MIT Kerberos

From: support@securiteam.com
Date: 01/29/03

  • Next message: support@securiteam.com: "[UNIX] New YabbSE Remote Code Execution Vulnerability Found (News.php)" 
    From: support@securiteam.com
To: list@securiteam.com
Date: 29 Jan 2003 16:21:08 +0200

    The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
    - - promotion

    Beyond Security would like to welcome Tiscali World Online
    to our service provider team.
    For more info on their service offering IP-Secure,
    please visit http://www.worldonline.co.za/services/work_ip.asp
    - - - - - - - - -

      Multiple Vulnerabilities in Old Releases of MIT Kerberos
    ------------------------------------------------------------------------

    SUMMARY

    Multiple vulnerabilities have been found in MIT Kerberos 5 releases prior
    to release 1.2.5. MIT recommends updating to 1.2.7 if possible.

    DETAILS

    Vulnerable systems:
     * All releases of MIT Kerberos 5 before 1.2.5

    Immune systems:
     * All releases of MIT Kerberos 5 after and including 1.2.7.

    Impact:
     * A remote user can crash the KDC.
     * A user authenticated in a remote realm may be able to claim to be other
    non-local users to an application server.
     * It may be possible for a user to gain access to the KDC system and
    database.

    Fix:
    MIT recommends updating to release 1.2.5 or later, preferably to the
    latest release. Patches specifically to fix these problems are not
    available at this time.

    This announcement and related security advisories may be found on the MIT
    Kerberos security advisory page at:
    <http://web.mit.edu/kerberos/www/advisories/index.html>
    http://web.mit.edu/kerberos/www/advisories/index.html

    The main MIT Kerberos web page is at:
    <http://web.mit.edu/kerberos/www/index.html>
    http://web.mit.edu/kerberos/www/index.html

    Technical details:
    Problem 1: KDC null pointer dereferences
    Certain protocol requests, compliant with the protocol encoding scheme but
    indicative of a client system most likely configured incorrectly, can
    crash a KDC with a null pointer dereference. MIT does not believe any
    exploit to gain access to the KDC or otherwise alter its behavior is
    possible on systems without storage mapped at address zero. MIT has not
    explored the effects of this on a system with mapped memory at address
    zero.

    The fallback and retransmit algorithm used in the MIT krb5 library will
    cause an application not receiving a reply from a KDC to try other KDCs in
    the same realm; it will iterate through this list a few times, or until it
    gets a response. Thus, one client may take down multiple KDCs.

    MIT believes this vulnerability is limited to the TGS-REQ exchange, that
    is, cases where the user has already authenticated to the KDC or one with
    which it shares inter-realm keys. So (ignoring cases of well-known
    passwords) there is an audit trail of sorts, even if it has to be dug out
    of a core file, and it is not a simple, scriptable attack against KDCs in
    general.

    Workarounds:
     - Start your KDC from inittab or a loop in a shell script. (The inittab
    approach may not work well if the KDC is crashed too often in a short span
    of time.)

    Thanks to <mailto:GregPryzby@aol.com> greg pryzby for reporting this
    problem.

    Problem 2: realm transit checks
    Realms with shared keys can impersonate people in other non-local realms
    in certain cases. It may be exploitable in various ways if non-local
    principal names are on critical ACLs.

    This vulnerability affects both the KDC and Kerberos application servers.

    This problem was fixed in the 1.2.3 release. That release also added a
    flag to the KDC config file that can be set to refuse untrusted
    cross-realm authentication, in case application servers cannot be updated
    quickly enough. This is not recommended as a long-term solution, because
    the current model MIT use says that the application server is responsible
    for doing this validation, which allows (for example) a service on a
    specific machine (perhaps one set up for software testing) to be
    configured to know about authentication paths known to the maintainer of
    the service, even if the maintainer of the KDC does not trust these paths
    for general use within the realm. Enforcing this limitation in the KDC
    takes this option away from the maintainers of individual machines.

    Workarounds:
     - Delete or change inter-realm keys so inter-realm authentication is
    disabled.
     - Remove all non-local principals from all critical ACLs in services
    using old MIT Kerberos code to validate the realm transit path

    Thanks to <mailto:seph@mit.edu> Joseph Sokol-Margolis and
    <mailto:gbritton@alum.mit.edu> Gerald Britton for finding this problem.

    Problem 3: format strings
    Older versions of the MIT KDC used strings containing Kerberos principal
    names as printf-style format strings in logging routines.

    At least some cases do not require successful authentication, so this can
    be used as a remote, anonymous attack.

    It is easy to crash the KDC with this exploit. MIT does not know of any
    exploits to gain access to the host system, but MIT does not rule out the
    possibility.

    Workarounds:
    See under problem 1. ***However, these do not address the host access
    possibility.***

    Thanks to <mailto:ellidz@eridu.uchicago.edu> E. Larry Lidz for
    discovering this problem.

    Problem 4: bounds checking on data sizes
    Some of our code does not do bounds checking on lengths before allocating
    storage. On some systems, attempting to allocate large negative amounts of
    storage can crash the program. Thus, some bogus packets may crash the KDC
    or an application server using Kerberos. MIT does not believe this can be
    exploited to gain access to the host system.

    Workarounds:
     - Start KDC in a loop in a script, or from inittab
     - Do likewise for any server processes that need to handle multiple
    client connections

    Thanks to CERT for bringing this to our attention.

    ADDITIONAL INFORMATION

    The information has been provided by <mailto:raeburn@MIT.EDU> Ken
    Raeburn.

    ========================================

    This bulletin is sent to members of the SecuriTeam mailing list.
    To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

    ====================
    ====================

    DISCLAIMER:
    The information in this bulletin is provided "AS IS" without warranty of any kind.
    In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

    Relevant Pages