Hi~ I'm a fresh man to grsec. Today I met a strange probelm, when I try to run "gradm -a admin", I was told "The terminal you are using is unsafe for this operation. Use another terminal." the username I was using is root. and the policy usr is default which has G flag Has anyone met this problem ? Thanks.
Hi, we are having little problems with symlinks and security (well, these two things were always doing problems when needed togater). One example can be seen here: https://forums.proftpd.org/smf/index.php?topic=11225.new To make things short - we would like to deny creating of symlinks to our users. Not all applications can disallow this so it would be best to make it on kernel level. What about to make a feature in grsecurity which will work similar to TPE? Create a group which is able/not able to _create_ symlinks. What do you think? azur
Hi, can anyone, please, explain this message? Never saw it until yesterday, no luck with Google. Dec 10 02:03:29 server01 kernel: [ 220.366486] grsec: From 141.105.120.152: bruteforce prevention initiated for the next 30 minutes or until service restarted, stalling each fork 30 seconds. Please investigate the crash report for /usr/lib/apache2/mpm-itk/apache2[apache2:3586] uid/euid:1258/1258 gid/egid:100/100, parent /usr/lib/apache2/mpm-itk/apache2[apache2:2142] uid/euid:0/0 gid/egid:0/0 Thank you! azurIt
Hi All,
Please let me know how to check the hardware support of XN/XI bit support on ARM/MIPS platform.
As there is support of XN bit on ARM v >= 6 (I was using ARM 6), but no support on MIPS (MIPS 34Kc).
To check the hardware support , I run the paxtest i.e execstack. The execstack test program must crash on ARM, but not on MIPS.
But It is crashing on both ARM and MIPS.
Please let me know how I can prove/check the hardware support of XN bit in arm platform.
/* execstack.c - Tests wether code on the stack can be executed
*
*/
#include <stdlib.h>
#include <stdio.h>
#include <sys/mman.h>
#include <unistd.h>
#include <errno.h>
#include <limits.h>
#include <signal.h>
#include <sys/types.h>
#include <sys/wait.h>
#ifndef PAGESIZE
#define PAGESIZE (4096)
#endif /* PAGESIZE */
typedef void (*fptr)(void);
char *testname = "Executable stack ";
void itworked( void )
{
printf( "Vulnerable\n" );
exit( 1 );
}
void doit( void )
{
char buf[8192];
fptr func;
/* Put a RETN instruction in the buffer */
buf[0] = '\xc3';
/* Convert the pointer to a function pointer */
func = (fptr)buf;
/* Call the code in the buffer */
func();
/* It worked when the function returns */
itworked();
}
int main( int argc, char *argv[] )
{
int status;
printf( "%s: ", testname );
fflush( stdout );
if( fork() == 0 ) {
do_mprotect((unsigned long)argv & ~4095U, 4096, PROT_READ|PROT_WRITE|PROT_EXEC);
doit();
} else {
wait( &status );
if( WIFEXITED(status) == 0 ) {
printf( "Killed\n" );
exit( 0 );
}
}
exit( 0 );
}
void itfailed( void )
{
printf( "Ok\n" );
exit( 2 );
}
int do_mprotect( const void *addr, size_t len, int prot )
{
void *ptr;
int retval;
/* Allign to a multiple of PAGESIZE, assumed to be a power of two */
ptr = (char *)(((unsigned long) addr) & ~(PAGESIZE-1));
retval = mprotect( ptr, len, prot );
if( retval != 0 && errno == EINVAL ) {
perror( "could not mprotect():" );
exit( 1 );
}
return retval;
}
On MIPS target the execstack testcase giving below
coredump although I assume that XI bit is not supported in MIPS.
To check the XI bit support on MIPS target I read the bit No 12 i.e RXI of Config 3 register.
The value of config3 register is 0x2425 in MIPS kernel (X13).
Followings are the bit wise representation:
|
Position |
31
|
|
|
|
|
|
|
24 |
|
|
|
|
|
|
|
16 |
|
|
13 |
|
|
10 |
|
|
|
|
5 |
|
|
2 |
|
0 |
|
Value |
0
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
0 |
1 |
0 |
0 |
0 |
0 |
1 |
0 |
0 |
1 |
0 |
1 |
VDLinux#> ./execstack
Executable stack[ 53.272000] do_ri() : sending SIGILL to execstack, PID:386
[ 53.280000] ================================================================================
[ 53.288000] KERNEL Version : 0045, debug
[ 53.292000] ================================================================================
[ 53.300000]
[ 53.304000] --------------------------------------------------------------------------------------
[ 53.312000] EPC, RA MEMINFO
[ 53.316000] --------------------------------------------------------------------------------------
[ 53.324000] epc:7f9c9548, ra:400854
[ 53.328000] --------------------------------------------------------------------------------------
[ 53.336000] EPC meminfo (0x7f9c9148 to 0x7f9c9548)
[ 53.340000] 9140: 00000000 00000000 00000000 00000000 00000000 00000000
[ 53.348000] 9160: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 53.360000] 9180: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
---- SKIP ---
[ 53.616000] 9540: 00000000 00000000 ffffffff
[ 53.624000] --------------------------------------------------------------------------------------
[ 53.636000] RA meminfo (0x00400054 to 0x00400854)
[ 53.640000] 0040: 00000003 00000154 00400154
[ 53.648000] 0060: 00400154 0000000d 0000000d 00000004 00000001 70000000 00000184 00400184
[ 53.656000] 0080: 00400184 00000018 00000018 00000004 00000004 00000001 00000000 00400000
[ 53.692000] 0100: 00400164 00000020 00000020 00000004 00000004 6474e550 00000aac 00400aac
[ 53.700000] 0120: 00400aac 00000034 00000034 00000004 00000004 00000000 00000000 00000000
--SKIP --
[ 53.888000] 03e0: 001b0011 00000035 00000000 00000000 00000012 000000a0 00400568 00000000
[ 53.896000] 0400: 000c0012 00000001 00000000 00000000 00000022 675f5f00 5f6e6f6d 72617473
[ 54.200000] --------------------------------------------------------------------------------------
[ 54.208000]
[ 54.208000] Cpu 0
[ 54.212000] $ 0 : 00000000 00000001 00000000 00000001
[ 54.216000] $ 4 : 7f9ca000 00001000 00000007 00000000
[ 54.224000] $ 8 : 00000000 80000008 800ebe90 fffffff8
[ 54.228000] $12 : 20202020 2af76000 00000000 7f9c9e20
[ 54.232000] $16 : 7f9ca0e4 00000000 00580000 00d584a8
[ 54.240000] $20 : 00590e05 00d5933c 005b0000 00000000
[ 54.244000] $24 : 00000000 7f9c7fd8
[ 54.248000] $28 : 2c1b6980 7f9c7fc0 00000000 00400854
[ 54.256000] Hi : 00000308
[ 54.256000] Lo : 0001e624
[ 54.260000] epc : 7f9c9548 0x7f9c9548
[ 54.264000] Tainted: P
[ 54.268000] ra : 00400854 0x400854
[ 54.272000] Status: 01008c13 USER EXL IE
[ 54.276000] Cause : 10800028
[ 54.280000] PrId : 00019555 (MIPS 34Kc)
[ 54.284000] -----------------------------------------------------------
[ 54.292000] * dump maps on pid (386)
[ 54.296000] -----------------------------------------------------------
[ 54.300000] 00400000-00401000 r-xp 00000000 08:01 353 /dtv/usb/sda1/pax_test_mips/execstack
[ 54.312000] 00410000-00411000 rw-p 00000000 08:01 353 /dtv/usb/sda1/pax_test_mips/execstack
[ 54.320000] 2af76000-2af88000 rw-p 00000000 00:00 0
[ 54.324000] 2c000000-2c021000 r-xp 00000000 8a:0a 67 /mtd_exe/lib/ld-2.14.1.so
[ 54.332000] 2c030000-2c031000 r--p 00020000 8a:0a 67 /mtd_exe/lib/ld-2.14.1.so
[ 54.340000] 2c031000-2c032000 rw-p 00021000 8a:0a 67 /mtd_exe/lib/ld-2.14.1.so
[ 54.348000] 2c040000-2c19b000 r-xp 00000000 8a:0a 71 /mtd_exe/lib/libc-2.14.1.so
[ 54.356000] 2c19b000-2c1aa000 ---p 0015b000 8a:0a 71 /mtd_exe/lib/libc-2.14.1.so
[ 54.368000] 2c1aa000-2c1ae000 r--p 0015a000 8a:0a 71 /mtd_exe/lib/libc-2.14.1.so
[ 54.376000] 2c1ae000-2c1b0000 rw-p 0015e000 8a:0a 71 /mtd_exe/lib/libc-2.14.1.so
[ 54.384000] 2c1b0000-2c1b3000 rw-p 00000000 00:00 0
[ 54.388000] 7f9a9000-7f9cb000 rwxp 00000000 00:00 0 [stack]
[ 54.396000] 7fff7000-7fff8000 r-xp 00000000 00:00 0 [vdso]
[ 54.400000] -----------------------------------------------------------
[ 54.400000]
[ 54.408000] task stack info : pid(386) stack area (0x7f9a9000 ~ 0x7f9cb000)
[ 54.416000] -----------------------------------------------------------
[ 54.424000] * dump user stack
[ 54.428000] -----------------------------------------------------------
[ 54.432000] dump user stack(0x7f9c7fc0 to 0x7f9c9f78)
[ 54.440000] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 54.448000] 7fe0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
--- SKIP ---
[ 55.884000] 94c0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 55.912000] 9520: 00000000 00000000 2c039000 00000000 00000000 2c007458 00000000 00000000
[ 55.920000] 9540: 00000000 00000000 ffffffff 00000000 00000000 00000000 00000000 00000000
--- SKIP ---
[ 56.600000] 9f20: 00000000 00000000 00000000 00000000 00410bbc 00d584a8 00590e05 00d5933c
[ 56.608000] 9f40: 005b0000 00000000 00000000 2c00fea8 00410be0 00d584a8 00590e05 2af7628c
[ 56.616000] 9f60: 2af76a70 00000001 00000001 00000000 2c039000 00d5933c 2c04a2bc
[ 56.624000] -----------------------------------------------------------
[ 56.624000]
[ 56.636000] ##### send signal from KERNEL, SIG : 4, execstack, PID:386, force_sig_info
[ 56.644000] Call Trace:
[ 56.644000] [<802fccd8>] dump_stack+0x8/0x34 from[<80044180>] force_sig_info+0x54/0x1b0
[ 56.652000] [<80044180>] force_sig_info+0x54/0x1b0 from[<80007364>] ret_from_exception+0x0/0x10
[ 56.664000]
[ 56.664000] ##### send signal SIG : 4, execstack(386)->execstack(386) __send_signal
[ 56.672000] ##### deliver signal SIG : 4, execstack(386) get_signal_to_deliver
[ 56.680000] [VDLP COREDUMP] SIGNR:4
[ 56.680000]
[ 56.684000] ***** Coredump : Insert USB memory stick, mount check per 10sec... *****
[ 57.724000] ***** USB detected *****
[ 57.728000] ***** Create pid : 386 coredump file to USB mount dir /dtv/usb/sda1/Coredump.386.gz ******
[ 57.736000] * Ultimate CoreDump v1.0 : started dumping core into 'Coredump.386.gz' file *
[ 57.744000] <1>##### elf aligned pages num : 1 + (3 Coredump guard buffers)
[ 57.752000] ##### Not used first lower guard page, elf_foffset : 1364, aligned_elf_foffset : 4096
[ 57.764000] ##### set_gzip_header() return success...
[ 57.768000] ##### Allocated 267980 bytes for deflate workspace
[ 57.776000] ##### coredump_alloc_workspaces() return success...
[ 57.980000] ##### (vma->vm_next) == NULL ...
[ 57.992000] ##### Process addr space debug Info #####
[ 57.996000] ##### vma_cnt : 13
[ 58.000000] ##### vm_page : 65
[ 58.004000] ##### user_page_cnt : 17
[ 58.008000] ##### zero_page_cnt : 48
[ 58.012000] ##### kernel_page_cnt : 0
[ 58.016000] ##### uncomp_coredump_file_size : 270336
[ 58.020000] ##### GZIP tailer CRC32 : 2982301179
[ 58.028000] ***** Create coredump file to USB mount dir ******
[ 58.032000] CoreDump: finished dumping core
: Killed
Similarly for ARM also it is giving core dump like this:
VDLinux#> ./execstack
Executable stack[ 451.784000] execstack: unhandled page fault (11) at 0xbead5860, code 0x80000007
[ 451.792000] ================================================================================
[ 451.800000] KERNEL Version : 0000
[ 451.804000] ================================================================================
[ 451.812000]
[ 451.812000] --------------------------------------------------------------------------------------
[ 451.820000] PC, LR MEMINFO
[ 451.824000] --------------------------------------------------------------------------------------
[ 451.832000] PC:bead5860, LR:85c0
[ 451.836000] --------------------------------------------------------------------------------------
[ 451.844000] PC meminfo (0xbead5460 to 0xbead5c60)
[ 451.848000] 5460: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
--- SKIP --
[ 452.524000] 7fe0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
[ 452.532000] 8000: 464c457f 00010101 00000000 00000000 00280002 00000001 00008500 00000034
--- SKIP ---
[ 453.156000] 8980: 04000000 0000001d 00841901 05010000 0086b403 004f0500 14000000 02000001
[ 453.164000] 89a0: 00004200 9a010400 01000000 000000da 00000043 00008644 000086ac 00000027
[ 453.172000] --------------------------------------------------------------------------------------
[ 453.180000]
[ 453.180000] pgd = e317c000
[ 453.184000] [bead5860] *pgd=a9d2e831, *pte=00000000, *ppte=00000000
[ 453.192000]
[ 453.192000] Pid: 429, comm: execstack
[ 453.196000] CPU: 1 Tainted: P (3.0.33 #124)
[ 453.200000] PC is at 0xbead5860
[ 453.204000] LR is at 0x85c0
[ 453.208000] pc : [<bead5860>] lr : [<000085c0>] psr: 60000010
[ 453.208000] sp : bead5860 ip : 40220f80 fp : 00000000
[ 453.220000] r10: 40119000 r9 : 00000000 r8 : 00000000
[ 453.224000] r7 : 00000000 r6 : 00008500 r5 : 00000000 r4 : bead79c4
[ 453.232000] r3 : bead5860 r2 : 00000007 r1 : 00001000 r0 : 00000000
[ 453.236000] Flags: nZCv IRQs on FIQs on Mode USER_32 ISA ARM Segment user
[ 453.244000] Control: 10c53c7d Table: a9d7c04a DAC: 00000015
[ 453.252000] [<c004b034>] (show_regs+0x0/0x58) from [<c004e588>] (show_info+0xb0/0x104)
[ 453.260000] r4:e38e4ba0 r3:00000002
[ 453.260000] [<c004e4d8>] (show_info+0x0/0x104) from [<c0055468>] (__do_user_fault+0x50/0x94)
[ 453.272000] r6:0000000b r5:bead5860 r4:e38e4ba0 r3:00000000
[ 453.276000] [<c0055418>] (__do_user_fault+0x0/0x94) from [<c03bf93c>] (do_page_fault+0x2d8/0x324)
[ 453.284000] r7:e38e4ba0 r6:bead5860 r5:00030002 r4:e31c7fb0
[ 453.292000] [<c03bf664>] (do_page_fault+0x0/0x324) from [<c003b260>] (do_PrefetchAbort+0x44/0xa8)
[ 453.300000] [<c003b21c>] (do_PrefetchAbort+0x0/0xa8) from [<c03bd6c8>] (ret_from_exception+0x0/0x10)
[ 453.308000] Exception stack(0xe31c7fb0 to 0xe31c7ff8)
[ 453.312000] 7fa0: 00000000 00001000 00000007 bead5860
[ 453.320000] 7fc0: bead79c4 00000000 00008500 00000000 00000000 00000000 40119000 00000000
[ 453.328000] 7fe0: 40220f80 bead5860 000085c0 bead5860 60000010 ffffffff
[ 453.336000] r7:00000000 r6:00008500 r5:00000007 r4:0000040f
[ 453.344000] -----------------------------------------------------------
[ 453.348000] * dump maps on pid (429)
[ 453.352000] -----------------------------------------------------------
[ 453.360000] 00008000-00009000 r-xp 00000000 08:11 440 /dtv/usb/sdb1/paxtest-0.9.5/execstack
[ 453.368000] 00010000-00011000 rw-p 00000000 08:11 440 /dtv/usb/sdb1/paxtest-0.9.5/execstack
[ 453.376000] 400bc000-400bd000 rw-p 400bc000 08:11 440
[ 453.380000] 400ce000-400cf000 rw-p 400ce000 08:11 440
[ 453.384000] 400f2000-40110000 r-xp 00000000 b3:03 105 /mtd_exe/lib/ld-2.14.1.so
[ 453.392000] 40118000-40119000 r--p 0001e000 b3:03 105 /mtd_exe/lib/ld-2.14.1.so
[ 453.400000] 40119000-4011a000 rw-p 0001f000 b3:03 105 /mtd_exe/lib/ld-2.14.1.so
[ 453.408000] 4011c000-4011d000 rw-p 4011c000 b3:03 105
[ 453.412000] 4015d000-40277000 r-xp 00000000 b3:03 113 /mtd_exe/lib/libc-2.14.1.so
[ 453.420000] 40277000-4027f000 ---p 0011a000 b3:03 113 /mtd_exe/lib/libc-2.14.1.so
[ 453.428000] 4027f000-40281000 r--p 0011a000 b3:03 113 /mtd_exe/lib/libc-2.14.1.so
[ 453.436000] 40281000-40282000 rw-p 0011c000 b3:03 113 /mtd_exe/lib/libc-2.14.1.so
[ 453.444000] 40282000-40285000 rw-p 40282000 b3:03 113
[ 453.448000] beab6000-bead7000 rw-p befde000 b3:03 113
[ 453.452000] bead7000-bead8000 rwxp befff000 b3:03 113
[ 453.460000] ffff0000-ffff1000 r-xp ffff0000 b3:03 113
[ 453.464000] -----------------------------------------------------------
[ 453.464000]
[ 453.472000] task stack info : pid(429) stack area (0xbead7000 ~ 0xbead8000)
[ 453.480000] -----------------------------------------------------------
[ 453.484000] * dump user stack
[ 453.488000] -----------------------------------------------------------
[ 453.496000] pid(429) : seems stack overflow.
[ 453.496000] sp(bead5860), stack vma (0xbead7000 ~ 0xbead8000)
[ 453.504000] -----------------------------------------------------------
[ 453.504000]
[ 453.512000] [VDLP COREDUMP] SIGNR:11
[ 453.512000]
[ 453.520000] ***** Coredump : Insert USB memory stick, mount check per 10sec... *****
[ 453.528000] ***** USB detected *****
[ 453.528000] ***** Create pid : 429 coredump file to USB mount dir /dtv/usb/sdb1/Coredump.429.gz ******
[ 453.540000] * Ultimate CoreDump v0.4 : started dumping core into 'Coredump.429.gz' file *
[ 453.548000] <1>##### elf aligned pages num : 1 + (3 Coredump guard buffers)
[ 453.552000] ##### Not used first lower guard page, elf_foffset : 1488, aligned_elf_foffset : 4096
[ 453.564000] ##### set_gzip_header() return success...
[ 453.568000] ##### Allocated 267980 bytes for deflate workspace
[ 453.572000] ##### coredump_alloc_workspaces() return success...
: [ 453.692000] ##### (vma->vm_next) == NULL ...
[ 453.700000] ##### Process addr space debug Info #####
[ 453.704000] ##### vma_cnt : 16
[ 453.708000] ##### vm_page : 47
[ 453.708000] ##### user_page_cnt : 15
[ 453.712000] ##### zero_page_cnt : 32
[ 453.716000] ##### kernel_page_cnt : 0
[ 453.720000] ##### uncomp_coredump_file_size : 196608
[ 453.724000] ##### GZIP tailer CRC32 : 1604686521
[ 453.732000] ***** Create coredump file to USB mount dir ******
[ 453.736000] CoreDump: finished dumping core
Killed
Please let me know how to check the hardware support of XN bit in ARMv6 /ARMv7 and XI bit support on MIPS 34Kc.
_______________________________________________ grsecurity mailing list grsecurity@... http://grsecurity.net/cgi-bin/mailman/listinfo/grsecurity
On 17 Mar 2012 at 14:15, grsecurity@... wrote: > hello folks, > > as of last night we have a new plugin from Emese Revfy (author of the constify > plugin as well) that i'd like to briefly introduce to you now (while she's working > on her blog post ;). as those on the rss feed have no doubt noticed it by now, her blog post's been out since last night: http://forums.grsecurity.net/viewtopic.php?f=7&t=3043 enjoy ;)
hello everyone, it's time to introduce the newest member of our plugin family to you. the inspiration came from the work described at https://factorable.net/ that you should all check out eventually (and do get your keys tested). the short story is that generating crypto keys while the system's random pool is low on entropy is not a good idea. and it so happens that some systems do actually have little entropy after boot when some userland decides to generate said keys. the end result is not pretty, the details are in the paper at the above URL. now there are several ways to improve the situation, some will soon find their way into the kernel in fact (check out the random tree by Theodore Ts'o at http://git.kernel.org/?p=linux/kernel/git/tytso/random.git;a=summary). the basic idea is always to find some potential source of randomness, or even just deterministic diversity (e.g., a MAC address) and mix that into the random pools in the hope that enough bits accumulate by the time some early userland app decides to extract entropy from them. this is where the new gcc plugin comes in: we can instrument the kernel's boot code to do some hash-like computation and extract some entropy from whatever program state we decide to mix into that computation. a similar idea has in fact been implemented by Larry Highsmith of Subreption fame in http://www.phrack.org/issues.html?issue=66&id=15 where he (manually) instrumented the kernel's boot code to extract entropy from a few kernel variables such as time (jiffies) and context switch counts. the latent entropy plugin takes this extraction to a whole new level. first, we define a new global variable that we mix into the kernel's entropy pools on each initcall. second, each initcall function (and all other boot-only functions they call) gets instrumented to compute a 'random' number that gets mixed into this global variable at the end of the function (you can think of it as an artificially created return value that each instrumented function computes for our purposes). the computation is a mix of add/xor/rol (the happy recovery Halvar mix :) with compile-time chosen random constants and the sequence of these operations follows the instrumented functions's control flow graph. for the rest of the gory details see the source code ;). as for the results of this whole adventure: i tried an allnoconfig amd64 kernel in qemu and i still saw a few bits of entropy in the last computed random function, so i'd like to believe that with real hardware around we can perhaps generate entropy in useful amounts, but time (and some real analysis by someone with more free time than me) will tell ;). there's also some impact on the boot time that i didn't bother to measure because it's probably in the noise, but feel free to post your numbers. there're also many ways this code can be tweaked to change the tradeoff between entropy extraction and boot time impact. one last note for those who care about binary checksums, reproducibility and the like: the injected code depends on the compiler version, optimization switches, kernel config, target architecture, etc (anything that can affect the control flow graph) and also on gcc's internal random seed generated for each compilation unit. if you want some determinism in the generated binaries, make use of -frandom-seed that the latent entropy plugin will honour as well (or at least that was the intention). the other side of the coin is that even if you keep all the above variables the same (minus the gcc seed), your kernel images will still be different and produce a different random pool on boot. tl;dr: go read the whole thing, there're no shortcuts ;P cheers, PaX Team
On 9 May 2012 at 12:24, Daniel Schulz wrote:
> root <at> server:/usr/local/jre1.7.0_04/bin# paxctl -v java
> - PaX flags: -p-s-m-x-e-r [java]
vs.
> root <at> server:/home/mc/bukkit-server# cat /proc/1411/status
> PaX: PemRs
first, paxctl flags have no effect on your binary, so you should figure out how
you configured the PaX control method ;).
second, can you compile/run this small program:
------------------------------------------------------------------------------------------
#include <stdio.h>
#include <sys/mman.h>
int main(void)
{
return (long)mmap(NULL, 2097152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_HUGETLB,
-1, 0);
}
------------------------------------------------------------------------------------------
and see if it fails the same way? and if it does, can you try it on a more recent
kernel, say 3.3.5? i have the latter here and it worked fine, so maybe it's a problem
specific to 2.6.32 but before i make my system bootable with 2.6.32 again (hello udev),
i'd like to know for sure.
also, is there anything in dmesg or on the console when the system hangs (maybe try
netconsole)?
hello folks, as of last night we have a new plugin from Emese Revfy (author of the constify plugin as well) that i'd like to briefly introduce to you now (while she's working on her blog post ;). first some background: almost 3 years ago we had introduced a small hack into grsecurity to handle a specific bug class, namely, (unintended) integer overflows occuring in calculating certain function parameters, such as those used to allocate memory or copy data between the kernel and userland (the bug class is obviously not specific to the kernel, userland programs have had their fair share of them over the years ;). the effect of such bugs is that due to the finite precision of integers, the integer overflow ends up producing a value much smaller than the program logic assumes. this in turn can cause memory underallocation and a buffer overflow on later accesses, among others. spender's hack attempted to handle a specific but also quite typical instance of these bugs where the calculation is a simple multiplication of two variables, with at least one under the attacker's control, e.g., void *p = kmalloc(a*b). by (ab)using C operator precedence rules and some macro magic, he could turn this into a kmalloc((intoverflow_t)a*b) call where the intoverflow_t type was specifically created to have double width precision of what the original function argument had. this would in turn force the compiler to compute the multiplication with the same double width precision and thus the integer overflow could be detected by a simple range check on the result. now this approach has numerous drawbacks (more complex calculations and wrappers around the interesting functions can't be handled without more invasive patching) and it was clear from the beginning that a better way is needed - enter gcc plugins. since the compiler sees the entire calculation step-by-step and can also see through function calls it is possible to modify the internal representation of all the calculations leading up to the final interesting function argument to use a double width integer type. now there's a lot of devil in the details as her blog post will explain it, but for now what you need to be aware of is that you should consider this plugin as experimental. in particular, there's a possibility for false positive reports (the runtime detection logic logs integer overflow events with a "size overflow detected in function ..." message) that we'd like to know about whenever you see them. of course if you catch a real size overflow alive we'd like to know about that too ;). note that the result of such an event will be a SIGKILL to the current task with all that it brings with it (user account lockout or kernel panic ;). another message you should not but still may see during compilation is "Function ... is missing from the size_overflow hash table ..." please report them to her (re.emese@...) and us directly along with your kernel config and exact patch version. last but not least, simple performance tests showed some puzzling results in that i measured a speedup of 2% on a specific load that exercised the kernel almost exclusively ('du -s' on a directory containing many files). while we hope you won't see any major performance regressions either, we're still interested in any numbers you can get on your workloads. that's all for now, if you have further questions, let us know. also don't forget to thank Emese for her work, she's been busting at it since last August and produced a plugin that's bigger and more complex than all the others we've had so far, that's no small feat! cheers, PaX Team
On 2 Dec 2011 at 13:34, Daniel Schulz wrote: > Sorry, i'm a little bit confused now (and sorry for mailing directly > to you), because sometimes the Bukkit-Server starts and sometimes not, > always the same kernel. I have reboot again and start the server normal: it's because the jvm runs out of address space randomly (due to ASLR the biggest address space hole size changes randomly, so sometimes this failing allocation does succeed). now i don't quite see why the address space is consumed so much based on the strace but i did note that you should be using PAGEEXEC since your CPU is capable of NX support (you'll also have to enable PAE in .config).
Hi there,
first of all, thanks very much for grsecurity. Its a very useful and
easy to use kernel-hardening-patch.
I have successfully compile a kernel 2.6.32.49-grsec on Debian Squeeze
32bit, first with "Security Level high". Because, a java Server does not
start with enabled mprotect, i have disable this option (and change
"Security Level to Custom). Now, the Minecraft-Server starts, but something
is not right yet:
-------------------------------------------------------------
[...]
14:55:51 [SCHWERWIEGEND] Error occurred while enabling dynmap v0.24 (Is it up to date?): unable to create
new native thread
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:640)
at java.util.concurrent.ThreadPoolExecutor.addIfUnderCorePoolSize(ThreadPoolExecutor.java:703)
at java.util.concurrent.ThreadPoolExecutor.prestartCoreThread(ThreadPoolExecutor.java:1381)
at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:222)
at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:397)
at org.dynmap.MapManager$DynmapScheduledThreadPoolExecutor.schedule(MapManager.java:141)
at org.dynmap.MapManager.scheduleDelayedJob(MapManager.java:957)
at org.dynmap.MapManager.startRendering(MapManager.java:970)
at org.dynmap.DynmapPlugin.onEnable(DynmapPlugin.java:293)
at org.bukkit.plugin.java.JavaPlugin.setEnabled(JavaPlugin.java:174)
at org.bukkit.plugin.java.JavaPluginLoader.enablePlugin(JavaPluginLoader.java:957)
at org.bukkit.plugin.SimplePluginManager.enablePlugin(SimplePluginManager.java:280)
at org.bukkit.craftbukkit.CraftServer.loadPlugin(CraftServer.java:171)
at org.bukkit.craftbukkit.CraftServer.enablePlugins(CraftServer.java:154)
at net.minecraft.server.MinecraftServer.e(MinecraftServer.java:297)
at net.minecraft.server.MinecraftServer.a(MinecraftServer.java:284)
at net.minecraft.server.MinecraftServer.init(MinecraftServer.java:152)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:348)
at net.minecraft.server.ThreadServerApplication.run(SourceFile:417)
14:55:51 [INFO] [mcMMO] PermissionsEx found, using PermissionsEx.
14:55:51 [INFO] Loading Config File...
14:55:52 [INFO] mcMMO version 1.1.17 is enabled!
14:55:52 [SCHWERWIEGEND] Exception in thread "Thread-5"
14:55:52 [SCHWERWIEGEND] java.lang.OutOfMemoryError: unable to create new native thread
14:55:52 [SCHWERWIEGEND] at java.lang.Thread.start0(Native Method)
14:55:52 [SCHWERWIEGEND] at java.lang.Thread.start(Thread.java:640)
14:55:52 [SCHWERWIEGEND] at org.bukkit.craftbukkit.scheduler.CraftWorker.<init>(CraftWorker.java:28)
14:55:52 [SCHWERWIEGEND] at org.bukkit.craftbukkit.scheduler.CraftThreadManager.executeTask(CraftThreadManager.java:14)
14:55:52 [SCHWERWIEGEND] at org.bukkit.craftbukkit.scheduler.CraftScheduler.processTask(CraftScheduler.java:107)
14:55:52 [SCHWERWIEGEND] at org.bukkit.craftbukkit.scheduler.CraftScheduler.run(CraftScheduler.java:64)
14:55:52 [SCHWERWIEGEND] at java.lang.Thread.run(Thread.java:662)
14:55:52 [INFO] [MonsterHunt] MonsterHunt Loaded!
[...]
-------------------------------------------------------------
This is a plugin of the Server (bukkit.org), which have a own little
Webserver listing on port 8123. Without grsecurity, it starts normal.
Any ideas?
Daniel
Hi list,
I am currently working on methods to detect (identify, count, filter)
single hosts behind NAT gateways. We already have a working proof of
concept which uses TCP timestamps (the basic idea is similar to the one
introduced in Phrack a few years ago). A trivial way to defeat this
approach (without deactivating timestamps) is to randomize initial
timestamp values on a per-connection basis (instead of initializing it
to the current system time, like Linux does).
OpenBSD already has this feature ("reassamble tcp"). Is something like
this implemented (or planned to be implemented) in grsecurity? If not, why?
Thanks!
Flo
RSS Feed2 | |
|---|---|
1 | |
2 | |
1 | |
1 | |
3 | |
1 | |
1 | |
5 | |
3 | |
2 | |
6 | |
1 | |
1 | |
7 | |
5 | |
4 | |
1 | |
4 | |
5 | |
16 | |
8 | |
1 | |
15 | |
7 | |
8 | |
15 | |
15 | |
2 | |
1 | |
2 | |
2 | |
9 | |
7 | |
3 | |
10 | |
9 | |
8 | |
27 | |
4 | |
5 | |
5 | |
5 | |
4 | |
20 | |
1 | |
1 | |
21 | |
8 | |
3 | |
10 | |
28 | |
18 | |
20 | |
6 | |
8 | |
4 | |
15 | |
50 | |
14 | |
28 | |
31 | |
33 | |
43 | |
24 | |
53 | |
50 | |
19 | |
91 | |
47 | |
52 | |
55 | |
43 | |
39 | |
62 | |
24 | |
8 |
