CVE-2010-0547 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-0547): client/mount.cifs.c in mount.cifs in smbfs in Samba 3.4.5 and earlier does not verify that the (1) device name and (2) mountpoint strings are composed of valid characters, which allows local users to cause a denial of service (mtab corruption) via a crafted string.
CVE-2010-0787 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-0787): client/mount.cifs.c in mount.cifs in smbfs in Samba 3.0.22, 3.0.28a, 3.2.3, 3.3.2, 3.4.0, and 3.4.5 allows local users to mount a CIFS share on an arbitrary mountpoint, and gain privileges, via a symlink attack on the mountpoint directory file.
Those versions of samba are no longer in portage. Is it needed to keep this open?
(In reply to comment #2) > Those versions of samba are no longer in portage. Is it needed to keep this > open? Thanks, Victor. We need to decide if this requires a GLSA. GLSA Vote: no.
Vote: YES.
GLSA vote: YES, request filed.
For the record: 3.4.6 was the first fixed version and stable.
This issue was resolved and addressed in GLSA 201206-29 at http://security.gentoo.org/glsa/glsa-201206-29.xml by GLSA coordinator Stefan Behte (craig).
(In reply to comment #7) > This issue was resolved and addressed in > GLSA 201206-29 at http://security.gentoo.org/glsa/glsa-201206-29.xml > by GLSA coordinator Stefan Behte (craig). This GLSA lists ">=net-fs/mount-cifs-3.4.6", but the only available versions are: 3.0.25c 3.0.28 3.0.30 With mount-cifs as it's own package, how are the version numbers being tracked against samba?
reopening. Just p.masked mount-cifs since it's dead upstream and the upgrade-path is to use cifs-utils instead (which contains mount.cifs). So there is no 3.4.6 of mount-cifs.
Indeed. I think GLSA 201206-29 is incorrect. @security, updated draft is available. Please review.
dropped
@Security team: Is it still needed to keep this open? Affected versions are long gone, last activity on this bug was more than 1 year ago
Thanks for bringing attention to this and sorry for such enormous delay
This issue was resolved and addressed in GLSA 201206-29 at http://security.gentoo.org/glsa/glsa-201206-29.xml by GLSA coordinator Sergey Popov (pinkbyte).