Bug 144412 - CAN-2005-0001 page fault @ SMP privilege escalation
CAN-2005-0001 page fault @ SMP privilege escalation
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Jason Baron
Brian Brock
embargoed=20050112,impact=important
: Security
Depends On:
Blocks: 144195
  Show dependency treegraph
 
Reported: 2005-01-06 15:05 EST by Josh Bressers
Modified: 2013-03-06 00:58 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-18 12:20:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
upstream 2.6.10 patch (2.53 KB, patch)
2005-01-17 23:21 EST, Dave Jones
no flags Details | Diff
expand stack race fix (696 bytes, text/plain)
2005-01-19 14:08 EST, Jason Baron
no flags Details

  None (edit)
Description Josh Bressers 2005-01-06 15:05:48 EST
*** This bug has been split off bug 144403 ***

------- Original comment by Josh Bressers (Security Response Team) on 2005.01.06
14:56 -------

This has been reported to vendor-sec by Paul Starzetz

I have found an exploitable flaw in the page fault handler, however only
in the SMP case.

The problem is this:

[A]     down_read(&mm->mmap_sem);

        vma = find_vma(mm, address);
        if (!vma)
                goto bad_area;
        if (vma->vm_start <= address)
                goto good_area;
        if (!(vma->vm_flags & VM_GROWSDOWN))
                goto bad_area;
        if (error_code & 4) {
                /*
                 * accessing the stack below %esp is always a bug.
                 * The "+ 32" is there due to some instructions (like
                 * pusha) doing post-decrement on the stack and that
                 * doesn't show up until later..
                 */
                if (address + 32 < regs->esp)
                        goto bad_area;
        }
        if (expand_stack(vma, address))
[B]             goto bad_area;


an exploitable race scenario looks as follows:

1) one thread issues down_write on the sem (remap, madvise, ...)

2) two other threads faul below a VM_GROWSDOWN segment (note that they can
fault anywhere below vm_start since esp is arbitrary) and sleep in [A]

3) first thread releases the sem and the two others run again, both find
the same VMA but:

thread1 ----------F1----------[   VMA   ]
thread2 ---------------F2-----[   VMA   ]

where F1/2 faul address.

If timed carefully we get:

thread1 expands stack to F1, installs pte1
thread2 expands stack to F2, installs pte2

resulting in pte1 not covered by the VMA. Techniques like in mremap_pte
can be applied to further exploit this condition.

Please do not argue that the race window is small - I have seen even
smaller windows opening like a barn :-]

The critical section is only from [A] to [B], we do not care about timings
of handle_mm_fault etc, since the VMA is later consulted only for page
flags.

Note that this also races with ptrace/proc etc (everything using
access_process_vm/get_user_pages).
Comment 2 Mark J. Cox (Product Security) 2005-01-12 09:39:34 EST
public, removing embargo
http://www.isec.pl/vulnerabilities/isec-0022-pagefault.txt
Comment 3 Dave Jones 2005-01-17 23:21:37 EST
Created attachment 109912 [details]
upstream 2.6.10 patch

Here's what got merged upstream, we'll need to modify this somewhat though, as
exec-shield plays in the same area.
Comment 4 Dave Jones 2005-01-17 23:24:20 EST
actually, that's on top of about 4-5 patches in the same area, so it's not
particularly helpful without the other bits.
Comment 5 Jason Baron 2005-01-19 14:08:51 EST
Created attachment 109981 [details]
expand stack race fix
Comment 6 Jason Baron 2005-01-19 14:10:17 EST
The patch from comment #5 is taken from the -ac patch, and should fix
this issue. I haven't tested this yet, but Dave mentioned that he had
a test program.

Comment 7 Dave Jones 2005-01-25 02:56:07 EST
I was mistaken. (Getting my isec.pl advisories mixed up) I don't have a test for
this issue.
Comment 9 Josh Bressers 2005-02-18 12:20:55 EST
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-092.html

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