Bug 144412

Summary: CAN-2005-0001 page fault @ SMP privilege escalation
Product: Red Hat Enterprise Linux 4 Reporter: Josh Bressers <bressers>
Component: kernelAssignee: Jason Baron <jbaron>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: 4.0CC: davej, knoel, mjc, riel, security-response-team
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: embargoed=20050112,impact=important
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-02-18 17:20:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 144195    
Attachments:
Description Flags
upstream 2.6.10 patch
none
expand stack race fix none

Description Josh Bressers 2005-01-06 20:05:48 UTC
*** 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 2005-01-12 14:39:34 UTC
public, removing embargo
http://www.isec.pl/vulnerabilities/isec-0022-pagefault.txt

Comment 3 Dave Jones 2005-01-18 04:21:37 UTC
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-18 04:24:20 UTC
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 19:08:51 UTC
Created attachment 109981 [details]
expand stack race fix

Comment 6 Jason Baron 2005-01-19 19:10:17 UTC
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 07:56:07 UTC
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 17:20:55 UTC
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