Bug 86387 - 2.4.18-27.7 introduces /proc bug
Summary: 2.4.18-27.7 introduces /proc bug
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-03-21 01:20 UTC by Ben Goodwin
Modified: 2007-04-18 16:52 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-06-27 21:36:16 UTC

Attachments (Terms of Use)

Description Ben Goodwin 2003-03-21 01:20:23 UTC
The initial sympom was when my Apache RSA/ACE module started always thinking 
that it was already running even if it wasn't.. preventing the service from 
working..  That program appears to run the following command to check (this is 
from a 'strings' on the binary - source isn't available):

grep aceapi_rpc_server /proc/*/cmdline | sed 's/\/cmdline.*\/proc\// /g' | 
sed 's/\/cmdline.*/ /'  | sed 's/.*\/proc\// /' | sort -u

Now, aceapi_rpc_server perms are 4700, owner is nobody .. so, digging, I find 
that if I create a copy of the 'cat' binary and set the perms the same, it 
produces vastly less output than a non-suid binary..  This behavior is NOT 
present in 2.4.18-26.7
To see what I mean:

(all commands run as root)
cp /bin/cat /tmp/cat
chown nobody /tmp/cat
chmod 4700 /tmp/cat
cat /proc/*/cmdline | wc
/tmp/cat /proc/*/cmdline | wc
rm -f /tmp/cat

Try this on both kernel versions obviously.

As long as that binary is set suid to a non-root user, this behavior will show 

[root@arf /root]# cat /proc/*/cmdline | wc
      4      13    4365
[root@arf /root]# /tmp/!!
/tmp/cat /proc/*/cmdline | wc
      4      13    4375

[1:syslog] [~] > cat /proc/*/cmdline | wc
      0       1    2119

[1:syslog] [~] > /tmp/!!
/tmp/cat /proc/*/cmdline | wc
      0       1     518

Comment 1 Ben Goodwin 2003-03-21 01:22:53 UTC
I'm prioritizing high/high for now because I can't run my apache server under 
the latest kernel, and backing down to an earlier rev leaves me open to the 
local root compromise.

Comment 2 Ben Goodwin 2003-04-02 19:52:46 UTC
Are you guys looking at this?  When should I expect to work with someone, if 
at all?  I'd just like to have my expectations set.  Thanks -

Comment 3 Alan Cox 2003-06-27 21:36:16 UTC
The behaviour change was a security fix. The newest errata relax the rules
slightly based on further auditing.

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