UPDATED: MITKRB5-SA-2006-001: multiple local privilege escalationvulnerabilities - Kerberos

This is a discussion on UPDATED: MITKRB5-SA-2006-001: multiple local privilege escalationvulnerabilities - Kerberos ; -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 MIT krb5 Security Advisory 2006-001 Original release: 2006-08-08 Last update: 2006-08-16 Topic: multiple local privilege escalation vulnerabilities Severity: serious SUMMARY ======= [patch corrected since original release] In certain application programs packaged in the MIT ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: UPDATED: MITKRB5-SA-2006-001: multiple local privilege escalationvulnerabilities

  1. UPDATED: MITKRB5-SA-2006-001: multiple local privilege escalationvulnerabilities

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

    MIT krb5 Security Advisory 2006-001

    Original release: 2006-08-08
    Last update: 2006-08-16

    Topic: multiple local privilege escalation vulnerabilities

    Severity: serious

    SUMMARY
    =======

    [patch corrected since original release]

    In certain application programs packaged in the MIT Kerberos 5 source
    distribution, calls to setuid() and seteuid() are not always checked
    for success. A local user could exploit one of these vulnerabilities
    to result in privilege escalation. No exploit code is known to exist
    at this time. It is believed that the primary risk is to Linux
    systems, due to the behavior of their implementation of the setuid()
    and seteuid() system calls.

    IMPACT
    ======

    Actual impact depends on implementation details within a specific
    operating system. Vulnerabilities result when the OS implementations
    of setuid() or seteuid() can fail due to resource exhaustion when
    changing to an unprivileged user ID. We believe that only unchecked
    calls to setuid(), and not calls to seteuid(), are vulnerable on
    Linux.

    On AIX, Kerberos applications provided by IBM are not vulnerable. If,
    in place of or in addition to IBM-provided Kerberos applications, MIT
    krb5 code is installed on an AIX system, the affected MIT krb5
    applications are vulnerable to the setuid() issues listed in
    CVE-2006-3083. We believe that no other operating systems are
    affected.

    [CVE-2006-3083, VU#580124] The following vulnerabilities may result
    from unchecked calls to setuid(), and are believed to only exist on
    Linux and AIX:

    * Unchecked calls to setuid() in krshd may allow a local privilege
    escalation leading to execution of programs as root.

    * Unchecked calls to setuid() in the v4rcp may allow a local privilege
    escalation leading to reading, writing, or creating files as root.
    v4rcp is the remote end of a krb4-authenticated rcp operation, but
    may be executed directly by an attacker, as it is a setuid program.

    [CVE-2006-3084, VU#401660] The following vulnerabilities may result
    from unchecked calls to seteuid(). These vulnerabilities are not yet
    known to exist on any operating system:

    * Unchecked calls to seteuid() in ftpd may allow a local privilege
    escalation leading to reading, writing, or creating files as root.

    * Unchecked calls to seteuid() in the ksu program may allow a local
    privilege escalation resulting in filling a file with null bytes as
    root and then deleting it (the "kdestroy" operation).

    AFFECTED SOFTWARE
    =================

    * The above-listed programs are vulnerable in all releases of MIT
    krb5, up to and including krb5-1.5. The krb5-1.5.1 and krb5-1.4.4
    releases will contain fixes for these problems.

    FIXES
    =====

    * The upcoming krb5-1.5.1 and krb5-1.4.4 releases will include fixes
    for these vulnerabilities.

    * Disable krshd and ftpd, and remove the setuid bit from the ksu
    binary and the v4rcp binary.

    * For the krb5-1.5 release, apply the patch at

    http://web.mit.edu/kerberos/advisori...-patch_1.5.txt

    A PGP-signed version of this patch is at

    http://web.mit.edu/kerberos/advisori...ch_1.5.txt.asc

    This patch was generated against the krb5-1.5 release, and may apply
    to earlier releases with some fuzz. The patch also updates some
    calls to other setuid-like system calls on less-common operating
    systems, though these calls are less likely to be vulnerable.

    Note that the original version of this patch contained an error in
    the patch to ksu which introduced a minor bug; this erroneous ksu
    patch may be identified by diff header
    "*** clients/ksu/main.c (revision 18419)"

    * For the krb5-1.4.3 release, apply the patch at

    http://web.mit.edu/kerberos/advisori...atch_1.4.3.txt

    A PGP-signed version of this patch is at

    http://web.mit.edu/kerberos/advisori...atch_1.4.3.txt

    This patch was generated against the krb5-1.4.3 release, and may apply
    to earlier releases with some fuzz. The patch also updates some
    calls to other setuid-like system calls on less-common operating
    systems, though these calls are less likely to be vulnerable.

    Note that the original version of this patch contained an error in
    the patch to ksu which introduced a minor bug; this erroneous ksu
    patch may be identified by diff header
    "*** clients/ksu/main.c (revision 18419)"

    REFERENCES
    ==========

    This announcement and related security advisories may be found on the
    MIT Kerberos security advisory page at:

    http://web.mit.edu/kerberos/advisories/index.html

    The main MIT Kerberos web page is at:

    http://web.mit.edu/kerberos/index.html

    CVE: CVE-2006-3083
    http://cve.mitre.org/cgi-bin/cvename...=CVE-2006-3083

    CERT: VU#580124
    http://www.kb.cert.org/vuls/id/580124

    CVE: CVE-2006-3084
    http://cve.mitre.org/cgi-bin/cvename...=CVE-2006-3084

    CERT: VU#401660
    http://www.kb.cert.org/vuls/id/401660

    ACKNOWLEDGMENTS
    ===============

    Thanks to Michael Calmer and Marcus Meissner at SUSE for reporting
    this problem.

    Thanks to Shiva Persaud at IBM for information on AIX.

    Thanks to Sachin Punadikar for reporting the error in the ksu patch.

    DETAILS
    =======

    Typically, setuid(), seteuid(), and similar system calls cannot fail
    except in cases of inadequate privilege or system misconfiguration.
    Unlike other operating systems, Linux and AIX system calls which
    change the real user ID can fail if the change would cause the target
    user ID to exceed its quota of allowed processes. A local attacker
    may be able to exhaust a process quota in a way which artificially
    creates such a failure condition. This may result in privilege
    escalation when a program making an unchecked call to one of these
    system calls expects to continue execution with reduced privilege
    following the affected call, but instead continues to run as a
    privileged user.

    Specific places where various system calls are not checked include:

    appl/bsd/krcp.c: setreuid (uncompiled code), setuid (irrelevant
    because not installed setuid)
    appl/bsd/krshd.c: setuid
    appl/bsd/krsh.c: setuid (irrelevant because not installed setuid)
    appl/bsd/v4rcp.c: setuid
    appl/gssftp/ftpd/ftpd.c: seteuid
    client/ksu/main.c: seteuid
    lib/krb4/kuserok.c: seteuid (but likely irrelevant)

    REVISION HISTORY
    ================

    2006-08-16 updated patch to correct ksu error
    2006-08-08 original release

    Copyright (C) 2006 Massachusetts Institute of Technology
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.3 (SunOS)

    iQCVAwUBROOaEKbDgE/zdoE9AQJJpwP/ZLA21YIZuGU9wuJeYiRM9QdvnMZE/+My
    xY1FeWPVx6puQ1Zkh12Vn30gQH8a6ZnFjunAlkx0TQjUM9iqtl A9PUwjwBYCywcm
    p6qdS91ESpgqsYoDZVDajqxDhvlWyEYfsT8vzfcep+BGG2iqIi cdvz95n9HuwRKG
    rWIgVg83BLM=
    =jv57
    -----END PGP SIGNATURE-----
    _______________________________________________
    kerberos-announce mailing list
    kerberos-announce@mit.edu
    https://mailman.mit.edu/mailman/list...beros-announce
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. Creation of principal without password

    Is it possible to create a principal without password in kerberos? Thank
    you.

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  3. Re: Creation of principal without password

    a principal witout its associated password would be pointless for
    kerberos since that account would not be able to use tickets that by
    definition are encrypted with a key based on said accounts password.

    i.e. no

    On 8/17/06, Fariba wrote:
    > Is it possible to create a principal without password in kerberos? Thank
    > you.
    >
    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos
    >

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  4. Re: Creation of principal without password

    Fariba wrote:
    > Is it possible to create a principal without password in kerberos? Thank
    > you.


    You can create a principal with a random key (password) by using the
    -randkey option (i.e. in kadmin, 'addprinc -randkey user'). You can
    then extract this to a keytab, and use the keytab to authorise the user.

    Note also that if you create a principal & set the password, then
    extract this principal to a keytab using 'ktadd', the key is randomised
    in the process (so your previous password will no longer work).

    I think (not sure!) you *can* also set an empty password, if your
    policies are appropriate, but that would be somewhat insecure!

    The manpage for kadmin is helpful.


    Juliet

    --
    ++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++
    + Ms Juliet Kemp +
    + Computer Manager star@imperial.ac.uk +
    + Astrophysics Group +
    + Imperial College Tel: +44 (0)20759 47538 +
    + London. SW7 2AZ Fax: +44 (0)20759 47541 +
    ++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  5. Re: Creation of principal without password

    (PLEASE don't include kerberos-announce in the recipient list on
    queries. It's just more work for us to go delete the messages from
    the moderation queue.)

    On Aug 17, 2006, at 06:07, ronnie sahlberg wrote:
    > a principal witout its associated password would be pointless for
    > kerberos since that account would not be able to use tickets that by
    > definition are encrypted with a key based on said accounts password.


    Not at all... a keytab file could be generated to store the key
    directly, without using a password. In fact, in the MIT
    implementation, this is the normal case for server principals.

    Theoretically, if you separated the "create principal" and "set
    password" privileges into different groups of admins, you could
    create a new account for a new hire, or an incoming group of
    students, or whatever (assuming your local policy dictates how
    principal names are formed, and doesn't give the users the option),
    with a random key, and then let a less-privileged administrator set
    the password for the user later. Offhand I don't know of anyone who
    does it this way, but you *could*...

    Ken
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  6. Re: Creation of principal without password

    On Aug 17, 2006, at 12:20, Fariba wrote:
    > Thank you and others for replying. If we use the randkey option to
    > create the principal and do not transfer it to the keytab (if you
    > transfer it to the keytab, I assume anyone typing the username is
    > authenticated, so it is nor secure), is there a way to set the real
    > password? Using k_chpass requires the knowledge of the old
    > password, which when it is random we do not know it . Unless we can
    > set the password to known string (even null) for the users, I do
    > not see an alternative. I think I am answering myself. Seems like
    > you cannot use kerberos just to store the users and later add their
    > passwords. Any thoughts?


    You'd need some sort of administrator access, either through the
    kadmin protocol, or the set/change password protocol being worked on
    in the IETF.

    Ken


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  7. Re: Creation of principal without password

    Thank you and others for replying. If we use the randkey option to
    create the principal and do not transfer it to the keytab (if you
    transfer it to the keytab, I assume anyone typing the username is
    authenticated, so it is nor secure), is there a way to set the real
    password? Using k_chpass requires the knowledge of the old password,
    which when it is random we do not know it . Unless we can set the
    password to known string (even null) for the users, I do not see an
    alternative. I think I am answering myself. Seems like you cannot use
    kerberos just to store the users and later add their passwords. Any
    thoughts?
    Ken Raeburn wrote:
    >
    >
    > On Aug 17, 2006, at 06:07, ronnie sahlberg wrote:
    >> a principal witout its associated password would be pointless for
    >> kerberos since that account would not be able to use tickets that by
    >> definition are encrypted with a key based on said accounts password.

    >
    > Not at all... a keytab file could be generated to store the key
    > directly, without using a password. In fact, in the MIT
    > implementation, this is the normal case for server principals.
    >
    > Theoretically, if you separated the "create principal" and "set
    > password" privileges into different groups of admins, you could create
    > a new account for a new hire, or an incoming group of students, or
    > whatever (assuming your local policy dictates how principal names are
    > formed, and doesn't give the users the option), with a random key, and
    > then let a less-privileged administrator set the password for the user
    > later. Offhand I don't know of anyone who does it this way, but you
    > *could*...
    >
    > Ken


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  8. Re: Creation of principal without password

    Could you elaborate on that?
    Ken Raeburn wrote:
    > On Aug 17, 2006, at 12:20, Fariba wrote:
    >> Thank you and others for replying. If we use the randkey option to
    >> create the principal and do not transfer it to the keytab (if you
    >> transfer it to the keytab, I assume anyone typing the username is
    >> authenticated, so it is nor secure), is there a way to set the real
    >> password? Using k_chpass requires the knowledge of the old
    >> password, which when it is random we do not know it . Unless we can
    >> set the password to known string (even null) for the users, I do not
    >> see an alternative. I think I am answering myself. Seems like you
    >> cannot use kerberos just to store the users and later add their
    >> passwords. Any thoughts?

    >
    > You'd need some sort of administrator access, either through the
    > kadmin protocol, or the set/change password protocol being worked on
    > in the IETF.
    >
    > Ken
    >
    >


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  9. Re: Creation of principal without password

    Fariba writes:

    > Thank you and others for replying. If we use the randkey option to
    > create the principal and do not transfer it to the keytab (if you
    > transfer it to the keytab, I assume anyone typing the username is
    > authenticated, so it is nor secure), is there a way to set the real
    > password?


    I'm not sure I'm following quite what you're talking about here, but
    there's no difference to Kerberos whether you put the key in a keytab or
    not. -randkey is -randkey; either way, the key is randomized in the KDC.
    If you don't write that key to a keytab, no one's going to be able to
    authenticate to that user unless they can get at the KDC database somehow
    to get the key. If you do write it to a keytab, anyone who has access to
    that keytab can read the key from it and authenticate; anyone else will be
    in the same position.

    There's nothing about writing a key to a keytab that would allow "anyone
    typing in the username" to authenticate.

    --
    Russ Allbery (rra@stanford.edu)

  10. Re: Creation of principal without password

    Fariba writes:

    > Could you elaborate on that?


    In order to change the key of a principal, you need administrative access
    to the KDC database, either through kadmin.local, the kadmin network
    protocol, or something like the password change protocol (which is only
    semi-standardized).

    --
    Russ Allbery (rra@stanford.edu)

  11. Re: Creation of principal without password

    On Aug 17, 2006, at 12:38, Fariba wrote:
    > Could you elaborate on that?
    > Ken Raeburn wrote:
    >> You'd need some sort of administrator access, either through the
    >> kadmin protocol, or the set/change password protocol being worked on
    >> in the IETF.


    An administrator could change the password with kadmin's "cpw" command.

    This is roughly the use case I had in mind: At a school, a registrar
    creates accounts (including Kerberos principals) for use by the
    students in a class, with names constructed like identifier>, e.g., c101_12, with random keys (or, if
    we allowed it, with no keys). The realm is shared across a bunch of
    classes. The instructors for the class are given the ability to
    change passwords for accounts, but not to create new accounts. After
    the first class, each student meets with the instructor or teaching
    assistants, gets assigned an account id, and picks a password which
    is set on the principal then and there by the instructor. Probably
    not the most convenient way of doing it, compared to, say, having the
    registrar assign initial passwords and require that the passwords be
    changed immediately, but it would work.


    Another no-password case would be PKINIT; if the initial tickets are
    always acquired via PKINIT, there's no need for a password.

    Ken
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  12. Re: Creation of principal without password

    Your case is a good example. How do you allow principal creation with no
    random keys? I hope this means with no password as well. Also with
    PKINIT, it is window's specific. right? And still user needs to have the
    password set first and then PKINIT comes to picture. right? As admin we
    want to create the users via a process and when user tries to login to
    our system, it is asked to set its password and our admin process will
    set the password in kerberos for them. But it seems kerberos cannot be a
    place holder for username without password!? And if somehow it is how
    does it handle when it comes to authentication? I see its chpassword
    needs old and new password to be specified. Even if it lets you to say
    the old password is null and does not return an error, then it is a
    security hole, since anybody with that username and null password can
    authenticate!? Thank you.

    Ken Raeburn wrote:
    > An administrator could change the password with kadmin's "cpw" command.
    >
    > This is roughly the use case I had in mind: At a school, a registrar
    > creates accounts (including Kerberos principals) for use by the
    > students in a class, with names constructed like > identifier>, e.g., c101_12, with random keys (or, if
    > we allowed it, with no keys). The realm is shared across a bunch of
    > classes. The instructors for the class are given the ability to
    > change passwords for accounts, but not to create new accounts. After
    > the first class, each student meets with the instructor or teaching
    > assistants, gets assigned an account id, and picks a password which is
    > set on the principal then and there by the instructor. Probably not
    > the most convenient way of doing it, compared to, say, having the
    > registrar assign initial passwords and require that the passwords be
    > changed immediately, but it would work.
    >
    >
    > Another no-password case would be PKINIT; if the initial tickets are
    > always acquired via PKINIT, there's no need for a password.
    >
    > Ken


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  13. Re: Creation of principal without password

    > How do you allow principal creation with no random keys? I hope
    > this means with no password as well.


    At the moment, I don't think it's possible in the MIT code. But with
    PKINIT, we may want to change that.

    > Also with PKINIT, it is window's specific. right?


    Um, no, but MIT isn't shipping an implementation yet.

    > And still user needs to have the password set first and then PKINIT
    > comes to picture. right?


    At least in theory, no; if you present a certificate and proof that
    you have the key, you get your Kerberos credentials. (Well, subject
    to a bunch of other constraints, but not involving having a separate
    Kerberos key or password.)

    > As admin we want to create the users via a process and when user
    > tries to login to our system, it is asked to set its password and
    > our admin process will set the password in kerberos for them. But
    > it seems kerberos cannot be a place holder for username without
    > password!? And if somehow it is how does it handle when it comes to
    > authentication?


    If you created a placeholder account and set the password later,
    you'd need to set the password via some privileged process (such as
    having an administrator do it with their credentials), ideally after
    using some other verification system (like looking at the user's
    government-issued identification). My point was that different
    administrators might have different privileges, with some being able
    to set passwords on certain previously-created accounts but not
    allowed to create them; then the "placeholder" functionality would
    make sense, but there'd be little use for a password or even a random
    key (with the approach I described).

    > I see its chpassword needs old and new password to be specified.
    > Even if it lets you to say the old password is null and does not
    > return an error, then it is a security hole, since anybody with
    > that username and null password can authenticate!?


    You'd have to have the right privileges to set the password on a
    principal without having the old password. It wouldn't be allowed
    for random users.

    Ken
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


+ Reply to Thread