grsecurity forums

A few weeks ago I struggled to get gr securty to work with my kernel without success with some help from this forum. I will launching a free linux shell service to the public and do not want to go online without proper security. Can you guys suggest alternatives to gr security or links or books, anything that will secure my debian system against hackers. Thanks.

cizzi wrote:I will launching a free linux shell service to the public and do
not want to go online without proper security.

Giving shell service is itself hideously insecure. Anyway, I'm afraid
grsecurity is wrong tool for securing such a system, at least, I was
told so by PaX developer(s), see

viewtopic.php?f=3&t=1707#p6811

cizzi wrote:Can you guys suggest alternatives to gr security or links or books, anything
that will secure my debian system against hackers.

I think some kind of virtualization (user mode linux, vserver, kvm, etc.)
is a better (as in: simple and reasonably secure) approach.

If you feel masochistic enough you might want to try RSBAC or SELinux.
Be forewarned:
1. Although their security model is fairly simple, it's radically different
from traditional *NIX one. Learning it and getting used to it takes a while.
(The same applies to grsecurity).
2. Unfortunately, *NIX software was not designed with such a "strong" security
in mind, so it breaks more often than not.

P.S.

The only *simple* way to secure system from crackers is to plug off the power cord.

RSBAC or SELinux won't provide more security for a shell server than grsecurity. Remember, as I have demonstrated with my local root exploit, it only takes one kernel bug to completely disable SELinux. At least grsecurity includes PaX which provides protection against specific bug classes and exploitation methods in the kernel. SELinux now ships with a weaker form of "protection" against null ptr dereference bugs (unlike the generic invalid userland access class PaX protects against) which was able to be bypassed by at least two separate methods that the PaX team and myself discovered back in May of last year, which were just recently fixed with no CVE from Redhat.

-Brad

A quick real-life example of how SELinux's "protection" is inferior to that provided by PaX's UDEREF: a recent exploitable bug in the Linux kernel (of course still called a DoS, or "bugfix" by the ignorant Linux developers) involved a corrupted function pointer, which instead of having the value of NULL, had the value of a memory poisoning constant, which happens to translate to a userland-accessible address. The bug is just as exploitable as a null ptr deref bug, but SELinux will provide no protection against it, since the constant is an address higher than one can set their mmap_min_addr value.

-Brad

spender wrote:RSBAC or SELinux won't provide more security for a shell server than grsecurity.

Sure, it's possible to implement an equivalent grsecurity policy.
However, writing a (complex enough) RSBAC policy is easier for me.

At least grsecurity includes PaX

RSBAC also includes PaX.

which provides protection against specific bug classes and exploitation
methods in the kernel.

Either you or PaX team must be wrong, see
viewtopic.php?p=6791


> SELinux now ships with a weaker form of "protection" against null ptr
> dereference bugs (unlike the generic invalid userland access class PaX
> protects against)

AFAIK, uderef is ia-32 only. I wouldn't call that "generic".

> which was able to be bypassed by at least two separate methods that
> the PaX team and myself discovered back in May of last year, which
> were just recently fixed with no CVE from Redhat.

Sadly, grsecurity is even worse. Bugs get fixed with no CVEs, no ChangeLogs,
no announcements. Even no PGP signatures of those "test patches".

spender wrote:A quick real-life example of how SELinux's "protection" is inferior

viewtopic.php?t=1813

At least, SELinux does not introduce new kernel bugs.

Alexei.Sheplyakov wrote:

spender wrote:which provides protection against specific bug classes and exploitation methods in the kernel.

Either you or PaX team must be wrong, see viewtopic.php?p=6791

