Bug 562568 (CVE-2010-0926) - CVE-2010-0926 samba: insecure "wide links" default
Summary: CVE-2010-0926 samba: insecure "wide links" default
Alias: CVE-2010-0926
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL: http://www.youtube.com/watch?v=NN50Rt...
Depends On: 722553 722556
Blocks: 721358 734229 742493
TreeView+ depends on / blocked
Reported: 2010-02-07 13:17 UTC by Jan Lieskovsky
Modified: 2021-02-25 01:43 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-02-21 07:59:16 UTC

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2012:0313 0 normal SHIPPED_LIVE Low: samba security, bug fix, and enhancement update 2012-02-21 07:25:13 UTC

Description Jan Lieskovsky 2010-02-07 13:17:45 UTC
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 13:19:27 UTC
Link to public Metasploit module:


Comment 4 Tomas Hoger 2010-02-08 14:34:52 UTC
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-06 04:09:00 UTC
This has been assigned CVE-2010-0926.

Comment 10 Vincent Danen 2011-03-28 17:32:50 UTC
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 20:29:54 UTC
This was corrected in upstream versions 3.4.6 and 3.5.0:


Comment 13 errata-xmlrpc 2012-02-21 04:31:31 UTC
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.