| Summary: | Please mark =sys-kernel/hardened-sources-2.6.32-r9 stable | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Anthony Basile <blueness> |
| Component: | New packages | Assignee: | The Gentoo Linux Hardened Kernel Team (OBSOLETE) <hardened-kernel+disabled> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bernd, capsel, ppc |
| Priority: | High | Keywords: | STABLEREQ |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Anthony Basile
2010-07-04 15:33:28 UTC
+ 06 Jul 2010; <chainsaw@gentoo.org> hardened-sources-2.6.32-r9.ebuild: + Marked stable on AMD64 as requested by Anthony G. Basile + <blueness@gentoo.org> in bug #326885. Operational testing done for 1 week + on roughly two dozen HP Proliant DL365 G1 and DL385 G2 systems. alpha/ia64/sparc will pass, i'm not even sure why we have this keyworded... x86 stable HPPA keywording seems to have appeared with 2.6.24-r3. Will pass for now. ppc64 stable - special arrangement with arch team. (In reply to comment #5) > ppc64 stable - special arrangement with arch team. > Please make stable any of gradm 2.1.14 too, because this kernel requires it. (In reply to comment #6) > (In reply to comment #5) > > ppc64 stable - special arrangement with arch team. > > > > Please make stable any of gradm 2.1.14 too, because this kernel requires it. > Yep, had to wait the month in tree as ~arch. I'm makeing the request now. (In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > ppc64 stable - special arrangement with arch team. > > > > > > > Please make stable any of gradm 2.1.14 too, because this kernel requires it. > > > > Yep, had to wait the month in tree as ~arch. I'm makeing the request now. > See bug #331301 for =sys-apps/gradm-2.1.14.201005041005.ebuild STABLEREQ there is root exploit for x86_64: http://sota.gen.nz/compat2/robert_you_suck.c test@brat-sas /tmp $ ./robert resolved symbol commit_creds to 0xffffffff81058850 resolved symbol prepare_kernel_cred to 0xffffffff81058700 mapping at 3f80000000 UID 0, EUID:0 GID:0, EGID:0 sh-4.0# uname -a Linux brat-sas 2.6.32-hardened-r9 #1 SMP Tue Aug 31 13:38:30 EEST 2010 x86_64 Quad-Core AMD Opteron(tm) Processor 2372 HE AuthenticAMD GNU/Linux sh-4.0# id uid=0(root) gid=0(root) groups=0(root) (In reply to comment #9) > there is root exploit for x86_64: http://sota.gen.nz/compat2/robert_you_suck.c > > test@brat-sas /tmp $ ./robert > resolved symbol commit_creds to 0xffffffff81058850 > resolved symbol prepare_kernel_cred to 0xffffffff81058700 > mapping at 3f80000000 > UID 0, EUID:0 GID:0, EGID:0 > sh-4.0# uname -a > Linux brat-sas 2.6.32-hardened-r9 #1 SMP Tue Aug 31 13:38:30 EEST 2010 x86_64 > Quad-Core AMD Opteron(tm) Processor 2372 HE AuthenticAMD GNU/Linux > sh-4.0# id > uid=0(root) gid=0(root) groups=0(root) > I will have the fix in the tree as soon as possible and try to fast track stabilization. However, hardened users are in good shape: 1) Whether hardened or not, if you don't have CONFIG_IA32_EMULATION, the exploit fails. 2) If you hide kernel symbols in /proc/kallsyms, *this* particular POC won't work. You can do that by either not enabling CONFIG_KALLSYMS on non-hardened kernels, or just set CONFIG_GRKERNSEC_HIDESYM=y on hardened. (However, there may still be ways of making the exploit work even without symbol info.) 3) On hardened systems, if you enable CONFIG_PAX_MEMORY_UDEREF=y, the exploit fails even with access to symbol info. I hope this ties people over until the fix trickles down.
> I will have the fix in the tree as soon as possible and try to fast track
> stabilization. However, hardened users are in good shape:
hardened-sources-2.6.32-r18.ebuild and hardened-sources-2.6.34-r6.ebuild
I tested turning off *all* grsec and pax, and the exploit still failed. As far as I know, no configuration of the latest hardened kernels is vulnerable.
Hardened-sources 2.6.32-r18 and 2.6.34-r6 have been marked stable for amd64 in the tree. See bug #338273. Having said that, this is a bug for stabilizing 2.6.32-r9 and is not the appropriate place to continue a discussion about the IA32 syscall root exploit. Please refer to bug #337645 for that. Okay closing this in favor of bug #341915 |