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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