| Summary: | app-admin/webmin binary package contains sensitive info | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Tavis Ormandy (RETIRED) <taviso> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | eradicator |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | B3 [glsa] koon | ||
| Package list: | Runtime testing required: | --- | |
|
Description
Tavis Ormandy (RETIRED)
2005-01-12 13:16:07 UTC
how does miniserv.users get the root password? The tbz2 is generated in src_install as user portage who can't even read /etc/shaddow Am I missing something? looks like it get's it from this line in the ebuild:
crypt=`grep "^root:" ${ROOT}/etc/shadow | cut -f 2 -d :`
perhaps you could just put some nonsense in there and then sed it out in pkg_postinst with the correct data? Although users who quickpkg it would still include the sensitive data..perhaps best to leave it out of the package altogether and create the file in pkg_postinst()?
src_install is run as root, i believe, otherwise it wouldnt be able to chown stuff...perhaps the userpriv feature changes that? I don't know it very well :)
packages affected -> replacements =app-admin/webmin-1.170-r2 -> >=app-admin/webmin-1.170-r2 The affected package was removed since all the stable keywords were on my archs. Not sure how you guys want to handle this as it's not wrong with installs but rather the binpkgs. usermin isn't affected. Thx everyone. Both Koon and I vote for no GLSA on this one -> closing. changing subject as usermin wasn't affected I do not think we need a GLSA for this. regarding glsa, doesnt this qualify under the vulnerability treatment policy as "Global service compromise: denial of service, passwords or full database leaks", the webmin tbz2 would be world readable and these are often distributed by people to other users...these users need to know that their root password has been compromised (assuming the attacker knows how to use jtr). Also, user action has to be taken to ensure security, ie actually removing the old tbz2..isnt that the point of security advisories? I found 2 users on the web who had these tbz2 accessible to the world, i let them know about this and advised them to change their pass :) It's possible there are still packages with passwords in out there now (portage doesnt remove old ones!), I only spotted this as I was affected on a server i maintain, i know I would have liked to be informed that my root pass should be considered compromised? according to gentoo-stats.org about 10% of systems have webmin installed. reopening regarding glsa issue I tend to think now that Tavis is right, and we should issue a GLSA about it. I orginally thought it was quickpkg's fault (by design, it includes the files currently used on your filesystem), but here we had something in the ebuild that copied the root password over before the tbz2 was built (in the "buildpkg" feature or emerge -B), which is a clear ebuild flaw. So I vote YES now :) agree with koon. think GLSA is needed. I'll try to write the GLSA GLSA 200502-12 |