========================================================== == == Subject: Possible remote code execution == CVE ID#: CAN-2004-1154 == == Versions: Samba 2.x & 3.0.x <= 3.0.9 == == Summary: A potential integer overflow when == unmarshalling specific MS-RPC requests == from clients could lead to heap == corruption and remote code execution. == ========================================================== | Our plans are to release 3.0.10 on Thursday, December | 16, 6am CST (GMT-6) to address this security hole | and one other segv fault. | | The patch is rather large due to the fact that once | you point out one integer overflow, everyone starts | looking for more. The changes address the specific | issue that was originally reported as well as attempting | to reduce the possibility of similar exploits following | the public announcement. =========== Description =========== Remote exploitation of an integer overflow vulnerability in the smbd daemon included in Samba 2.0.x, Samba 2.2.x, and Samba 3.0.x prior to and including 3.0.9 could allow an attacker to cause controllable heap corruption, leading to execution of arbitrary commands with root privileges. Successful remote exploitation allows an attacker to gain root privileges on a vulnerable system. In order to exploit this vulnerability an attacker must possess credentials that allow access to a share on the Samba server. Unsuccessful exploitation attempts will cause the process serving the request to crash with signal 11, and may leave evidence of an attack in logs. ================== Patch Availability ================== A patch for Samba 3.0.9 (samba-3.0.9-CAN-2004-1154.patch) has been attached to this mail. The patch has been signed with the "Samba Distribution Verification Key" (ID F17F9772). ============================= Protecting Unpatched Servers ============================= The Samba Team always encourages users to run the latest stable release as a defense against attacks. However, under certain circumstances it may not be possible to immediately upgrade important installations. In such cases, administrators should read the "Server Security" documentation found at http://www.samba.org/samba/docs/server_security.html. ======= Credits ======= This security issue was reported to Samba developers by iDEFENSE Labs. The vulnerability was discovered by Greg MacManus, iDEFENSE Labs. ========================================================== == Our Code, Our Bugs, Our Responsibility. == The Samba Team ==========================================================
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.
