bugtraq - Re: /proc filesystem allows bypassing directory permissions on Linux

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1256403548.24148.10.camel@mare-infinitum.sigsegv.cx>
Date: Sat, 24 Oct 2009 17:59:08 +0100
From: Anton Ivanov <arivanov@...segv.cx>
To: Dan Yefimov <dan@...htwave.net.ru>
Cc: Matthew Bergin <matt.bergin@...mail.com>,
	bugtraq@...urityfocus.com
Subject: Re: /proc filesystem allows bypassing directory permissions
	on	Linux

[snip]

> If the application sets wrong permissions on files, it is by definition broken. 
> Yes, setting more restrictive directory permissions can to some extent mitigate 
> the problem, but not really fix it. What if that application is used by multiple 
> users?

There have been cases and quite a few. 

My first thoughts were about Word Perfect. Actually it is just a
representative of a wider class of apps there. The semantics of locking
on Windows and Unix differ and when apps get ported (especially using a
toolkit) people do not account for the advisory nature of Unix flock().
As a result files that were reasonably safe in the original environment
due to OS-level exclusive locking stop being so on the Unix port. 

Also, while it is a wonderful position to stand up and proclaim that
application is broken in a commercial environment you quite often have
no choice but to bolt it down to the maximum extent possible until the
developers fix it and directory permissions is the valid way of doing
so.

> The problem raised in the original mail is to some extent artificial, as the 
> only users able to access /proc/<PID>/fd/ are the user with the same UID, as the 
> process EUID, and root, and if the process is either setuid or setgid, 
> /proc/<PID>/fd of that process is accessible only by root. Not to tell about 
> that /proc/<PID>/fd/ contains only symbolic links, not files, so I can't 
> understand, how the original reporter managed to gain access to the file in the 
> restricted directory using that symlink.

The perms are definitely broken and without a code audit on procfs I
would not bet that this is limited just to this rather obscure test
case. 

To be honest, I hope that it is limited to this rather obscure test
case. If it is not there may be entertaining ramifications.

Cheers,

-- 
   Understanding is a three-edged sword:
            your side, their side, and the truth. --Kosh Naranek

A. R. Ivanov
E-mail:  aivanov@...segv.cx
WWW:     http://www.sigsegv.cx/
pub 1024D/DDE5E715 2002-03-03 Anton R. Ivanov <arivanov@...segv.cx>
    Fingerprint: C824 CBD7 EE4B D7F8 5331  89D5 FCDA 572E DDE5 E715