From owner-freebsd-security@FreeBSD.ORG Tue Jan 15 04:43:21 2008 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A4A416A417 for ; Tue, 15 Jan 2008 04:43:21 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id F302513C448 for ; Tue, 15 Jan 2008 04:43:20 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id m0F4SbXp087872 for ; Mon, 14 Jan 2008 23:28:37 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m0F4SaH1084137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 14 Jan 2008 23:28:37 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200801150428.m0F4SaH1084137@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 14 Jan 2008 23:28:46 -0500 To: freebsd-security@freebsd.org From: Mike Tancsa In-Reply-To: <200801142309.m0EN9has056540@freefall.freebsd.org> References: <200801142309.m0EN9has056540@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: FreeBSD Security Advisory FreeBSD-SA-08:02.libc X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2008 04:43:21 -0000 At 06:09 PM 1/14/2008, FreeBSD Security Advisories wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >============================================================================= >FreeBSD-SA-08:02.libc Security Advisory > The FreeBSD Project > >Topic: inet_network() buffer overflow > >For programs which passes untrusted data to inet_network(), an >attacker may be able to overwrite a region of memory with user defined >data by causing specially crafted input to be passed to >inet_network(). For the "usual suspects" of applications running, (e.g. sendmail, apache, BIND etc) would it be possible to pass crafted packets through to this function remotely via those apps ? ie how easy is this to do ? ---Mike