Bug 82041 - ignores wide links, serving files which shouldn't be served
Summary: ignores wide links, serving files which shouldn't be served
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: samba
Version: 8.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jay Fenlason
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-01-16 18:05 UTC by Chris Ricker
Modified: 2014-08-31 23:24 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-04-08 07:00:50 UTC


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2003:137 0 high SHIPPED_LIVE : New samba packages fix security vulnerability 2003-04-08 04:00:00 UTC

Description Chris Ricker 2003-01-16 18:05:35 UTC
Samba has two options which control Samba's behavior when a Samba client
requests a file which is a symbolic link.

follow symlinks = yes

instructs Samba to give the requesting client the target of the symlink

If follow symlinks = yes, then a second option enters in:

wide links = yes

instructs Samba to serve the target of the symlink, even if the target is
outside the directory space being shared

wide links = no

instructs Samba to serve the target of the symlink only when the target is
within the directory space being shared

This behavior is documented in the Samba documentation

http://us2.samba.org/samba/docs/man/smb.conf.5.html#FOLLOWSYMLINKS
http://us2.samba.org/samba/docs/man/smb.conf.5.html#WIDELINKS

However, on Red Hat 8 (samba-2.2.5-10) this option does not work. Whether wide
links = yes or wide links = no, targets of symlinks outside shared space are
always served if follow symlinks = yes.

This has the usual obvious security implications....


To reproduce this easily, on one machine use a trivial smb.conf file

# cat /etc/samba/smb.conf
[global]
workgroup = EXAMPLE
netbios name = station1
follow symlinks = yes

[tmp]
path = /tmp
writeable = yes
guest ok = yes
wide links = no


Then on that machine

# cd /tmp
# ln -s /etc/passwd .

Connect from another machine (guest access is fine) and download passwd. Your
download will succeed, even though it shouldn't

Comment 1 Jay Fenlason 2003-01-31 22:52:43 UTC
This only occurs on symlinks to files, rather than symlinks to directories.  I
get the same behavior with samba-2.2.7a on an OpenBSD-2.1 system, so this is
either a generic Samba bug or an undocumented feature.  I've opened a bug report
upstream, so we'll see what they say.

Note that this does not allow reading of files that the user cannot usually
read: a symlink to /etc/shadow correctly returns "Access Denied" when a Windows
client attempts to read it.  Also note that any user that can create a symlink
to /etc/passwd can also do "cp /etc/passwd resume.txt", so the actual security
enhancement in blocking symlinks to files is minimal.

Comment 2 Jay Fenlason 2003-03-06 20:28:38 UTC
This is fixed in samba-2.2.8pre1 and later.  I'll probably make errata after
2.2.8 is released.

Comment 3 Kjartan Maraas 2003-04-03 19:42:20 UTC
These were included in the current errata, right? Close this then?

Comment 4 Mark J. Cox 2003-04-08 07:00:50 UTC
An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2003-137.html



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