Date: Mon, 24 Jan 2000 15:19:19 -0800 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Brett Glass <brett@lariat.org>, security@FreeBSD.ORG Subject: Re: stream.c as "monkey" Message-ID: <200001242319.PAA24095@salsa.gv.tsc.tdk.com> In-Reply-To: <4.2.2.20000124103221.01e1a410@localhost> References: <4.2.2.20000124103221.01e1a410@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 24, 10:45am, Brett Glass wrote: } Subject: stream.c as "monkey" } But I digress. In a way, stream.c functions as a TCP "monkey," sending } packets with insane addresses and port numbers. It's not a very good "monkey" because it only randomizes addresses and port numbers. That doesn't exercise many different code paths, and it seems that the only interesting thing it finds is what happens when it picks a multicast source address. } (It doesn't exercise } the TCP option flags, but it could be made to do so.) Maybe this program } should be regarded as a way to beat the stuffing out of the stack and } avoid problems with long code paths, memory allocation problems, and/or } future DoS attacks. It surely wouldn't make a bad networking regression } test. Other things it might test are the flags, the TCP options, different packet lengths, and sequence numbers. This is a large enough search space that you might find that you can't explore much of it in a reasonable period of time, so you might want to try some more extensive testing of a subset of this space. In addition to some of the other references, you might want to dig up a copy of "crashme" (hey, where's the port!), which executes random code. I think there is also a variant that executes random syscalls, which wouldn't be very well exercised by running random code. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001242319.PAA24095>