Summary: In Samba's SAMR server we neglect to ensure that
attempted password changes will update the bad password
count, nor set the lockout flags.
This would allow a user unlimited attempts against the
password by simply calling ChangePasswordUser2
This is available without any other authentication.
Samba versions 3.4.0 and above allow the administrator to implement
locking out Samba accounts after a number of bad password attempts.
However, all released versions of Samba did not implement this check for
password changes, such as are available over multiple SAMR and RAP
interfaces, allowing password guessing attacks.
As this was found during an internal audit of the Samba code there are
no currently known exploits for this problem (as of March 11th 2014).
+*samba-4.1.6 (14 Mar 2014)
+*samba-4.0.16 (14 Mar 2014)
+*samba-3.6.23 (14 Mar 2014)
+ 14 Mar 2014; Lars Wendler <firstname.lastname@example.org> -samba-3.6.19.ebuild,
+ -samba-3.6.20.ebuild, -samba-3.6.21.ebuild, +samba-3.6.23.ebuild,
+ -samba-4.0.15-r1.ebuild, +samba-4.0.16.ebuild, -samba-4.1.5-r1.ebuild,
+ +samba-4.1.6.ebuild, files/3.6/samba.initd:
+ Security bump (bug #504494). Removed old.
Arches please test and mark stable =net-fs/samba-3.6.23 with target KEYWORDS:
alpha amd64 arm hppa ia64 ~mips ppc ppc64 sparc x86 ~amd64-fbsd ~x86-fbsd ~arm-linux ~x86-linux
Stable for HPPA.
Maintainer(s), please cleanup.
Security, please vote.
Arches, Thank you for your work
Maintainer(s), please drop the vulnerable version.
Added to an existing GLSA request.
Samba 3.x before 3.6.23, 4.0.x before 4.0.16, and 4.1.x before 4.1.6 does
not enforce the password-guessing protection mechanism for all interfaces,
which makes it easier for remote attackers to obtain access via brute-force
ChangePasswordUser2 (1) SAMR or (2) RAP attempts.
No vulnerable packages in 3.6, 4.0 and 4.1 series left in the tree. <3.6 is package masked
# Lars Wendler <email@example.com> (14 Mar 2014)
# Masked for security reasons.
# Do NOT remove this mask or the affected packages without speaking to
# bonsaikitten first! You have been warned!
This issue was resolved and addressed in
GLSA 201502-15 at http://security.gentoo.org/glsa/glsa-201502-15.xml
by GLSA coordinator Kristian Fiskerstrand (K_F).