Bug 91434 (CVE-2005-1913)

Created attachment 39465 [details]
itimer-patch.diff

Created attachment 39466 [details]
thread_itimer.c

test case

doesnt trigger with 9.3 ga and sp2 rc4 on ppc64

I assume this is already public, so I can add it to all trees?

yes, please. only the 2.6 branches are affected. 

The patch does not apply at all to our SLES9 tree. And with regards to comment
#3 it seems we are not vulnerable here. The code looks quite different to newer
kernels.

Seems that 9.3 is the only kernel vulnerable by this problem. Fix has been
committed to that tree.

While the patch applies against our 9.3, it does not even compile. I will drop
the patch now. If somebody comes up with a working patch, we can re-consider
adding it.

we need to test the exploit. 
 
9.3 has very different looking code. 

There seems to be a previous patch to this: 
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5323125031799a7fd8602ce150c3902aedfdcba6 
 
 
[PATCH] reset real_timer target on exec leader change 
  
When a noninitial thread does exec, it becomes the new group leader.  If 
there is a ITIMER_REAL timer running, it points at the old group leader and 
when it fires it can follow a stale pointer.  The timer data needs to be 
reset to point at the exec'ing thread that is becoming the group leader. 
This has to synchronize with any concurrent firing of the timer to make 
sure that it_real_fn can never run when the data points to a thread that 
might have been reaped already. 
 
On july 12th 2005. 
 
 
even this comment suggests that the issue was there before. 

Created attachment 46481 [details]
itimer-fix1.patch

git extract

atrually the last patch was added on July 12... so it is newer. 

inquired at vendor-sec. 
 
i am a bit at loss here. 

Waiting for more input... 

From: Chris Wright <chrisw@osdl.org> 
To: Marcus Meissner <meissner@suse.de> 
Cc: vendor-sec@lst.de, security@kernel.org 
User-Agent: Mutt/1.5.6i 
Subject: [vendor-sec] Re: [Security] kernel / itimer reparenting problems 
Errors-To: vendor-sec-admin@lst.de 
Date: Mon, 22 Aug 2005 11:53:08 -0700 
 
* Marcus Meissner (meissner@suse.de) wrote: 
> I am a bit at loss with the itimer reparenting problems. 
> The first one was mailed by Chris Wright to vendor-sec ... 
> With sample exploit, which I was not able to get running on a 2.6.11 or 
> earlier kernels. 
 
(This definitely killed 2.6.11 for me, but I vaguely recall Marcelo having 
some problem getting that to work as well, which I assumed to be lack of 
NPTL). 
 
> 
+http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h 
+=c2a0f5943d8935766a42b2d0870aa4c645e3423d 
> 
> |Clean up subthread exec 
> | 
> |Make sure we re-parent itimers, and use BUG_ON() instead of an explicit 
> |conditional BUG(). 
> 
> 
> Then this change happened a month ago which also seems security relevant, 
> but was announced: 
> 
> 
+http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=532 
+3125031799a7fd8602ce150c3902aedfdcba6 
> 
> |[PATCH] reset real_timer target on exec leader change 
> | 
> |When a noninitial thread does exec, it becomes the new group leader.  If 
> |there is a ITIMER_REAL timer running, it points at the old group leader and   
> |when it fires it can follow a stale pointer.  The timer data needs to be 
> |reset to point at the exec'ing thread that is becoming the group leader. 
> |This has to synchronize with any concurrent firing of the timer to make 
> |sure that it_real_fn can never run when the data points to a thread that 
> |might have been reaped already. 
> 
> The latter seems to be security critical too, correct? 
 
It's intended as a more complete version of same fix.  The first one 
still has a theoritical race (albeit a quite narrow window instead of 
a window as wide as you'd like). 
 
thanks, 
-chris 
 

Reading the code, the main issue is that after the exec, the old group leader is gone   
without first removing any timers pending on his real_timer.   
   
I tried the exploit on a sles9 kernel and could not trigger the oops.   It isn't immediately  
clear why the oops isn't happening, looking through the code the timer is not being  
deleted.  My guess is that I'm happily stomping on ram somewhere. 
 
I think we need the patch from comment #11.  I'm changing around the exploit to make 
sure I can trigger/understand the bug. 
  

Ok, I understand now.  We don't need to patch sles9 because real_timer lives in the task 
struct there.  The timer is properly deleted with the task exits. 
 
SL93 does have the bug.  I'm attaching a patch ported there. 

I spoke too soon.  SL93 also has real_timer in the task struct.  I don't see how kernels 
without this patch can trigger. 
 
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;a=commit;h=1c4505555d420ca1678320b79a379dc6efc01705 
 
 

reinquired at vendorsec, security@kernel.org 
  
this patch is in 2.6.12-rc1 , it was not in 2.6.11.  

Correct, which means there's a conflict between my analysis and comment #1.  Did 
vendorsec/security@kernel.org decide 2.6.11 was safe? 

still waiting for a reply. 

I just got this reply from Chris Wright, making this a non-issue for us. 
 
Date: Tue, 30 Aug 2005 11:42:08 -0700  
From: Chris Wright <chrisw@osdl.org>  
To: Marcus Meissner <meissner@suse.de>  
Cc: Chris Wright <chrisw@osdl.org>, Chris L Mason <mason@suse.de>,  
        Olaf Kirch <okir@suse.de>, vendor-sec@lst.de, security@kernel.org  
Subject: Re: [vendor-sec] Re: [Security] kernel / itimer reparenting problems     
User-Agent: Mutt/1.5.6i  
  
* Marcus Meissner (meissner@suse.de) wrote:   
> Chris Mason, Olaf Kirch and I had looks at this, and we think that this  
> started to be problematic with this BK change moving the itimers from  
> the task struct to where it is now.  
>  
>  
+http://www.kernel.org/git/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;a=comm  
+it;h=1c4505555d420ca1678320b79a379dc6efc01705  
>  
> It appeared in 2.6.12-rc1, so it was _AFTER_ the 2.6.11 release.  
>  
> Can you confirm that you saw it with 2.6.11 vanilla?  
  
I just rebuilt from clean 2.6.11, and I cannot recreate it.  I must have  
had a kernel marked as 2.6.11 which was actually an updated bk pull (and  
2.6.12-rc1 wasn't out yet, so version didn't change).  This is my fault,  
sorry for confusion.  
  
thanks,  
-chris  
  

CVE-2005-1913: CVSS v2 Base Score: 2.1 (AV:L/AC:L/Au:N/C:N/I:N/A:P)