From silvio Fri Sep 20 04:27:25 2002 Return-Path: Delivered-To: silvio@big.net.au Received: from big.net.au [202.7.194.4] by localhost with POP3 (fetchmail-5.5.0) for silvio@localhost (single-drop); Fri, 20 Sep 2002 04:27:25 -0700 (PDT) Received: (qmail 30308 invoked from network); 20 Sep 2002 10:50:58 -0000 Received: from unknown (HELO netsys.com) (199.201.233.10) by mail.big.net.au with SMTP; 20 Sep 2002 10:50:58 -0000 Received: from NETSYS.COM (localhost [127.0.0.1]) by netsys.com (8.11.6/8.11.6) with ESMTP id g8KAYfK18914; Fri, 20 Sep 2002 06:34:41 -0400 (EDT) Received: from ns2.sea (ns2.sea.interquest.net [66.135.144.2]) by netsys.com (8.11.6/8.11.6) with ESMTP id g8KAXOK18827 for ; Fri, 20 Sep 2002 06:33:26 -0400 (EDT) Received: from big.net.au (ip172.aurora.sfo.interquest.net [66.135.130.172]) by ns2.sea (8.12.5/8.12.5) with ESMTP id g8KAXN5H012009; Fri, 20 Sep 2002 03:33:23 -0700 Received: (from silvio@localhost) by big.net.au (8.11.0/8.11.0) id g8KAdYZ11202; Fri, 20 Sep 2002 03:39:34 -0700 From: silvio@big.net.au To: Matthew McGehrin Cc: full-disclosure@lists.netsys.com Subject: gated 3.6 ripquery, was Re: [Full-Disclosure] we should block: hushmail.com, hush.com Message-ID: <20020920033934.A11142@hamsec.aurora.sfo.interquest.net> References: <006401c2607e$e31bf040$af00a8c0@orange> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <006401c2607e$e31bf040$af00a8c0@orange>; from mcgehrin@reverse.net on Fri, Sep 20, 2002 at 04:22:40AM -0400 Sender: full-disclosure-admin@lists.netsys.com Errors-To: full-disclosure-admin@lists.netsys.com X-BeenThere: full-disclosure@lists.netsys.com X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Discussion of security issues List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 20 Sep 2002 03:39:34 -0700 Status: RO Content-Length: 2859 Lines: 98 i've not actually verified any of this, so comments are welcome i guess. looking at gated 3.6 ripquery we see this code --> static void ripq_trace (const char * dir, struct sockaddr_in * who, void_t cp, register int size) { register struct rip *rpmsg = (struct rip *) cp; register struct rip_netinfo *n; register const char *cmd = "Invalid"; /* XXX - V2 extensions */ if (rpmsg->rip_cmd && rpmsg->rip_cmd < RIPCMD_MAX) { cmd = trace_state(rip_cmd_bits, rpmsg->rip_cmd); } now.. this is ok, if it is indeed true that the the rip msg is infact of the correct minimum size so we dont do conceptual out of bounds reads (ignoring the fact that the cp buffer comes from the bss). looking at where this is called from .. --> /* * Handle an incoming routing packet. */ static void ripq_input (struct sockaddr_in * from, struct in_addr * to, int size) { register struct rip *msg = (struct rip *) ((void_t) packet); struct rip_netinfo *n; struct hostent *hp; if (dflag) { ripq_trace("RECV", from, (void_t) msg, size); } if (msg->rip_cmd != RIPCMD_RESPONSE) return; this also has a similar view that the size can at least accomodate the rip header etc.. the layer above this does stuff like size = recvfrom() well.. thats bad i spose, but the data is already zero initialized since its on the bss at this point, so its not going to cause major problems.. some logs and some conceptual "out of bounds" reads, but not segfault or otherwise crash. lets look at some other code switch (rpmsg->rip_cmd) { #ifdef RIPCMD_POLL case RIPCMD_POLL: #endif /* RIPCMD_POLL */ case RIPCMD_REQUEST: case RIPCMD_RESPONSE: (void) fprintf(stderr, "\n"); size -= 4 * sizeof(char); ok.. the reason for the 4*sizeof(char), is that the header is 4 bytes here (remember this for 2 seconds). back to ripq_input.. printf(" version %u:\n", msg->rip_vers); size -= sizeof(int); n = (struct rip_netinfo *) ((void_t) (msg + 1)); now we do size -= sizeof(int) which for something like x86 is going to be 4 as above.. on a 64 bit architecture, this is mostly likely going to be 8 bytes. i wonder if anyone reported weird bugs against ripquery on 64 bit architectures? -- Silvio On Fri, Sep 20, 2002 at 04:22:40AM -0400, Matthew McGehrin wrote: > I think the list should just block hushmail.com and hush.com, as in the few days it has been proven that these folks are using anonymity to hide behind dozens of stupid posts. > > I vote to block hushmail.com > > -- Matthew i say we cut of china from google. i heard they have automated porn havesting bots that rely on it. -- Silvio _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html