[Samba] Urgent, Security: Privilege Escalation in 3.0.24?

[moe]

Hi list,

we have spotted a serious problem with our Samba
(Debian version 3.0.24-6) on linux 2.4.31, ext2 with ACLs enabled.

We use "hide unreadable = yes" to reduce clutter for our
users. Today we noticed that with this option enabled any
linux client can access and read *all* directories under the
share, even directories that are owned by root and set to 0700.
No ACLs are set on the directories in question nor on any
parent directory.

We have reproduced the same problem on a separate gentoo box
(Kernel 2.6.18, Samba 3.0.24-r3, ext3 without acl support).

I'd be glad if someone could look at our smb.conf (pasted
at the end of this mail) and comment on whether this is a
configuration problem or if we have hit a bug.

Below a shell transcript to illustrate the problem:

###
### commands executed as root on the samba host
###

##
## 1. create the test directory and file,
##    make them accessible only for root
##

root at srv:~# cd /vol0
root at srv:/vol0# mkdir test
root at srv:/vol0# echo "secret" >test/file.txt
root at srv:/vol0# chown -R root:root test
root at srv:/vol0# chmod -R 0700 test
root at srv:/vol0# ls -al
total 12
drwx------    2 root root    4096 Jul 12 17:02 .
drwxrwx---  139 root users   4096 Jul 12 15:04 ..
-rwx------    1 root root       7 Jul 12 17:02 file


##
## 2. create a new samba user
##

root at srv:/vol0# useradd -m -g users testuser

root at srv:/vol0# smbpasswd -a testuser
New SMB password:
Retype new SMB password:
Added user testuser.

root at srv:/vol0# id testuser
uid=1137(testuser) gid=100(users) groups=100(users)

root at srv:/vol0# pdbedit -L -u testuser        
Unix username:        testuser
NT username:          
Account Flags:        [U          ]
User SID:             S-1-5-21-3613053638-1853485231-1729343208-3274
Primary Group SID:    S-1-5-21-3613053638-1853485231-1729343208-513
Full Name:            
Home Directory:       \\srv\testuser
HomeDir Drive:        
Logon Script:         
Profile Path:         \\srv\testuser\profile
Domain:               FOO
Account desc:         
Workstations:         
Munged dial:          
Logon time:           0
Logoff time:          Tue, 19 Jan 2038 04:14:07 CET
Kickoff time:         Tue, 19 Jan 2038 04:14:07 CET
Password last set:    Thu, 12 Jul 2007 17:05:54 CEST
Password can change:  Thu, 12 Jul 2007 17:05:54 CEST
Password must change: Tue, 19 Jan 2038 04:14:07 CET
Last bad password   : 0
Bad password count  : 0
Logon hours         : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

root at srv:/vol0# su - testuser

testuser at srv:~$ ls /vol0/test
ls: /vol0/test: Permission denied

testuser at srv:~/$ cat /vol0/test/test.txt
cat: /vol0/test/test.txt: Permission denied


###
### commands executed as user (uid 1023) on
### a remote linux client
###

##
## 3. mount the remote share
##

someuser at ws:~$ mkdir fileserver
someuser at ws:~$ smbmount //srv/data fileserver -o username=testuser
Password: 

##
## 4. do things that should not be possible
##

someuser at ws:~$ ls -al fileserver
total 8
drwxr-xr-x  1 someuser users 4096 Jul 12 17:02 .
drwxr-xr-x  1 someuser users 4096 Jul 12 17:28 ..

### comment: this is correct, the "test" directory doesn't show

someuser at ws:~$ ls -al fileserver/test
total 8
drwxr-xr-x  1 someuser users 4096 Jul 12 17:02 .
drwxr-xr-x  1 someuser users 4096 Jul 12 17:28 ..

### comment: this should not be possible

someuser at ws:~$ cat fileserver/test/file.txt
secret


###
### end of transcript
###


further observations:

- during one session i can sometimes cd to the "test"-directory,
  sometimes i get "Permission denied". also sometimes
  the directory listing for the "test" directory shows the
  contained files, sometimes it doesn't. intermittent bug?

- when we set "hide unreadable = no" (but leave the rest of
  smb.conf as is) the permission checking seems to work properly.
  remote clients can then not get into the "test" directory.
  i am not quite sure if this really works around the actual
  problem or only disguises it (i.e. does it cause the client
  to honor the access bits or does it cause the server to
  *enforce* them?)


well, and finally our smb.conf...

### smb.conf ###

[global]
  workgroup = foo
  unix extensions = no
  server string = fileserver
  
  dns proxy = no
  
  log file = /var/log/samba/log.%U.%m.log
  
  max log size = 50000
  
  log level = 0 vfs:2
  syslog = 0
  panic action = /usr/share/samba/panic-action %d
  
  security = user
  encrypt passwords = true
  obey pam restrictions = yes
  invalid users = root
  
  passwd program = /usr/bin/passwd %u
  passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n .
  
  socket options = TCP_NODELAY

[data]
  path = /vol0
  vfs objects = full_audit
  full_audit:prefix = %u|%I
  full_audit:success = open opendir rmdir unlink rename write chmod chmod_acl mkdir close chown chmod_acl fchmod_acl fset_nt_acl aio_write
  full_audit:failure = open opendir unlink
  full_audit:facility = LOCAL7
  full_audit:priority = ALERT
  guest ok = no
  writable = yes
  share modes = yes
  force directory mode = 0770
  force create mode = 0660
  directory security mask = 0000
  enable privileges = no
  hide unreadable = yes

### end of smb.conf ###


i'm looking forward to your feedback as this is obviously a
very serious issue. i'm still hoping that we just made a
configuration mistake but the fact that it misbehaves the
same way on the second, vanilla gentoo installation (with a
mostly default config) makes it seem unlikely to me.

i apologize in advance if we're just missing something
obvious here.


regards, moe