Description of problem: A remote client of the GSS-API FTP daemon in the krb5-appl distribution can access files using the effective group ID that the FTP daemon process had when it started. Version-Release number of selected component (if applicable): krb5-appl-1.0.1-2.mga1.src.rpm How reproducible: N/A Red Hat src.rpm (should have a patch): ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Client/en/os/SRPMS/krb5-appl-1.0.1-2.el6_1.1.src.rpm Red Hat bugzilla entry: https://bugzilla.redhat.com/show_bug.cgi?id=711419 Upstream Patch: http://web.mit.edu/kerberos/advisories/2011-005-patch.txt Test: It would appear that /etc/xinetd.d/gssftp is misconfigured, pointing to /usr/kerberos/sbin/ftpd, which doesn't appear to exist, and the service startup fails. After removing "kerberos": chkconfig --add gssftp service gssftp start ftp localhost (as a normal user) unfortunately this fails too, looks like something else is broken: [stew@lenovo ~]$ ftp localhost Connected to localhost.localdomain. 220 lenovo.e-artisan.org FTP server (Version 5.60) ready. 334 Using authentication type GSSAPI; ADAT must follow GSSAPI accepted as authentication type GSSAPI error major: Unspecified GSS failure. Minor code may provide more information GSSAPI error minor: Credentials cache file '/tmp/krb5cc_500' not found GSSAPI error: initializing context GSSAPI authentication failed So perhaps we're not vulnerable, since the server doesn't work anyway :/ Possible advisory text: It was found that gssftp, a Kerberos-aware FTP server, did not properly drop privileges. A remote FTP user could use this flaw to gain unauthorized read or write access to files that are owned by the root group. (CVE-2011-1526). Updated packages are patched to correct this issue.
Keywords: (none) => Security
CC: (none) => ahmadsamir3891, guillomovitch, pterjan
The GSSAPI error just means the server is not correcty configured to handle GSSAPI authentication, probably because it doesn't have a keytab file. You'd rather test it with standard password authentication before concluding it is broken. I just fixed configuration files in cauldron package.
Whiteboard: (none) => [close at EOL mageia 1]
CC: (none) => sander.lepikAssignee: bugsquad => pterjan
pascal, guillaume can you handle this security bugreport and push into update_testing please ?
CC: (none) => dmorganec
ping
CC: (none) => stormi
Patched release 1.0.1-2.1 available in updates_testing, untested.
Ok thanks. As we don't really have a 'security team' I assign this bug to the QA.
Assignee: pterjan => qa-bugsWhiteboard: [close at EOL mageia 1] => (none)
How do you suggest testing this? # urpmi gssftp No package named gssftp
Ok so gssftp is part of the krb5-appl-server or client packages Installed both of those # service xinetd start # chkconfig --add gssftp # service gssftp start $ ftp localhost ftp: connect: Connection refused
The /etc/xinetd.d/* files all point to /usr/kerberos/sbin/ but the programs are in /usr/sbin.
CC: (none) => davidwhodgins
Confirmed. server = /usr/kerberos/sbin/telnetd server = /usr/kerberos/sbin/ftpd server = /usr/kerberos/sbin/klogind server = /usr/kerberos/sbin/kshd # ll /usr/kerberos ls: cannot access /usr/kerberos: No such file or directory
I just uploaded a 1.0.1-2.2.mga1, with fixed *default* configuration files (default means modifiable here).
I'm working on i585 testing. I've got the master kerberos db setup on my host, and am currently working on a mageia 1 guest in virtualbox. It'll probably be a day or so, to complete the setup for the testing. Is there any way to confirm the privileges have been dropped properly?
In the guest, I'm able to use kinit to login to the host kerberos system, but ftp is failing ... [dave@mageiavb ~]$ ftp -f hodgins.homeip.net Connected to hodgins.homeip.net. 220 hodgins.homeip.net FTP server (Version 5.60) ready. 334 Using authentication type GSSAPI; ADAT must follow GSSAPI accepted as authentication type GSSAPI authentication succeeded Name (hodgins.homeip.net:dave): dave 550 Can't open PAM session. Login failed. Remote system type is GSSAPI. In the hosts /var/log/auth.log is has ... Nov 9 17:11:40 hodgins xinetd[23004]: START: ftp pid=31457 from=192.168.20.100 Nov 9 17:11:44 hodgins ftpd[31457]: PAM unable to dlopen(/lib/security/pam_selinux.so): /lib/security/pam_selinux. so: cannot open shared object file: No such file or directory Nov 9 17:11:44 hodgins ftpd[31457]: PAM adding faulty module: /lib/security/pam_selinux.so Nov 9 17:11:44 hodgins ftpd[31457]: pam_tcb(gssftp:session): Session opened for dave by dave(uid=0) The file pam_selinux.so is not available in any package on Mageia or Mandriva.
I found http://osdir.com/ml/scm-fedora-commits/2011-06/msg05473.html Looks like we have a copy of gssftp from before the pam_selinux req was dropped, but don't have pam_selinux. I guess this makes gssftp quite secure. :-)
Assigning to maintainer. Please reassign to QA when you've had a chance to look into this. Thanks.
CC: (none) => qa-bugsAssignee: qa-bugs => guillomovitch
There is another security update for this package (affecting telnetd): http://lists.mandriva.com/security-announce/2011-12/msg00027.php
CC: (none) => luigiwalser
Guillaume, is this package ready again ? http://sophie-web.latmos.ipsl.fr/rpms/536ad216372a4c36b02e2389558de0ba/changelog
This update works for me on i586.
Does this fix CVE-2011-0285, CVE-2011-0284, CVE-2010-4022, CVE-2011-0281, and CVE-2011-0282? References: http://lists.mandriva.com/security-announce/2011-02/msg00004.php http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0284 http://lists.mandriva.com/security-announce/2011-04/msg00024.php
i added a comment on the spec file about the CVE fixed: http://svnweb.mageia.org/packages/updates/1/krb5/current/SPECS/krb5.spec?r1=189488&r2=189487&pathrev=189488
i just pushed krb5-appl that fixes CVE-2011-4862 src.rpm: krb5 krb5-appl
Assignee: guillomovitch => qa-bugs
This is clearly a mess, with too many people involved. Now we have a package with a new shiny three-number 2.3.1 release number, a duplicated patch (one being not applied), and a less-than-readable changelog. OK, I forgot to update this ticket when submitting the 2.3 release friday, but was it really necessary to go into such hurry for a bug opened since 6 monthes already ? Anyway, we now have package fixing two security issues (CVE-2011-1526 and CVE-2011-4862), and a minor default configuration issue. Can someone validate it, push it to updates, and close this endless ticket ?
Sorry for the delay. I'd reset my vb guest to a clean install, and had some problems getting the kerberos workstation going. Forgot about having to get the reverse dns setup. Got it working now to the point I can get a ticket from the host running the kerberos server, in the guest running under virtualbox. The ftp server still fails with PAM unable to dlopen(/lib/security/pam_selinux.so as in comment 12. For telnet, after using kinit to get a ticket, and using "telnet -a -f -k REALM host", it's still asking for the password. The telnet server/client work, but are not using kerberos authentication, or I've messed something up, in my testing, which seems more likely. I'm willing to consider testing complete on i586 for this update, as the telnet server/client work when not using kerberos. I'll do more testing and open a separate bug report for the ftp server and the telnet/kerberos usage later. This update should be validated once someone confirms the telnet server/client work when not using kerberos, on x86-64.
For the PAM warning, it's quite expectable, as we don't ship selinux. Maybe we could tune the default configuration file a little bit more. Also, telnet (and other legacy applications) are quite difficult nowadays to configure for kerberos authentication, given than they only support DES encoding, and recent versions of kerberos implementations don't support DES by default anymore. While very valuable, your testing efforts seems a bit overkill here for a minor security update, given than the package in the distribution release probably never get any kind of testing at all...
We still need someone to test on x86-64 that telnet (without kerberos authentication) works.
Guillaume are you tuning further or is this ready for final testing/validation? Thanks.
This is ready for final validation, for me at least. As already said, this package has probably been more tested now than for the stable release of the distribution...
Testing x86_64 $ ftp localhost Connected to localhost. 220 mega FTP server (Version 5.60) ready. 334 Using authentication type GSSAPI; ADAT must follow GSSAPI accepted as authentication type GSSAPI error major: Unspecified GSS failure. Minor code may provide more information GSSAPI error minor: Credentials cache file '/tmp/krb5cc_500' not found GSSAPI error: initializing context GSSAPI authentication failed Name (localhost:claire): claire 530 Must perform authentication before identifying USER. Login failed. Remote system type is UNIX. Using binary mode to transfer files. ftp> I'm not sure if this means it is working or not but it doesn't seem to have logged in. ftp> ls 530 Please login with USER and PASS. Passive mode refused. Turning off passive mode. 200 PORT command successful. 530 Please login with USER and PASS. ftp> It seems to have dropped to a normal ftp prompt. ftp> user claire 530 Must perform authentication before identifying USER. Login failed. Is this due to not having a kerberos server set up? If so then rejecting the login is probably working correctly.
For CVE-2011-4862, Mandriva's advisory says this: In Mandriva the telnetd daemon from the netkit-telnet-server package does not have an initscript to start and stop the service, however one could rather easily craft an initscript or start the service by other means rendering the system vulnerable to this issue. And to go along with that they also issued an update for their netkit-telnet package (MDV 2011 only, same netkit-telnet version we have). Does this apply to us as well? If so, both Mageia 1 and Cauldron would probably be affected. The advisory is here: http://www.mandriva.com/en/support/security/advisories/?dis=2010.1&name=MDVSA-2011:195
For when this gets validated, here's a suggested advisory for the krb5-appl. Advisory: ======================== Updated krb5-appl packages fix security vulnerabilities: It was found that gssftp, a Kerberos-aware FTP server, did not properly drop privileges. A remote FTP user could use this flaw to gain unauthorized read or write access to files that are owned by the root group. ftpd.c in the GSS-API FTP daemon in MIT Kerberos Version 5 Applications (aka krb5-appl) 1.0.1 and earlier does not check the krb5_setegid return value, which allows remote authenticated users to bypass intended group access restrictions, and create, overwrite, delete, or read files, via standard FTP commands, related to missing autoconf tests in a configure script (CVE-2011-1526). An unauthenticated remote attacker can cause a buffer overflow and probably execute arbitrary code with the privileges of the telnet daemon (CVE-2011-4862). Additionally, the paths to the server binaries in the xinetd service configuration files were incorrect and have been corrected. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1526 https://bugzilla.redhat.com/show_bug.cgi?id=711419 http://www.mandriva.com/en/support/security/advisories/?dis=2010.1&name=MDVSA-2011:117 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4862 http://web.mit.edu/kerberos/advisories/MITKRB5-SA-2011-008.txt http://www.mandriva.com/support/security/advisories/?dis=2010.1&name=MDVSA-2011:195 ======================== Updated packages in core/updates_testing: ======================== krb5-appl-clients-1.0.1-2.3.1.mga1 krb5-appl-servers-1.0.1-2.3.1.mga1 from krb5-appl-1.0.1-2.3.1.mga1.src.rpm
Thankyou David :) Just need to hear from Guillaume. If it is actually working then this can be validated.
It seems to be working, The GSSAPI errors messages are clearly due to the lack of a kerberos environment.
Thats good news, thanks Guillaume :) Validating the update. SRPM: krb5-appl-1.0.1-2.3.1.mga1.src.rpm Please see comment 29 for advisory. Could sysadmin please push from core/updates_testing to core/updates Thankyou!
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugsHardware: i586 => All
update pushed.
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED