linux-kernel - Re: [linux-cifs-client] [PATCH] Remove information leak in Linux CIFS clientg

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <524f69650801191455g5eab5edfw80f27136662a465c@mail.gmail.com>
Date:	Sat, 19 Jan 2008 16:55:53 -0600
From:	"Steve French" <smfrench@...il.com>
To:	"Andi Kleen" <andi@...stfloor.org>
Cc:	simo <idra@...ba.org>, linux-kernel@...r.kernel.org,
	linux-cifs-client@...ts.samba.org, samba-technical@...ts.samba.org
Subject: Re: [linux-cifs-client] [PATCH] Remove information leak in Linux CIFS clientg

On Jan 19, 2008 4:30 PM, Andi Kleen <andi@...stfloor.org> wrote:
> On Sat, Jan 19, 2008 at 04:06:57PM -0600, Steve French wrote:
> > The access denied message in the dmesg log reveals no more information
> > than strace on stat of a local file does (which also returns access
>
> You can't strace a process you don't own. And you might not be able
> to access the directory below which the file is.

If you can't access the directory that the file is in then you get
access denied on stat of the file (local over ext3 or remote over
cifs) - it does not tell you anything about whether the file existed
or not.  If you do "stat
/mnt/dir-with-0700-perm/file-which-does-not-exist"  I get access
denied.  I don't think that it really tells you anything interesting
since the same error comes back whether or not the file existed.
Other unexpected errors (e.g. -EIO) should be logged because they
indicate possibly severe problems with the network, but also don't
tell you anything about whether the file exists.

> Logging the path would be only safe if you determine that the
> file and all its parent directories were world read (and accessable)able,
> but that would be probably difficult.

If the parent of the parent were not readable/accessable then you
would not have gotten this far (the stat of the parent directory
rather than the file would have returned the error).  If the parent
were readable then the access denied on stat is the same over cifs and
ext3 - and the logging of the error only occurs in cases like EIO in
which e.g. the network has crashed (but you can't tell from the error
whether the file exists or not).  I don't mind taking out the path
name from the logging of EIO in this case but it could make debugging
harder if we ever hit a strange bug.

-- 
Thanks,

Steve
--
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/