...or that was a false dichotomy and you are wrong . i suggest you actually read the linked topic and look for my statement on specific vs. generic protections (hint: it's possible/not possible, respectively) and notice which word i highlighted above in spender's quote.

> SELinux now ships with a weaker form of "protection" against null ptr
> dereference bugs (unlike the generic invalid userland access class PaX
> protects against)

AFAIK, uderef is ia-32 only. I wouldn't call that "generic".

some archs such as sparc/sparc64 have natural userland/kernel separation, so they already have UDEREF and they don't need any code in PaX per se. also i'm spilling some beans here, but i've been working on UDEREF for amd64, we'll see how well it goes.

> which was able to be bypassed by at least two separate methods that
> the PaX team and myself discovered back in May of last year, which
> were just recently fixed with no CVE from Redhat.

Sadly, grsecurity is even worse. Bugs get fixed with no CVEs, no ChangeLogs, no announcements.

if you know of security bugs that we've fixed silently, raise your voice! don't just throw out empty accusations.

Even no PGP signatures of those "test patches".

because they're test patches and not releases? as for the generic wisdom of PGP signatures (and it's only my opinion, not necessarily spender's), what do they help you? nothing except giving you a false sense of security (this is not grsec specific of course, goes for all PGP signatures that people blindly put their faith in).

Alexei.Sheplyakov wrote:

spender wrote:A quick real-life example of how SELinux's "protection" is inferior

viewtopic.php?t=1813

At least, SELinux does not introduce new kernel bugs.

that was a bug in PaX, not grsecurity. try to compare apples to oranges next time . and speaking of no kernel bugs in SELinux, care you enlighten the folks at securityfocus that the following apparently doesn't exist: http://www.securityfocus.com/bid/17830, at least according to you .

PaX Team wrote:if you know of security bugs that we've fixed silently, raise your voice! don't just throw out empty accusations.

Maybe, a very small , local, "strange" bug :
but "silently fixed bug"...

kernel bug at mmap.c in 2.1.10

demonstration (avi)

2.1.11 contains the patch for this problem. But changelog or other information, I don't found.

PaX Team wrote:if you know of security bugs that we've fixed silently, raise your voice!
don't just throw out empty accusations.

Recently (a week ago) I've upgraded to Linux 2.6.23.14 (because of some
VFS-related security bug) and grsecurity-2.1.11-2.6.23.9-200712101800 (because
that was the lastest available version). I get this several times a day:

Code: Select all

[  136.044821] Unable to handle kernel NULL pointer dereference at 00000000000000b0 RIP:
[  136.044826]  [<ffffffff8026f23e>] __vm_enough_memory+0x6e/0x130
[  136.044833] PGD 69d0d067 PUD 69d0e067 PMD 0
[  136.044836] Oops: 0000 [1] SMP
[  136.044838] CPU 1
[  136.044839] Modules linked in: cpufreq_powersave cpufreq_conservative powernow_k8 freq_table tun ipt_MASQUERADE iptable_nat
nf_nat ipt_REJECT ipt_LOG xt_limit ipt_iprange xt_tcpudp nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_multiport iptable
_filter ip_tables x_tables ext2 mbcache reiserfs fuse snd_pcm_oss snd_mixer_oss snd_hda_intel i2c_piix4 k8temp hwmon snd_pcm sn
d_timer button i2c_core floppy pcspkr tsdev snd soundcore snd_page_alloc rtc mousedev evdev xfs dm_mirror dm_snapshot dm_mod id
e_generic usbhid hid ide_cd cdrom sd_mod atiixp generic ide_core ata_generic ahci libata scsi_mod ohci1394 ieee1394 ehci_hcd oh
ci_hcd usbcore thermal processor fan unix skge
[  136.044871] Pid: 4493, comm: khelper Not tainted 2.6.23.14-grsec-k8-smp #1
[  136.044873] RIP: 0010:[<ffffffff8026f23e>]  [<ffffffff8026f23e>] __vm_enough_memory+0x6e/0x130
[  136.044876] RSP: 0000:ffff810058a15bf0  EFLAGS: 00010216
[  136.044878] RAX: 00000000002b3df4 RBX: 0000000000000001 RCX: 000000000007ee5a
[  136.044879] RDX: 00000000000fb970 RSI: 0000000000000001 RDI: 0000000000000004
[  136.044881] RBP: 0000000000000001 R08: ffff81007e6097c0 R09: 0000000000000001
[  136.044883] R10: 0000000000055029 R11: 0000000000000001 R12: 0000000000000000
[  136.044884] R13: 0000000000000001 R14: ffff810065e0f978 R15: ffff810065cf9200
[  136.044886] FS:  000039df3e48cd20(0000) GS:ffff8100379c4dc0(0000) knlGS:00000000ec8a98c0
[  136.044888] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[  136.044890] CR2: 00000000000000b0 CR3: 0000000069d0c000 CR4: 00000000000006e0
[  136.044891] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  136.044893] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  136.044895] Process khelper (pid: 4493, threadinfo ffff810058a14000, task ffff81007e6097c0)
[  136.044896] Stack:  ffff81007e3c7e40 ffff81007f2e7800 0000000000002000 ffffffff8026d2d9
[  136.044900]  ffff810065e0f978 00007fffffffd000 0000000000000001 0000000000001000
[  136.044902]  0000000000000002 ffffffff8026d5ac ffff810065cf9200 00007fffffffdfe6
[  136.044904] Call Trace:
[  136.044910]  [<ffffffff8026d2d9>] acct_stack_growth+0xe9/0x140
[  136.044914]  [<ffffffff8026d5ac>] expand_stack_downwards+0x8c/0xa0
[  136.044919]  [<ffffffff80283a48>] get_arg_page+0x28/0xd0
[  136.044923]  [<ffffffff80283d00>] copy_strings+0x100/0x1e0
[  136.044929]  [<ffffffff802856b9>] do_execve+0x1e9/0x3d0
[  136.044933]  [<ffffffff803f907a>] __sched_text_start+0x11a/0x1ef
[  136.044939]  [<ffffffff8022bf25>] try_to_wake_up+0x65/0x370
[  136.044943]  [<ffffffff8025fd73>] __pagevec_free+0x23/0x30
[  136.044947]  [<ffffffff8022db7c>] __cond_resched+0x1c/0x50
[  136.044950]  [<ffffffff803f9792>] cond_resched+0x32/0x40
[  136.044953]  [<ffffffff803074f0>] __strncpy_from_user+0x20/0x60
[  136.044959]  [<ffffffff8020ada4>] sys_execve+0x44/0xb0
[  136.044963]  [<ffffffff8020cfd4>] kernel_execve+0x64/0xd0
[  136.044973]  [<ffffffff802426eb>] ____call_usermodehelper+0x16b/0x180
[  136.044976]  [<ffffffff8020cf68>] child_rip+0xa/0x12
[  136.044983]  [<ffffffff80242580>] ____call_usermodehelper+0x0/0x180
[  136.044988]
[  136.044988]
[  136.044989] Code: 49 8b 84 24 b0 00 00 00 48 63 15 67 ef 2d 00 48 c1 e8 05 48
[  136.044995] RIP  [<ffffffff8026f23e>] __vm_enough_memory+0x6e/0x130
[  136.044998]  RSP <ffff810058a15bf0>
[  136.044999] CR2: 00000000000000b0


