From roman at liten.cz Fri Jul 7 14:38:19 2006 From: roman at liten.cz (Roman Vesely) Date: Fri Jul 7 14:07:05 2006 Subject: [grsec] Any plan to release STABLE grsec for 2.6.[16|17] ? Message-ID: <20060707203819.2a7e38de.roman@liten.cz> Hello, Last stable grsec is more than 6 month's old. Any plan to make next stable release? Thanks, Roman From jason at touchsupport.com Fri Jul 7 14:46:28 2006 From: jason at touchsupport.com (Jason Hamilton) Date: Fri Jul 7 14:15:46 2006 Subject: [grsec] Any plan to release STABLE grsec for 2.6.[16|17] ? In-Reply-To: <20060707203819.2a7e38de.roman@liten.cz> References: <20060707203819.2a7e38de.roman@liten.cz> Message-ID: <44AEAC04.7030502@touchsupport.com> Roman, Checkout http://grsecurity.net/~spender/grsecurity-2.1.9-2.6.17.3-200607060904.patch Brad puts new developments in there first for testing and are generally quite stable. -Jason Roman Vesely wrote: > Hello, > > Last stable grsec is more than 6 month's old. > Any plan to make next stable release? > > Thanks, > > Roman > _______________________________________________ > grsecurity mailing list > grsecurity@grsecurity.net > http://grsecurity.net/cgi-bin/mailman/listinfo/grsecurity > From les at jaguarpc.com Fri Jul 7 20:25:19 2006 From: les at jaguarpc.com (Les) Date: Fri Jul 7 19:53:00 2006 Subject: [grsec] [SA20953] Linux Kernel "prctl" Privilege Escalation Vulnerability Message-ID: <44AEFB6F.1080309@jaguarpc.com> An HTML attachment was scrubbed... URL: http://grsecurity.net/pipermail/grsecurity/attachments/20060707/735ab6a0/attachment.htm From sgtphou at fire-eyes.org Fri Jul 7 20:41:10 2006 From: sgtphou at fire-eyes.org (fire-eyes) Date: Fri Jul 7 20:09:46 2006 Subject: [grsec] [SA20953] Linux Kernel "prctl" Privilege Escalation Vulnerability In-Reply-To: <44AEFB6F.1080309@jaguarpc.com> References: <44AEFB6F.1080309@jaguarpc.com> Message-ID: <200607072041.10298.sgtphou@fire-eyes.org> On Friday 07 July 2006 20:25, Les wrote: > References: <44AEFB6F.1080309@jaguarpc.com> <200607072041.10298.sgtphou@fire-eyes.org> Message-ID: <44AF011A.6090301@jaguarpc.com> Resent via plain text. Sorry for the trouble. Greetings all, This advisory just made it's way to me. I have yet to locate a proof of concept test to verify this vulnerability. I felt the best course of action is ask the experts here if the current stable 2.6 release (grsecurity-2.1.8-2.6.14.6-200601211647) is sufficient to protect against this. Regards, Les fire-eyes wrote: > On Friday 07 July 2006 20:25, Les wrote: > >> > > > Thank you, however, can we please get that in plain text? No, I don't want to > start a txt vs html mail war... Please don't reply that way. > > From pageexec at freemail.hu Fri Jul 7 21:03:57 2006 From: pageexec at freemail.hu (pageexec@freemail.hu) Date: Fri Jul 7 20:32:59 2006 Subject: [grsec] [SA20953] Linux Kernel "prctl" Privilege Escalation Vulnerability In-Reply-To: <200607072041.10298.sgtphou@fire-eyes.org> References: <44AEFB6F.1080309@jaguarpc.com> Message-ID: <44AF209D.27580.4A4719CA@pageexec.freemail.hu> On 7 Jul 2006 at 20:41, fire-eyes wrote: > On Friday 07 July 2006 20:25, Les wrote: > > > Thank you, however, can we please get that in plain text? No, I don't want to > start a txt vs html mail war... Please don't reply that way. > > -- > "When you walk across the fields with your mind pure and holy, then from > all the stones, and all growing things, and all animals, the sparks of > their soul come out and cling to you. And then they are purified, and > become a holy fire in you." -- Ancient Hasidic Saying not to rain on your parade, but i think i'm not the only one who sees a certain discrepancy between 2 lines of content and a 4 line sig... as for the original question, no, the 2.6.14 patch doesn't fix this bug and you need to apply the mainline patch yourself. From les at jaguarpc.com Fri Jul 7 21:07:07 2006 From: les at jaguarpc.com (Les) Date: Fri Jul 7 20:34:54 2006 Subject: [grsec] [SA20953] Linux Kernel "prctl" Privilege Escalation Vulnerability In-Reply-To: <44AF011A.6090301@jaguarpc.com> References: <44AEFB6F.1080309@jaguarpc.com> <200607072041.10298.sgtphou@fire-eyes.org> <44AF011A.6090301@jaguarpc.com> Message-ID: <44AF053B.6020703@jaguarpc.com> Arg, and of course when I resend it in plain text I fail to include the notice itself. Here it is. -----Original Message----- From: Secunia Security Advisories [mailto:sec-adv@secunia.com] TITLE: Linux Kernel "prctl" Privilege Escalation Vulnerability SECUNIA ADVISORY ID: SA20953 VERIFY ADVISORY: http://secunia.com/advisories/20953/ CRITICAL: Less critical IMPACT: Security Bypass, Privilege escalation WHERE: Local system OPERATING SYSTEM: Linux Kernel 2.6.x http://secunia.com/product/2719/ DESCRIPTION: A vulnerability has been reported in the Linux Kernel, which can be exploited by malicious, local users to bypass certain security restrictions or potentially gain escalated privileges. The vulnerability is caused due to improper handling of core dumps. This can be exploited to dump core files into usually restricted directories or potentially gain root privileges. SOLUTION: Update to version 2.6.17.4. http://www.kernel.org/ PROVIDED AND/OR DISCOVERED BY: The vendor credits Red Hat. ORIGINAL ADVISORY: http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.17.4 Regards, Les F. Les wrote: > Resent via plain text. Sorry for the trouble. > > Greetings all, > > This advisory just made it's way to me. I have yet to locate a proof > of concept test to verify this vulnerability. I felt the best course > of action is ask the experts here if the current stable 2.6 release > (grsecurity-2.1.8-2.6.14.6-200601211647) is sufficient to protect > against this. > Regards, > Les > > > > fire-eyes wrote: >> On Friday 07 July 2006 20:25, Les wrote: >> >>> >> >> >> Thank you, however, can we please get that in plain text? No, I don't >> want to start a txt vs html mail war... Please don't reply that way. >> >> > _______________________________________________ > grsecurity mailing list > grsecurity@grsecurity.net > http://grsecurity.net/cgi-bin/mailman/listinfo/grsecurity From boysenberry at humaniteque.com Mon Jul 17 10:37:50 2006 From: boysenberry at humaniteque.com (Boysenberry Payne) Date: Mon Jul 17 12:00:12 2006 Subject: [grsec] New to grsecurity and updating my kernel Message-ID: <1ddd074c6b18d508ed2236d15d559ff2@humaniteque.com> I was just informed that I should update my current kernel build, which until recently was managed for me, from 2.6.11.12-grsec to a new version. Can I use the current: grsecurity-2.1.9-2.6.17.4-200607120947.patch on the 2.6.17.6 kernel, or do I need to use a 2.6.17.4 build? Thanks, -BOP "The more I know the more I know I don't know." -Socrates From br at x86.sk Mon Jul 17 13:12:02 2006 From: br at x86.sk (Jakub Cerveny) Date: Mon Jul 17 12:38:53 2006 Subject: [grsec] New to grsecurity and updating my kernel In-Reply-To: <1ddd074c6b18d508ed2236d15d559ff2@humaniteque.com> References: <1ddd074c6b18d508ed2236d15d559ff2@humaniteque.com> Message-ID: <1153156322.4512.6.camel@localhost> hi, in 2.6.17.{5,6} kernels was changed only one file fs/proc/base.c - Makefile | 2 +- fs/proc/base.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) and grsecurity patches doesn't affect this file, so you could use 2.6.17.4 patches against 2.6.17.6 kernel regards, Jakub On Mon, 2006-07-17 at 09:37 -0500, Boysenberry Payne wrote: > I was just informed that I should update my current kernel > build, which until recently was managed for me, from > 2.6.11.12-grsec to a new version. Can I use the current: > grsecurity-2.1.9-2.6.17.4-200607120947.patch > on the 2.6.17.6 kernel, or do I need to use a 2.6.17.4 build? > > Thanks, > -BOP > > "The more I know the more I know I don't know." -Socrates > > _______________________________________________ > grsecurity mailing list > grsecurity@grsecurity.net > http://grsecurity.net/cgi-bin/mailman/listinfo/grsecurity From boysenberry at humaniteque.com Mon Jul 17 14:30:24 2006 From: boysenberry at humaniteque.com (Boysenberry Payne) Date: Mon Jul 17 13:57:08 2006 Subject: [grsec] New to grsecurity and updating my kernel In-Reply-To: <1153156322.4512.6.camel@localhost> References: <1ddd074c6b18d508ed2236d15d559ff2@humaniteque.com> <1153156322.4512.6.camel@localhost> Message-ID: <0b57ad6686a643d470b7cea12a9eb554@humaniteque.com> So if I have grsecurity-2.1.9-2.6.17.4-200607120947.patch in the same directory as my unpacked linux-2.6.17.6 directory the following ought to patch the source? patch -p0 < ./grsecurity-2.1.9-2.6.17.4-200607120947.patch Do I do this before do the following? make oldconfig make make modules_install install Does this seem right? Thanks, Boysenberry boysenberrys.com | habitatlife.com | selfgnosis.com On Jul 17, 2006, at 12:12 PM, Jakub Cerveny wrote: > hi, > > in 2.6.17.{5,6} kernels was changed only one file fs/proc/base.c - > > Makefile | 2 +- > fs/proc/base.c | 3 ++- > 2 files changed, 3 insertions(+), 2 deletions(-) > > and grsecurity patches doesn't affect this file, so you could use > 2.6.17.4 patches against 2.6.17.6 kernel > > regards, > > Jakub > > On Mon, 2006-07-17 at 09:37 -0500, Boysenberry Payne wrote: >> I was just informed that I should update my current kernel >> build, which until recently was managed for me, from >> 2.6.11.12-grsec to a new version. Can I use the current: >> grsecurity-2.1.9-2.6.17.4-200607120947.patch >> on the 2.6.17.6 kernel, or do I need to use a 2.6.17.4 build? >> >> Thanks, >> -BOP >> >> "The more I know the more I know I don't know." -Socrates >> >> _______________________________________________ >> grsecurity mailing list >> grsecurity@grsecurity.net >> http://grsecurity.net/cgi-bin/mailman/listinfo/grsecurity > > > From marc at schiffbauer.net Mon Jul 17 15:52:37 2006 From: marc at schiffbauer.net (Marc Schiffbauer) Date: Mon Jul 17 15:19:26 2006 Subject: [grsec] New to grsecurity and updating my kernel In-Reply-To: <0b57ad6686a643d470b7cea12a9eb554@humaniteque.com> References: <1ddd074c6b18d508ed2236d15d559ff2@humaniteque.com> <1153156322.4512.6.camel@localhost> <0b57ad6686a643d470b7cea12a9eb554@humaniteque.com> Message-ID: <20060717195237.GB5894@schiffbauer.lan> * Boysenberry Payne schrieb am 17.07.06 um 20:30 Uhr: > So if I have grsecurity-2.1.9-2.6.17.4-200607120947.patch in the same > directory > as my unpacked linux-2.6.17.6 directory the following ought to patch > the source? > > patch -p0 < ./grsecurity-2.1.9-2.6.17.4-200607120947.patch > > Do I do this before do the following? Yes. And you need to do a "make menuconfig" or something to configure grsec features if you do not have them in your oldconfig already -Marc -- ------------------------------------------- Take back the Net! http://www.anti-dmca.org ------------------------------------------- From cfp at ruxcon.org.au Tue Jul 18 00:17:34 2006 From: cfp at ruxcon.org.au (cfp@ruxcon.org.au) Date: Mon Jul 17 23:53:18 2006 Subject: [grsec] RUXCON 2006 Final Call For Papers Message-ID: <20060718041734.44850FC191@mail.ruxcon.org.au> RuxCon staff would like to announce the call for papers for the fourth annual RuxCon conference. This year the conference will run from the 30th of September to the 1st of October, over the long weekend. As with previous years, RuxCon will be held at the University of Technology, Sydney, Australia. The deadline for submissions is the 15th of September. What is RuxCon? RuxCon strives to be Australia's most technical and interesting computer security conference. We're back for the fourth year running and intend to bring you another high quality conference. The conference is held over two days in a relaxed atmosphere, allowing attendees to enjoy themselves whilst expanding their knowledge of security. Live presentations and activities will cover a full range of defensive and offensive security topics, varying from unpublished research to required reading for the public security community. For more information, please visit http://www.ruxcon.org.au Presentation Information Presentations will be 50 minutes in length, and should be fully supplemented with slides and any other relevant material. Presentation Submissions RuxCon would like to invite people who are interested to submit a presentation. Topics of interest include, but are not limited to: * Code analysis * Exploitation techniques * Network scanning and analysis * Cryptography * Malware Analysis * Reverse engineering * Forensics and Anti-forensics * Social engineering * Web application security * Legal aspects of computer security and surrounding issues * Law enforcement activities * Telecommunications security (mobile, GSM, fraud issues, etc.) Submissions should thoroughly outline your desired presentation subject. Accompanying your submission should be the slides you intend to use or a detailed paper explaining your subject. If you have any enquiries about submissions, or would like to make a submission, please send an e-mail to presentations@ruxcon.org.au. The deadline for submissions is the 15th of September. If approved we will additionally require: 1. A brief personal biography (between 2-5 paragraphs in length), including: skill set, experience, and credentials. 2. A description on your presentation (between 2-5 paragraphs in length). Contact Details Presentation Submissions: presentations@ruxcon.org.au General Enquiries: ruxcon@ruxcon.org.au From simoneau at ele.uri.edu Tue Jul 18 09:58:17 2006 From: simoneau at ele.uri.edu (Will Simoneau) Date: Tue Jul 18 11:56:29 2006 Subject: [grsec] kdeinit causes scheduling while atomic Message-ID: <20060718135817.GA21666@ele.uri.edu> A scheduling while atomic just started showing up in the kernel log on my machine, which unfortunately is running an odd combination of non-vanilla patches. Maybe someone who knows at least some of the code can give me some hints tracking this down? Or maybe the grsecurity folks have an idea? Patches applied on top of 2.6.17.6: grsecurity-2.1.9-2.6.17.4-200607120947 suspend2-2.2.7-for-2.6.17 (without 9920-linus-basic-trace - that plus grsecurity gives rejects on vmlinux.lds.S) System is running Gentoo, the compiler is gcc 3.4.6 with pie & ssp although those features are turned off when compiling a kernel by the specs file. Userland is compiled with -fstack-protector, and I am using SEGMEXEC for userland NX support. I have two different traces and some PaX output, here they all are: ---cut here--- BUG: scheduling while atomic: kdeinit/0x00000002/31816 schedule+0x53e/0x674 schedule_timeout+0x4d/0x9a process_timeout+0x0/0x5 sched_fork+0x51/0x86 copy_process+0x614/0xdea do_fork+0x75/0x1b2 vfs_write+0xec/0x16e sys_clone+0x32/0x36 syscall_call+0x7/0xb init_script_binfmt+0x6/0xa ---end cut---- ---cut here--- BUG: scheduling while atomic: kdeinit/0x00000002/31816 schedule+0x53e/0x674 schedule_timeout+0x4d/0x9a process_timeout+0x0/0x5 sched_fork+0x51/0x86 copy_process+0x614/0xdea do_fork+0x75/0x1b2 sys_clone+0x32/0x36 syscall_call+0x7/0xb irq_entries_start+0xecb/0xef0 ---end cut---- ---cut here--- PAX: execution attempt in: , 00000000-00000000 00000000 PAX: terminating task: /usr/kde/3.5/bin/konqueror(konqueror):21177, uid/euid: 1000/1000, PC: 00000010, SP: 5953cf80 PAX: bytes at PC: ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? PAX: bytes at SP-4: 00000010 00000003 5953cfb0 00000000 0000000a 0000001c 40488ef8 0000001d 5618e6e0 40083d30 00000000 00000003 55efdb83 40189c00 56108d92 56b09377 5618e6e0 5953d000 00000006 404eadb8 55f2bef8 ---end cut---- Call of a null function pointer? Sometimes konqueror is killed by PaX, sometimes it dies on its own (I think with a segfault). I can reproduce this 100% of the time by firing up Konqueror and going to www.wikipedia.org, just before the front page loads the window dissapears and leave those traces behind. Other sites seem to work fine. The process either segfaults or is killed by PaX immediately after causing the scheduling while atomic. In the terminal where I start konqueror I see this (when PaX does the killing): ---cut here--- Try to load libthai dynamically... Error, can't load libthai... zsh: killed konqueror ---end cut---- ... which seems to be an old unsolved bug in qt. Do I or anybody else have any hope of tracking this down? It almost sounds like an interaction of multiple bugs. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://grsecurity.net/pipermail/grsecurity/attachments/20060718/70f3645a/attachment.pgp From pageexec at freemail.hu Sun Jul 23 08:08:09 2006 From: pageexec at freemail.hu (pageexec@freemail.hu) Date: Sun Jul 23 07:35:02 2006 Subject: [grsec] kdeinit causes scheduling while atomic In-Reply-To: <20060718135817.GA21666@ele.uri.edu> Message-ID: <44C382C9.4760.1D4085C8@pageexec.freemail.hu> On 18 Jul 2006 at 9:58, Will Simoneau wrote: > A scheduling while atomic just started showing up in the kernel log on > my machine, which unfortunately is running an odd combination of > non-vanilla patches. Maybe someone who knows at least some of the code > can give me some hints tracking this down? Or maybe the grsecurity folks > have an idea? given that probably neither side is familiar with the other's patches, you should try to reproduce this with only one patch first. in the meantime, it'd help to find out what gets called at copy_process+0x614/0xdea, there's probably a 'call' insn around copy_process+60f, you can use objdump to find out who the target is. > Patches applied on top of 2.6.17.6: > grsecurity-2.1.9-2.6.17.4-200607120947 > suspend2-2.2.7-for-2.6.17 (without 9920-linus-basic-trace - that plus > grsecurity gives rejects on vmlinux.lds.S) from what i see, it's a trivial reject, you can apply it by hand after RODATA. > ---cut here--- > PAX: execution attempt in: , 00000000-00000000 00000000 > PAX: terminating task: /usr/kde/3.5/bin/konqueror(konqueror):21177, uid/euid: 1000/1000, PC: 00000010, SP: 5953cf80 > PAX: bytes at PC: ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? > PAX: bytes at SP-4: 00000010 00000003 5953cfb0 00000000 0000000a 0000001c 40488ef8 0000001d 5618e6e0 40083d30 00000000 00000003 55efdb83 40189c00 56108d92 56b09377 5618e6e0 5953d000 00000006 404eadb8 55f2bef8 > ---end cut---- > > Call of a null function pointer? it's interesting that at esp-4 you have 0x10, which happens to be the faulting eip value as well. this can occur if the fault occured not due to a 'call' but rather a 'retn' insn, that is, a function was trying to return to its caller, but the return address got overwritten on the stack. now whether that happened due to some programming error or a gcc/ssp bug is a good question. i'd first try to recompile it (and all related libraries!) w/o ssp, it's known to have code generation bugs for c++ code. if that cures the problem, you should enter it into the gentoo bugzilla. > Sometimes konqueror is killed by PaX, sometimes it dies on its own (I > think with a segfault). I can reproduce this 100% of the time by firing > up Konqueror and going to www.wikipedia.org, just before the front page > loads the window dissapears and leave those traces behind. Other sites > seem to work fine. The process either segfaults or is killed by PaX > immediately after causing the scheduling while atomic. you mean, the first mentioned schedule BUG triggered in kdeinit is related to this crash in konqueror? or are you getting a schedule BUG in konqueror as well? in any case, eliminating one variable at a time (like ssp) should help you nail the bug(s) down. From simoneau at ele.uri.edu Sun Jul 23 17:00:39 2006 From: simoneau at ele.uri.edu (Will Simoneau) Date: Sun Jul 23 16:25:42 2006 Subject: [grsec] kdeinit causes scheduling while atomic In-Reply-To: <44C382C9.4760.1D4085C8@pageexec.freemail.hu> References: <20060718135817.GA21666@ele.uri.edu> <44C382C9.4760.1D4085C8@pageexec.freemail.hu> Message-ID: <20060723210039.GC30515@ele.uri.edu> On 14:08 Sun 23 Jul , pageexec@freemail.hu wrote: > On 18 Jul 2006 at 9:58, Will Simoneau wrote: > > A scheduling while atomic just started showing up in the kernel log on > > my machine, which unfortunately is running an odd combination of > > non-vanilla patches. Maybe someone who knows at least some of the code > > can give me some hints tracking this down? Or maybe the grsecurity folks > > have an idea? > > given that probably neither side is familiar with the other's patches, > you should try to reproduce this with only one patch first. in the meantime, > it'd help to find out what gets called at copy_process+0x614/0xdea, there's > probably a 'call' insn around copy_process+60f, you can use objdump to find > out who the target is. objdump -d: c014838a: be 00 f0 ff ff mov $0xfffff000,%esi c014838f: 8b bb a0 00 00 00 mov 0xa0(%ebx),%edi c0148395: 21 e6 and %esp,%esi c0148397: 8b 06 mov (%esi),%eax c0148399: 85 ff test %edi,%edi c014839b: 0f b7 40 2c movzwl 0x2c(%eax),%eax c014839f: 66 89 43 2c mov %ax,0x2c(%ebx) c01483a3: 74 51 je c01483f6 -> c01483a5: e8 a7 ab 0f 00 call c0242f51 c01483aa: 8b 83 ac 00 00 00 mov 0xac(%ebx),%eax c01483b0: 05 b0 00 00 00 add $0xb0,%eax c01483b5: 8b 4c 24 0c mov 0xc(%esp),%ecx > > > Patches applied on top of 2.6.17.6: > > grsecurity-2.1.9-2.6.17.4-200607120947 > > suspend2-2.2.7-for-2.6.17 (without 9920-linus-basic-trace - that plus > > grsecurity gives rejects on vmlinux.lds.S) > > from what i see, it's a trivial reject, you can apply it by hand after RODATA. > > > ---cut here--- > > PAX: execution attempt in: , 00000000-00000000 00000000 > > PAX: terminating task: /usr/kde/3.5/bin/konqueror(konqueror):21177, uid/euid: 1000/1000, PC: 00000010, SP: 5953cf80 > > PAX: bytes at PC: ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? > > PAX: bytes at SP-4: 00000010 00000003 5953cfb0 00000000 0000000a 0000001c 40488ef8 0000001d 5618e6e0 40083d30 00000000 00000003 55efdb83 40189c00 56108d92 56b09377 5618e6e0 5953d000 00000006 404eadb8 55f2bef8 > > ---end cut---- > > > > Call of a null function pointer? > > it's interesting that at esp-4 you have 0x10, which happens to be the > faulting eip value as well. this can occur if the fault occured not > due to a 'call' but rather a 'retn' insn, that is, a function was trying > to return to its caller, but the return address got overwritten on the > stack. now whether that happened due to some programming error or a > gcc/ssp bug is a good question. i'd first try to recompile it (and all > related libraries!) w/o ssp, it's known to have code generation bugs for > c++ code. if that cures the problem, you should enter it into the gentoo > bugzilla. It's caused by qt, with -fstack-protector(-all?) enabled. Version is x11-libs/qt-3.3.6-r1 from portage. Without ssp, going to wikipedia in konqueror works fine. Will file at bugs.gentoo.org when I get a chance. > > > Sometimes konqueror is killed by PaX, sometimes it dies on its own (I > > think with a segfault). I can reproduce this 100% of the time by firing > > up Konqueror and going to www.wikipedia.org, just before the front page > > loads the window dissapears and leave those traces behind. Other sites > > seem to work fine. The process either segfaults or is killed by PaX > > immediately after causing the scheduling while atomic. > > you mean, the first mentioned schedule BUG triggered in kdeinit is related > to this crash in konqueror? or are you getting a schedule BUG in konqueror > as well? in any case, eliminating one variable at a time (like ssp) should > help you nail the bug(s) down. > I'm not sure what's happening with the scheduling while atomic now. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://grsecurity.net/pipermail/grsecurity/attachments/20060723/e7768b4b/attachment.pgp From pageexec at freemail.hu Mon Jul 24 05:22:32 2006 From: pageexec at freemail.hu (pageexec@freemail.hu) Date: Mon Jul 24 04:49:16 2006 Subject: [grsec] kdeinit causes scheduling while atomic In-Reply-To: <20060723210039.GC30515@ele.uri.edu> References: <44C382C9.4760.1D4085C8@pageexec.freemail.hu> Message-ID: <44C4AD78.19489.21CF417C@pageexec.freemail.hu> On 23 Jul 2006 at 17:00, Will Simoneau wrote: > objdump -d: > > -> c01483a5: e8 a7 ab 0f 00 call c0242f51 spender's bug ;). that function explicitly sleeps if a brute force attempt was detected (too many crashes in a given time period), which is apparently not the right to do when inside copy_process(). > It's caused by qt, with -fstack-protector(-all?) enabled. Version is > x11-libs/qt-3.3.6-r1 from portage. Without ssp, going to wikipedia in > konqueror works fine. Will file at bugs.gentoo.org when I get a chance. start here: http://bugs.gentoo.org/show_bug.cgi?id=135265 From spender at grsecurity.net Mon Jul 24 17:05:53 2006 From: spender at grsecurity.net (Brad Spengler) Date: Mon Jul 24 17:06:02 2006 Subject: [grsec] kdeinit causes scheduling while atomic In-Reply-To: <44C4AD78.19489.21CF417C@pageexec.freemail.hu> References: <44C382C9.4760.1D4085C8@pageexec.freemail.hu> <44C4AD78.19489.21CF417C@pageexec.freemail.hu> Message-ID: <20060724210553.GA7184@grsecurity.net> > > -> c01483a5: e8 a7 ab 0f 00 call c0242f51 > > spender's bug ;). that function explicitly sleeps if a brute force > attempt was detected (too many crashes in a given time period), > which is apparently not the right to do when inside copy_process(). The latest patch in ~spender resolves this issue. -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grsecurity.net/pipermail/grsecurity/attachments/20060724/b5e79590/attachment.pgp From aghidottipiovan at yahoo.it Wed Jul 26 05:11:37 2006 From: aghidottipiovan at yahoo.it (Ghido) Date: Wed Jul 26 04:34:39 2006 Subject: [grsec] Log Analysis Message-ID: <44C731C9.60709@yahoo.it> Hello, I want to analyze realtime grsecurity logs to report known attacks to the administrator or launch some scripts after detection. Do you know if yet exists a working way to derive matching rules to detect attacks from analyzing logs, or if exists something as a "plugin" or a "rules collection" for most common log analyzers? And, what log analyzer do you advise me for doing this work? I heard about swatch, tenshi... but i don't know which is the best for ease of using and flexibility. Which one do you prefer? Thank you very much. Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com From pageexec at freemail.hu Wed Jul 26 05:59:30 2006 From: pageexec at freemail.hu (pageexec@freemail.hu) Date: Wed Jul 26 05:25:54 2006 Subject: [grsec] Log Analysis In-Reply-To: <44C731C9.60709@yahoo.it> Message-ID: <44C75922.1362.2C3DD243@pageexec.freemail.hu> On 26 Jul 2006 at 11:11, Ghido wrote: > I want to analyze realtime grsecurity logs to report known attacks to > the administrator or launch some scripts after detection. maybe http://www.prelude-ids.org/ ? From spender at grsecurity.net Wed Jul 26 21:26:41 2006 From: spender at grsecurity.net (Brad Spengler) Date: Wed Jul 26 21:26:51 2006 Subject: [grsec] grsecurity 2.1.9 released for 2.4.32/2.4.33-rc2/2.6.17.7 Message-ID: <20060727012641.GA14773@grsecurity.net> grsecurity 2.1.9 has been released for the 2.4.32, 2.4.33-rc2, and 2.6.17.7 series of Linux kernels. Changes in this release include: * A new PaX feature that eliminates a class of kernel vulnerabilities from being exploitable. The PaX feature prevents exploitation in the case of any invalid userland pointer dereferences. This feature is also useful for debugging purposes, since it will catch any driver that uses userland memory directly and not through the proper copy_(to/from)_user channels. This feature is highly recommended, though it should not be enabled in kernels meant to run inside virtual machines (unless your processor supports virtualization extensions). * A new PaX feature that zeroes out physical memory pages as soon as they are freed. Though an encrypted swap helps reduce the chance of certain sensitive information being recovered, it does nothing against short-term recovery of sensitive information which may be properly locked into physical memory. The sensitive information can be found by reading /dev/mem and /dev/kmem (if you haven't protected those with grsecurity), or through arbitrary read bugs in the kernel. Enabling this feature incurs a small performance hit (3% measured on kernel compilation). In the future, it will be integrated into the RBAC, so that it can be toggled on a per-process basis, reducing the overall performance hit. * The long-time unmounting failure on reboot bug (caused by certain /proc assumptions by killall5) has been resolved. * An RBAC bug reported on the forums related to automatic policy regeneration has been resolved. * A rare deadlock condition in the IP tagging code has been resolved. * Resource logging has become a sysctl-tunable feature. * Disabling support for module loading at runtime through the grsecurity feature no longer prevents writes to other grsecurity-related sysctl entries. * Additional minor grsecurity/gradm bugfixes Please note that the 2.4.33-rc2 kernel is currently being recommended instead of the 2.4.32 kernel, since it includes a number of fixes for reported security bugs. The 2.6 patch has changed the way it adds -grsec to the kernel's extraversion, so it should apply cleanly to most 2.6.17.x kernel releases. We however continue to discourage the 2.6 series of kernels for production use for reasons that should by now be obvious to everyone. On another note, my employer is sending me to Blackhat/Defcon this year, so I hope to get a chance to meet some of you there. Enjoy, -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grsecurity.net/pipermail/grsecurity/attachments/20060726/279fd932/attachment.pgp