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