(the .config can be found here:
http://theor.jinr.ru/~varg/web/linux/co ... -k8-smp.gz)

This seems to be PaX related, as it never(?) happens with vanilla 2.6.23.14
kernel (and several times a day with patched one). Unfortunately, I don't
know of any systematic way to reproduce this. Apparently, the bug was fixed(?)
in grsecurity-2.1.11-2.6.23.14-200801231800. Where can I find CVE/ChangeLog?


Likewise, those two bugs I've reported previously were never announced.

PaX Team wrote:as for the generic wisdom of PGP signatures (and it's only my opinion,
not necessarily spender's), what do they help you?

They give me a (small) chance to detect some bad things (e.g. somebody
rooted the proxy I use, or something like that).

PaX Team wrote:

Alexei.Sheplyakov wrote:At least, SELinux does not introduce new kernel bugs.

that was a bug in PaX, not grsecurity. try to compare apples
to oranges next time .

SELinux also contains an equivalent of PaX' PAGEEXEC|MPROTECT,
so I think the comparison is fair enough.

PaX Team wrote:and speaking of no kernel bugs in SELinux, care you enlighten
the folks at securityfocus that the following apparently doesn't
exist: http://www.securityfocus.com/bid/17830,

1. That bug was discovered by SELinux developer *before* somebody
actually hit it.
2. There's a CVE and detailed analysis of the bug
(see http://marc.info/?l=selinux&m=114226465106131&w=2)

Unfortunately, I don't know of any systematic way to reproduce this.

Starting several memory hungry apps (i.e. konqueror) right after bootup seems
to trigger it.

Apparently, the bug was fixed(?) in grsecurity-2.1.11-2.6.23.14-200801231800.

Not really. I've reporduced it with that version too.

Code: Select all

[  146.408997] Unable to handle kernel NULL pointer dereference at 00000000000000b0 RIP:
[  146.409002]  [<ffffffff8026f23e>] __vm_enough_memory+0x6e/0x130
[  146.409007] PGD 66990067 PUD 6698b067 PMD 0
[  146.409010] Oops: 0000 [1] SMP
[  146.409012] CPU 0
[  146.409013] Modules linked in: cpufreq_powersave cpufreq_conservative powernow_k8 freq_table tun ipt_MASQUERADE iptable_nat nf_nat ipt_REJECT ipt_LOG xt_limit ipt_iprange xt_tcpudp nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_multiport iptable_filter ip_tables x_tables ext2 mbcache reiserfs fuse snd_pcm_oss snd_mixer_oss k8temp hwmon button snd_hda_intel i2c_piix4 i2c_core floppy rtc snd_pcm snd_timer snd soundcore snd_page_alloc pcspkr tsdev mousedev evdev xfs dm_mirror dm_snapshot dm_mod ide_generic ide_cd cdrom atiixp usbhid hid generic ide_core sd_mod ohci1394 ieee1394 ehci_hcd ohci_hcd usbcore ata_generic ahci libata scsi_mod thermal processor fan unix skge
[  146.409043] Pid: 4459, comm: khelper Not tainted 2.6.23.14-grsec-200801231800-k8-smp #1
[  146.409045] RIP: 0010:[<ffffffff8026f23e>]  [<ffffffff8026f23e>] __vm_enough_memory+0x6e/0x130
[  146.409048] RSP: 0018:ffff810058947bf0  EFLAGS: 00010216
[  146.409050] RAX: 00000000002b3df4 RBX: 0000000000000001 RCX: 000000000007ee5a
[  146.409051] RDX: 00000000000fb970 RSI: 0000000000000001 RDI: 0000000000000004
[  146.409053] RBP: 0000000000000001 R08: ffff81005c770800 R09: 0000000000000001
[  146.409055] R10: 00000000000552be R11: 0000000000000001 R12: 0000000000000000
[  146.409056] R13: 0000000000000001 R14: ffff81005fdc1348 R15: ffff810037e53800
[  146.409058] FS:  00003a32d53e0d20(0000) GS:ffffffff804cc000(0000) knlGS:00000000ddc158c0
[  146.409060] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[  146.409062] CR2: 00000000000000b0 CR3: 000000006698c000 CR4: 00000000000006e0
[  146.409064] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  146.409065] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  146.409067] Process khelper (pid: 4459, threadinfo ffff810058946000, task ffff81005c770800)
[  146.409069] Stack:  ffff810058906e00 ffff810060e2a780 0000000000002000 ffffffff8026d2d9
[  146.409072]  ffff81005fdc1348 00007fffffffd000 0000000000000001 0000000000001000
[  146.409074]  0000000000000000 ffffffff8026d5ac ffff810037e53800 00007fffffffdff5
[  146.409077] Call Trace:
[  146.409081]  [<ffffffff8026d2d9>] acct_stack_growth+0xe9/0x140
[  146.409085]  [<ffffffff8026d5ac>] expand_stack_downwards+0x8c/0xa0
[  146.409089]  [<ffffffff80283a48>] get_arg_page+0x28/0xd0
[  146.409093]  [<ffffffff80283d00>] copy_strings+0x100/0x1e0
[  146.409098]  [<ffffffff802856d8>] do_execve+0x208/0x3d0
[  146.409107]  [<ffffffff8022db7c>] __cond_resched+0x1c/0x50
[  146.409110]  [<ffffffff803f9792>] cond_resched+0x32/0x40
[  146.409114]  [<ffffffff803074f0>] __strncpy_from_user+0x20/0x60
[  146.409119]  [<ffffffff8020ada4>] sys_execve+0x44/0xb0
[  146.409122]  [<ffffffff8020cfd4>] kernel_execve+0x64/0xd0
[  146.409131]  [<ffffffff802426eb>] ____call_usermodehelper+0x16b/0x180
[  146.409134]  [<ffffffff8020cf68>] child_rip+0xa/0x12
[  146.409140]  [<ffffffff80242580>] ____call_usermodehelper+0x0/0x180
[  146.409142]  [<ffffffff8020cf5e>] child_rip+0x0/0x12
[  146.409144]
[  146.409145]
[  146.409145] Code: 49 8b 84 24 b0 00 00 00 48 63 15 67 ef 2d 00 48 c1 e8 05 48
[  146.409151] RIP  [<ffffffff8026f23e>] __vm_enough_memory+0x6e/0x130
[  146.409153]  RSP <ffff810058947bf0>
[  146.409155] CR2: 00000000000000b0


Alexei.Sheplyakov wrote:

Code: Select all

[  146.408997] Unable to handle kernel NULL pointer dereference at 00000000000000b0 RIP:
[  146.409002]  [<ffffffff8026f23e>] __vm_enough_memory+0x6e/0x130


Code: Select all

$ grep -e '\<__vm_enough_memory\>' /boot/System.map-2.6.23.14-grsec-200801231800-k8-smp | sed -e 's/^\([^ \t]\+\).*$/0x\1/'
0xffffffff8026f1d0
$ gdb --silent /boot/vmlinux-2.6.23.14-grsec-200801231800-k8-smp
(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
disassemble 0xffffffff8026f1d0
Dump of assembler code for function __vm_enough_memory:
0xffffffff8026f1d0 <__vm_enough_memory+0>:      sub    $0x18,%rsp
0xffffffff8026f1d4 <__vm_enough_memory+4>:      mov    %r12,0x10(%rsp)
0xffffffff8026f1d9 <__vm_enough_memory+9>:      mov    %rdi,%r12
0xffffffff8026f1dc <__vm_enough_memory+12>:     mov    %rsi,%rdi
0xffffffff8026f1df <__vm_enough_memory+15>:     mov    %rbx,(%rsp)
0xffffffff8026f1e3 <__vm_enough_memory+19>:     mov    %rbp,0x8(%rsp)
0xffffffff8026f1e8 <__vm_enough_memory+24>:     mov    %rsi,%rbx
0xffffffff8026f1eb <__vm_enough_memory+27>:     mov    %edx,%ebp
0xffffffff8026f1ed <__vm_enough_memory+29>:     callq  0xffffffff802626d0 <vm_acct_memory>
0xffffffff8026f1f2 <__vm_enough_memory+34>:     mov    3010488(%rip),%eax        # 0xffffffff8054e1b0 <sysctl_overcommit_memory>
0xffffffff8026f1f8 <__vm_enough_memory+40>:     cmp    $0x1,%eax
0xffffffff8026f1fb <__vm_enough_memory+43>:     je     0xffffffff8026f2f2 <__vm_enough_memory+290>
0xffffffff8026f201 <__vm_enough_memory+49>:     test   %eax,%eax
0xffffffff8026f203 <__vm_enough_memory+51>:     je     0xffffffff8026f280 <__vm_enough_memory+176>
0xffffffff8026f205 <__vm_enough_memory+53>:     movslq 2327316(%rip),%rax        # 0xffffffff804a7520 <sysctl_overcommit_ratio>
0xffffffff8026f20c <__vm_enough_memory+60>:     mov    $0x28f5c28f5c28f5c3,%rdx
0xffffffff8026f216 <__vm_enough_memory+70>:     imul   2561106(%rip),%rax        # 0xffffffff804e0670 <totalram_pages>
0xffffffff8026f21e <__vm_enough_memory+78>:     shr    $0x2,%rax
0xffffffff8026f222 <__vm_enough_memory+82>:     mul    %rdx
0xffffffff8026f225 <__vm_enough_memory+85>:     mov    %rdx,%rcx
0xffffffff8026f228 <__vm_enough_memory+88>:     shr    $0x2,%rcx
0xffffffff8026f22c <__vm_enough_memory+92>:     test   %ebp,%ebp
0xffffffff8026f22e <__vm_enough_memory+94>:     jne    0xffffffff8026f237 <__vm_enough_memory+103>
0xffffffff8026f230 <__vm_enough_memory+96>:     shr    $0x7,%rdx
0xffffffff8026f234 <__vm_enough_memory+100>:    sub    %rdx,%rcx
0xffffffff8026f237 <__vm_enough_memory+103>:    add    3010530(%rip),%rcx        # 0xffffffff8054e220 <total_swap_pages>
0xffffffff8026f23e <__vm_enough_memory+110>:    mov    0xb0(%r12),%rax
^^^^^^^^^^ HERE
0xffffffff8026f246 <__vm_enough_memory+118>:    movslq 3010407(%rip),%rdx        # 0xffffffff8054e1b4 <vm_committed_space>
0xffffffff8026f24d <__vm_enough_memory+125>:    shr    $0x5,%rax
0xffffffff8026f251 <__vm_enough_memory+129>:    sub    %rax,%rcx
0xffffffff8026f254 <__vm_enough_memory+132>:    cmp    %rcx,%rdx
0xffffffff8026f257 <__vm_enough_memory+135>:    jl     0xffffffff8026f2f2 <__vm_enough_memory+290>
0xffffffff8026f25d <__vm_enough_memory+141>:    neg    %rbx
0xffffffff8026f260 <__vm_enough_memory+144>:    mov    %rbx,%rdi
0xffffffff8026f263 <__vm_enough_memory+147>:    callq  0xffffffff802626d0 <vm_acct_memory>
0xffffffff8026f268 <__vm_enough_memory+152>:    mov    $0xfffffff4,%eax
0xffffffff8026f26d <__vm_enough_memory+157>:    mov    (%rsp),%rbx
0xffffffff8026f271 <__vm_enough_memory+161>:    mov    0x8(%rsp),%rbp
0xffffffff8026f276 <__vm_enough_memory+166>:    mov    0x10(%rsp),%r12
0xffffffff8026f27b <__vm_enough_memory+171>:    add    $0x18,%rsp
0xffffffff8026f27f <__vm_enough_memory+175>:    retq   
0xffffffff8026f280 <__vm_enough_memory+176>:    mov    3010241(%rip),%rax        # 0xffffffff8054e148 <vm_stat+40>
0xffffffff8026f287 <__vm_enough_memory+183>:    xor    %ecx,%ecx
0xffffffff8026f289 <__vm_enough_memory+185>:    mov    3010256(%rip),%rdx        # 0xffffffff8054e160 <vm_stat+64>
0xffffffff8026f290 <__vm_enough_memory+192>:    test   %rax,%rax
0xffffffff8026f293 <__vm_enough_memory+195>:    cmovs  %rcx,%rax
0xffffffff8026f297 <__vm_enough_memory+199>:    add    3010026(%rip),%rax        # 0xffffffff8054e088 <nr_swap_pages>
0xffffffff8026f29e <__vm_enough_memory+206>:    test   %rdx,%rdx
0xffffffff8026f2a1 <__vm_enough_memory+209>:    cmovns %rdx,%rcx
0xffffffff8026f2a5 <__vm_enough_memory+213>:    test   %ebp,%ebp
0xffffffff8026f2a7 <__vm_enough_memory+215>:    lea    (%rax,%rcx,1),%rdx
0xffffffff8026f2ab <__vm_enough_memory+219>:    jne    0xffffffff8026f2b7 <__vm_enough_memory+231>
0xffffffff8026f2ad <__vm_enough_memory+221>:    mov    %rdx,%rax
0xffffffff8026f2b0 <__vm_enough_memory+224>:    shr    $0x5,%rax
0xffffffff8026f2b4 <__vm_enough_memory+228>:    sub    %rax,%rdx
0xffffffff8026f2b7 <__vm_enough_memory+231>:    cmp    %rbx,%rdx
0xffffffff8026f2ba <__vm_enough_memory+234>:    ja     0xffffffff8026f2f2 <__vm_enough_memory+290>
0xffffffff8026f2bc <__vm_enough_memory+236>:    mov    3010141(%rip),%rax        # 0xffffffff8054e120 <vm_stat>
0xffffffff8026f2c3 <__vm_enough_memory+243>:    test   %rax,%rax
0xffffffff8026f2c6 <__vm_enough_memory+246>:    js     0xffffffff8026f25d <__vm_enough_memory+141>
0xffffffff8026f2c8 <__vm_enough_memory+248>:    mov    2560937(%rip),%rcx        # 0xffffffff804e0678 <totalreserve_pages>
0xffffffff8026f2cf <__vm_enough_memory+255>:    cmp    %rcx,%rax
0xffffffff8026f2d2 <__vm_enough_memory+258>:    jbe    0xffffffff8026f25d <__vm_enough_memory+141>
0xffffffff8026f2d4 <__vm_enough_memory+260>:    sub    %rcx,%rax
0xffffffff8026f2d7 <__vm_enough_memory+263>:    test   %ebp,%ebp
0xffffffff8026f2d9 <__vm_enough_memory+265>:    mov    %rax,%rcx
0xffffffff8026f2dc <__vm_enough_memory+268>:    jne    0xffffffff8026f2e5 <__vm_enough_memory+277>
0xffffffff8026f2de <__vm_enough_memory+270>:    shr    $0x5,%rax
0xffffffff8026f2e2 <__vm_enough_memory+274>:    sub    %rax,%rcx
0xffffffff8026f2e5 <__vm_enough_memory+277>:    lea    (%rdx,%rcx,1),%rax
0xffffffff8026f2e9 <__vm_enough_memory+281>:    cmp    %rax,%rbx
0xffffffff8026f2ec <__vm_enough_memory+284>:    jae    0xffffffff8026f25d <__vm_enough_memory+141>
0xffffffff8026f2f2 <__vm_enough_memory+290>:    xor    %eax,%eax
0xffffffff8026f2f4 <__vm_enough_memory+292>:    jmpq   0xffffffff8026f26d <__vm_enough_memory+157>
0xffffffff8026f2f9 <__vm_enough_memory+297>:    data16
0xffffffff8026f2fa <__vm_enough_memory+298>:    data16
0xffffffff8026f2fb <__vm_enough_memory+299>:    data16
0xffffffff8026f2fc <__vm_enough_memory+300>:    nop   
0xffffffff8026f2fd <__vm_enough_memory+301>:    data16
0xffffffff8026f2fe <__vm_enough_memory+302>:    data16
0xffffffff8026f2ff <__vm_enough_memory+303>:    nop


mm/mmap.c

Code: Select all

 
 177         allowed = (totalram_pages - hugetlb_total_pages())
 178                 * sysctl_overcommit_ratio / 100;
 179         /*
 180          * Leave the last 3% for root
 181          */
 182         if (!cap_sys_admin)
 183                 allowed -= allowed / 32;
 184         allowed += total_swap_pages;
 185
 186         /* Don't let a single process grow too big:
 187            leave 3% of the size of this process for other processes */
 188         allowed -= mm->total_vm / 32;


So, if I'm not missing something, mm happened to be NULL here. What gives?

Oscon wrote:Maybe, a very small , local, "strange" bug :
but "silently fixed bug"...

we're talking about security bugs, not bugs in general. in my judgement it wasn't a security bug but feel free to prove me wrong.

2.1.11 contains the patch for this problem. But changelog or other information, I don't found.

it was a test patch, not a release so no changelog. besides, due to the way 2.6 is developed and we can track it, we're surely not going to announce every silly bug we come across (interdiff is your friend), be that in our code or in linux itself. FYI, i think a good chunk of PaX, possibly up to one half of it, is now such bugfix/feature reversal/rework/cleanup/etc.

Alexei.Sheplyakov wrote:This seems to be PaX related, as it never(?) happens with vanilla 2.6.23.14
kernel (and several times a day with patched one). Unfortunately, I don't
know of any systematic way to reproduce this. Apparently, the bug was fixed(?)
in grsecurity-2.1.11-2.6.23.14-200801231800. Where can I find CVE/ChangeLog?

i'm glad you figured out it wasn't fixed silently, given that this was the first time we'd heard from you about this bug . so you'll probably forgive me for not providing the CVE but all is not lost, you can still make history. here's how: you carefully read the explanation below then go through the proper bug reporting process both saving me time and earning yourself that much coveted CVE. deal?

now for the bug. i think it was around sometime in the 2.6.22 days that the vanilla kernel changed how execve set up the new task's address space, in particular, how the initial stack was initialized, allowing 'unlimited' number of args/env/etc. this was done by making use of the already present and setup mm struct of the new task and normal VM logic that deals with automatic userland stack expansion. the problem is that this broke assumptions elsewhere in the kernel, in particular in LSM where current->mm was used in some accounting code and which happened to be NULL for kernel threads (think of the kernel module loader or hotplug/udev as in-kernel execve users). the bugfix was http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commitdiff;h=34b4e4aa3c470ce8fa2bd78abb1741b4b58baad7 except it didn't properly make use of the new security_vm_enough_memory_mm function everywhere it was needed. case in point, acct_stack_growth(). the reason this path doesn't manifest in the vanilla kernel is that it's only PaX that does 'sub-page' stack randomization, so it can cause the one page of the initial stack to run out and trigger a stack expansion. bad idea when a kernel thread does this since its current->mm is NULL, hence your oops reports. i've fixed it in 2.6.24-test9 and you're welcome to explain/push this upstream as the current situation is quite fragile.

Likewise, those two bugs I've reported previously were never announced.

see my response to Oscon.

They give me a (small) chance to detect some bad things (e.g. somebody rooted the proxy I use, or something like that).

you don't need PGP signatures for this then, SSL would be enough (except it'd cost money for us, so good luck convincing spender). also, every other means of compromising the software delivery foodchain is acceptable risk for you then?