there are 3 security problems. 1 is tracked in the other bug, 2 are here:

From: Mark J Cox <mjc@redhat.com>
To: vendor-sec@lst.de
Subject: Re: [vendor-sec] Announce: OpenSSH 4.4 released (fwd)
Errors-To: vendor-sec-admin@lst.de
Date: Wed, 27 Sep 2006 23:36:31 +0100 (BST)

Mitre gave me:

>>  * Fix an unsafe signal hander reported by Mark Dowd.
>Use CVE-2006-5051 but please coordinate this with ISS.

>>  * On portable OpenSSH, fix a GSSAPI authentication abort that could
>>    be used to determine the validity of usernames on some platforms.
>Use CVE-2006-5052

We will merge the last update and this one.

I have submitted new patchinfos.

From: Markus Friedl <markus.r.friedl@arcor.de>
To: Josh Bressers <bressers@redhat.com>
Cc: Damien Miller <djm@cvs.openbsd.org>, vendor-sec@lst.de
Subject: Re: [vendor-sec] Announce: OpenSSH 4.4 released
User-Agent: Mutt/1.4.2i
Errors-To: vendor-sec-admin@lst.de
Date: Thu, 28 Sep 2006 11:11:15 +0200

On Wed, Sep 27, 2006 at 07:33:51PM -0400, Josh Bressers wrote:
> Hi Damien,
>
> I'm wondering if you can offer some clarification to these two issues (I'd
> gladly take some clarification from anyone on vendor-sec too).  I'm not
> familiar enough with the openssh code to easily figure these out.
>
> >
> >  * Fix an unsafe signal hander reported by Mark Dowd. The signal
> >    handler was vulnerable to a race condition that could be exploited
> >    to perform a pre-authentication denial of service. On portable
> >    OpenSSH, this vulnerability could theoretically lead to
> >    pre-authentication remote code execution if GSSAPI authentication
> >    is enabled, but the likelihood of successful exploitation appears
> >    remote.
>
> I'm wondering why this only affects GSSAPI, and beyond that, does GSSAPI
> authentication have to be enabled and working, or is having
> "GSSAPIAuthentication yes" in the configuration file enough for this to be
> triggered?

it might be possible that this codes get triggered:

#ifdef KRB5
        if (options.kerberos_ticket_cleanup &&
            authctxt->krb5_ctx)
                krb5_cleanup_proc(authctxt);
#endif
#ifdef GSSAPI
        if (compat20 && options.gss_cleanup_creds)
                ssh_gssapi_cleanup_creds();
#endif

before kerberos/gssapi contexts are setup properly.  the cleanup
code might act on undefined state.  however, we have not checked   
all details of the kerberos/gssapi libraries.

-m

From: "Ralf S. Engelschall" <rse+openpkg-security@openpkg.org>
To: Damien Miller <djm@openbsd.org>
Cc: vendor-sec@lst.de
Subject: Re: [vendor-sec] Announce: OpenSSH 4.4 released
Reply-To: rse@engelschall.com
User-Agent: Mutt/1.5.13 OpenPKG/CURRENT (2006-08-11)
Errors-To: vendor-sec-admin@lst.de
Date: Thu, 28 Sep 2006 11:54:39 +0200

On Wed, Sep 27, 2006, Damien Miller wrote:

> [...]
>  * Fix an unsafe signal hander reported by Mark Dowd. The signal
>    handler was vulnerable to a race condition that could be exploited
>    to perform a pre-authentication denial of service. On portable
>    OpenSSH, this vulnerability could theoretically lead to
>    pre-authentication remote code execution if GSSAPI authentication
>    is enabled, but the likelihood of successful exploitation appears
>    remote.
>
>  * On portable OpenSSH, fix a GSSAPI authentication abort that could
>    be used to determine the validity of usernames on some platforms.
> [...]

For the first GSSAPI related issue above I think I was able to determine
the changes from the OpenBSD CVS. But can anybody sched some light on me
what particular patch (from portable OpenSSH) fixes the second GSSAPI
related issue above? I'm having trouble to determine for OpenPKG the
right commit in the portable OpenSSH CVS...

                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com

