linux-kernel - Re: v2.6.28-rc1: readlink /proc/*/exe returns uninitialized data to userspace

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: <m1hc6nbw2c.fsf@frodo.ebiederm.org>
Date:	Tue, 04 Nov 2008 02:54:35 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Alexey Dobriyan <adobriyan@...il.com>
Cc:	Vegard Nossum <vegard.nossum@...il.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	"Koyama, Yoshiya" <Yoshiya.Koyama@...com>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Ingo Molnar <mingo@...e.hu>,
	Pekka Enberg <penberg@...helsinki.fi>,
	LKML <linux-kernel@...r.kernel.org>, Greg KH <greg@...ah.com>,
	Kay Sievers <kay.sievers@...y.org>,
	linux-fsdevel@...r.kernel.org
Subject: Re: v2.6.28-rc1: readlink /proc/*/exe returns uninitialized data to userspace

Alexey Dobriyan <adobriyan@...il.com> writes:

> On Tue, Nov 04, 2008 at 10:39:19AM +0100, Vegard Nossum wrote:
>> # uname -a
>> Linux ubuntu 2.6.28-rc2-next-20081031 #60 SMP Sat Nov 1 13:19:49 CET
>> 2008 i686 GNU/Linux
>> # prelink -mRf /sbin/udevd
>> # ./a.out /proc/4764/exe
>> warning: /proc/4764/exe: got return value 38, expected 11
>> 2f7362696e2f756465766400fffffffffdfffffffffffff7ffffbfff202864656c6574656429
>> /sbin/udevd                  (deleted)
>
> reproduced
>
> As I said previously, kmemcheck rocks (slowly). :-)

It is reproducible here as well.  At least to the point of the
strange readlink length.

prelink generates a new executable and renames it on top
of the old executable.  So I'm guessing something on the unlink
and rename path is what is giving us the strange length.

Hmm.  The string: '/sbin/udevd.#prelink#.J9NyXV (deleted)'
is 38 bytes long...   So I'm guessing d_move is doing something
wrong and we are not seeing the name string we expect.

Why do we see /sbin/udevd and not /sbin/udevd.#prelink#.J9NyXV 
after d_move.  It looks like both names are short enough that
they are inline.

Oh.  I see.  switch_names when both names are internal,
does a memcpy of the new name to the target name,
but it doesn't do anything with the source name.
Then later we swap the name lengths.

So the length on the dentry no longer matches the data
we put in the buffer.

Certainly not a resource leak or any kind of deadlock.
And the length is right.  But it is an information leak.

I suppose a clever person could figure out how to steal
information that way.

The nice fix would be to keep the old length in this case,
so we don't have a name mangled because someone renamed
on top of us.  But that is inconsistent.

Eric

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