Date: Thu, 12 Dec 1996 10:31:46 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: cracauer@wavehh.hanse.de Cc: freebsd-security@freeBSD.org Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) Message-ID: <199612120001.KAA29724@genesis.atrad.adelaide.edu.au> In-Reply-To: <9612111329.AA16058@wavehh.hanse.de> from Martin Cracauer at "Dec 11, 96 02:29:42 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Martin Cracauer stands accused of saying: > >> > >>Evil evil evil. Definitely never on a public server; bpf lets you do > >>lots more than just snoop, it makes it possible (easier) to spoof as > >>well. > > As far as I understand, BPF in the kernel is only a risk when someone > gets root rights, not? In that case, if you don't have BPF in the > kernel the person in question could also ftp a new kernel and wait for > the next reboot. Sure; providing they're in a position to do that. A suitably paranoid installation will have measures in place that make it harder (not impossible, obviously) to replace the kernel on a public system. (Think network boot from an inaccessible server, for example.) > What am I overlooking? What makes BPF dangerous as long as noone has > root access to the machine? Point. I think we have to accept that root access will always be available, and look at steps to reduce the damage that can be caused thereby. > And in what way can BPF make spoofing easier? The ability to emit arbitrary network data, subject only to the framing imposed by the transport hardware. > Martin -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612120001.KAA29724>