From: "Ralf S. Engelschall" <rse+openpkg-security@openpkg.org>
To: Josh Bressers <bressers@redhat.com>
Cc: Damien Miller <djm@cvs.openbsd.org>, vendor-sec@lst.de
Subject: Re: [vendor-sec] Announce: OpenSSH 4.4 released
Reply-To: rse@engelschall.com
User-Agent: Mutt/1.5.13 OpenPKG/CURRENT (2006-08-11)
Errors-To: vendor-sec-admin@lst.de
Date: Thu, 28 Sep 2006 16:07:50 +0200

On Wed, Sep 27, 2006, Josh Bressers wrote:

> I'm wondering if you can offer some clarification to these two issues (I'd
> gladly take some clarification from anyone on vendor-sec too).  I'm not
> familiar enough with the openssh code to easily figure these out.
>
> >  * Fix an unsafe signal hander reported by Mark Dowd. The signal
> >    handler was vulnerable to a race condition that could be exploited
> >    to perform a pre-authentication denial of service. On portable
> >    OpenSSH, this vulnerability could theoretically lead to
> >    pre-authentication remote code execution if GSSAPI authentication
> >    is enabled, but the likelihood of successful exploitation appears
> >    remote.
>
> I'm wondering why this only affects GSSAPI, and beyond that, does GSSAPI
> authentication have to be enabled and working, or is having
> "GSSAPIAuthentication yes" in the configuration file enough for this to be
> triggered?

I'm currently reviewing the OpenSSH code changes for this issue and I'm
also wondering why this should be GSSAPI related at all. The code change
mainly just "makes signal handler termination path shorter" according
to both the commit information and my own review (it does an _exit()
now while before it was cleanup_exit()). And I think the signal handler
could also fire for non-GSSAPI based authentications if I understood
the code correctly. Hmmm...?

> >  * On portable OpenSSH, fix a GSSAPI authentication abort that could
> >    be used to determine the validity of usernames on some platforms.
>
> Do we know which platforms are affected by this?

Here it is the same IMHO. I'm still having trouble too exactly determine
which code change tried to fix this, but the only possible changes I've
found are not directly GSSAPI related. Instead this also looked for me
that the problem could be triggered without GSSAPI. But I do not know
the OpenSSH code well enough to be sure.

Does anybody already know more?
                                       Ralf S. Engelschall
                                       rse@engelschall.com

To: rse@engelschall.com,
        "Ralf S. Engelschall" <rse+openpkg-security@openpkg.org>
Cc: Josh Bressers <bressers@redhat.com>,
        Damien Miller <djm@cvs.openbsd.org>, vendor-sec@lst.de
From: Josh Bressers <bressers@redhat.com>
Subject: Re: [vendor-sec] Announce: OpenSSH 4.4 released
Comments: In-reply-to "Ralf S. Engelschall" <rse+openpkg-security@openpkg.org>
   message dated "Thu, 28 Sep 2006 16:07:50 +0200."
Errors-To: vendor-sec-admin@lst.de
Date: Thu, 28 Sep 2006 10:32:21 -0400

>
> I'm currently reviewing the OpenSSH code changes for this issue and I'm
> also wondering why this should be GSSAPI related at all. The code change
> mainly just "makes signal handler termination path shorter" according
> to both the commit information and my own review (it does an _exit()
> now while before it was cleanup_exit()). And I think the signal handler
> could also fire for non-GSSAPI based authentications if I understood
> the code correctly. Hmmm...?

It's probably not out of the question that there is a race in the PAM   
cleanup source too.  I've done some code analysis, and it looks like there
could be a race condition, but not so much with GSSAPI.

The call to fatal() eventually makes it way to this code:

#ifdef KRB5 
    if (options.kerberos_ticket_cleanup &&
        authctxt->krb5_ctx)
        krb5_cleanup_proc(authctxt);
#endif

#ifdef GSSAPI
    if (compat20 && options.gss_cleanup_creds)
        ssh_gssapi_cleanup_creds();
#endif

#ifdef USE_PAM
    if (options.use_pam) {
        sshpam_cleanup();
        sshpam_thread_cleanup();
    }
#endif

The call to ssh_gssapi_cleanup_creds() only results in unlink() being
called on a file.  I see no way this could be exploited as part of a race
condition to execute arbitrary code.

