Summary: | net-fs/samba CAN-2004-1154: Integer overflow could lead to remote code execution in Samba 2.x, 3.0.x <= 3.0.9 (Vendor-Sec) | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Sune Kloppenborg Jeppesen (RETIRED) <jaervosz> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | critical | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
URL: | http://www.samba.org/samba/security/CAN-2004-1154.html | ||
Whiteboard: | A1 [glsa] jaervosz | ||
Package list: | Runtime testing required: | --- | |
Attachments: |
Description
Sune Kloppenborg Jeppesen (RETIRED)
2004-12-09 13:53:54 UTC
Created attachment 45624 [details, diff]
samba-3.0.9-CAN-2004-1154.patch
Christian please prepare and attach an updated ebuild (do NOT commit to Portage yet) so we can call on specific devs to mark stable. Created attachment 45681 [details, diff]
samba-3.0.9-r1.ebuild diff against samba-3.0.9.ebuild
Since the size of the patch (> 400Kb, 70Kb bzipped), I put it in my web space.
The installation seems straightforward, and the functionality tests I made were
all successful.
Only a note for the cvs commiters: please refetch all your old copies of
smbldap*, since at least one of you has a deprecated version (which may be
saved in the digest files): the upstream packager did retain the same version
number for two different releases. :-(
Created attachment 45682 [details, diff]
samba-3.0.9-r1.ebuild diff against samba-3.0.9.ebuild
small lib preload fix. other comments as before.
Everyone : this is a confidential bug, please do not disclose any of it. We need you to test the samba-3.0.9-r1.ebuild that is provided on this bug and report here if it can be committed as stable directly on your platform. Target KEYWORDS="alpha amd64 arm hppa ia64 mips ppc ppc64 s390 sparc x86" Calling last stable markers for each supported arch: for alpha -> kloeri@gentoo.org for amd64 -> blubb@gentoo.org for ppc -> SeJo@gentoo.org for ppc64 -> corsair@gentoo.org for sparc -> gustavoz@gentoo.org for x86 -> tester@gentoo.org If you can't handle it, please comment here and give us the name of someone who can :) Thanks in advance. green light on sparc. looks good so far on amd64 I have a problem on x86 with USE=cups if I start samba with cups running it segfaults in smbd with this stacktrace... I'll check if it happens on the version that currently stable.. Dec 10 17:54:54 [smbd] #3 [0xffffe420]_ Dec 10 17:54:54 [smbd] #4 /lib/libc.so.6(malloc+0x8e) [0xb7d8f8de]_ Dec 10 17:54:54 [smbd] #5 /usr/sbin/smbd(bitmap_allocate+0x40) [0x81b2810]_ Dec 10 17:54:54 [smbd] #6 /usr/sbin/smbd(init_rpc_pipe_hnd+0x12) [0x813e0fc]_ Dec 10 17:54:54 [smbd] #7 /usr/sbin/smbd [0x8218a22]_ Dec 10 17:54:54 [smbd] #8 /usr/sbin/smbd(main+0x273) [0x8218ca6]_ and the cups stuff works with 3.0.8.. I'll try to get more details later tonight or tomorrow morning. The bug is definitely with the patch... I dont have enough free hd space to build it with -g ... Can anyone else reproduce it ? looks good on ppc... greets Alpha is good. Christian (and anyone else on x86) please look into comment #8 Tested on x86, with '-g': it needs over 1.1 Gb of space... Cups seems ok: I didn't have any errors. corsair please test this asap and report back. If you're not able to do it please point out someone who is. Tester can you retest on x86? looks good on ppc64 We are still on track for the release tomorrow morning at 6am GMT-6. Back to ebuild status. Christian please apply the needed patches ASAP. ---- There are 2 additional patches included in the 3.0.10 release. We are still on track for the release tomorrow morning at 6am GMT-6. Back to ebuild status. Christian please apply the needed patches ASAP. ---- There are 2 additional patches included in the 3.0.10 release. Both should apply to 3.0.9 + the CAN=2004-1154 patch previously posted. http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=rev&rev=2413 http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=rev&rev=4120 Neither are required for security. However, the second is needed for stability. My cups bug is fixed by http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=rev&rev=4120 With this patch I declare it ok on x86 Created attachment 46112 [details, diff] samba-3.0.9-r1.ebuild diff against samba-3.0.9.ebuild http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=rev&rev=2413 is already present in 3.0.9 http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=rev&rev=4120: first part (lib/util.c) is invalid for 3.0.9; second part (lib/bitmap.c) is ok Created attachment 46113 [details, diff] files/samba-3.0.9-bitmap.c-4120.patch http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=rev&rev=4120: bitmap part this issue is now public http://www.idefense.com/application/poi/display?id=165 Created attachment 46125 [details, diff] samba-3.0.9-r1.ebuild diff against samba-3.0.9.ebuild forget comment #20: http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=rev&rev=4120 is partially a fix to the CAN patch, so what I tought to be the 'invalid' portion was the remedy the a post-CAN bug. Created attachment 46126 [details, diff]
files/samba-3.0.9-util.c-bitmap.c-4120.patch
and now the patch...
I confirm that the patches from comments 22 and 23 work on x86 Samba advisory has been published at http://www.samba.org/samba/security/CAN-2004-1154.html Patch at http://www.samba.org/samba/ftp/patches/security/samba-3.0.9-CAN-2004-1154.patch Signature: http://www.samba.org/samba/ftp/patches/security/samba-3.0.9-CAN-2004-1154.patch.asc As this is now public unCC'ing specific devs and adding arches. Please mark stable ASAP. Thx. Ok arches, no ebuild in Portage yet. Please test the one on the bug. Christian please commit the fixed ebuild. might be useful to have the samba ppl in CC... Samba ppl: you have x time (x being a small number) before I commit the last attachment to the tree... Guessing I'm beyond x, so unmasking for all archs (since it' a CAN, even for the untested ones...) Closing? Thx Christian. Marked stable on all arches, we're ready for GLSA. When was it made policy that CAN's get pushed into stable before arch testing? Especially since it was a version bump as well (most archs were at 3.0.8 stable)... Jeremy it's not policy for CANs. But it is custom practice to let the package maintainer decide stable markings. I can understand this being acceptable if the delta was small (just the security patch), but it's also version bumping. It is clear in Gentoo policy that developers can only mark a stable package if they have access to that arch. Again, I can understand bending the rules for a minimal security patch, but this is just too much. With the exception of portage and baselayout, package maintainers *never* decide whether ebuilds go stable on archs which they don't have access to. This is a policy violation, and a fairly nasty one at that... Adding devrel to the Cc: list -- can you guys please help ensure that this never happens again? Seems all those emails I send out about it just aren't enough. readding archs so they can actually test the package even though it's already marked stable... I intentionally left amd64 off as I've tested it already on that arch. eradicator: you're right. I've already (re)masked the archs not tested in this bug. So, the still stable archs are alpha, amd64, ppc, ppc64, sparc and x86 (which gave their ok in this bug). I know I could have been too fast, but, since the tests on all these platforms were successfull (even with the (upstream words) 'excessive zelous' CAN corrected by the latest 'minor' patch), I felf confident on the release. So, the unmasked time range was about half an hour: I'm now waiting for other platform approval. Then perhaps the policy should say that in a big fat warning. I don't think this is anything for devrel and if someone think it is it should be handled on a separate bug. Snip from current Ebuild policy: Moving package versions from ~ARCH to ARCH When a package version has proved stable for sufficient time and the Gentoo maintainer of the package is confident that the upgrade will not break a regular Gentoo user's machine, then it can be moved from ~ARCH to ARCH. An indication of the package's stability would be no verified or unresolved bug report for a month after the version's introduction. It is up to the maintainer of the package to deem which versions are stable or if development versions should be in package.mask or left in ~arch. You must also ensure that all the dependencies of such a package version are also in ARCH. Warning: The ~ARCH step may only be ignored if and only if the concerned package version contains a security fix or is needed to fix an important bug in the Gentoo system. a partial comment on #33, #36 and #37 (brief, I promise :-): -- since it's for a glsa, and appreciating the urgence, I unmasked all remaing platforms in the ebuild: this lasted for half an hour. -- _my_ fault: after the first comment of eradicator, I left stable only the 6 archs that gave me ok to proceed. But this fault was made with a lot of pre-reasoning: -- 3.0.8 has been an upstream rush to close another security flaw: upstream maintainers did indeed introduce some bugs in it (docs and kde subcomponents issues for example: for more info, see the 3.0.9 release note: mainly bug fixes): 3.0.9 is the 'what we though for 3.0.8 but we did't have the time to do it' (mine words, but not mine concepts). So, I'm here suggesting: could it be sufficient a 'majority' of platform testing to mark a release stable for all others, if a glsa is involved? (majority==2/3 of platforms? 75% of user base (I know this is unfair for some archs)?) Or: what about platform-based glsa, if needed? I know this is not the proper place to discuss this, but the CC includes all archs, devrel and security, so... This is not the place to discuss this. Please read http://www.gentoo.org/security/en/vulnerability-policy.xml and open a new bug/send mail to security if anything needs to be change, thanks. Arches: sorry for the noise, please mark stable. samba-3.0.9-r1 is good on alpha. sparc ok after the new patch and tests. samba-3.0.9-r1 is good on ppc64 Tested again on ppc and removing CC. actually removing the cc :P Thank you all, closing with GLSA 200412-13. arm, hppa, ia64, mips, s390 please remember to mark stable. Stable on hppa. Stable on mips. |