From owner-freebsd-net@FreeBSD.ORG Tue Dec 7 21:55:02 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 6DC1F10656A3 for ; Tue, 7 Dec 2010 21:55:02 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout028.mac.com (asmtpout028.mac.com [17.148.16.103]) by mx1.freebsd.org (Postfix) with ESMTP id 506728FC19 for ; Tue, 7 Dec 2010 21:55:02 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp028.mac.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 64bit)) with ESMTPSA id <0LD200CT9SPE3C70@asmtp028.mac.com> for freebsd-net@freebsd.org; Tue, 07 Dec 2010 12:53:40 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1010190000 definitions=main-1012070159 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-12-07_10:2010-12-07, 2010-12-07, 1970-01-01 signatures=0 From: Chuck Swiger In-reply-to: <4cfe88b6.1cedd80a.33f5.119d@mx.google.com> Date: Tue, 07 Dec 2010 12:53:38 -0800 Message-id: References: <4cfe88b6.1cedd80a.33f5.119d@mx.google.com> To: Rozhuk.IM@gmail.com X-Mailer: Apple Mail (2.1082) 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 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 21:55:02 -0000 Hi, Rozhuk-- 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); 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: "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. ?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]" > check in in_arpinput: > if (ifp->if_addrlen != 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!!!! 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: if (ifp->if_addrlen != 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; } > 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 = 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 = sizeof(*ah) + (2 * ah->ar_pln) + (2 * ah->ar_hln); > ( eq arphdr_len(ah) ) I think I agree that this is not being checked for properly.... Regards, -- -Chuck