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.