Bug 7104 - "wide links" and "unix extensions" are incompatible; CVE-2010-0926
"wide links" and "unix extensions" are incompatible; CVE-2010-0926
Status: RESOLVED FIXED
Product: Samba 3.5
Classification: Unclassified
Component: File services
3.5.0pre2
All All
: P3 normal
: ---
Assigned To: Karolin Seeger
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-02-05 17:12 UTC by Jeremy Allison
Modified: 2012-03-17 00:01 UTC (History)
0 users

See Also:


Attachments
git-am fix for 3.5.0. (5.75 KB, patch)
2010-02-05 17:27 UTC, Jeremy Allison
no flags Details
git-am fix for 3.4.6. (5.86 KB, patch)
2010-02-05 18:12 UTC, Jeremy Allison
no flags Details
git-am fix for 3.3.11. (6.09 KB, patch)
2010-02-05 18:26 UTC, Jeremy Allison
vl: review+
Details
git-am fix for 3.4.6. (6.11 KB, patch)
2010-02-05 18:27 UTC, Jeremy Allison
vl: review+
Details
git-am fix for 3.5.0 (6.01 KB, patch)
2010-02-05 18:30 UTC, Jeremy Allison
vl: review+
Details
Supplementary git-am patch for 3.5.0. (4.06 KB, patch)
2010-02-11 12:24 UTC, Jeremy Allison
no flags Details
git-am patch for 3.5.0. (4.03 KB, patch)
2010-02-11 13:06 UTC, Jeremy Allison
no flags Details
git-am patch for 3.4.6 (4.03 KB, patch)
2010-02-11 13:09 UTC, Jeremy Allison
no flags Details
git-am patch for 3.3.11. (4.02 KB, patch)
2010-02-11 13:47 UTC, Jeremy Allison
no flags Details
git-am jumbo patch for 3.5.0rc3. (6.50 KB, patch)
2010-02-11 17:57 UTC, Jeremy Allison
no flags Details
git-am jumbo patch for 3.5.0rc3 (fixed version). (6.18 KB, patch)
2010-02-11 18:02 UTC, Jeremy Allison
vl: review+
Details
git-am jumbo patch for 3.4.6. (6.17 KB, patch)
2010-02-11 18:04 UTC, Jeremy Allison
vl: review+
Details
git-am jumbo patch for 3.3.11. (6.16 KB, patch)
2010-02-11 18:13 UTC, Jeremy Allison
vl: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Allison 2010-02-05 17:12:17 UTC
See the youtube video:

http://www.youtube.com/watch?v=NN50RtZ2N74&aia=true

for details (first bug report with its own video :-).

Jeremy.

--------------------------------------------------------
A user named "kcopedarookie" posted what they claim to be a video of a zero-day exploit in Samba on youtube yesterday.

The video shows modifications to smbclient allowing /etc/passwd to be downloaded from a remote server.

The issue is actually a default insecure configuration in Samba.
Quick FAQ: What do I do !

Set:

  wide links = no

in the [global] section of your smb.conf and restart smbd to eliminate this problem.

Longer FAQ: The real issue

The problem comes from a combination of two features in Samba, each of which on their own are useful to Administrators, but in combination allow users to access any file on the system that their logged in username has permissions to read (this is not a privilege escalation problem).

By default Samba ships with the parameter "wide links = yes", which allows Administrators to locally (on the server) add a symbolic link inside an exported share which SMB/CIFS clients will follow.

As an example, given a share definition:

  [tmp]
	path = /tmp
	read only = no
	guest ok = yes

The administrator could add a symlink:

  $ ln -s /etc/passwd /tmp/passwd

and SMB/CIFS clients would then see a file called "passwd" within the [tmp] share that could be read and would allow clients to read /etc/passwd.

If the "wide links" parameter is set to "no", any attempt to read this file will fail with an "access denied" error.

The problem occurs as Samba allows clients using the UNIX extensions (which are also turned on by default) to create symlinks on remotely mounted shares on which they have write access that point to any path on the file system.

This is by design, as applications running on UNIX clients may have good reasons to create symlinks anywhere on the filesystem they have write access that point to local files (such as /etc/passwd).

UNIX clients will resolve these links locally, but Windows clients will resolve them on the server. It is this combination that causes the problem.

