grsecurity forums

gradm 2.1.1, kernel 2.4.29, grsecurity 2.1.1

When running the full learning mode (-F -L /etc/grsec/learned -O /etc/grsec/policy) the gradm program crashes with sigsegv on some programs. It happens in the "Beginning full learning object reduction for subject...".

I've noticed it happens when /etc/protocols were minimal (only ip/udp/tcp, on embedded system). I installed full protocols file and gradm went on a bit further - but crashed anyway on another file. I installed full version of /etc/services, but crashes continue.

I'm trying to trace the problem down, but it seems like some kind of assumption about contents of the protocols/services file which not always are true.

Beginning full learning object reduction for subject /bin/tinylogin...done.
Beginning full learning object reduction for subject /bin/tncfg...
Program received signal SIGSEGV, Segmentation fault.
0x0805bc85 in find_insert_file (base=0x8088abc, insert=0x8092898, filelen=10, parent=0xbfffd7d8) at gradm_newlearn.c:886
886 if (cachednode && *cachednode && (cachedlen < filelen) && !strncmp((*cachednode)->filename, insert->filename, cachedlen)
(gdb) bt
#0 0x0805bc85 in find_insert_file (base=0x8088abc, insert=0x8092898, filelen=10, parent=0xbfffd7d8)
at gradm_newlearn.c:886
#1 0x0805bdb7 in do_insert_file (base=0x8088abc, filename=0x808e8c0 "/bin/tncfg", mode=24, subj=0 '\0')
at gradm_newlearn.c:913
#2 0x0805bea3 in insert_file (base=0x8088abc, filename=0x808e8c0 "/bin/tncfg", mode=24, subj=0 '\0')
at gradm_newlearn.c:941
#3 0x0805df14 in full_reduce_object_node (subject=0x8088aa8, unused1=0x0, unused2=0x0) at gradm_fulllearn.c:119
#4 0x0805e5bf in fulllearn_pass3 (subject=0x8088aa8, unused=0x0, stream=0x8079048) at gradm_fulllearn.c:370
#5 0x0805ab1e in traverse_file_tree (base=0x8088aa8, act=0x805e558 <fulllearn_pass3>, optarg=0x0, stream=0x8079048)
at gradm_newlearn.c:285
#6 0x0805ab5c in traverse_file_tree (base=0x80878e0, act=0x805e558 <fulllearn_pass3>, optarg=0x0, stream=0x8079048)
at gradm_newlearn.c:293
#7 0x0805ea98 in generate_full_learned_acls (learn_log=0x8079018 "/etc/grsec/learn1", stream=0x8079048)
at gradm_fulllearn.c:497
#8 0x080538f9 in parse_args (argc=6, argv=0xbffffc14) at gradm_arg.c:408
#9 0x0804c265 in main (argc=6, argv=0xbffffc14) at gradm.l:559

Program received signal SIGSEGV, Segmentation fault.
0x0805bc85 in find_insert_file (base=0x8088abc, insert=0x8092898, filelen=10, parent=0xbfffd7d8) at gradm_newlearn.c:886
886 if (cachednode && *cachednode && (cachedlen < filelen) && !strncmp((*cachednode)->filename, insert->filename, cachedlen)
3: insert->filename = 0x8091550 "/bin/tncfg"
1: cachednode = (struct gr_learn_file_node **) 0x80942b0
(gdb) p insert->filename
$3 = 0x8091550 "/bin/tncfg"
(gdb) p *cachednode
$4 = (struct gr_learn_file_node *) 0x65672f73
(gdb) p *cachednode->filename
Cannot access memory at address 0x65672f73
(gdb) p (*cachednode)->filename
Cannot access memory at address 0x65672f73
(gdb) p **cachednode
Cannot access memory at address 0x65672f73

kravietz wrote:$4 = (struct gr_learn_file_node *) 0x65672f73
(gdb) p *cachednode->filename

if that value's supposed to be a pointer then gradm got a nice overflow somewhere as it decodes to 's/ge' or something like that. you can try to dump more memory around cachednode (not *cachednode) to see what string overwrote memory, that may give us a clue. also, if that pointer is on the heap, you can try to debug it with electricfence, it may catch the overflow in action (this crash is after the fact, so it's not that helpful).

Can you mail your learning log to spender@grsecurity.net?

-Brad