The call to krb5_cleanup_proc() looks suspect though.  That function calls
a number of krb5 cleanup functions, one of which will free a number of
variables.  This leads me to believe there are two possible problems.
Double free flaws, and use after free bugs.

I've not even looked at the pam cleanup bits yet.  

The advisory claims that this is simply a DoS for OpenBSD.  I believe
OpenBSD can catch a double free, but I'm not sure about the use after free
issue.  While I've found some documentation that claims it can catch them,
a quick test on an OpenBSD machine says they're not caught.

So this where I'm at right now, I'm trying to figure out what's allocating
and using the various krb5 things.

I've mailed Mark Dowd asking for more details as Damien isn't responding.
I'll pass along any details I find.

Can any of you OpenBSD guys on the list chime in on why this isn't      
exploitable?

Thanks.

--
    JB

To: vendor-sec@lst.de
Cc: rse@engelschall.com,
        "Ralf S. Engelschall" <rse+openpkg-security@openpkg.org>,
        Damien Miller <djm@cvs.openbsd.org>
From: Josh Bressers <bressers@redhat.com>
Subject: Re: [vendor-sec] Announce: OpenSSH 4.4 released
Comments: In-reply-to Josh Bressers <bressers@redhat.com>
   message dated "Thu, 28 Sep 2006 10:32:21 -0400."
Errors-To: vendor-sec-admin@lst.de
Date: Thu, 28 Sep 2006 11:07:21 -0400

>
> I've mailed Mark Dowd asking for more details as Damien isn't responding.
> I'll pass along any details I find.
>

Here's the reply I got from Mark, it looks like it's a double free issue
(which I know modern glibc catches).

    You're right, the kerberos code is more dangerous than the GSSAPI
    stuff, I think they made a bit of a mistake in that announcement.   
    Essentially, utilizing the bug with kerberos allowed you to trigger a
    large double-free() within kerberos. The PAM stuff might also be
    somewhat interesting, although it wasn't as much of a vector as I'd
    hoped for at the time I examined it.

So has anyone taken a look at the PAM bits by chance?

--
    JB

CVE-2006-5051 fixed and submited for all distros (except SLES9-SP4, I will submited tomorrow)

There isn't special fix for CVE-2006-5052.

Could I append fix for bug 210122 to this security release?

From: Marco Ivaldi <raptor@0xdeadbeef.info>
To: vendor-sec@lst.de
Subject: [vendor-sec] timing leak vulnerability summary
Errors-To: vendor-sec-admin@lst.de
Date: Fri, 13 Oct 2006 10:32:01 +0200 (CEST)

Hey,

I've some news on the timing leak vulnerability i reported some days ago.

I finally reproduced it on a freshly installed SUSE box: the sshd process
has a peak in CPU usage when processing user credentials stored in
/etc/shadow, only for those usernames whose password has been changed
manually, i.e. without using yast. Take a look at the following example:

[add a new user "test" using yast]

root@testlab-suse[~]: grep test /etc/shadow
test:$2a$05$OE8sRobsfoZVO137cEiSDe1fQ8L1fSk2KiuCJ7VkAyAZzsU8F/uWu:13433:0:99999:7:-1::

[password is "test123"]

root@testlab-suse[~]: ./sshtime localhost dict

sshtime v0.1 - Simple OpenSSH remote timing attack tool
Copyright (c) 2006 Marco Ivaldi <raptor@0xdeadbeef.info>

