Bug 160199 - CVE-2005-1768 64bit execve() race leads to buffer overflow
CVE-2005-1768 64bit execve() race leads to buffer overflow
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Dave Anderson
Brian Brock
source=secalert,reported=20050612,imp...
: Security
Depends On:
Blocks: 156320
  Show dependency treegraph
 
Reported: 2005-06-13 06:47 EDT by Mark J. Cox (Product Security)
Modified: 2007-11-30 17:07 EST (History)
5 users (show)

See Also:
Fixed In Version: RHSA-2005-663
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-28 11:21: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)
Proposed patch from Andi Kleen (2.45 KB, patch)
2005-06-13 06:47 EDT, Mark J. Cox (Product Security)
no flags Details | Diff
Update/fix of Andi Kleen's proposed patch (2.17 KB, patch)
2005-06-29 11:43 EDT, Dave Anderson
no flags Details | Diff
Second proposed patch from Andi Kleen (3.02 KB, patch)
2005-06-30 15:54 EDT, Dave Anderson
no flags Details | Diff
Update/fix of Andi Kleen's second proposed patch (2.66 KB, patch)
2005-06-30 15:55 EDT, Dave Anderson
no flags Details | Diff

  None (edit)
Description Mark J. Cox (Product Security) 2005-06-13 06:47:30 EDT
Reported to secalert@redhat.com by Ilja van Sprundel, a race condition in execve
affecting x86_64 and ia64 which exists because kmalloc() or get_user() can
block, and hence another thread can change the argv and envp pointers, causing a
bufferoverflow (also on SMP without blocking)

          na = nargs(argv, NULL);
 ...      ne = nargs(envp, NULL);
 ...      len = (na + ne + 2) * sizeof(*av);
 ...      av = kmalloc(len, GFP_KERNEL);
 ...      r = nargs(argv, av);
 ...      r = nargs(envp, ae);

"the nargs() function is used to first count the amount of argv and
envp pointers, next a kmalloc() is done, and then nargs() is called again to
copy the argv and envp pointer into this newly allocated memory.        the race
condition exists because kmalloc() or get_user() can block, and hence another
thread can change the argv and envp pointers, causing a buffer overflow."

Currently embargoed
Comment 1 Mark J. Cox (Product Security) 2005-06-13 06:47:31 EDT
Created attachment 115347 [details]
Proposed patch from Andi Kleen
Comment 7 Dave Anderson 2005-06-28 11:48:30 EDT
The patch posted in Comment #1 is clearly "theoretical" because it
wouldn't work or apply.  Ernie's reference to the need for a "signed int" is
one example, and in addition, the ia64 piece shows a "cnt" variable
below which doesn't exist (it should be "n"): 

+		if (n >= (MAX_ARG_PAGES * PAGE_SIZE) / sizeof(char *) || (max >= 0 && cnt >=
max))
                        return -E2BIG;

In any case, with a patch cobbled into place, and run against a test program
Ernie whipped up, there's what appears to be a regression, where the test
program works OK without the patch, but fails with it -- returning E2BIG when
it shouldn't.  So further investigation to determine whether patch was created
incorrectly is in order. 

So if Andi Kleen posts a public patch today, can you copy it to this bugzilla
ASAP for comparison to the old one?

Thanks,
  Dave
Comment 8 Dave Anderson 2005-06-29 11:43:11 EDT
Created attachment 116130 [details]
Update/fix of Andi Kleen's proposed patch


The attached patch addresses the two irregularities in Andi Kleen's patch
mentioned above (the "unsigned int" and the "cnt" complaints), as well as
two other fixes: 

(1) ensure that the correct errno gets passed back in the x86_64 case, and
(2) fixes for both the x86_64 and ia64 nargs() "if" statements that cause E2BIG

    to be returned.

We would like to compare this patch to the upstream version that get applied.
Comment 9 Dave Anderson 2005-06-30 15:54:20 EDT
Created attachment 116183 [details]
Second proposed patch from Andi Kleen
Comment 10 Dave Anderson 2005-06-30 15:55:47 EDT
Created attachment 116184 [details]
Update/fix of Andi Kleen's second proposed patch
Comment 11 Dave Anderson 2005-06-30 16:05:05 EDT
Andi Kleen sent us an updated version of his original patch, 
which he said was sent to Marcelo.  However, it has two bugs
in it, which I have fixed in the attached patch.

I sent Andi the following response regarding the bugs:

--------------------------------------------------------------

Hi Andi, 

There appears to be two problems with this patch: 

(1) In the x86_64 case, if the user attempts to use too 
    many arguments, the intial call to nargs() will recognize 
    it, and return E2BIG.  But then sys32_execve() ignores 
    the E2BIG return argument and returns EFAULT.  The ia64 
    case works OK because it returns what nargs() returns. 

(2) Also in the x86_64 case, nargs() returns the number of 
    arguments found, which sys32_execve() stores in "na", and 
    which is later passed back to nargs() as the "max" arg. 
    But the second call to nargs() will then allow "na+1" 
    arguments, and therefore the buffer overflow.  So the 
    second set of calls to nargs() should pass "na-1" and 
    "ne-1" respectively.  The ia64 case works OK because its 
    nargs() returns the number of arguments minus 1. 

I verified case (1).  As far as (2), I've never been able to 
reproduce the the overflow, but the logic seems to make sense. 
Agreed? 

Dave 

--------------------------------------------------------------

Comment 12 Mark J. Cox (Product Security) 2005-07-08 05:15:40 EDT
Public 20050704, opening embargo
Comment 14 Ernie Petrides 2005-07-11 21:15:10 EDT
A fix for this problem has just been committed to the RHEL3 U6
patch pool this evening (in kernel version 2.4.21-32.10.EL).
Comment 16 Martin Jenner 2005-08-30 12:00:51 EDT
Is there a reproducer for this bug that QE can use for testing this ?
Comment 17 Dave Anderson 2005-08-30 13:14:40 EDT
Actually, no.  I don't believe anybody has ever reproduced it.
Comment 19 Red Hat Bugzilla 2005-09-28 11:21: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-663.html

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