gdb versus PAX: Oops (readily reproducible)

[Alexei.Sheplyakov]

Hi!

I was debugging my program

Code: Select all

Breakpoint 1, GiNaC::expairseq::make_flat (this=0x5, v=@0x0)
     at /afs/diastp.jinr.ru/user/varg/work/sw/ginac/ginac/expairseq.cpp:1060
1060    void expairseq::make_flat(const epvector &v)
(gdb) call this->dbgprint()


and got this:

Code: Select all

PAX: execution attempt in: <NULL>, 00000000-00000000 00000000
PAX: terminating task: /home/pc7131/varg/common(common):3066, uid/euid: 1000/1000, PC: 00001000, SP: 5bd8f984
PAX: bytes at PC: ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
PAX: bytes at SP-4: 5243bbee 0804ae50 00000005 5243c602 0806de58 0806de28 5bd8fa44 5bd8fa48 5243c5de 5264b3ec 0806de38 523dedb0 0806de58 0806de28 52382000 002c9d7c 5238f258 5264b3ec 0806de58 5bd8fa44 0806de10
------------[ cut here ]------------
Kernel BUG at [verbose debug info unavailable]
invalid opcode: 0000 [#1]
SMP
Modules linked in: button ac battery ppdev lp cpufreq_powersave p4_clockmod speedstep_lib freq_table binfmt_misc nfsd exportfs lockd nfs_acl sunrpc ipt_LOG xt_limit xt_conntrack ip_conntrack xt_tcpudp ipt_iprange xt_multiport iptable_filter ip_tables x_tables nls_utf8 ntfs xfs it87 hwmon_vid hwmon i2c_isa fuse mousedev tsdev snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_pcm snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_timer snd_seq_device snd psmouse usblp dv1394 soundcore sg i2c_i801 analog serio_raw snd_page_alloc rtc shpchp pci_hotplug parport_pc parport raw1394 intel_agp agpgart floppy iTCO_wdt i2c_core gameport evdev sr_mod cdrom ext3 jbd mbcache dm_mirror dm_snapshot dm_mod ide_generic sd_mod piix generic ide_core ata_piix skge ohci1394 ieee1394 ata_generic libata scsi_mod ehci_hcd uhci_hcd usbcore thermal processor fan unix fbcon tileblit font bitblit softcursor
CPU:    0
EIP:    0060:[<0005336a>]    Not tainted VLI
EFLAGS: 00010202   (2.6.19.2-grsec-p4-smp #1)
eax: 00000002   ebx: c1c06c40   ecx: dfaced40   edx: c16f6a20
esi: 00000000   edi: dfd1a3c0   ebp: dfd1a3c0   esp: f7381ef8
ds: 0068   es: 0068   ss: 0068
Process common (pid: 3066, ti=f7380000 task=f7af1030 task.ti=f7380000)
Stack: 00000000 f7381f08 00000000 c1c06c40 0000008c dfd1a3c0 dfd1a408 00000001
       0001cd66 f7333bcc f7af1030 00021f01 f735b000 f7388000 dfd1a3c0 5bd8f984
       00000009 f7333bcc dfd1a3f4 f7af1030 dfd1a3c0 00017200 f7af149c 00000000
Call Trace:
 =======================
Code: 5b 5e 5f c3 c7 43 08 00 00 00 00 8b 03 e8 2d c0 fb ff 8b 53 04 83 fa ff 74 d8 8d 43 10 e8 3b 3a 00 00 c7 43 04 00 00 00 00 eb c7 <0f> 0b eb ce 56 89 c6 53 89 d3 83 ec 14 8b 42 48 85 c0 75 18 8b
EIP: [<0005336a>]  SS:ESP 0068:f7381ef8
 <1>Fixing recursive fault but reboot is needed!


I use linux 2.6.19.2 from kernel.org, grsecurity-2.1.10-2.6.19.2-200701222307.patch.
My .config is available from
http://theor.jinr.ru/~varg/web/linux/co ... -p4-smp.gz

This Oops is 100% reproducible, but the procedure is somewhat cumbersome
(the binary I was debugging uses a bunch of [C++] libraries).

I've tried to debug the same binary when running vanilla kernel. No Oops
happens, instead gdb prints something like

Code: Select all

Can't access memory at 0x5


Any ideas?

[PaX Team]

I use linux 2.6.19.2 from kernel.org, grsecurity-2.1.10-2.6.19.2-200701222307.patch.

can you try the patch for 2.6.20.x? i think it's the same bug as http://bugs.gentoo.org/show_bug.cgi?id=169121 and i'd like you to reproduce it if possible on 2.6.20 as .19 is no longer supported (and soon it'll be .21 .

[Alexei.Sheplyakov]

can you try the patch for 2.6.20.x? i think it's the same bug as
http://bugs.gentoo.org/show_bug.cgi?id=169121

Will try this weekend.

and i'd like you to reproduce it if possible on 2.6.20 as .19 is no
longer supported

Sorry? http://www.grsecurity.net says that the lastest version
is 2.1.10... (http://pax.grsecurity.net holds
pax-linux-2.6.16-200604281210.patch, I suppose this one is out of date by now).

Anyway, upgrading the kernel every month or so is certainly not the option.
Are there any work-arounds?

[PaX Team]

and i'd like you to reproduce it if possible on 2.6.20 as .19 is no longer supported

Sorry? http://www.grsecurity.net says that the lastest version is 2.1.10... (http://pax.grsecurity.net holds
pax-linux-2.6.16-200604281210.patch, I suppose this one is out of date by now).

the latest test patches are always posted to http://www.grsecurity.net./~spender and http://www.grsecurity.net/~paxguy1/, i meant to try those.

Anyway, upgrading the kernel every month or so is certainly not the option.
Are there any work-arounds?

unfortunately that's the pace of linux 2.6, we don't have a choice, we can't support as many releases as users wish. as for this bug, i don't know what caused it but i also won't spend time on debugging it on 2.6.19, so you can either reproduce it on the currently supported version or it won't be fixed. as a workaround, maybe turn off SEGMEXEC as that's the most likely code that does something bad to vma/page table accounting (which is what BUG'd here).

[Alexei.Sheplyakov]

the latest test patches are always posted to
http://www.grsecurity.net./~spender and
http://www.grsecurity.net/~paxguy1/, i meant to try those.

I've tried grsecurity-2.1.10-2.6.20.4-200703271911.patch -- no Oops
any more.

we don't have a choice, we can't support as many releases as users wish.

In fact no release is supported at the moment: .19 is already not
supported, and .20 is not supported _yet_ (I guess PAX patches for
.20 are called -test for a reason).

Don't get me wrong, I appreciate all the good work you have done very
much, but two DoSable (or may be exploitable -- who knows?) kernel bugs
in 3 months in conjunction with such a "release policy" (not to mention
that bugs like this never get announced properly) kind of deny the whole
purpose of PAX and grsec.

[PaX Team]

In fact no release is supported at the moment: .19 is already not supported, and .20 is not supported _yet_ (I guess PAX patches for .20 are called -test for a reason).

support for 2.6 means something else than support for 2.4. for the latter we're more confident with our code (or that of the vanilla kernel, for that matter) than with 2.6 therefore we can 'guarantee' some level of security whereas it's 'all bets are off' for 2.6. sad state of affairs if you ask me, but that's what our resources allow. in other words, for 2.6 we try to follow the last stable (2.6.x and 2.6.x.y) version and fix bugs there, but beyond that there're no guarantees that we got every little detail right (as i said already, i know for certain that i need to check out several 2.6 features for PaX interference and i'm also certain that i'll need to change some of my own code as a result, meaning that the current state is NOT correct).

Don't get me wrong, I appreciate all the good work you have done very much, but two DoSable (or may be exploitable -- who knows?) kernel bugs in 3 months in conjunction with such a "release policy" (not to mention that bugs like this never get announced properly) kind of deny the whole purpose of PAX and grsec.

no offense taken, mostly because i think it's you who misunderstands the purpose of PaX/grsec. these projects exist solely because of remotely exploitable bugs, there have never been ANY guarantees about local ones (be they in vanilla or our code). if you think about it, this is the only realistic position one can take, there's simply NO generic solution for the local kernel privilege elevation problem. sure, you can create specific environments where some of them are no longer exploitable (KERNEXEC/UDEREF, strict MAC policies, TPE, digitally signed stuff, or lately, certain forms of virtualisation, etc), but that's not a generic enough solution. so you can blame us as much as you want for all the regrettable bugs, but it won't change the FACT that many of the other linux bugs would have STILL allowed your systems to be compromised (i think we have exposed some of those ourselves in the past). so if you expected invulnerability from local bugs, then it's you who set your expectations too high (and good luck in finding a system that fits your goals, don't forget to let us know too .