From owner-freebsd-net@FreeBSD.ORG Thu Dec 9 21:18:43 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAA251065670 for ; Thu, 9 Dec 2010 21:18:43 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 31DBA8FC14 for ; Thu, 9 Dec 2010 21:18:42 +0000 (UTC) Received: by wwf26 with SMTP id 26so2752388wwf.31 for ; Thu, 09 Dec 2010 13:18:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:reply-to:from:to:cc :references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=Co5nnXk+bcvsw+ZgXcnoBJYJ82EICYw3S33vC5QUtic=; b=IlKlq2iPoV1SKGh88NwPO+azxIX9/+hB/LtFScoxoTT5YwNE+26DVhcnLO+zuTc78I 7zsLHs9fEk6cYIKZATifZD3tR05DD5vM85UrWo61T0fbXAlOBRxX33lPwYnSQrvL9wvP HrrsoxWfq3C6jmESnHoRND7IE2LuUG8fabwBY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=reply-to:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=Eouq6KM8/bowTZ99cK+SRRIh6hwVF5aQb7A/B3t8QwvNh8v1fws4K+eiIfEtXmnxr3 t4aKTmcIowaVgnqenkSYqu9YCjrpaPg2iqLdBvXzOl1ZCiDrLs4LZWtrPzn+KdEJXhkH 4he1NblwgM+eLxLeI0K3Gq16E2wMcCSVS6itU= Received: by 10.227.136.15 with SMTP id p15mr10201149wbt.124.1291927800286; Thu, 09 Dec 2010 12:50:00 -0800 (PST) Received: from rimwks1x64 ([92.124.9.131]) by mx.google.com with ESMTPS id 11sm1534320wbi.0.2010.12.09.12.49.57 (version=SSLv3 cipher=RC4-MD5); Thu, 09 Dec 2010 12:49:59 -0800 (PST) From: rozhuk.im@gmail.com To: "'Chuck Swiger'" References: <4cfe88b6.1cedd80a.33f5.119d@mx.google.com> In-Reply-To: Date: Fri, 10 Dec 2010 04:49:54 +0800 Message-ID: <4d0140f7.4b02e30a.7efb.7963@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuWUOOW+QSJMKZqQW2X4ll10edqdABkVYFg Content-Language: ru Cc: freebsd-net@freebsd.org Subject: RE: [arp] possible DoS, fixes and improvements X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rozhuk.IM@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 21:18:44 -0000 Hi! > I wonder which version of netinet/if_ether.c you are working from? uname -a FreeBSD firewall 9.0-CURRENT FreeBSD 9.0-CURRENT #2: Wed Dec 8 02:53:50 IRKT 2010 root@firewall:/usr/obj/usr/src/sys/RIMx64 amd64 =A0 -- Rozhuk Ivan =A0=20 > -----Original Message----- > From: Chuck Swiger [mailto:cswiger@mac.com] > Sent: Wednesday, December 08, 2010 4:54 AM > To: Rozhuk.IM@gmail.com > Cc: freebsd-net@freebsd.org > Subject: Re: [arp] possible DoS, fixes and improvements >=20 > Hi, Rozhuk-- >=20 > On Dec 7, 2010, at 11:19 AM, rozhuk.im@gmail.com wrote: > > Hi! > > > > 1. ah->ar_hln - is depend from ar_hrd? > > Yes, and for ARPHRD_ETHER is 6 (ETHER_ADDR_LEN) > > For ARPHRD_IEEE1394 - sizeof(struct fw_hwaddr) > > ah->ar_hln ignored in ether_output: bcopy(ar_tha(ah), edst, > ETHER_ADDR_LEN); >=20 > If you know that ar_hrd is ARPHRD_ETHER, then you can either assume = the > length is ETHER_ADDR_LEN, or optionally check it, per RFC 826: >=20 > "When an address resolution packet is received, the receiving > Ethernet module gives the packet to the Address Resolution module > which goes through an algorithm similar to the following. > Negative conditionals indicate an end of processing and a > discarding of the packet. >=20 > ?Do I have the hardware type in ar$hrd? > Yes: (almost definitely) > [optionally check the hardware length ar$hln] > ?Do I speak the protocol in ar$pro? > Yes: > [optionally check the protocol length ar$pln]" >=20 > > check in in_arpinput: > > if (ifp->if_addrlen !=3D ah->ar_hln) { > > LLE_WUNLOCK(la); > > log(LOG_WARNING, > > "arp from %*D: addr len: new %d, i/f %d > (ignored)", > > ifp->if_addrlen, (u_char *) ar_sha(ah), ":", > > ah->ar_hln, ifp->if_addrlen); > > goto reply; > > } > > NO DROP!!!! >=20 > I wonder which version of netinet/if_ether.c you are working from? > In 7-STABLE sources, it breaks rather than going to generate a reply: >=20 > if (ifp->if_addrlen !=3D ah->ar_hln) { > log(LOG_WARNING, > "arp from %*D: addr len: " > "new %d, i/f %d (ignored)", > ifp->if_addrlen, (u_char *) > ar_sha(ah), > ":", ah->ar_hln, ifp->if_addrlen); > RT_UNLOCK(rt); > break; > } >=20 > > In reply we get: > > (void)memcpy(ar_tha(ah), ar_sha(ah), ah->ar_hln); > > (void)memcpy(ar_sha(ah), enaddr, ah->ar_hln); > > Or > > (void)memcpy(ar_tha(ah), ar_sha(ah), ah->ar_hln); > > (void)memcpy(ar_sha(ah), &lle->ll_addr, ah->ar_hln); > > > > How to use it see below. > > > > > > 2. ah->ar_pln - does not checked! > > We can make big arp request (512 nulls after struct arphdr + 2*6 + > 2*4) , > > valid for host, set ar_plt =3D 255 > > And in reply will receive part of stack or core panic: > > in_arpinput: > > (void)memcpy(ar_spa(ah), &itaddr, ah->ar_pln); > > ... > > m->m_len =3D sizeof(*ah) + (2 * ah->ar_pln) + (2 * ah->ar_hln); > > ( eq arphdr_len(ah) ) >=20 > I think I agree that this is not being checked for properly.... >=20 > Regards, > -- > -Chuck