linux-kernel - problems with latest smbfs changes on 2.4.34 and security backports

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070117100030.GA11251@clandestino.aytolacoruna.es>
Date:	Wed, 17 Jan 2007 11:00:30 +0100
From:	Santiago Garcia Mantinan <manty@...ian.org>
To:	linux-kernel@...r.kernel.org, debian-kernel@...ts.debian.org
Subject: problems with latest smbfs changes on 2.4.34 and security backports

Hi!

I have discovered a problem with the changes applied to smbfs in 2.4.34 and
in the security backports like last Debian's 2.4 kernel update these changes
seem to be made to solve CVE-2006-5871 and they have broken symbolic links
and changed the way that special files (like devices) are seen.

For example:
Before: symbolic links were seen as that, symbolic links an thus if you tried
to open the file the link was followed and you ended up reading the
destination file
Now: symbolic links are seen as normal files (at least with a ls) but their
length (N) is the length of the symbolic link, if you read it, you'll get the
first N characters of the destination file. For example, on my filesystem
bin/sh is a symlink to bash, thus it is 4 bytes long, if I to a cat bin/sh I
get ELF (this is, the first 4 characters of the bash program, first one
being a DEL).

Another example:
Before: if you did a ls of a device file, like dev/zero you could see it as
a device, if you tried opening it, it wouldn't work, but if you did a cp -a
of that file to a local filesystem the result was a working zero device.
Now: the devices are seen as normal files with a length of 0 bytes.

Seems to me like a mask is erasing some mode bits that shouldn't be erased.

I have carried my tests on a Debian Sarge machine always mounting the share
using: smbmount //server/share /mnt without any other options. The tests
were carried on a unpatched 2.4.34 comparing it to 2.4.33 and also on
Debian's 2.4.27 comparing 2.4.27-10sarge4 vs -10sarge5. The server is a
samba 3.0.23d and I have experienced the same behaviour with samba's
unix extensions = yes and unix extensions = no.

I don't know what else to add, if you need any more info or want me to do
any tests just ask for it.

Regards...
-- 
Santiago García Mantiñán
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/