Recently announced at http://www.samba.org/samba/security/CVE-2012-1182:
"Samba 3.0.x to 3.6.3 are affected by a vulnerability that allows remote code execution as the "root" user. Samba 3.6.4, Samba 3.5.14 and 3.4.16 have been issued as security releases to correct the defect."
"As this does not require an authenticated connection it is the most serious vulnerability possible in a program, and users and vendors are encouraged to patch their Samba installations immediately."
Thanks for the bug, Chris, appreciate it.
@samba, from the upstream advisory at $URL:
Additionally, Samba 3.6.4, Samba 3.5.14 and 3.4.16 have been issued as
security releases to correct the defect. Patches against older Samba
versions are available at:
+ 11 Apr 2012; Patrick Lauer <email@example.com> +samba-3.5.14.ebuild,
+ Bump for #411487
Suggest stabling of 3.5.14 as we're still missing keywords on 3.6
(In reply to comment #2)
> + 11 Apr 2012; Patrick Lauer <firstname.lastname@example.org> +samba-3.5.14.ebuild,
> + +samba-3.6.4.ebuild:
> + Bump for #411487
> Suggest stabling of 3.5.14 as we're still missing keywords on 3.6
To get things stabilised faster, I agree. This bug has replaced a net-fs/samba-3.6.3 STABLEREQ bug, but as I said, I think 3.5.14 has a chance of being stabilised sooner and for a critical security issue like this, that's important IMO.
Arches, please test and mark stable:
Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86"
x86 stable, thanks.
Archtested on amd64: Everything looks OK to me
Why are keywords missing on 3.6.*? Someone should file a keywording bug for that.
Stable for HPPA.
(In reply to comment #8)
> Why are keywords missing on 3.6.*? Someone should file a keywording bug for
> Stable for HPPA.
sys-libs/ldb , a net-fs/samba DEPEND, must be keyworded first; check bug 377809 .
I feel tempted to close that bug and reopen one that includes both sys-libs/ldb and net-fs/samba
Thanks, everyone. GLSA is already drafted and ready for review.
The RPC code generator in Samba 3.x before 3.4.16, 3.5.x before 3.5.14, and
3.6.x before 3.6.4 does not implement validation of an array length in a
manner consistent with validation of array memory allocation, which allows
remote attackers to execute arbitrary code via a crafted RPC call.
This issue was resolved and addressed in
GLSA 201206-22 at http://security.gentoo.org/glsa/glsa-201206-22.xml
by GLSA coordinator Sean Amoss (ackle).