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:	Tue, 12 Jul 2016 11:52:09 -0500
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Cyrill Gorcunov <gorcunov@...il.com>
Cc:	Stanislav Kinsburskiy <skinsbursky@...tuozzo.com>,
	peterz@...radead.org, mingo@...hat.com, mhocko@...e.com,
	keescook@...omium.org, linux-kernel@...r.kernel.org,
	mguzik@...hat.com, bsegall@...gle.com, john.stultz@...aro.org,
	oleg@...hat.com, matthltc@...ibm.com, akpm@...ux-foundation.org,
	luto@...capital.net, vbabka@...e.cz, xemul@...tuozzo.com
Subject: Re: [PATCH] prctl: remove one-shot limitation for changing exe link

Cyrill Gorcunov <gorcunov@...il.com> writes:

> On Tue, Jul 12, 2016 at 07:30:29PM +0400, Stanislav Kinsburskiy wrote:
>> This limitation came with the reason to remove "another
>> way for malicious code to obscure a compromised program and
>> masquerade as a benign process" by allowing "security-concious program can use
>> this prctl once during its early initialization to ensure the prctl cannot
>> later be abused for this purpose":
>> 
>> http://marc.info/?l=linux-kernel&m=133160684517468&w=2
>> 
>> But the way how the feature can be used is the following:
>> 
>> 1) Attach to process via ptrace (protected by CAP_SYS_PTRACE)
>> 2) Unmap all the process file mappings, related to "exe" file.
>> 3) Change exe link (protected by CAP_SYS_RESOURCE).
>> 
>> IOW, some other process already has an access to process internals (and thus
>> it's already compromised), and can inject fork and use the child of the
>> compromised program to masquerade.
>> Which means this limitation doesn't solve the problem it was aimed to.
>> 
>> While removing this limitation allow to replace files from underneath of a
>> running process as many times as required. One of the use cases is network
>> file systems migration (NFS, to be precise) by CRIU.
>> 
>> NFS mount can't be mounted on restore stage because network is locked.
>> To overcome this limitation, another file system (FUSE-based) is used. Then
>> opened files replaced by the proper ones NFS is remounted.
>> Thus exe link replace has to be done twice: first on restore stage and second
>> - when actual NFS was remounted.
>> 
>> Signed-off-by: Stanislav Kinsburskiy <skinsbursky@...tuozzo.com>
>
> Persistent exe-link doesn't guarantee anything if you have rights to ptrace
> task and inject own code into (from security POV). So lets rip it out.
>
> Acked-by: Cyrill Gorcunov <gorcunov@...nvz.org>

I believe the original concern was someone injecting a code into a
process and playing silly buggers with the exe link.  Someone who does
not have ptrace capability.

It is completely not ok to change this until someone goes back to the
original conversation and looks at the original threat model, and
refutes it.

Eric

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