Bugzilla Bug 73943

==========================================================
==
== 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 an attachment (id=45624) [details]
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 an attachment (id=45681) [details]
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 an attachment (id=45682) [details]
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 an attachment (id=46112) [details]
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 an attachment (id=46113) [details]
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 an attachment (id=46125) [details]
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 an attachment (id=46126) [details]
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.