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: <20120129141920.497d96d4@pyramind.ukuu.org.uk>
Date:	Sun, 29 Jan 2012 14:19:20 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Cong Wang <xiyou.wangcong@...il.com>
Cc:	Bryan Jacobs <its@...ytoremember.us>, linux-kernel@...r.kernel.org
Subject: Re: /proc/[pid]/mem write implications

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

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.

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