Bugzilla Bug 199207

Heimdal ftpd uninitialized vulnerability

[Security Advisory]



Advisory: [AD_LAB-07015] Heimdal ftpd uninitialized vulnerability

Class: implementation Error

DATE:11/12/2007

CVEID:CVE-2007-5939

Vulnerable:

        <=heimdal 0.7.2
Affected distribution:
        Gentoo <=heimdal-0.7.2-r3
        ubuntu <=heimdal-0.7.2
Vendor:



I.Synopsis

A vulnerability has been discovered in Heimdal's ftpd.

II.DETAILS:

----------

Background

The Heimdal's ftpd is a  kerberized FTP server , that can be authenticated with
Kerberos 5.

Description

        There is a uninitialized  vulnerability in function gss_userok() in
ftpd.c.
int     gss_userok(void *app_data, char *username)      
{
...
77              if (data->delegated_cred_handle != GSS_C_NO_CREDENTIAL) {
78                 krb5_ccache ccache = NULL; 
79 (1)             char* ticketfile;    <---- declared ticketfile  without
initializer
80                 struct passwd *pw;
81                 
82                 pw = getpwnam(username);
83                 
84 (2)             if (pw == NULL) {
85                     ret = 1;
86                     goto fail;
87                 }
88      
...
110                
111     fail:
112                if (ccache)
113                   krb5_cc_close(gssapi_krb5_context, ccache); 
114 (3)            free(ticketfile); <---- free the uninitialized variable
115             }

at (1) declared ticketfile  without initializer, if match (2) condition,will go
to (3) without 
initialize the ticketfile, then free will cause security problem.

Impact
Free uninitialized variables can result in unpredictable behavior, crashes, or
security holes.

III.CREDIT: 

----------

    Venustech AD-LAB discovery this vuln. Thank to all Venustech AD-Lab guys.



V.DISCLAIMS:

-----------



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. 



Copyright 1996-2007 VENUSTECH. All Rights Reserved. Terms of use.



VENUSTECH Security Lab 

VENUSTECH INFORMATION TECHNOLOGY CO.,LTD(http://www.venustech.com.cn)



Security

Trusted {Solution} Provider

Service

Reproducible: Always

I can't find this security announcement referenced on heimdal's website. What
exact versions does it affect? 

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5939

provides no details currently.

Is there a fix available somewhere?

The fix is trivial. I'll write it. But I was hoping to get more details on the
affected versions since I added 1.0.1 to the tree recently and that could be
stabled if unaffected.

Peeking at the 1.0.1 code it looks totally different then what's pasted below
so I'd say it's not affected.

Doug, sorry for getting back so late. Please bump to 1.0.1.

Turns out just plain 1.0.1 isn't going to work. There's a bunch of issues that
Seemant was working on with other users to fix regressions. I have tried to
recruit those users to become a heimdal maintainer because I only use heimdal
in 1 minor situation which is going away so I wouldn't be a good maintainer for
it. None of the users were interested in becoming maintainers. This app is dead
from a Gentoo side and contains a security hole.

I've just contacted the Gentoo-Dev ML to hope that someone picks this up. If
not, I'll fix the security issue but I'm going to take steps to remove it from
the tree.

Mandriva apparantly has a fix:
  http://www.mandriva.com/security/advisories?name=MDKSA-2007:239

(In reply to comment #7)
> Mandriva apparantly has a fix:
>   http://www.mandriva.com/security/advisories?name=MDKSA-2007:239
> 

any news here?

No real news on it. We have first stabilized and secured mit-krb5. It will be
my next step to get heimdal in an actual version (1.1) into the tree. But this
will require some effort and needs time because of the dependencies.

g, mueli

(In reply to comment #9)
> No real news on it. We have first stabilized and secured mit-krb5. It will be
> my next step to get heimdal in an actual version (1.1) into the tree. But this
> will require some effort and needs time because of the dependencies.
> 
> g, mueli
> 
I see that you added 1.2.1 to the tree. Is it ok to go stable?

See bug #185899 for the status of heimdal 1.x in portage. The core problem are
some dependencies where my proposed solutions aren't commited yet. I've created
all bugs -> see the dependency graph. Apart from that heimdal is fully ready to
stabalize it.

The bugs blocking #185899 are all for support of heimdal in applications
(nfs-utils and others). Why are they holding up stabilization of heimdal-1 ?
Support for heimdal in more applications could be easily delivered after it
goes stable, or am I missing something?

That's more or less a question of policy. heimdal and mit-krb5 are providing
virtual/krb5 and therefore my intention was to make the same compatibility for
heimdal as for mit-krb5. nfs-utils is some kind of core util for me and that
was the reason for me holding back stabilization. I's simply possible for a lot
of people that stable nfs-utils won't compile because it depends on stable
heimdal - not very satisfying.

Comments on my view of the situation are really appreciated! As you might now I
am rather alone with kerberos ;)

g, mueli

Is our in-tree nfs-utils working with stable heimdal-0.7 ? 

nfs-utils-1.1.0-r1 reads:
# kth-krb doesn't provide the right include
# files, and nfs-utils doesn't build against heimdal either,
# so don't depend on virtual/krb.
# (04 Feb 2005 agriffis)
RDEPEND="...
        kerberos? (
                net-libs/librpcsecgss
                net-libs/libgssglue
                app-crypt/mit-krb5
        )"

If it does not cause a regression, I see no reason to upgrade heimdal first and
nfs-utils later.

Hmmm ... it's not a regression. I agree with you that we can uncouple heimdal
and nfs-utils. The dependency on fetchmail isn't that worse either.

One issue I forgot is still left. We need >=sys-devel/autoconf-2.62 and would
need >=sys-devel/libtool-2.2 which is a dep I prevent with a hack. At least the
dependency on the unstable autoconf is a problem for which I haven't seen a
solution. (Have forgotten to mention it in the first answer - sry)

Ok, so per bug 227603 we cannot currently stable that autoconf version. One
workaround would be to prepare the autotool files and ship them as another
patch against the vanilla tarball, and not call eautoreconf.
We should either do that or try to find a timeframe for autoconf stabilization.

bug 217647 is closed, let's revisit this bug then. Is there still a blocker for
stable?

No - I'd say we can go stable with heimdal-1.2.1-r1. I am going to open a
stabilization bug.

(In reply to comment #18)
> No - I'd say we can go stable with heimdal-1.2.1-r1. I am going to open a
> stabilization bug.
> 
Just FYI, for security issues, we handle stabling on the same bug, as it's
easier for us to track...

Time for GLSA decision. I vote NO.

NO, closing.