Bug 185289 - CVE-2006-1052 SELinux flaw
CVE-2006-1052 SELinux flaw
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Paris
Brian Brock
reported=20060310,impact=moderate,sou...
: Security
Depends On:
Blocks: 181409
  Show dependency treegraph
 
Reported: 2006-03-13 06:05 EST by Mark J. Cox (Product Security)
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version: RHSA-2006-0575
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-10 18:37:15 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)
proposed upstream patch (1.10 KB, patch)
2006-03-13 06:05 EST, Mark J. Cox (Product Security)
no flags Details | Diff

  None (edit)
Description Mark J. Cox (Product Security) 2006-03-13 06:05:03 EST
Here's some background info provided by Stephen Smalley.

  Note:  This is a security bug fix for SELinux.  Bug has been present
  since Linux 2.6.6, was introduced by a prior patch by me to fix a race
  condition in this same logic:
  http://marc.theaimsgroup.com/?l=git-commits-head&m=108305094908582&w=2

  Preconditions for exploitation of this bug:  a) Attacker has ptrace
  permission to his own domain and can thus attach to one of his own
  processes, which we rarely allow in the example policy outside of user
  domains and unconfined, and b) Attacker can wait for or induce a trusted
  process that has ptrace permission to the target domain to read the file
  /proc/pid/environ and possibly /proc/pid/mem (further restrictions apply
  here) for his own ptrace'd process, thereby resetting the ptrace_sid
  to the trusted process sid, and c) Attacker has execute permission
  to the target program and transition permission to the target domain.
  Further, if the target program is setuid, then the capability module
  logic would still prevent the uid and capability change from occurring
  under the ptrace, limiting the effective permissions gained by the
  attacker (since the process has to pass both normal Linux checking
  and SELinux checking).

No embargo, being fixed upstream shortly.
Comment 1 Mark J. Cox (Product Security) 2006-03-13 06:05:03 EST
Created attachment 126029 [details]
proposed upstream patch
Comment 7 Eric Paris 2006-06-19 14:42:26 EDT
So I just verified this is broken in 2-6-9.34.0.1 and fixed in 2.6.9-39

First I added these rules to policy/test_exectrace.te

allow test_exectrace_parent_t initrc_devpts_t:chr_file { read write getattr };
allow test_exectrace_parent_t initrc_t:fd use;

allow test_exectrace_child_t initrc_devpts_t:chr_file { read write };
allow test_exectrace_child_t initrc_t:fd use;

allow test_exectrace_notchild_t initrc_devpts_t:chr_file { read write };
allow test_exectrace_notchild_t initrc_t:fd use;

which simply allow it to actually read and write to the ssh terminal.  Be sure
to run 'make -C $(LTPROOT)/testcases/kernel/security/selinux/policy load'

Next I patch selinux_exectrace_parent.c.   Being sure to run make and make install

Now run the test on an old kernel and you will get results like

[root@wbar1 tests]# ./runtest.sh exectrace
/root/ltp-full-20060615/testcases/kernel/security/selinux-testsuite/tests
Running with security context=root:system_r:unconfined_t
Run cat /proc/9107/environ in an unconfined shell and then hit return here.

Child stopped by signal 5.
Child has context root:system_r:test_exectrace_child_t
..Resuming the child.
Child exited with status 0.
test01   PASS : exectrace passed.
Run cat /proc/9109/environ in an unconfined shell and then hit return here.

Child stopped by signal 5.
Child has context root:system_r:test_exectrace_notchild_t
..Resuming the child.
Child exited with status 0.
test02   FAIL : exectrace failed.
Done.

Notice that the second test we are supposed to be tracing a child that we do not
have permissions to trace.  Yet it worked just fine!  Since the child trace
worked fine and exited with status 0 (success) the test failed.   This is bad. 
The child is supposed to fail which indicates the test passed.

Now on the new kernel we run the same tests

[root@test05-64 tests]# ./runtest.sh exectrace
/root/ltp-full-20060615/testcases/kernel/security/selinux-testsuite/tests
Running with security context=root:system_r:unconfined_t
Run cat /proc/3931/environ in an unconfined shell and then hit return here.

Child stopped by signal 5.
Child has context root:system_r:test_exectrace_child_t
..Resuming the child.
Child exited with status 0.
test01   PASS : exectrace passed.
Run cat /proc/3969/environ in an unconfined shell and then hit return here.

Child terminated by signal 9.
..This is consistent with a ptrace permission denial - check the audit message.
test02   PASS : exectrace passed.
Done.

Notice in this case on the second test the child actually failed because of a
denial.  So the test passed.


I'm not sure what you saw happening, but using that test case I am able to
proove that this exploit is fixed.
Comment 9 Mike Gahagan 2006-06-19 16:15:50 EDT
After looking through some audit logs I had saved, I see what happened now.. due
to the policy problems you had pointed out.. evidently the parent wasn't even
being run (because the policy was denying it) and it was being interpreted as a
PASS. I don't think the LTP folks do much with the static policy anymore, looks
like all the work goes into refpolicy at this point which as far as I know we
can't use on RHEL 4. 

Comment 11 Red Hat Bugzilla 2006-08-10 18:37:15 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-2006-0575.html

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