Bugzilla – Bug 64210
VUL-0: CVE-2004-1144: root hole in 2.4 x86-64 kernel
Last modified: 2017-03-24 07:22:46 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
<!-- SBZ_reproduce --> Exploit should be easy to write from the description.
added project managers for awareness
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?
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.
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.
feel free to release it whenever you like ... i am fine with a delayed update in t his case.
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?
yes. I try to think of something. :/
btw, does this fix really help? mov eax,eax ? or has it excplicit clear of the upper 32bit?
Fix is correct. The 32bit self move clears the upper 32bits.
CAN-2004-1144
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.
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?
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.
New embargo date is 22.12 12:00 GMT
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.
Kernel has been submitted for checkin.
kernels released... waiting for connetion to company to come backup to write advisory.
advisory released.