[6798] in bugtraq
Re: pingflood.c
daemon@ATHENA.MIT.EDU (pedward@WEBCOM.COM)
Mon May 18 15:03:07 1998
Date: Mon, 18 May 1998 10:23:32 -0700
Reply-To: pedward@WEBCOM.COM
From: pedward@WEBCOM.COM
X-To: avarvit@cc.ece.ntua.gr
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <199805181039.NAA19336@cc.ece.ntua.gr> from "Aggelos P.
Varvitsiotis" at May 18, 98 01:39:07 pm
The reason that this works is because many platforms implement sleep(2)
as:
alarm(seconds);
sigsuspend(...);
This is implementation is done in Solaris, etc. I have implemented my
own sleep function because when using threads under Solaris, messing with
signals is a bad proposition. So:
void mysleep(int seconds)
{
struct timeval tv;
tv.tv_sec=seconds;
tv.tv_usec=0;
select(0,NULL,NULL,NULL,&tv);
}
The code above should be portable to every platform that supports the standard
select(2) semantics. It allows for subsecond precision too. This implementation
isn't subject to signal dainbrammage either.
--Perry
> Verified it on SunOS 5.5.1. Basically, it is so simple that it
> should work on any Unix box. The "bug" in ping's code is that
> the code naively assumes the SIGALRM is system-generated (due
> to a previous alarm() call). At least on SunOS 5.5.1, sigaction(2)
> can be used to examine the source of the SIGALRM (e.g. check
> that (siginfo_t *)si->si_code > 0 -- (siginfo_t *)si is returned
> to the signal handler if the sa_flags member of the struct sigaction
> passed to sigaction() has the SA_SIGINFO bit set). I am not sure
> how this can be implemented on other systems.
>
> BTW, how many setuid programs are there that will catch various
> signals and will behave "not-as-expected" when forked off by a
> signal-bomber parent process, such as pingflood?
>
> a.varvitsiotis@iccs.ntua.gr A.Varvitsiotis
> ICCS Computer Center
> National Technical University of Athens
>
>
--
Perry Harrington System Software Engineer zelur xuniL ()
http://www.webcom.com perry.harrington@webcom.com Think Blue. /\
