I recently tried to run p0f on a grsec enabled system and encountered problems. The first problem is that it immediately dies with the following errors showing up in my logs: Mar 10 10:22:34 blah@blah grsec: From 1.2.3.4: signal 11 sent to /usr/sbin/p0f[p0f:28827] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0 Mar 10 10:22:34 blah@blah grsec: From 1.2.3.4: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/sbin/p0f[p0f:28827] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0 The second problem is that both /etc/init.d/p0f start AND stop report [OK]! If I didn't check running processes/logs, I wouldn't have noticed that p0f had died. I'm not sure what this really means, but p0f is a security tool, and I would really like to be able to run it on gresec/PAX enabled systems. Here's my info: Portage 2.0.54 (hardened/x86/2.6, gcc-3.4.5, glibc-2.3.5-r2, 2.6.14-hardened-r5 i686) ================================================================= System uname: 2.6.14-hardened-r5 i686 Intel(R) Xeon(TM) CPU 3.00GHz Gentoo Base System version 1.6.14 dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig buildpkg distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://gentoo.chem.wisc.edu/gentoo" MAKEOPTS="-j8" PKGDIR="/usr/portage//packages/x86/" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage/" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 berkdb bzip2 crypt curl doc fam fastcgi gif hardened imap jpeg ldap libclamav maildir mailwrapper mmx nfsv4 nptl nptl-only pam pcre perl pic png postgres python readline samba sasl sse ssl tcpd tiff unicode vhosts zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS Everything is updated to within a few weeks, and I use gcc-3.4.5.
By grsec, I mean I use hardened sources and the hardened toolchain (grsecurity is part of the hardened kernel). Perhaps building p0f with the hardened gcc is causing it to segfault?
This is probably more of a hardened issue where ssp or pax stuff prevents p0f from building correctly, i'll add them to the CC list...
Please see the first question at http://www.grsecurity.net/wiki/index.php/GrsecurityFAQ.
Suggestion: Recompile it with debugging enabled, paxctl it and get a gdb full backtrace. Some tips on debugging while +hardened is enabled can be found here. - http://gentoo-wiki.com/SECURITY_Debugging_with_Hardened_Gentoo The part about GCC_SPECS= is strange advice and should be using gcc-config but no matter that method would work anyway.
I tried to debug it, but I didn't have any luck: 1) removed -fomit-frame-pointer from make.conf 2) changed to gcc-vanilla with gcc-config 3) source /etc/profile 4) emerge p0f 5) gdb (gdb) set args -i eth0 -v "tcp and tcp[13] & 2 = 2" >> /var/log/p0f 2>&1 Reading symbols from /usr/sbin/p0f...(no debugging symbols found)...done. Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) file /usr/sbin/p0f (gdb) run Starting program: /usr/sbin/p0f -i eth0 -v "tcp and tcp[13] & 2 = 2" >> /var/log/p0f 2>&1 Warning: Cannot insert breakpoint -2. Error accessing memory address 0x4d490241: Input/output error. (gdb) bt #0 0x4d484820 in ?? () Am I doing something wrong? I noticed that if I removed the filter rule and just ran 'p0f -i eth1 -v', it wouldn't segfault. The init script says the filter rule makes it only analyze packets with the SYN flag set (a very useful default). I tested the rule with tcpdump and it appears valid.
(In reply to comment #5) I think, you did not switch off MPROTECT for /usr/sbin/p0f, so gdb cannot set the breakpoint. Try with MPROTECT switched off: # paxctl -m /usr/sbin/p0f before invoking gdb.
(In reply to comment #5) > Error accessing memory address 0x4d490241: Input/output error. For this you need to relax the mprotect restriction, as Dominik said: /sbin/paxctl -m /usr/sbin/p0f > (gdb) bt > #0 0x4d484820 in ?? () For this you need to: (1) enable debug symbols by adding '-ggdb3' for example to CFLAGS (2) link no-pie (or build vanilla, if that yields a binary that shows the same behaviour). CFLAGS=-ggdb3 LDFLAGS=-nopie emerge p0f However as r2d2 intimated in comment #3, just because grsec reports a signal in the logs doesn't mean there's a problem; the same happens without grsec, but it doesn't get logged. Anyway, I took a look and the app is broken. It has a bunch of unlimited sprintfs which overrun buffers; for example from line 1616 on we see: if (argv[optind] && *(argv[optind])) { sprintf(buf,"(%s) and (%3000s)",use_rule,argv[optind]); use_rule = buf; } if (use_vlan) { _u8* x = strdup(use_rule); sprintf(buf,"(%1000s) or (vlan and (%1000s))",x,x); free(x); use_rule = buf; } which means that buf is overrun quite insanely if both conditions are true (which is the case if you supply a rule and '-v). Effects of the overrun will be unpredictable, as the overrun trashes the stack. Note that since this part of the code is a long code segment in main, i.e. not in separate functions, the stack protector won't notice anything amiss. Changing the declaration of buf in main to: int main(int argv,char** argv) { _u8 buf[MAXLINE*8]; gets things running, but really the app needs some proper attention to sort out all the use of unbounded string functions (especially sprintf).
Since problem is not with hardened (app fails the same way when built vanilla), removing us from CC. Netmon - up to you to fix or take upstream.
Wow, thanks for the info... I guess this is really an upstream issue, so I'll try to contact the author (lcamtuf (at) coredump (dot) cx) to see if he can make official changes. We need to mask this as unstable in portage since the default script includes options that cause it to segfault (did this bypass QC or something?). Either that, or we can release a patched version that removes -v for now...
The author has replied to my questions about this bug and said that the bug should be fixed in 2.0.6.
(In reply to comment #7) > Anyway, I took a look and the app is broken. It has a bunch of unlimited > sprintfs which overrun buffers; for example from line 1616 on we see: > > if (argv[optind] && *(argv[optind])) { > sprintf(buf,"(%s) and (%3000s)",use_rule,argv[optind]); > use_rule = buf; > } > > if (use_vlan) { > _u8* x = strdup(use_rule); > sprintf(buf,"(%1000s) or (vlan and (%1000s))",x,x); > free(x); > use_rule = buf; > } > > which means that buf is overrun quite insanely if both conditions are true > (which is the case if you supply a rule and '-v). Effects of the overrun will > be unpredictable, as the overrun trashes the stack. Note that since this part > of the code is a long code segment in main, i.e. not in separate functions, the > stack protector won't notice anything amiss. Good job :) This overrun could lead to a security issue. I suggest that security team watches this bug as for now. Waiting for other points of view...
Reassigning to security to keep track of it.
looks like you can execute code as yourself, so not a security issue. please REOPEN if i've misunderstood.
