linux-kernel - Re: /proc/[pid]/mem write implications

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: <bf0d05d510da3650d12fb66a65a3ce37.squirrel@webmail.greenhost.nl>
Date:	Mon, 30 Jan 2012 09:10:03 +0100
From:	"Indan Zupancic" <indan@....nu>
To:	"Alan Cox" <alan@...rguk.ukuu.org.uk>
Cc:	"Cong Wang" <xiyou.wangcong@...il.com>,
	"Bryan Jacobs" <its@...ytoremember.us>,
	linux-kernel@...r.kernel.org
Subject: Re: /proc/[pid]/mem write implications

Hello,

On Sun, January 29, 2012 15:19, Alan Cox wrote:
>> > But I think that allowing arbitrary processes to write to **their own**
>> > memory via a file descriptor might in itself be problematic. Please,
>> > help me understand how this is safe.
>>
>> You will have a sysctl to control if it is writable.
>
> The problem is not that the check is done in write, the problem is more
> fundamental - the open should bind to the memory of the executable image
> currently running, instead it effectively late binds each write to the
> image now being run. That is the root cause.
>
> What's sad about this is that people went and re-introduced the bug and
> clearly didn't think to spend 2 minutes asking Google why the checks were
> there originally.

How did the patch enabling it get past review?

>
> 2006 thread
>
> http://lkml.indiana.edu/hypermail/linux/kernel/0605.2/1359.html
>
> 2004 thread
>
> http://lkml.indiana.edu/hypermail/linux/kernel/0407.0/1169.html
>
> 2002 thread
>
> http://www.eros-os.org/pipermail/cap-talk/2002-May/000922.html
>
>
> If you really want to fix this then you need to bind /proc/self/mem to
> the executable image in question, and you need to effectively revoke()
> that on exec so it can't be used to pin old images into memory.
>
> Fix that and the rest falls out in the wash.

There is process_vm_writev() now, so there is no need for a writeable
/proc/*/mem. User space can't count on it being writeable anyway.

Actually, as there is process_vm_readv() too now, I think /proc/*/mem
should be removed altogether.

Greetings,

Indan


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