From owner-freebsd-hackers Tue Oct 27 00:30:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA25754 for freebsd-hackers-outgoing; Tue, 27 Oct 1998 00:30:18 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id AAA25749 for ; Tue, 27 Oct 1998 00:30:14 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id HAA03642; Tue, 27 Oct 1998 07:25:27 +0100 From: Luigi Rizzo Message-Id: <199810270625.HAA03642@labinfo.iet.unipi.it> Subject: Potential problem with network drivers in promisc mode To: hackers@FreeBSD.ORG Date: Tue, 27 Oct 1998 07:25:26 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, just after my yesterday patch to if_ed.c i realised that there might be a severe problem with many network drivers. The problem is as follows: when the interface goes in promisc mode (e.g. because one is using bpf), certain drivers (I have not cheched how many, but for sure the "ed" driver does this) are configured to accept also RUNT pkts and those with bad CRCs. This means that very short packets may make it up to the point where the card prepares for ether_input(), and the usual action there is something like ms->m_pkthdr.len -= sizeof(struct ether_header); etc.. If m_pkthdr.len < 14, this results in a very large value going into m_pkthdr.len (u_short), with all sort of interesting consequences. Before you comment that packets are checked for a matching ether dst address, remember that multicast packets are passed up unconditionally, and because the multicast bit is the first one in the packet, they are more at risk than others. Possible countermeasures: * disable RUNT reception when in promisc mode (I am not sure if this is a standard bpf option, or just happens to be implemented in the "ed" driver for convenience); * use m_adj() to remove the ethernet header from packet buffers, because it does the appropriate length checks; * implement more accurate checks in all drivers before removing the packet headers. If it is allowed, i'd probably go for the first approach, because the code paths between bpf_mtap() and ether_input() can be a bit convoluted. I will try to come up with a more precise report on critical drivers on -stable and -current. cheers luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message