Bug 64210 (CVE-2004-1144)

Summary: VUL-0: CVE-2004-1144: root hole in 2.4 x86-64 kernel
Product: [Novell Products] SUSE Security Incidents Reporter: Andreas Kleen <ak>
Component: IncidentsAssignee: Security Team bot <security-team>
Status: RESOLVED FIXED QA Contact: Security Team bot <security-team>
Severity: Blocker    
Priority: P3 - Medium CC: aj, rf, security-team
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Andreas Kleen 2004-12-14 16:04:58 UTC 
This patch is not public yet and hasn't been sent to vendor-sec yet.

White space probably messed up in patch by cut'n'paste but should be
easy to redo. This affects all 2.4 x86-64 kernel and needs a security
update. Assigned to Hubert to add to all maintained x86-64 2.4 trees. 

From: Petr Vandrovec <vandrove@vc.cvut.cz>
Subject: [PATCH] Fix int $0x80 handler on x86-64

Hello,
  in my recent work I noticed that you can force x86-64 kernel to execute
arbitrary code
at CPL0 by just issuing int $0x80 with properly prepared %rax register - ia32
handler
checks %eax only, but uses %rax while accessing syscall table.  By mapping memory at
user accessible address at address of syscall table + k*32GB and then issuing
int $0x80
with %rax set to 1 + k*4G kernel will jump at CPL0 at address you (userspace)
specified,
causing execution of untrusted code at CPL0.

  Note that using 32bit userspace does not prevent this bug from being
exploited, any user
process can switch to 64bit mode and load %rax with any value it wants.

  2.6.x kernels are immune to this, as they have this mov in place for almost
two years.
                                                                Thanks,
                                                                        Petr
Vandrovec


Signed-off-by: Petr Vandrovec <vandrove@vc.cvut.cz>

--- linux-2.4.28/arch/x86_64/ia32/ia32entry.S.orig      2004-08-08
01:26:04.000000000 +0200
+++ linux-2.4.28/arch/x86_64/ia32/ia32entry.S   2004-12-06 21:36:06.000000000 +0100
@@ -52,6 +52,7 @@
 ENTRY(ia32_syscall)
        swapgs
        sti
+       mov %eax,%eax
        pushq %rax
        cld
        SAVE_ARGS
Comment 1 Andreas Kleen 2004-12-14 16:04:59 UTC 
<!-- SBZ_reproduce  -->
Exploit should be easy to write from the description.
Comment 2 Marcus Meissner 2004-12-15 00:24:18 UTC 
added project managers for awareness
Comment 3 Andreas Kleen 2004-12-15 18:13:08 UTC 
It's not confirmed yet, but I plan to embargo this until Dec 30 (about 2 weeks) 

Can we get security kernels for SLES8 and 9.0 ready by then?
Comment 4 Marcus Meissner 2004-12-15 18:15:14 UTC 
No, we cannot. 
 
The current maintenance update in the queue is the last one for this year, 
after release most of the people will already be gone into Xmas holidays. 
 
Earliest release of the next round of updates might be second week of january, 
but likely later.
Comment 5 Andreas Kleen 2004-12-15 18:16:30 UTC 
Sorry, but I'm unwilling to embargo the bug for over a month. That's far too long
for mainline. You'll have to live with a delayed update then.
Comment 6 Marcus Meissner 2004-12-15 18:33:57 UTC 
feel free to release it whenever you like ...  
 
i am fine with a delayed update in t his case.
Comment 7 Andreas Kleen 2004-12-15 18:38:35 UTC 
Ok. But you are aware that this is a real easy to exploit root hole?
Not one of the usual "maybe could be exploited somehow" issues?
Comment 8 Marcus Meissner 2004-12-15 18:47:33 UTC 
yes. 
 
I try to think of something. :/
Comment 9 Marcus Meissner 2004-12-15 20:23:05 UTC 
btw, does this fix really help? 
 
mov eax,eax ?  
 
or has it excplicit clear of the upper 32bit?
Comment 10 Andreas Kleen 2004-12-15 20:24:01 UTC 
Fix is correct. The 32bit self move clears the upper 32bits.
Comment 11 Ludwig Nussel 2004-12-15 22:00:46 UTC 
CAN-2004-1144
Comment 12 Marcus Meissner 2004-12-16 18:25:56 UTC 
talked to Ralf and Hubert. 
 
- after we released the current patch of update kernels (today or tomorrow) 
  Hubert will check in a new kernel source for SLES 8 containing just 
  this additional fix. 
 
- Only a patchinfo for ul1-x86_64 will be submitted. 
 
- QA should start ASAP on this kernel, so it is tested before Christmas 
  vacations. 
 
- The security team member on duty will approve it as soon as it is public. 
 
 
Since the SLES 8 SP3 branch is not tracked by KOTD we can commit the fix there 
I think.
Comment 13 Andreas Kleen 2004-12-16 18:27:02 UTC 
Ok thanks. I will ask on vendor-sec again for an earlier date,
as the RH guys prefered and nobody else complained so far. That would
be a in week. That's ok?
Comment 14 Marcus Meissner 2004-12-16 18:28:39 UTC 
i can't really say how fast we can be ready with all things including QA. 
 
I guess earliest next Tuesday or Wednesday. 
 
Wednesday 22.12. would be a nice day too I guess.
Comment 15 Andreas Kleen 2004-12-16 19:48:51 UTC 
New embargo date is 22.12 12:00 GMT
Comment 16 Marcus Meissner 2004-12-17 00:21:44 UTC 
Hubert will submit a new kernel from UL1-SP3 branch to done/SLES8  
friday morning.  
 
I will submit a patchinfo (together with Harald). 
 
Testing should start as soon as we have a free sles8-x86_64 machine.
Comment 17 Hubert Mantel 2004-12-17 16:53:21 UTC 
Kernel has been submitted for checkin.
Comment 18 Marcus Meissner 2004-12-22 21:56:22 UTC 
kernels released... waiting for connetion to company to come backup to write 
advisory.
Comment 19 Marcus Meissner 2004-12-23 02:03:13 UTC 
advisory released.