Bugzilla – Bug 326270
VUL-0: CVE-2007-4573: kernel: x86_64 local privilege escalation
Last modified: 2020-04-21 09:36:29 UTC
Hi. There is a security bug in 'kernel'. This information is from 'vendor-sec'. This bug is NOT PUBLIC. There is no coordinated release date (CRD) set. More information can be found here: https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec CVE number: CVE-2007-4573 CVE description: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4573 Original posting: Date: Wed, 19 Sep 2007 10:55:02 +0200 From: Thomas Biege <thomas@suse.de> To: Thomas Biege <thomas@suse.de> Subject: --m2b-- [vendor-sec] CVE-2007-4573 syscall invalid validation x86_64 @package = kernel @maintainer = kernel-maintainers@forge.provo.novell.com ----- Forwarded message from Mark J Cox <mjc@redhat.com> ----- From: Mark J Cox <mjc@redhat.com> To: security@kernel.org, vendor-sec@lst.de Cc: eteo@redhat.com Subject: [vendor-sec] CVE-2007-4573 syscall invalid validation x86_64 Errors-To: vendor-sec-admin@lst.de Date: Wed, 19 Sep 2007 09:05:45 +0100 (BST) Yesterday, Wojciech Purczynski of COSEINC notified us of a kernel security issue that could lead to local privilege escalation on x86_64 platforms. I've just received permission to share this with the kernel and vendor-sec teams, but note they have (for some reason) set an embargo of 21st Sept Eugene Teo of Red Hat has come up with a proposed patch (untested), inlined. Comment #1 From Mark J. Cox (Security Response Team) (mjc@redhat.com) on 2007-09-18 07:21 EST [reply] Private ===[ ABSTRACT ]========================================================= Insufficient validation of general-purpose register in IA32 system call emulation code may lead to local system compromise on x86_64 platform. ===[ AFFECTED SOFTWARE ]================================================ Linux 2.6 - successfully tested on 2.6.23-rc5 Linux 2.4 - seems vulnerable but not tested For the exact kernel version please refer to an information provided by your vendor. ===[ DESCRIPTION ]====================================================== On x86_64 platform the Linux kernel supports compatibility emulation for IA32 userland applications providing 32-bit system calls amongst other 32-bit resources. As a result of arch/x86_64/ia32/ia32entry.S code optimization invalid opcodes was used in the low level assembler routines providing insufficient validation of %RAX register in the following part of code: ---8<--- sysenter_do_call: cmpl $(IA32_NR_syscalls-1),%eax ja ia32_badsys IA32_ARG_FIXUP 1 call *ia32_sys_call_table(,%rax,8) ---8<--- cstar_do_call: cmpl $IA32_NR_syscalls-1,%eax ja ia32_badsys IA32_ARG_FIXUP 1 call *ia32_sys_call_table(,%rax,8) ---8<--- ia32_do_syscall: cmpl $(IA32_NR_syscalls-1),%eax ja ia32_badsys IA32_ARG_FIXUP call *ia32_sys_call_table(,%rax,8) # xxx: rip relative ---8<--- Improperly validated 64-bit values stored in the %RAX register may lead to out-of-bounds system call table access resulting in the ability to execute arbitrary code in the context of the Linux kernel. ===[ IMPACT ]=========================================================== Unprivileged local user may execute arbitrary code in the context of the Linux kernel running on x86_64 platform. ===[ DISCLOSURE TIMELINE ]============================================== ??th September 2007 Vendor notification ??th September 2007 Public disclosure ===[ AUTHOR ]=========================================================== Wojciech Purczynski <cliph@research.coseinc.com> Wojciech Purczynski is a Security Researcher at Vulnerability Research Labs, COSEINC PTE Ltd. Wojciech Purczynski is also a member of iSEC Security Research. ===[ LEGAL DISCLAIMER ]================================================= Copyright (c) 2007 Wojciech Purczynski Copyright (c) 2007 COSEINC PTE Ltd. All Rights Reserved. PUBLISHING, DISTRIBUTING, PRINTING, COPYING, SCANNING, DUPLICATING IN ANY FORM, MODIFYING WITHOUT PRIOR WRITTEN PERMISSION IS STRICTLY PROHIBITED. THE DOCUMENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. THE CONTENT MAY CHANGE WITHOUT NOTICE. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, INJURIES, LOSSES OR UNLAWFUL OFFENCES. USE AT YOUR OWN RISK. Comment #3 From Eugene Teo (eteo@redhat.com) on 2007-09-19 01:04 EST [reply] Private 119 sysenter_do_call: 120 cmpl $(IA32_NR_syscalls-1),%eax test (%eax - $(IA32_NR_syscalls-1)) 121 ja ia32_badsys 122 IA32_ARG_FIXUP 1 123 call *ia32_sys_call_table(,%rax,8) We know that %eax is within range if it does not "jump if above". The upper 32-bits are not validated at all. We want to make sure that %rax has the same value as %eax, if not we are screwed. 124 movq %rax,RAX-ARGOFFSET(%rsp) I have attached my proposed patch (see next post). Please check/test it. ==== This patch fixes a vulnerability discovered by Wojciech Purczynski. It appears that the 64-bit values stored in the %rax register is not properly validated. This may lead to an out-of-bounds system call table access resulting in the ability to execute arbitrary code in the context of the kernel on x86_64 platform. CVE-2007-4573 Signed-off-by: Eugene Teo <eugeneteo@kernel.sg> --- arch/x86_64/ia32/ia32entry.S | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/x86_64/ia32/ia32entry.S b/arch/x86_64/ia32/ia32entry.S index 9382786..3ef1742 100644 --- a/arch/x86_64/ia32/ia32entry.S +++ b/arch/x86_64/ia32/ia32entry.S @@ -120,6 +120,7 @@ sysenter_do_call: cmpl $(IA32_NR_syscalls-1),%eax ja ia32_badsys IA32_ARG_FIXUP 1 + and $0x00000000ffffffff, %rax call *ia32_sys_call_table(,%rax,8) movq %rax,RAX-ARGOFFSET(%rsp) GET_THREAD_INFO(%r10) @@ -229,6 +230,7 @@ cstar_do_call: cmpl $IA32_NR_syscalls-1,%eax ja ia32_badsys IA32_ARG_FIXUP 1 + and $0x00000000ffffffff, %rax call *ia32_sys_call_table(,%rax,8) movq %rax,RAX-ARGOFFSET(%rsp) GET_THREAD_INFO(%r10) @@ -323,6 +325,7 @@ ia32_do_syscall: cmpl $(IA32_NR_syscalls-1),%eax ja ia32_badsys IA32_ARG_FIXUP + and $0x00000000ffffffff, %rax call *ia32_sys_call_table(,%rax,8) # xxx: rip relative ia32_sysret: movq %rax,RAX-ARGOFFSET(%rsp) _______________________________________________ Vendor Security mailing list Vendor Security@lst.de https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec ----- End forwarded message ----- -- Bye, Thomas -- Thomas Biege <thomas@suse.de>, SUSE LINUX, Security Support & Auditing SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- Die meisten Menschen wenden mehr Zeit und Kraft auf, um Probleme herumzureden, als sie anzupacken... -- Henry Ford I.
coolo probably wants this included in 10.3 GM already
From: Andi Kleen <ak@suse.de> To: security@kernel.org, vendor-sec@lst.de, eteo@redhat.com User-Agent: KMail/1.9.1 Subject: [vendor-sec] CVE-2007-4573 Errors-To: vendor-sec-admin@lst.de Date: Wed, 19 Sep 2007 12:11:14 +0200 I don't think that person is telling the full story. While there is a problem it doesn't happen for the normal system call path; but only with ptrace. He doesn't mention ptrace though so I'm not sure he really understands the problem at all. Does anybody have the exploit? The normal system call paths already zero extend eax by doing mov %eax,%eax at the beginning. eteo's patch just did that redundantly. ptrace does this also when the target is a 32bit task, but not when it's a 64bit task and it's unfortunately possible for 64bit tasks to call int 0x80 (but not sysenter or 32bit syscall) so a 64bit value could be injected here by a malicious debugger by using system call tracing. Here are proposed (untested) patches. The 2.6 patch does more than strictly necessary. On 2.4 just a single instruction needs to be changed. -Andi
Created attachment 173796 [details] 2.4.patch patch from Andi
Created attachment 173797 [details] 2.6.patch patch from Andi
From: Mark J Cox <mjc@redhat.com> To: Andi Kleen <ak@suse.de> Cc: security@kernel.org, vendor-sec@lst.de, eteo@redhat.com Subject: Re: [vendor-sec] CVE-2007-4573 Errors-To: vendor-sec-admin@lst.de Date: Wed, 19 Sep 2007 11:50:06 +0100 (BST) >I don't think that person is telling the full story. I think this is only part of it (in a mail to Marcel before he left he mentioned this was one of several flaws they'd found); so perhaps he's relying on some combination of other flaws too for his exploit. >Does anybody have the exploit? No; I asked for it, but he is still deciding if to release it privately. Mark
From: Mark J Cox <mjc@redhat.com> To: Andi Kleen <ak@suse.de> Cc: security@kernel.org, vendor-sec@lst.de, eteo@redhat.com Subject: [vendor-sec] Re: [Security] CVE-2007-4573 Errors-To: vendor-sec-admin@lst.de Date: Thu, 20 Sep 2007 12:48:56 +0100 (BST) >Does anybody have the exploit? No responses. Coseinc only said "we will release what we have inform you." so I guess they are sticking with their schedule of 21st Sept (tommorrow). I don't believe they're going to release any exploit publically at that time (it would be unusual for them), and I guess they think the patch will be in 2.6.23? Mark
From: Andi Kleen <ak@suse.de> To: Mark J Cox <mjc@redhat.com> User-Agent: KMail/1.9.1 Cc: security@kernel.org, vendor-sec@lst.de, eteo@redhat.com Subject: [vendor-sec] Re: [Security] CVE-2007-4573 Errors-To: vendor-sec-admin@lst.de Date: Thu, 20 Sep 2007 14:19:33 +0200 On Thursday 20 September 2007 13:48, Mark J Cox wrote: > > Does anybody have the exploit? > > No responses. Coseinc only said "we will release what we have inform > you." so I guess they are sticking with their schedule of 21st Sept > (tommorrow). I don't believe they're going to release any exploit > publically at that time (it would be unusual for them), and I guess > they think the patch will be in 2.6.23? I can send it to Linus if it's ok for everybody (needs some testing first) But if their exploit works without ptrace it must be some other unknown hole. And at least their description doesn't mention ptrace at all. -Andi
From: Mark J Cox <mjc@redhat.com> To: Andi Kleen <ak@suse.de> Cc: security@kernel.org, vendor-sec@lst.de, eteo@redhat.com Subject: [vendor-sec] Re: [Security] CVE-2007-4573 Errors-To: vendor-sec-admin@lst.de Date: Thu, 20 Sep 2007 18:01:37 +0100 (BST) >But if their exploit works without ptrace it must be some other unknown >hole. And at least their description doesn't mention ptrace at all. Here is what he said. I'll ask him if I can just cc him into the thread to cut out the middle-man (but they kind of like encrypting all their mails) Yes, I successfully exploited this bug with ptrace as an attack vector. The are some other problems that may need to be fixed as well. I combined (1) and (2) issues together in my exploit. 1) On x86_64 platform any process may switch to/from 64-bit or 32-bit compatibility mode by changing CS selector. Q: This is mainly GDT problem. Is this fixable? Can we use separate GDT tables for 32 and 64 processes? 2) On x86_64 platform any process may call 64-bit or 32-bit system calls despite of the mode the process is currently running at (either 64-bit or 32-bit compatibility mode). Q: Should we block 32-bit system calls from 64-bit binary and vice versa? 3) load_aout_binary() in arch/x86_64/ia32/ia32_aout.c does not initialize some 64-bit general purpose registers for 32-bit a.out binary. NOTE: I found these issues a while ago and haven't checked latest changes to the kernel code in these parts.
From: Andi Kleen <ak@suse.de> To: Mark J Cox <mjc@redhat.com> User-Agent: KMail/1.9.6 Cc: security@kernel.org, vendor-sec@lst.de, eteo@redhat.com Subject: [vendor-sec] Re: [Security] CVE-2007-4573 Errors-To: vendor-sec-admin@lst.de Date: Thu, 20 Sep 2007 19:06:51 +0200 On Thursday 20 September 2007 19:01:37 Mark J Cox wrote: > > But if their exploit works without ptrace it must be some other unknown > > hole. And at least their description doesn't mention ptrace at all. > > Here is what he said. I'll ask him if I can just cc him into the thread > to cut out the middle-man (but they kind of like encrypting all their > mails) > > Yes, I successfully exploited this bug with ptrace as an attack vector. > > The are some other problems that may need to be fixed as well. I > combined (1) and (2) issues together in my exploit. > > 1) On x86_64 platform any process may switch to/from 64-bit or 32-bit > compatibility mode by changing CS selector. > > Q: This is mainly GDT problem. Is this fixable? Can we use separate GDT > tables for 32 and 64 processes? It would make context switch slower and in principle there is no reason to stop processes from doing this. Of course the entry points need to be bullet proof. > 2) On x86_64 platform any process may call 64-bit or 32-bit system calls > despite of the mode the process is currently running at (either 64-bit > or 32-bit compatibility mode). > > Q: Should we block 32-bit system calls from 64-bit binary and vice versa? We cannot easily (without switching IDTs) which is not worth it. Also it was intentionally supported e.g. for 64bit JITs running 32bit programs. > 3) load_aout_binary() in arch/x86_64/ia32/ia32_aout.c does not > initialize some 64-bit general purpose registers for 32-bit a.out binary. Hmm yes it probably should; although i doubt there is anything interesting in them. -Andi
going into mainline today If I got that correctly you can get root on any x86_64 machine, right?
Not sure on the any. You will need some known jump address relative to sys_call_table, which might be not always there. But you can probably get root on some known configurations
It's actually pretty clean to exploit using ptrace. a) mmap shellcode at specific address b) use PTRACE_SYSCALL to intercept syscall entry on a child process that does nothing but do an int80 syscall c) parent replaces %rax with offset between syscall table and mmaped shellcode d) when child process' syscall is performed, it jumps directly to shellcode You've got to know where the syscall table is in memory (which you can figure out by the oops you generate while testing), but other than that, it's remarkably easy to exploit.
public now
Created attachment 174869 [details] exploit.c working exploit. gcc -o foo foo.c ./foo
We need an update, fast. :( Is there a workaround available?
MaintenanceTracker-13520
andi, please apply to all affected branches ASAP
Note: The x86_64 32-bit ptrace local root exploit is really scary, it works just like 'su -' (without password) on any x86_64 where I tried it, serious. Anja Stock wrote: Submission deadline: Tuesday morning Nuremberg time 10:00 a.m. Provo time 2:00 a.m. SWAMPID is 13520 As 10.3 didn't get the fix, I have added them to the "affected:" section. ---------------------------------------------------------------------------- Lately, several kernel security issues have been found, and those should be added as well, the Ubuntu security update mentions tree more, 1-3 in the list below, and I found 5-7 in addition in the related advisories list of 1) at http://secunia.com/advisories/26935/ Ubuntu advisory: http://www.ubuntu.com/usn/usn-518-1 The links to secunia.com have more detail and links to source-code patches: 1) Evan Teran discovered that the Linux kernel ptrace routines did not correctly handle certain requests robustly. Local attackers could exploit this to crash the system, causing a denial of service. CVE-2007-3731 http://secunia.com/advisories/26935/ 2) It was discovered that hugetlb kernels on PowerPC systems did not prevent the stack from colliding with reserved kernel memory. Local attackers could exploit this and crash the system, causing a denial of service. > bk@suse.de: It's enabled since SLES10-ppc64, wasn't available before. CVE-2007-3739 http://secunia.com/advisories/23955/ 3) It was discovered that certain CIFS filesystem actions did not honor the umask of a process. Local attackers could exploit this to gain additional privileges. CVE-2007-3740 http://secunia.com/advisories/26366/ 4) Wojciech Purczynski discovered that the Linux kernel ia32 syscall emulation in x86_64 kernels did not correctly clear the high bits of registers. Local attackers could exploit this to gain root privileges. (CVE-2007-4573) 5) Linux Kernel "sysfs_readdir()" Denial of Service http://secunia.com/advisories/25771/ --------------------------------------------------------------------------- Security fixes which apply for pre-10.3 kernels only, AFAICS: 6) Linux Kernel AACRAID Driver IOCTL Security Bypass http://secunia.com/advisories/26322/ 7) Linux Kernel Multiple Denial of Service Vulnerabilities http://secunia.com/advisories/25955/ ============================================================================= Its not sure to be complete, but if the last security update from September 6 was complete with all fixes until that date, this should it hopefully be. Novell Sec updates: http://www.novell.com/linux/security/securitysupport.html
Jeff, I think you already commited the fix for this, right?
Yes, the patches for the zero extend bug are applied to all affected trees. Are we planning on tracking down and applying fixes for the security problems BK listed in comment #20 as well?
the others are already tracked in oither bugs, also asigned to kernel-maintainers In my eyes only the ALSA memory leak (bug 328404) is important enough to be mandatory for this update, the others are ptional but nice to have.
Ok, since the security problems cross releases, I'll take responsibility for the list on all trees.
SLES 9 and 10 Thanks
Created attachment 175587 [details] x86_64: Zero extend all registers after ptrace in 32bit entry path. (SLES9)
Created attachment 175588 [details] x86_64: Zero extend all registers after ptrace in 32bit entry path. (SLES10)
PTFs built by Anders Johansson are now available for download: SLES9 SP1: https://you.novell.com/update/x86_64/update/SUSE-SLES/9/PTF/fc1a8dedf5fd91604037c9e206ee1883/20070929/ SLES10 SP1: https://you.novell.com/update/x86_64/update/SUSE-SLES/10/PTF/fc1a8dedf5fd91604037c9e206ee1883/20070929/ SLES10 GA: https://you.novell.com/update/x86_64/update/SUSE-SLES/10/PTF/fc1a8dedf5fd91604037c9e206ee1883/20070929/GA/
Note: SLES GA is officially not supported, so this is (at the moment) an "unofficial" PTF.
Ok, in response to BK's CVE list, I did a bit of research and backporting to address them. Here's my report. If the bugs without bugzilla entries are to be addressed, please open bugzillas for them. I'll note recent commits. CVE-2007-3104: no bugzilla, NULL dentry->d_inode deref in sysfs_readdir Reported against RHEL 4.5 alone. I'm not researching this one. CVE-2007-3107: bugzilla 290622 sles8: unaffected sles9: affected,applied 10.0: affected,applied * applied today sles10: affected,applied 10.2: affected,applied 10.3: unaffected CVE-2007-3642: bugzilla 290611 sles8: unaffected sles9: unaffected 10.0: unaffected sles10: unaffected 10.2: affected,applied 10.3: unaffected CVE-2007-3731: ptrace single step issue sles8: unaffected sles9: unaffected 10.0: unaffected sles10: affected,applied * applied today 10.2: affected,applied * applied today 10.3: affected,applied * applied today CVE-2007-3739: bugzilla 294021, hugetlb stack growth bug sles8: unaffected sles9: unaffected 10.0: affected,applied sles10: affected,applied 10.2: unaffected 10.3: unaffected CVE-2007-3740: no bugzilla, CIFS should honor umask sles8: affected, cifs-should-honor-umask-sles8 sles9: affected, cifs-should-honor-umask-sles9 sl100: affected, cifs-should-honor-umask-sl100 sles10: affected, cifs-should-honor-umask-2.6.16-and-later 10.2: affected, cifs-should-honor-umask-2.6.16-and-later 10.3: unaffected CVE-2007-3843: no bugzilla, cifs using old global for signing sles8: unaffected sles9: unaffected 10.0: unaffected sles10: affected 10.2: affected 10.3: affected Patch: cifs-fix-sign-mount-option-and-sign-proc-config-setting Patch: cifs-mount-should-fail-if-server-signing-off-but-client-mount-option-requires-it Contains behavior change: Mounting with signing requested but unsupported by the server changes from a warning to an error. CVE-2007-4308: no bugzilla, no permission check in aacraid ioctls sles8: affected,aacraid-fix-ioctl-permissions-check-sles8 sles9: affected,aacraid-fix-ioctl-permissions-check 10.0: affected,aacraid-fix-ioctl-permissions-check sles10: affected,aacraid-fix-ioctl-permissions-check 10.2: affected,aacraid-fix-ioctl-permissions-check 10.3: affected,aacraid-fix-ioctl-permissions-check CVE-2007-4573: 326270, Zero extend all registers after ptrace in 32bit entry sles8: affected,applied * applied Friday sles9: affected,applied * applied Friday 10.0: affected,applied * applied Friday sles10: affected,applied * applied Friday 10.2: affected,applied * applied Friday 10.3: affected,applied * applied Friday CVE-2007-5753: bugzilla 230270, bad inode sign extension bug sles8: affected,bad_inode-types.diff sles9: affected,applied 10.0: affected,applied sles10: affected,applied 10.2: affected, applied 10.3: unaffected
Created attachment 175648 [details] aacraid-fix-ioctl-permissions-check
Created attachment 175649 [details] aacraid-fix-ioctl-permissions-check-sles8
Created attachment 175650 [details] bad_inode-types.diff
Created attachment 175651 [details] cifs-fix-sign-mount-option-and-sign-proc-config-setting
Created attachment 175652 [details] cifs-mount-should-fail-if-server-signing-off-but-client-mount-option-requires-it
Created attachment 175653 [details] cifs-should-honor-umask-2.6.16-and-later
Created attachment 175654 [details] cifs-should-honor-umask-sl100
Created attachment 175655 [details] cifs-should-honor-umask-sles8
Created attachment 175656 [details] cifs-should-honor-umask-sles9
If you really want to fix *everything* then http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=480eccf9ae1073b87bb4fe118971fbf134a5bc61 should be probably also backported down to sles9. It's a possible memory leak in all NUMA kernels (this means only x86-64/ia64/ppc64; i386/s390 are not affected)
> 1) > Evan Teran discovered that the Linux kernel ptrace routines did not correctly > handle certain requests robustly. Local attackers could exploit this to crash > the system, causing a denial of service. > > CVE-2007-3731 http://secunia.com/advisories/26935/ https://bugzilla.novell.com/show_bug.cgi?id=329757 > > 2) > It was discovered that hugetlb kernels on PowerPC systems did not prevent the > stack from colliding with reserved kernel memory. Local attackers could exploit > this and crash the system, causing a denial of service. > > bk@suse.de: It's enabled since SLES10-ppc64, wasn't available before. > > CVE-2007-3739 http://secunia.com/advisories/23955/ https://bugzilla.novell.com/show_bug.cgi?id=325652 > 3) > It was discovered that certain CIFS filesystem actions did not honor the umask > of a process. Local attackers could exploit this to gain additional privileges. > > CVE-2007-3740 http://secunia.com/advisories/26366/ https://bugzilla.novell.com/show_bug.cgi?id=325654 > 4) > Wojciech Purczynski discovered that the Linux kernel ia32 syscall emulation in > x86_64 kernels did not correctly clear the high bits of registers. Local > attackers could exploit this to gain root privileges. (CVE-2007-4573) This one. > 5) > Linux Kernel "sysfs_readdir()" Denial of Service > http://secunia.com/advisories/25771/ https://bugzilla.novell.com/show_bug.cgi?id=329758 > > --------------------------------------------------------------------------- > > Security fixes which apply for pre-10.3 kernels only, AFAICS: > > 6) > Linux Kernel AACRAID Driver IOCTL Security Bypass > http://secunia.com/advisories/26322/ https://bugzilla.novell.com/show_bug.cgi?id=329764 > 7) > Linux Kernel Multiple Denial of Service Vulnerabilities > http://secunia.com/advisories/25955/ https://bugzilla.novell.com/show_bug.cgi?id=329765
We don't want to fix every bug known so far with this update. We can fix it with a later update. I'll create new bugzilla entries for c#37 and copy the patches there.
Sounds sensible. I'll open a separate bug for the issue in #47
(In reply to comment #37 from Jeff Mahoney) > Ok, in response to BK's CVE list, I did a bit of research and backporting to > address them. Here's my report. If the bugs without bugzilla entries are to be > addressed, please open bugzillas for them. I'll note recent commits. > > CVE-2007-3104: no bugzilla, NULL dentry->d_inode deref in sysfs_readdir > Reported against RHEL 4.5 alone. I'm not researching this one. https://bugzilla.novell.com/show_bug.cgi?id=329758 > CVE-2007-3731: ptrace single step issue > sles8: unaffected > sles9: unaffected > 10.0: unaffected > sles10: affected,applied * applied today > 10.2: affected,applied * applied today > 10.3: affected,applied * applied today https://bugzilla.novell.com/show_bug.cgi?id=329757 > CVE-2007-3740: no bugzilla, CIFS should honor umask > sles8: affected, cifs-should-honor-umask-sles8 > sles9: affected, cifs-should-honor-umask-sles9 > sl100: affected, cifs-should-honor-umask-sl100 > sles10: affected, cifs-should-honor-umask-2.6.16-and-later > 10.2: affected, cifs-should-honor-umask-2.6.16-and-later > 10.3: unaffected https://bugzilla.novell.com/show_bug.cgi?id=325654 > > CVE-2007-3843: no bugzilla, cifs using old global for signing > sles8: unaffected > sles9: unaffected > 10.0: unaffected > sles10: affected > 10.2: affected > 10.3: affected > Patch: cifs-fix-sign-mount-option-and-sign-proc-config-setting > Patch: > cifs-mount-should-fail-if-server-signing-off-but-client-mount-option-requires-it > Contains behavior change: Mounting with signing requested > but unsupported by the server > changes from a warning to an error. https://bugzilla.novell.com/show_bug.cgi?id=329790 > CVE-2007-4308: no bugzilla, no permission check in aacraid ioctls > sles8: affected,aacraid-fix-ioctl-permissions-check-sles8 > sles9: affected,aacraid-fix-ioctl-permissions-check > 10.0: affected,aacraid-fix-ioctl-permissions-check > sles10: affected,aacraid-fix-ioctl-permissions-check > 10.2: affected,aacraid-fix-ioctl-permissions-check > 10.3: affected,aacraid-fix-ioctl-permissions-check https://bugzilla.novell.com/show_bug.cgi?id=329764 Jeff, thanks for this nice overview and for patching.
PTF for SLES8 is now available: https://you.novell.com/update/x86_64/update/SuSE-SLES/8/PTF/fc1a8dedf5fd91604037c9e206ee1883/20071001/
Is there a way to prevent the exploit for the privilege escalation from working? Like e.g. disallowing ptrace globally?
You could probably disable it using a suitable selinux policy. I don't think AA can disallow it globally (?) It would be also possible to write a simple kernel module (or user program) that just disables the 32bit entry points (or alternatively ptrace) by patching memory. Of course 32bit programs (or ptrace) then wouldn't work anymore.
Since the kernel update is expected to take one week until release from now at least any workaround would help to calm down the angry mob in the meantime.
Why does it take that long? The mob could be just pointed to KOTD kernels meanwhile.
(In reply to comment #58 from Andi Kleen) > Why does it take that long? > > The mob could be just pointed to KOTD kernels meanwhile. > That is what I did last Friday in the weekly summary report. BTW, I had email conversations with customers that patched the kernel on their own or wrote a LKM to disable ptrace().
A week latency for a relatively simple patch is still ridiculous. Something is very wrong with the procedures.
(In reply to comment #58 from Andi Kleen) > The mob could be just pointed to KOTD kernels meanwhile. Or be pointed to the PTFs if they are entitled to get them. After all that's why we built them.
(In reply to comment #60 from Andreas Kleen) > A week latency for a relatively simple patch is still ridiculous. Something > is very wrong with the procedures. > Often security updates carry normal patches piggyback. Building needs much of the time as well as testing too. Additionally Wednesday is national holiday. Nevertheless I often wonder why RH is so much fatser then we are.
Perhaps they don't include the other patches for critical security updates? With that a lot of the QA procedures could be likely waived based on analysis of the patch and what it could possibly break (very little for the ptrace patch)
(In reply to comment #63 from Andi Kleen) > Perhaps they don't include the other patches for critical security updates? > With that a lot of the QA procedures could be likely waived based on analysis > of the patch and what it could possibly break (very little for the ptrace > patch) And we do that already, that's what our PTFs are. The problem is that we don't push them to the regular update channel. Maybe we should.
Can we also get PTFs for the XEN kernels.
(a) please do not hijack this bugreport with other security issues, please discuss them in the other bugreports / open new ones. (b) A regular kernel update takes 3 - 4 weeks currently. We hope to get this specific one out faster, but we still carry all patches accumulated in CVS. A process review _WILL_ happen afterwards and we will have a "FAST Track" method of updating the kernel.
Re comment #68: No, it's not included. I built the PTFs against the latest released kernels, with no additional patches Re comment #65: I've built a kernel-xen PTF, bothe-ajohansson-30, awaiting copy
Patched Xen kernel for SLES10 SP1 is now available for download: https://you.novell.com/update/x86_64/update/SUSE-SLES/10/PTF/fc1a8dedf5fd91604037c9e206ee1883/20070929/
From: dann frazier <dannf@hp.com> To: keir@xensource.com Cc: vendor-sec@lst.de User-Agent: Mutt/1.5.16 (2007-06-11) Subject: [vendor-sec] CVE-2007-4573 also applies to xen code Errors-To: vendor-sec-admin@lst.de Date: Mon, 1 Oct 2007 18:14:01 -0600 hey Keir, A root privilege escalation vulnerability was recently announced and assigned CVE-2007-4573: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4573 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=176df2457ef6207156ca1a40991c54ca01fef567 Debian released an update for this issue, and a couple of users reported that our 'xen' flavour builds were still vulnerable. One of them provided us with a patch: http://lists.debian.org/debian-security/2007/10/msg00001.html An exploit is available: http://seclists.org/bugtraq/2007/Sep/0363.html Alex Williamson tested this against a recent upstream Xen tree, and found that it is vulnerable as well. -- dann frazier _______________________________________________ Vendor Security mailing list Vendor Security@lst.de https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
User-Agent: Microsoft-Entourage/11.3.6.070618 From: Keir Fraser <keir@xensource.com> To: dann frazier <dannf@hp.com> Cc: vendor-sec@lst.de Thread-Topic: CVE-2007-4573 also applies to xen code Thread-Index: AcgEtu76La2gNnCqEdyFZQAWy6hiGQ== Subject: [vendor-sec] Re: CVE-2007-4573 also applies to xen code Errors-To: vendor-sec-admin@lst.de Date: Tue, 02 Oct 2007 06:41:52 +0100 Thanks, I will commit the fix to the xen-unstable and xen-3.1.1 trees. -- Keir
I'm adding the xen patch.
Xen patch is needed on sles10 (committed), sles9 sp4 (committed) and 10.2 (committed). SLES9 SP3 is alright, because Xen/x86_64 wasn't available there.
Updated PTF for SLES10 SP1 kernel-xen available for download at: https://you.novell.com/update/x86_64/update/SUSE-SLES/10/PTF/fc1a8dedf5fd91604037c9e206ee1883/20070929/
From: dann frazier <dannf@dannf.org> To: Keir Fraser <keir@xensource.com> Cc: vendor-sec@lst.de, waldi@debian.org Subject: CVE-2006-5755/Xen (Was: Re: [vendor-sec] Re: CVE-2007-4573 also applies to xen code) User-Agent: Mutt/1.5.16 (2007-06-11) Errors-To: vendor-sec-admin@lst.de Date: Tue, 2 Oct 2007 13:26:56 -0600 On Tue, Oct 02, 2007 at 06:41:52AM +0100, Keir Fraser wrote: > Thanks, I will commit the fix to the xen-unstable and xen-3.1.1 trees. Great. Also, Bastian Blank (cc'd) just committed the following patch to our 2.6.18-based tree, which is a port of the upstream fix for CVE-2006-5755 for Xen. Note that there's a system.h change in the upstream patch that you may also need. http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=658fdbef66e5e9be79b457edc2cbbb3add840aa9 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5755
I think we're done. Closing.
Just for the record: Patches: patches.xen/handle-bogus-cs-selector-in-single-step-instruction-decoding patches.fixes/handle-bogus-%cs-selector-in-single-step-instruction-decoding patches.fixes/x86_64-zero-extend-all-registers-after-ptrace-in-32bit-entry-path 10.2 only:patches.fixes/i386-fixup-TRACE_IRQ-breakage included, enabled, and released in: SLE10 (and 10.1) kernel update 2.6.16.53-0.16 dated Oct 03, 2007 & released Oct 10, 2007. 10.0 kernel update 2.6.13-15.18 dated Oct 03, 2007 & released Oct 10, 2007. 10.2 kernel update 2.6.18.8-0.7 dated Oct 03, 2007 & released Oct 10, 2007. Patch: patches.fixes/x86_64-zero-extend-all-registers-after-ptrace-in-32bit-entry-path included, enabled, and released in: SLES-9 SP3 kernel update 2.6.5-7.287.3 dated Oct 02, 2007 & released Oct 11, 2007. Patch: patches.common/x86_64-validate-all-64bits-of-ptrace-information included, enabled, and released in: SLES-8 SP4 kernel update 2.4.21-325 dated Oct 04, 2007 & released Oct 12, 2007. Setting Whiteboard Status --> released for: SLE10-SP1 SLES9-SP3 SLES8 10.0 10.2
Removing "released:kernel:sle10sp1" tag in order to track more up-coming SLE10-SP1 patches (CVE-2007-4308, CVE-2007-4573: intended for the next kernel update).
Again, for the record: Patches: patches.fixes/aacraid-fix-ioctl-permissions-check (fix for CVE-2007-4308; see also: bug 329764) patches.xen/xen3-x86_64-zero-extend-all-registers-after-ptrace-in-32bit-entry-path patches.fixes/x86_64-zero-extend-all-registers-after-ptrace-in-32bit-entry-path (fixes on XEN, resp., x86_64, for CVE-2007-4573) included, enabled, and released in: SLE10 (and 10.1) kernel update 2.6.16.54-0.2.3 dated Nov 24, 2007 & released Dec 3, 2007. Adding Whiteboard Status "released:kernel:sle10sp1" again.
released sles9 updates kernel version is: 2.6.5-7.312
CVE-2007-4573: CVSS v2 Base Score: 7.2 (AV:L/AC:L/Au:N/C:C/I:C/A:C)
Starting L3 here
Patches have been scheduled for the next sles10sp1 TD rollup (bug 434477 comment 150).
This is no longer a crit-sit so I guess we can lower down priority (I can resume it back after we are done here).
Patches have been scheduled for the next sles9sp3 TD rollup (bug 426350 comment 181 and bug 426350 comment 182). L3 is done here