From owner-freebsd-security Mon Jan 24 9:45:25 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 0A31D14A2D for ; Mon, 24 Jan 2000 09:45:22 -0800 (PST) (envelope-from brett@lariat.org) Received: from workhorse (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id KAA25300 for ; Mon, 24 Jan 2000 10:45:19 -0700 (MST) Message-Id: <4.2.2.20000124103221.01e1a410@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 24 Jan 2000 10:45:18 -0700 To: security@FreeBSD.ORG From: Brett Glass Subject: stream.c as "monkey" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Stepping back from this whole long discussion of stream.c, it occurs to me that this exploit is not unlike the "monkey" desk accessory which programmers once used to beat Macintosh programs into submission. By emulating a monkey hitting random keys on the keyboard (and also clicking on anything and everything on the screen), this little desk accessory was surprisingly effective at crashing an app that wasn't solid. [Side note: The idea of monkeys typing away at keyboards trying to reproduce the works of William Shakespeare was an old joke at Apple after Mike Markkula wrote a sample program called "The Infinite Number of Monkeys." The program describes an experiment in which large numbers of monkeys peck at keyboards until one of the monkeys starts typing something like "To be or not to be; that is the gnumph glorgle glorzumplatz." The program comments that maybe it needs just a few more monkeys and repeats the "experiment." Silly, but it's fun the first time you see it.] But I digress. In a way, stream.c functions as a TCP "monkey," sending packets with insane addresses and port numbers. (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. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message