Bug 133113 - CAN-2004-1058 /proc/<PID>/cmdline information disclosure
CAN-2004-1058 /proc/<PID>/cmdline information disclosure
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
All Linux
medium Severity low
: ---
: ---
Assigned To: Dave Anderson
Brian Brock
impact=low,public=20040730
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-21 15:08 EDT by Josh Bressers
Modified: 2007-11-30 17:07 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-22 16:17:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Josh Bressers 2004-09-21 15:08:35 EDT
There's a race in the kernel, and considering the permissions on
/proc/PID/{cmdline,environ} a security bug as well: If you win the
race with a starting process, you can read its environment.

http://lkml.org/lkml/2004/7/29/332
Comment 1 Mark J. Cox (Product Security) 2004-11-17 05:28:16 EST
Might be 2.6 only
fixed in 2.6.9
http://linux.bkbits.net:8080/linux-2.6/cset@412a4baaEebwtKg-X7sS2r5Mua6uGw
Comment 2 Dave Anderson 2004-11-17 09:35:35 EST
It's a very small window of opportunity where the arg_start can be
initialized but the arg_end still not be, so it's hard to make
this happen easily.  

But if I manually modify arg_end to be zero in an existing task's
mm_struct, I can reproduce the problem.  

Here I'm in a crash session, where I've got a "doit" process just
sleeping.  Escaping to a shell, and doing a "ps -ax" shows it as pid
557:

crash> !ps -ax  | grep doit
  557 pts/10   S      0:00 ./doit
  577 pts/10   S      0:00 sh -c ps -ax  | grep doit
  579 pts/10   S      0:00 grep doit
crash>

If I then determine where pid 557's mm_struct's arg_end is located,
(in this example I've determined it to be at address df66dce4), and
them write a 0 there, a subsequent ps shows this:

crash> wr df66dce4 0
crash> !ps -ax  | grep doit
  557 pts/10   S      0:00 ./doit HOSTNAME=crash.boston.redhat.com
PVM_RSH=/usr/bin/rsh HOST=crash TERM=xterm SHELL=/bin/bas
  599 pts/10   S      0:00 sh -c ps -ax  | grep doit
  601 pts/10   S      0:00 grep doit
crash>

I'll apply an applicable 2.4 patch and verify that it handles it
properly.



Comment 3 Ernie Petrides 2004-12-09 21:52:39 EST
A fix for this problem has just been committed to the RHEL3 U5
patch pool this evening (in kernel version 2.4.21-27.3.EL).
Comment 4 Ernie Petrides 2005-04-13 20:07:31 EDT
A fix for this problem has also been committed to the RHEL3 E5
patch pool this evening (in kernel version 2.4.21-27.0.3.EL).
Comment 5 Josh Bressers 2005-04-22 16:17:32 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2005-293.html
Comment 6 Tim Powers 2005-05-18 09:28:10 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2005-294.html

Note You need to log in before you can comment on or make changes to this bug.