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: <20080119223029.GA5786@one.firstfloor.org>
Date:	Sat, 19 Jan 2008 23:30:29 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Steve French <smfrench@...il.com>
Cc:	simo <idra@...ba.org>, Andi Kleen <andi@...stfloor.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 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.

But there is no such access control on "dmesg". So if there is an
access error you leak the potentially protected information in 
the file name

> denied and displays access denied), but I agree that logging on
> -EACCESS on lookup does clutter the log.
> 
> I think it is ok to log a message on unexpected errors (for
> QueryPathInfo those would include anything other than ENOENT and
> EACCESS - Simo, can you think of others?)  I don't mind ratelimiting
> logging on this clause (for errors other than ENOENT and EACCESS) but
> it would complicate the code for a case I have not seen in the wild.
> 
> I prefer the following to remove the log cluttering on this case:

That would still be an information leak for other errors.

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.

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