Re: My network is dead because of this program :(
In the last episode (May 15), Brian O'Shea said: > On Tue, May 15, 2001 at 10:44:32PM -0400, Matthew Emmerton wrote: > [...] > > > After going to single user mode, cause I can't kill the offending > > > program once it is running in multiuser mode (even kill -9 won't > > > work ... > > Probably because the program is forking and you can't kill it's > children fast enough. A handy way to kill forkbombs like this is "su username -c kill -9 -1", which will kill all the processes owned by that user at once. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My network is dead because of this program :(
On Tue, May 15, 2001 at 10:44:32PM -0400, Matthew Emmerton wrote: [...] > > After going to single user mode, cause I can't kill the offending > > program once it is running in multiuser mode (even kill -9 won't > > work ... Probably because the program is forking and you can't kill it's children fast enough. > > Can anyone help me trace what the program does? And how can I > > prevent the program to DoS my network interface? Even when the > > program is started by unprivileged user, it works, it DoS my network > > interface. Is this a bug? [...] Unfortunately it looks like the program forks, does it's thing, and then each child forks too. There is a call to sleep probably to introduce a delay so that things don't go completely crazy right away, but processes build up exponentially with each child process forking, so eventually resources get exhausted. Take a look at the attachment for more details. -brian -- Brian O'Shea <[EMAIL PROTECTED]> It looks like the program basically does this, in pseudo-code: main() { int pid; while (1) { pid = fork(); if (pid == 0) { /* child process */ socketpair(); /* get two AF_LOCAL sockets */ setsockopt(); /* set receive buffer size on one socket */ setsockopt(); /* set send buffer size on other socket */ fcntl();/* set non-blocking I/O on both sockets */ fcntl(); write();/* write some data from one socket to the other */ write(); } /* else we're in the parent, or fork() failed */ sleep();/* sleep a while */ } return; } (gdb) disassemble main Dump of assembler code for function main: 0x804865c : push %ebp 0x804865d : mov%esp,%ebp 0x804865f : sub$0x32018,%esp 0x8048665 : nop We're probably in an infinite loop here. 0x8048666 :movl $0x0,0xfff4(%ebp) 0x804866d :lea0x0(%esi),%esi 0x8048670 :cmpl $0x12,0xfff4(%ebp) 0x8048674 :jle0x8048678 0x8048676 :jmp0x8048690 The first thing we do in the loop is call fork(). 0x8048678 :call 0x80484c0 Then we check its return value. 0x804867d :mov%eax,%eax 0x804867f :test %eax,%eax 0x8048681 :je 0x8048688 0x8048683 :jmp0x8048690 0x8048685 :lea0x0(%esi),%esi It looks like the parent calls fork in a loop. The child processes that it creates continue. 0x8048688 :incl 0xfff4(%ebp) 0x804868b :jmp0x8048670 0x804868d :lea0x0(%esi),%esi 0x8048690 :add$0xfff4,%esp Sleep for 5 seconds ... 0x8048693 :push $0x5 0x8048695 :call 0x8048490 0x804869a :add$0x10,%esp 0x804869d :lea0x0(%esi),%esi 0x80486a0 :jmp0x80486a8 0x80486a2 :jmp0x80487ac 0x80486a7 :nop Child calls socketpair with the following arguments: int socketpair(int domain, int type, int protocol, int *sv) int domain = 0x1 (AF_LOCAL) int type = 0x1 (SOCK_STREAM) int protocol = 0x0 (typically 0 for AF_LOCAL) int *sv = address of an array of two file descriptors Push arguments to socketpair onto stack and call socketpair again: 0x80486a8 :lea0xfff8(%ebp),%eax 0x80486ab :push %eax 0x80486ac :push $0x0 0x80486ae :push $0x1 0x80486b0 :push $0x1 0x80486b2 :call 0x80484e0 0x80486b7 :add$0x10,%esp 0x80486ba :mov%eax,%eax Note: It's strange that the address family is AF_LOCAL. I wouldn't think this would cause the problems that you are seeing with the xl0 device, unless AF_LOCAL sockets consume some of the same resources that this driver also consumes, and thus starves it of those resources. I don't know enough about FreeBSD to tell. Looks like we're checking the return value of socketpair. The value 0x is -1, which is what socketpair returns if it fails. 0x80486bc :cmp$0x,%eax 0x80486bf :jne0x80486c8 0x80486c1 : jmp0x80487ac If it fails, jumps ahead to a call to pause (below at main+336) 0x80486c6 : mov%esi,%esi 0x80486c8 : movl $0x32000,0xfff4(%ebp) 0x80486cf : add$0xfff4,%esp Push arguments to setsockopt onto stack and call setsockopt: 0x80486d2 : push $0x4 0x80486d4 : lea0xfff4(%ebp),%eax 0x80486d7 : push %eax 0x80486d8 : push $0x1002 0x80486dd : push $0x 0x80486e2 : mov0xfff8(%ebp),%eax 0x80486e5 : push %eax 0x80486e6 : call 0x80484b0 int setsockopt( int s, /* socket descriptor */ int level, /* 0x (SOL_SOCKET) */ int optname, /* 0x1002 (SO_RCVBUF) */ void*optval,/* pointer to a buffer containing optval */ socklen_t *optlen /* pointer to buffer length */ ) Pop arguments to first setsockopt call off stack. 0
Re: My network is dead because of this program :(
On Tue, May 15, 2001 at 10:19:34PM -0500, Mark Sergeant wrote: > Another solution would be to remove this users access ? Yeah, that also basically goes without saying :-) Kris PGP signature
Re: My network is dead because of this program :(
Another solution would be to remove this users access ? On Tue, 15 May 2001 20:16:15 -0700, Kris Kennaway said: :: On Wed, May 16, 2001 at 09:20:35AM +0700, John Indra wrote: :: > Dear all... :: > :: > First of all, really sorry for cross-posting... :: > :: > I am running a -CURRENT system (Apr 30th 2001). There is a user in my :: > machine running this small program to DoS my xl0 interface. I doubt that :: > this program is specifically designed for xl cards though. :: :: Don't run -current on a production system. Seriously, just don't, :: unless you like dealing with this kind of stuff. The bug report may :: be useful, but you're playing with fire. :: :: Kris :: -- Mark Sergeant Unix Systems Administrator Fortune follows... Machine-Independent, adj.: Does not run on any existing machine. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My network is dead because of this program :(
* John Indra <[EMAIL PROTECTED]> [010515 21:19]: > Dear all... > > First of all, really sorry for cross-posting... > > I am running a -CURRENT system (Apr 30th 2001). There is a user in my > machine running this small program to DoS my xl0 interface. I doubt that > this program is specifically designed for xl cards though. > > Once the program is started, it starts forking childs I assume. Then after > sometime, this messages start popping to my screen: > > xl0: no memory for rx lists -- packet dropped > Shouldn't reasonable resource limits (man limits), prevent this from happening - particularly the sbsize setting? Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My network is dead because of this program :(
On Wed, May 16, 2001 at 09:20:35AM +0700, John Indra wrote: > Dear all... > > First of all, really sorry for cross-posting... > > I am running a -CURRENT system (Apr 30th 2001). There is a user in my > machine running this small program to DoS my xl0 interface. I doubt that > this program is specifically designed for xl cards though. Don't run -current on a production system. Seriously, just don't, unless you like dealing with this kind of stuff. The bug report may be useful, but you're playing with fire. Kris PGP signature
Re: My network is dead because of this program :(
> Dear all... > > First of all, really sorry for cross-posting... > > I am running a -CURRENT system (Apr 30th 2001). There is a user in my > machine running this small program to DoS my xl0 interface. I doubt that > this program is specifically designed for xl cards though. > > Once the program is started, it starts forking childs I assume. Then after > sometime, this messages start popping to my screen: > > xl0: no memory for rx lists -- packet dropped > > After going to single user mode, cause I can't kill the offending program > once it is running in multiuser mode (even kill -9 won't work on my system), > then coming back to multiuser mode, I tried to run it and trace what it does > with truss. But, truss didn't seem to output anything at all. Then, I saw > the program state in top and it said the program is in mbuf state. > > I have searched all mailing lists archieves in > http://www.freebsd.org/search/search.html#mailinglists but wierdly, there > are no articles shown when I enter this as a query: "no memory for rx list" > > Can anyone help me trace what the program does? And how can I prevent the > program to DoS my network interface? Even when the program is started by > unprivileged user, it works, it DoS my network interface. Is this a bug? I don't know exactly what this program does, but by looking at the 'strings' output, it would appear to do a bunch of setsockopt(), socketpair(), write()s and fork()s. I imagine that it's forking like crazy (to grind your system to a half) and doing some funky socket stuff (to overload the NIC driver.) The reason why this works when run as an underpriviledged user is because a) any user can fork() and b) any user can create sockets and use the network. You should be able to kill -9 this program; however, you must make sure that you kill the parent. You may find the 'killall' command useful. There's not much that you can do to prevent the DoS of a NIC -- it could happen just as easily from the outside as from the inside (although via different means). However, you can monitor what your users are doing on the system, and take appropriate actions if they're abusing them. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
My network is dead because of this program :(
Dear all... First of all, really sorry for cross-posting... I am running a -CURRENT system (Apr 30th 2001). There is a user in my machine running this small program to DoS my xl0 interface. I doubt that this program is specifically designed for xl cards though. Once the program is started, it starts forking childs I assume. Then after sometime, this messages start popping to my screen: xl0: no memory for rx lists -- packet dropped After going to single user mode, cause I can't kill the offending program once it is running in multiuser mode (even kill -9 won't work on my system), then coming back to multiuser mode, I tried to run it and trace what it does with truss. But, truss didn't seem to output anything at all. Then, I saw the program state in top and it said the program is in mbuf state. I have searched all mailing lists archieves in http://www.freebsd.org/search/search.html#mailinglists but wierdly, there are no articles shown when I enter this as a query: "no memory for rx list" Can anyone help me trace what the program does? And how can I prevent the program to DoS my network interface? Even when the program is started by unprivileged user, it works, it DoS my network interface. Is this a bug? I have attached the offending program with this mail. Please don't run it on production system! You have been warned! Thank you very much... /john Live Free OR Die x