Bug 562568 - (CVE-2010-0926) CVE-2010-0926 samba: insecure "wide links" default
CVE-2010-0926 samba: insecure "wide links" default
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 722553 722556
Blocks: 721358 734229 742493
  Show dependency treegraph
Reported: 2010-02-07 08:17 EST by Jan Lieskovsky
Modified: 2015-08-19 04:43 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-02-21 02:59:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jan Lieskovsky 2010-02-07 08:17:45 EST
Security researcher called "Kingcope" pointed out:

  [1] http://seclists.org/fulldisclosure/2010/Feb/82
  [2] http://www.youtube.com/watch?v=NN50RtZ2N74

and detailed:

  [3] http://seclists.org/fulldisclosure/2010/Feb/99

a deficiency in the behaviour of Samba server, providing
SMB/CIFS services to the clients.

Samba server, in the default configuration, is shipped
with configuration file parameter "wide links" set to
"yes" ("wide links = yes"). If a local user would first
locally create a symbolic link, which target would point
to some system sensitive file / directory and link name
of this link would be placed into an exported Samba share,
with write access for Samba users, this might allow a remote
attacker to read, list and retrieve files, behind the target
of the symbolic link.

Samba upstream review of reasons and impact of this issue:

  [4] http://marc.info/?l=samba-technical&m=126539387432412&w=2

As mentioned in [4] the problem "is actually a default insecure
configuration in Samba." and "comes from a combination of two 
features in Samba, each of which on their own are useful to

Workaround -- to prevent occurrence of this deficiency set:

wide links = no

in the [global] section of your smb.conf and restart the
Samba (smbd) daemon. This will ensure, remote Samba clients
will not follow symbolink links, exported in Samba shares,
to their target anymore (thus prevent the potential disclosure
of sensitive data).
Comment 1 Jan Lieskovsky 2010-02-07 08:19:27 EST
Link to public Metasploit module:

Comment 4 Tomas Hoger 2010-02-08 09:34:52 EST
Upstream bug report and patch to make sure "wide links" and "unix extensions" can not both be enabled on one share:

Comment 7 Vincent Danen 2010-03-05 23:09:00 EST
This has been assigned CVE-2010-0926.
Comment 10 Vincent Danen 2011-03-28 13:32:50 EDT
Updated: 2012-02-21


This issue was addressed in Samba packages in Red Hat Enterprise Linux 5. It did not affect Samba packages in Red Hat Enterprise Linux 6.

The Red Hat Security Response Team has rated this issue as having low security impact. There is no plan to address this flaw in Red Hat Enterprise Linux 4.

To prevent this issue, disable "wide links" or "unix extensions" in the Samba configuration file (/etc/samba/smb.conf) and restart smbd (service smb restart). Disabled "wide links" ensure that remote Samba clients will not have wide symbolic links (links pointing outside of the shared directory) resolved on the server side when processing requests from a client that does not support UNIX extensions. Disabled "unix extensions" prevents creation of wide links by malicious clients which support UNIX extensions. For further information, please view http://www.samba.org/samba/news/symlink_attack.html
Comment 11 Vincent Danen 2011-03-30 16:29:54 EDT
This was corrected in upstream versions 3.4.6 and 3.5.0:

Comment 13 errata-xmlrpc 2012-02-20 23:31:31 EST
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2012:0313 https://rhn.redhat.com/errata/RHSA-2012-0313.html

Note You need to log in before you can comment on or make changes to this bug.