grsecurity forums

GRsec, sends kill signal to my sbnc

dmesg:

Code: Select all

grsec: From 192.168.217.189: signal 11 sent to /home/bergon2/sbnc/sbnc[sbnc:7721] uid/euid:1047/1047 gid/egid:100/100, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0

Debug:

Code: Select all

bergon2@Hera:~/sbnc$ gdb sbnc core.11511
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-slackware-linux"...Using host libthread_db library "/lib/tls/libth
read_db.so.1".

Core was generated by `./sbnc --rpc-child'.
Program terminated with signal 6, Aborted.

warning: current_sos: Can't read pathname for load map: Input/output error

Reading symbols from /lib/tls/libdl.so.2...done.
Loaded symbols for /lib/tls/libdl.so.2
Reading symbols from /usr/lib/libstdc++.so.5...done.
Loaded symbols for /usr/lib/./libstdc++.so.5
Reading symbols from /usr/lib/libcrypto.so.0...done.
Loaded symbols for /usr/lib/./libcrypto.so.0
Reading symbols from /usr/lib/libssl.so.0...done.
Loaded symbols for /usr/lib/./libssl.so.0
Reading symbols from /lib/tls/libm.so.6...done.
Loaded symbols for /lib/tls/libm.so.6
Reading symbols from /usr/lib/libgcc_s.so.1...done.
Loaded symbols for /usr/lib/./libgcc_s.so.1
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /home/bergon2/sbnc/lib-0/libsbnc.so.0...done.
Loaded symbols for /home/bergon2/sbnc/lib-0/libsbnc.so.0
Reading symbols from /home/bergon2/sbnc/lib-0/libbnctcl.so.0...done.
Loaded symbols for /home/bergon2/sbnc/lib-0/libbnctcl.so.0
Reading symbols from /lib/tls/libpthread.so.0...done.
Loaded symbols for /lib/tls/libpthread.so.0
Reading symbols from /usr/lib/libtcl8.5.so...done.
Loaded symbols for /usr/lib/./libtcl8.5.so
Reading symbols from /lib/tls/libnss_compat.so.2...done.
Loaded symbols for /lib/tls/libnss_compat.so.2
Reading symbols from /lib/tls/libnsl.so.1...done.
Loaded symbols for /lib/tls/libnsl.so.1
Reading symbols from /lib/tls/libnss_nis.so.2...done.
Loaded symbols for /lib/tls/libnss_nis.so.2
Reading symbols from /lib/tls/libnss_files.so.2...done.
Loaded symbols for /lib/tls/libnss_files.so.2
Reading symbols from /usr/lib/gconv/ISO8859-1.so...done.
Loaded symbols for /usr/lib/gconv/ISO8859-1.so
#0  0xb7c2b027 in raise () from /lib/tls/libc.so.6

Please help me to solve this problem.
Thanks.

kid wrote:GRsec, sends kill signal to my sbnc

grsec doesn't send the signal, it reports it only. as for the actual cause, you should provide the backtrace and register info at least (bt, info reg), and also the crashing insns (since it's in abort, the actual problem occured before, we'll see that when you post the backtrace). on a guess, newer glibc calls abort on certain heap corruption issues, try to run sbnc from the shell and see what it logs on stderr.

PaX Team wrote:

kid wrote:GRsec, sends kill signal to my sbnc

grsec doesn't send the signal, it reports it only. as for the actual cause, you should provide the backtrace and register info at least (bt, info reg), and also the crashing insns (since it's in abort, the actual problem occured before, we'll see that when you post the backtrace). on a guess, newer glibc calls abort on certain heap corruption issues, try to run sbnc from the shell and see what it logs on stderr.

Thanks for response PaX Team!
And this is the bt and info reg log:

Code: Select all

(gdb) bt
#0  0xb7c3760d in mempcpy () from /lib/tls/libc.so.6
#1  0xb7c2c861 in _IO_new_file_xsputn () from /lib/tls/libc.so.6
#2  0xb7c22b72 in fwrite () from /lib/tls/libc.so.6
#3  0xb7bb05cf in RpcWriteValue (Pipe=0xb7ce76c0, Value={Type = 2, Flags = 0 '\0', NeedFree = 0, {Integer = 336787976}})
    at RPCApi.cpp:193
#4  0xb7bb0ed0 in RpcInvokeFunction (Function=3086098448, Arguments=0xbfd745e0, ArgumentCount=4, ReturnValue=0xbfd745c0)
    at RPCApi.cpp:645
#5  0xb7bb3774 in safe_send (Socket=35, Buffer=0x6949a3a8, Size=336787976, Flags=0) at SafeAPI.cpp:985
#6  0xb7b97dc9 in CConnection::Write (this=0x879e6ab) at Connection.cpp:378
#7  0xb7b77d1d in CCore::StartMainLoop (this=0x80663c0) at Core.cpp:599
#8  0xb7ba5ff8 in sbncLoad (ModulePath=0xb7f22010 "PING :sbnc\r\n", Daemonize=false, argc=2, argv=0xbfd75af4) at sbnc.cpp:252
#9  0x08049f56 in main (argc=2, argv=0xbfd75af4) at sbncloader.cpp:417
(gdb) info reg
eax            0x3f0    1008
ecx            0xfc     252
edx            0xb7f22010       -1208868848
ebx            0xb7ce7000       -1211207680
esp            0xbfd7448c       0xbfd7448c
ebp            0xbfd74494       0xbfd74494
esi            0x6949a3a8       1766433704
edi            0xb7f22010       -1208868848
eip            0xb7c3760d       0xb7c3760d
eflags         0x10206  66054
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x33     51

But i saw that is differently in another core...

Code: Select all

(gdb) bt
#0  0x00000019 in ?? ()
#1  0xb7baa3c6 in CConnection::Destroy (this=0x86d8d30) at Connection.cpp:651
#2  0xb7b89fbd in CCore::StartMainLoop (this=0x80663a8) at Core.cpp:517
#3  0xb7bb7ff8 in sbncLoad (ModulePath=0x86d8d30 "\b╓@\bpa&\bF", Daemonize=false, argc=2, argv=0xbfd3faf4) at sbnc.cpp:252
#4  0x08049f56 in main (argc=2, argv=0xbfd3faf4) at sbncloader.cpp:417
(gdb) info reg
eax            0x840d608        138466824
ecx            0xb7cfa804       -1211127804
edx            0x86d8d30        141397296
ebx            0xb7bdd468       -1212296088
esp            0xbfd3e63c       0xbfd3e63c
ebp            0xbfd3e668       0xbfd3e668
esi            0x0      0
edi            0x86c8b3f        141331263
eip            0x19     0x19
eflags         0x10296  66198
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x33     51
(gdb) quit


I don't understand so much about the debugging, so that.. how exactly to see what it logs on stderr.? Did you mean to use strace?
Thanks PaX

kid wrote:I don't understand so much about the debugging, so that.. how exactly to see what it logs on stderr.? Did you mean to use strace?

based on what you posted i think sbnc has some memory corruption bug in it, unlikely to be caused by us . to get to the bottom of it, you should probably talk to the developers and help them debug it (fortunately, it seems you can reproduce it easily which certainly helps in debugging). if you want to start by yourself, run it through valgrind, maybe it will see the memory corruption. as for stderr, i just meant that if you run the daemon from the shell (and possibly tell it to not daemonize itself) you'll see the glibc abort message easily (but then, i'm not sure that it's such a heap corruption that glibc detects, valgrind and other debugging tools are better to tackle this).

PaX Team wrote:

kid wrote:I don't understand so much about the debugging, so that.. how exactly to see what it logs on stderr.? Did you mean to use strace?

based on what you posted i think sbnc has some memory corruption bug in it, unlikely to be caused by us . to get to the bottom of it, you should probably talk to the developers and help them debug it (fortunately, it seems you can reproduce it easily which certainly helps in debugging). if you want to start by yourself, run it through valgrind, maybe it will see the memory corruption. as for stderr, i just meant that if you run the daemon from the shell (and possibly tell it to not daemonize itself) you'll see the glibc abort message easily (but then, i'm not sure that it's such a heap corruption that glibc detects, valgrind and other debugging tools are better to tackle this).

PaX Team, see this... i think i have some serious problem, be cause:

1st i get this test.c
from the example here: http://cs.ecs.baylor.edu/~donahoo/tools/valgrind/

Code: Select all

#include <stdio.h>

int main()
{
  char *p;

  // Allocation #1 of 19 bytes
  p = (char *) malloc(19);

  // Allocation #2 of 12 bytes
  p = (char *) malloc(12);
  free(p);

  // Allocation #3 of 16 bytes
  p = (char *) malloc(16);

  return 0;
}

compiled it, and use valgrind with "valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 --track-fds=yes ./test" options

and the result is:

Code: Select all

Message from syslogd@Hera at Tue Nov 20 12:59:34 2007 ...
Hera kernel: Oops: 0000 [#244]

Message from syslogd@Hera at Tue Nov 20 12:59:34 2007 ...
Hera kernel: CPU:    0

Message from syslogd@Hera at Tue Nov 20 12:59:34 2007 ...
Hera kernel: EIP:    0060:[<c040ee67>]    Tainted: G      D VLI

Message from syslogd@Hera at Tue Nov 20 12:59:34 2007 ...
Hera kernel: EFLAGS: 00010246   (2.6.23-grsec #1)

Message from syslogd@Hera at Tue Nov 20 12:59:34 2007 ...
Hera kernel: eax: 00000000   ebx: 00000078   ecx: 00000000   edx: ffffe000

Message from syslogd@Hera at Tue Nov 20 12:59:34 2007 ...
Hera kernel: esi: 00000070   edi: 00000000   ebp: 00000000   esp: c8655ed0

Message from syslogd@Hera at Tue Nov 20 12:59:34 2007 ...
Hera kernel: ds: 007b   es: 007b   fs: 0000  gs: 0000  ss: 0068

Message from syslogd@Hera at Tue Nov 20 12:59:34 2007 ...
Hera kernel: Process memcheck (pid: 27694, ti=c8654000 task=e9c85030 task.ti=c8654000)

Message from syslogd@Hera at Tue Nov 20 12:59:34 2007 ...
Hera kernel: Stack: c047fcb9 d63144c0 c0624694 ffffe000 fffff000 00000072 0000002d 00000078

Message from syslogd@Hera at Tue Nov 20 12:59:34 2007 ...
Hera kernel:        00000070 00000000 00000000 00000000 00000000 c8655f2c 00000000 c0684300

Message from syslogd@Hera at Tue Nov 20 12:59:34 2007 ...
Hera kernel:        d63144c0 e9c85030 00000000 00000000 00000000 00000000 00000000 00000028

Message from syslogd@Hera at Tue Nov 20 12:59:34 2007 ...
Hera kernel: Call Trace:

Message from syslogd@Hera at Tue Nov 20 12:59:34 2007 ...
Hera kernel:  [<c047fcb9>] <0> [<c046c3d3>] <0> [<c0454755>] <0> [<c046c200>] <0> [<c0454b11>] <0> [<c0402ab2>] <0> =======================

Message from syslogd@Hera at Tue Nov 20 12:59:34 2007 ...
Hera kernel: Code: 00 00 00 00 89 d0 e9 49 c7 03 00 89 f6 8d bc 27 00 00 00 00 85 c0 75 03 31 c0 c3 e9 b4 c9 03 00 90 90 90 90 8b 08 8b 50 04 31 c0 <3b> 91 70 01 00 00 ba 42 b6 61 c0 0f 44 c2 c3 8d 76 00 8d bc 27

Message from syslogd@Hera at Tue Nov 20 12:59:34 2007 ...
Hera kernel: EIP: [<c040ee67>]  SS:ESP 0068:c8655ed0
test.sh: line 2: 27694 Segmentation fault      valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 --track-fds=yes ./test

what do you think about this, is that some hardware problem?

kid wrote:what do you think about this, is that some hardware problem?

it's a kernel NULL deref bug, you should decode the backtrace to see where exactly it happened (or send me System.map/vmlinux). also, which grsec/PaX version was this (could be something already fixed if it wasn't the last one)?