Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
As per the bugtraq post I suspect we're vulnerable to this. There'sa kernel patch in the thread however I don't think that's a solution for Gentoo to implement but rather a kernel maintainer fix. In the meantime though I think we may want to fix the setuid bit on smbmnt. root # ls -l `which smbmnt` -rwsr-xr-x 1 root root 569844 Apr 9 2003 /usr/sbin/smbmnt Thoughts ? Reproducible: Always Steps to Reproduce: 1. 2. 3.
Well, samba-3.0.2a merged this patch: http://lists.samba.org/archive/samba-technical/2004-February/034328.html Other than that, the background is that we've installed smbmnt, smbumount and mount.cifs setuid-root for convenience, where said convenience was clearly asked for. Then the read bits were revoked to lessen offset calculation exploit vectors I believe. Maybe it's time to stop installing them setuid-root and simply go with 755 permissions, convenience vs. security? Security team, what would you guys like to see?
i'm game for dropping the setuid's
We could add a postinst telling them how to make them suid and what the benefits/drawbacks are. Just an idea. But I am all for the default being secure rather than convenient.
I certainly think dropping the default special bit is apropriate. The change would probably go mostly unonoticed. -Dave
Thanks for the feedback, I'll remove those bits from the ebuilds shortly.
btw.: Why are 3.0 - 3.0.1 ebuilds still available via portage? ============================= Release Notes for Samba 3.0.2 February 9, 2004 ============================= Security Announcement: It has been confirmed that previous versions of Samba 3.0 are susceptible to a password initialization bug that could grant an attacker unauthorized access to a user account created by the mksmbpasswd.sh shell script. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0082 to this issue. (from: http://www.samba.org/samba/whatsnew/samba-3.0.2a.html)
Could we fix all the vulnerabilities in Samba in one move ? To close this one and #45965 (and the unreported passwd init vuln Carlo talks about) we need a 3.0.2a package with nosuid and the smbprint patch. It should at least have KEYWORDS="~x86 ppc ~sparc mips ~hppa ~amd64 ia64 ~alpha" since we have affected stable ppc, ia64 and mips ebuilds out there. We also need to hide 3.0.0-r1, 3.0.1 and 3.0.1-r1 which are still in portage. Donny, do you think we can have that ? Thanks in advance, -K
Hmmm... it should also have KEYWORDS = amd64 since the current 3.0.2a is stable on amd64. -K
Donny -- this is a local root exploit. Can we get some tender loving care on the ebuild?
Kurt -- I need some help. I've barely the time at the moment to read mails nevermind do commits at work :-( As I said, 3.0.2a has the minimum patch already, or so I thought. If that's marked stable then we're covered. The nosuid thing is only going to cause headaches for users. I don't think other distros have changed from installing those utils suid-root, they do it for convenience. Please feel free to correct any errors here ^^ and release an update if you feel up to it. The smbprint thing could be patched if you feel inclined at the same time. There's a good patch adding postgresql support to the ebuild in my queue as well. I could use somebody to start making them into a samba ebuild maintainer replacement, if you could have them come to me I'll get them up to speed on things. I don't want to be a bottleneck any longer.
From what I gathered, I'll post some comments here. First off samba 3.0.2a is not rootable; hence the reason they released the "a" afterwards. There's no need to strip the suid flags, some people actually use smbmnt a lot. As for what needs to be done, yes I agree that we need to strip the 3.0.0 and 3.0.1. One thing to watch out for is that they redid the database and you have to run a command to fix it "not in einfo yet" http://us2.samba.org/samba/whatsnew/samba-3.0.2a.html pdbedit --force-initialized-passwords I think after this is done, it should be a good to go to remove the older 3.0.0 and 3.0.1 ebuilds
I'll take a look at this, since I use Samba on occasion.
Setting a depend; it would probably be a good idea to fix both at the same time, and release a single GLSA. Having looked at the setuid vulnerability, I would vote for removing the setuid bits and adding an ewarn to that effect. Yes, it is inconvenient, but somehow I think getting rooted is 100x more inconvenient. ;) My recommentation re Donny's PostgreSQL patch would be to wait and do it in another release (either a -r2 or when Samba 3.0.3 comes out). That way people don't need to change their system any more than necessary. I'm working on an updated ebuild now that incorporates the setuid fix and the smbprint patch. I can add the Postgres patch while I'm at it if people think I should. :)
Created an attachment (id=28986) [details] samba-3.0.2a-r1.ebuild Updated ebuild which fixes the smbprint problem (bug 45965) and removes the setuid bits from smbmount/smbmnt/mount.cifs. The patch for the smbprint problem is attached to that bug.
mglauche -- I'm CCing you on this since you're the new Samba dev. Long story short, there is a vulnerability in smbfs (in the kernel) we need to work around, and there's another one in smbprint (bug 45965) which should be patched as well. I've written an updated ebuild and patch for these two, but someone should probably look at these and test them (well, more thoroughly than I have anyway). Also, someone on the gentoo-security mailing list suggested making a local USE flag for turning on setuid bits for the smbmount programs. What are your thoughts on this?
Subject needs both category and package name.
USE flag should be good idea, i think the "mount as user" functionally is too valuable to dismiss generally. But for "high security" system-admins it could be a good option to decrease the number of suid programs by 3 ...
Btw ... the samba-3.0.2a-r1.ebuild works fine for me, can someone else also test it, so we can get it commited ?
USE flags will not be tolerated for suid, NO. If somebody gets cute and tried to add that, I will simply revert your changes. I said I needed help to maintain samba, i didnt say I needed somebody to come in and start rolling all over the package and adding whatever little frivolous additions they pleased. Thanks.
re comment 19: There is already a precedent for this sort of thing in aRts, and some users have expressed concern about simply removing the bits, even with an ewarn/einfo. ----- From: David Garcia Watkins <dgw@...> To: gentoo-security@lists.gentoo.org Date: Tue, 13 Apr 2004 10:42:56 +0200 Subject: Re: [gentoo-security] Samba Testing Help X-UID: 857 > Also, what are your reactions to making smbmount non-setuid (thus > preventing normal users from mounting remote Samba filesystems)? Is there a > better workaround/fix for this (other than patching the kernel)? I'd rather > not tamper with existing functionality if I can help it. I like arts' aproach to this problem, users dont have to remember to chmod each time they upgrade. In other words, to create a local USE flag called something like "smbsuid". Regards, David Garcia Watkins ----- > If somebody gets cute and tried to add that, I will simply revert your > changes. My, how productive that will be. There's really no reason to go around threatening to undo people's commits when nobody has made them, or even said they were going to make them (or indeed, CAN make them in the first place). It just pisses people off. > I said I needed help to maintain samba, i didnt say I needed somebody to come > in and start rolling all over the package and adding whatever little frivolous > additions they pleased. I don't really care how it's fixed; that is between you and mglauche. But this bug has been sitting here for over a month now. Most other major distros have already released advisories/fixes for this, and we can't until it is committed and stable. If you are vehemently opposed to a USE flag, then I ask you to please take a look at the ebuild/patch as they are attached (without the flag), make sure they're OK, and please get them checked in. Then the security team can get moving on the GLSA process. Thank you.
>But this bug has been sitting here for over a month now. Say two. It's great to see scurity related bugs not being resolved in adequate time (this is not the only one). Instead nothing happens (x)or people become rude. Applause, Donny. How about a pkg_config() section and an explaining einfo, asking the user to do "ebuild /var/db... config" when they want to suid the binaries in question?
Donny, can you explain your thoughts on why this would be a bad idea?
I've committed condordes's ebuild. from what seemant says though, there are some things that need some adjusting, but I didn't realize this till after the fact.
well, it looks like the html documentation is getting gzipped is the problem I've noticed
seemant- samba-2.2.8a does not gzip the /usr/share/doc/samba-2.2.8a/full_docs/htmldocs directory. is this the dir you are referring to? If so, should I post a ebuild to correct it?
actually, after testing the ebuild, it doesn't seem to gzip that dir. in fact, there is gunzip ${D}/usr/share/doc/${PF}/full_docs/htmldocs/* in src_install().
The ewarns seem definitively paranoid to me, since, as sj7trunks pointed out, 3.0.2a is not rootable.
So is this ready to go to the archs for testing/bumping to stable, or not? Are there any outstanding issues with the ebuild/patch? Because if there aren't, I'm going to push it off and get it stabilized so we can get a GLSA out.
Please push it off.
Anything left todo on this bug?
OK, you're all probably going to hate me for this ... I feel like an idiot for not testing this myself sooner. The setuid() bug is NOT a problem in samba-3.0.2a (which is still unstable). It is, however, in earlier versions (<=net-fs/samba-3.0.1-r1). So we can leave the smbmount binaries setuid-root, but we still need to release a GLSA and (minimally) bump 3.0.2a to stable. I think the smbprint patch is a separate issue. My vote right now is to go ahead and make a -r2 ebuild with the smbprint patch and setuid bits turned back on, mark that stable, and release a GLSA for both at the same time. Thoughts?
Created an attachment (id=30045) [details] samba-3.0.2a-r2.ebuild -r2 ebuild, leaving the setuid bits alone, but still applying the smbprint patch. Also incorporating a change that was made to the 3.0.2a ebuild after I created the -r1 ebuild. I have tested this on my machine, and it installs OK for me.
Created an attachment (id=30052) [details] samba-3.0.2a-r2.ebuild (try 2) Added an ewarn to the -r2 ebuild after talking at length with sj7trunks (thanks again for your help today, btw).
Commited samba-3.0.2a-r2 to portage by request of CondorDes. I was unable to confirm this builds ok as I don't use any form of samba/MS on my network. KEYWORDS="~x86 ~ppc ~sparc ~mips ~hppa ~amd64 ~ia64 ~alpha" Arch maintainers please QA this package and mark stable if you/we can. CondorDes this bug is back you you..
Stable on alpha.
Stable on sparc.
Stable on x86.
Stable on hppa.
stable on amd64
ppc people -- Can someone please stabilize this? We'd like to get the GLSA out soon. Thanks.
Finally I changed it to stable on ppc.
GLSA 200404-21