All future versions of Samba will have the parameter "wide links" set to "no" by default, and the manual pages will be updated to explain this issue.
--------------------------------------------------------
Comment 1 Jeremy Allison 2010-02-05 17:27:25 UTC
Created attachment 5279 [details]
git-am fix for 3.5.0.
Comment 2 Jeremy Allison 2010-02-05 18:12:44 UTC
Created attachment 5280 [details]
git-am fix for 3.4.6.
Comment 3 Jeremy Allison 2010-02-05 18:26:20 UTC
Created attachment 5281 [details]
git-am fix for 3.3.11.
Comment 4 Jeremy Allison 2010-02-05 18:27:03 UTC
Created attachment 5282 [details]
git-am fix for 3.4.6.

Fix including removal of unused NTSTATUS status variable.
Comment 5 Jeremy Allison 2010-02-05 18:30:42 UTC
Created attachment 5283 [details]
git-am fix for 3.5.0

Fix including removal of unused NTSTATUS status variable.
Comment 6 Karolin Seeger 2010-02-09 03:30:08 UTC
Pushed to all branches.
Closing out bug report.

Thanks!
Comment 7 Jeremy Allison 2010-02-11 12:19:22 UTC
Re-opening bug due to an issue reported with "wide links = no", and a root preexec script that creates the share being connected to. I have reproduced this and have a fix.

Patch for all branches to follow.

Jeremy.
Comment 8 Jeremy Allison 2010-02-11 12:24:58 UTC
Created attachment 5325 [details]
Supplementary git-am patch for 3.5.0.

Suplementary patch for bug #7104 - "wide links" and "unix extensions" are incompatible.
    
    Bug reported by Ralf Zimmermann <r.zimmermann@siegnetz.de>. Reproduced by jra.
    
    If the target directory of a share doesn't exist, but is designed to
    be created by a "root preexec" script call, then the widelinks check
    is done too early - thus preventing the user from connecting to the
    share.
    
    Fix is to re-arrange the order of checks in make_connection_snum()
    to always do the following order of operations:
    
    (1). Turn off wide links if unix extensions = yes.
    (2). Call any root preexec scripts.
    (3). Canonicalize the share path to remove any symlinks (ie. end
    up with the realpath in the connection_struct).
Comment 9 Jeremy Allison 2010-02-11 13:06:00 UTC
Created attachment 5326 [details]
git-am patch for 3.5.0.

Bug reported by Ralf Zimmermann <r.zimmermann@siegnetz.de>. Reproduced by jra.

If the target directory of a share doesn't exist, but is designed to
be created by a "root preexec" script call, then the widelinks check
is done too early - thus preventing the user from connecting to the
share.

Fix is to re-arrange the order of checks in make_connection_snum()
to always do the following order of operations:

(1). Turn off wide links if unix extensions = yes.
(2). Call any root preexec scripts.
(3). Call any user preexec scripts.
(4). Canonicalize the share path to remove any symlinks (ie. end
up with the realpath in the connection_struct).

Includes patches cd18695fc2e4d09ab75e9eab2f0c43dcc15adf0b
and 94865e4dbd3d721c9855aada8c55e02be8b3881e from master.
Comment 10 Jeremy Allison 2010-02-11 13:09:40 UTC
Created attachment 5327 [details]
git-am patch for 3.4.6
Comment 11 Jeremy Allison 2010-02-11 13:47:48 UTC
Created attachment 5328 [details]
git-am patch for 3.3.11.
Comment 12 Jeremy Allison 2010-02-11 17:57:53 UTC
Created attachment 5329 [details]
git-am jumbo patch for 3.5.0rc3.

Jumbo patch discussed with Volker.
Comment 13 Jeremy Allison 2010-02-11 18:02:42 UTC
Created attachment 5330 [details]
git-am jumbo patch for 3.5.0rc3 (fixed version).

Sigh. Get the jumbo patch right :-).
Comment 14 Jeremy Allison 2010-02-11 18:04:55 UTC
Created attachment 5331 [details]
git-am jumbo patch for 3.4.6.
Comment 15 Jeremy Allison 2010-02-11 18:13:00 UTC
Created attachment 5332 [details]
git-am jumbo patch for 3.3.11.

Jumbo patch discussed with Volker.
Comment 16 Volker Lendecke 2010-02-12 13:03:39 UTC
Comment on attachment 5330 [details]
git-am jumbo patch for 3.5.0rc3 (fixed version).

Ok, does the job. Thanks!

Volker
Comment 17 Volker Lendecke 2010-02-12 13:22:49 UTC
Ok, I think this should be it. Pending more patches :-)

Karo, can you get those 3 patches into the respective branches?

Thanks,

Volker
Comment 18 Karolin Seeger 2010-02-15 03:21:17 UTC
(In reply to comment #17)
> Ok, I think this should be it. Pending more patches :-)
> 
> Karo, can you get those 3 patches into the respective branches?

Pushed to all branches.
Closing out bug report.

Thanks!