test@localhost          real 1.23 <- no delay (it's even a bit faster;)
aaaa@localhost          real 1.27

root@testlab-suse[~]: passwd test
Changing password for test.
New Password:
Reenter New Password:
Password changed.
root@testlab-suse[~]: grep test /etc/shadow
test:$2a$10$KZFZX7yYEpbfDvwP6Z5N5ut4Gc/rdIF64/TmpWssIPQvROTiK/TiG:13433:0:99999:7:::

[password has been manually changed to "test321"]

root@testlab-suse[~]: ./sshtime localhost dict

sshtime v0.1 - Simple OpenSSH remote timing attack tool
Copyright (c) 2006 Marco Ivaldi <raptor@0xdeadbeef.info>

test@localhost          real 2.18 <- we can observe a big delay!
aaaa@localhost          real 1.27

root@testlab-suse[~]:

The cause of this behaviour is easy to spot. For instance:

"The version number, the logarithm of the number of rounds and the
concatenation of salt and hashed password are separated by the `$' character
[in /etc/shadow]. An encoded `8' would specify 256 rounds".
        -- OpenBSD crypt(3) manual page

The manually entered password has a bigger logarithm of the number of rounds
("10"), so it takes much more time to process, depending on CPU power.

This suggests the obvious workaround and means other distros/OSes that use
blowfish crypt() might be vulnerable as well... Both OpenBSD and Owl use it,
dunno about other platforms (AFAIK most of them use MD5 hashing?).

Cheers,

--
Marco Ivaldi
Antifork Research, Inc.   http://0xdeadbeef.info/
3B05 C9C5 A2DE C3D7 4233  0394 EF85 2008 DBFD B707

_______________________________________________
Vendor Security mailing list
Vendor Security@lst.de
https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec

(In reply to comment #9)
> Could I append fix for bug 210122 to this security release?
> 

If the packages is not yet checked in, go ahead.

But, patchinfo files are already in /work/src/done/PATCHINFO/SWAMP-PROOFREAD-DONE/
I am not sure if changing them manually has side-effects.

added fix for bug 210122 in sles9,10.0,sles10 (others aren't affected)

one more mail from vendor-sec. JFYI

From: Solar Designer <solar@openwall.com>
To: Marco Ivaldi <raptor@0xdeadbeef.info>
Cc: vendor-sec@lst.de
Subject: Re: [vendor-sec] timing leak vulnerability summary
User-Agent: Mutt/1.4.2.1i
Errors-To: vendor-sec-admin@lst.de
Date: Fri, 13 Oct 2006 17:40:23 +0400

If I understood Marco correctly, this is on its way to Bugtraq, but I'll
comment in here first anyway -

On Fri, Oct 13, 2006 at 10:32:01AM +0200, Marco Ivaldi wrote:
> This suggests the obvious workaround and means other distros/OSes that use
> blowfish crypt() might be vulnerable as well... Both OpenBSD and Owl use
> it, dunno about other platforms (AFAIK most of them use MD5 hashing?).

I'd expect that this affects all platforms that do not bother to compute
password hashes with fake salts for non-existent accounts and/or to use
the same iteration count in those fake salts that is used for real passwords.

It means that this should affect those platforms that use MD5-based
hashes, too - only to a lesser extent (since those hashes are faster).
And it should be possible to spot the "$2a$05$" (quicker to compute)
hashes on SuSE, too, compared to non-existent accounts - one just has to
do more probes per-account.

On Owl, this instance of timing leaks is resolved with:

tcb:

* Wed Apr 16 2003 Dmitry V. Levin <ldv-at-owl.openwall.com> 0.9.8.4-owl1
- In pam_tcb, implemented proper fake salt creation to avoid a timing attack.

OpenSSH:

* Fri Apr 18 2003 Solar Designer <solar-at-owl.openwall.com> 3.6.1p1-owl3
...
- Pass prefix= and count= to pam_tcb also for authentication such that it
can use this information to reduce timing leaks.

(these settings have since been moved to system-auth).

However, this is indeed non-perfect.  If an admin changes the hash type
or iteration count for newly set passwords, then there will be two kinds
of password hashes on the system and it will be possible to distinguish
them through timings.  Also, this is not the only instance of timing and
other leaks of information on whether a username is valid.

--
/sd
_______________________________________________
Vendor Security mailing list
Vendor Security@lst.de
https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec

Thorsten might be interested in the Timing Problems (comment #c10), since they are mostly PAM related. (not sure if any action is required)

But pam_tcb still doesn't solve the timing problem when we have two type of hashes in teh system ;(. Maybe we should documentate it for admin ;(.

About the timing issue:
Hm, if you search in bugzilla, you will see that this was reported by me already several times and our security team didn't see it as real problem, so why should it be now?

But as usual in reality it does not make any difference: You can measure the times as often as you like, since you don't know which algorithm was used in which form, it does not help you in any kind. We use blowfish only for some passwords, not all. We use different "round" arguments for the passwords. So every time you meassure is meaningless. And about fake crypts: Doing fake crypts gives me the same information as not doing them.

updates + advisory released.

*** Bug 527859 has been marked as a duplicate of this bug. ***