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

Message-ID: <524f69650801191632h71f340band275d8abfe7ad0f3@mail.gmail.com>
Date:	Sat, 19 Jan 2008 18:32:11 -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

Just merged into the cifs-2.6 tree, changing the last patch as you
just suggested to take out the logged path name.

On Jan 19, 2008 5:25 PM, Andi Kleen <andi@...stfloor.org> wrote:
> On Sat, Jan 19, 2008 at 04:55:53PM -0600, Steve French wrote:
> > 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.
>
> The problem is that the file name ends up in the log for everybody to
> read even if they're totally unrelated. So if someone in a protected directory
> tree where they have access to does something that is denied the
> file names will still leak to everybody else to the log.
>
> e.g. more concrete example. you do something and get that message.
>
> Now even 'nobody" running in a chroot will know that you tried
> that and that at least parts of the file name likely exist.
>
> That is an information leak and imho a privacy problem.
>
> > 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.
>
> Sure errors should be logged, but not with path names.
>
> -Andi
>



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