From owner-freebsd-security  Wed Dec 11 12:16:52 1996
Return-Path: <owner-security>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id MAA06016
          for security-outgoing; Wed, 11 Dec 1996 12:16:52 -0800 (PST)
Received: from redmare.com (brian@lin-pm2-016.inetnebr.com [206.222.209.16])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA06010
          for <freebsd-security@freebsd.org>; Wed, 11 Dec 1996 12:16:49 -0800 (PST)
Received: from localhost (brian@localhost) by redmare.com (8.7.4/8.7.3) with SMTP id OAA00457; Wed, 11 Dec 1996 14:12:05 -0600 (CST)
X-Authentication-Warning: redmare.com: brian owned process doing -bs
Date: Wed, 11 Dec 1996 14:12:04 -0600 (CST)
From: Brian Mitchell <brian@saturn.net>
X-Sender: brian@redmare.com
To: Martin Cracauer <cracauer@wavehh.hanse.de>
cc: freebsd-security@freebsd.org
Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system)
In-Reply-To: <9612111329.AA16058@wavehh.hanse.de>
Message-ID: <Pine.BSI.3.95.961211140922.447A-100000@redmare.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-security@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Wed, 11 Dec 1996, Martin Cracauer wrote:

> >>>     What are people's feelings on enabling devices like bpf or snp
> >>> in the kernel on a public server?  Obviously, had I not compiled bpf
> >>> into the shell and Web server kernels, this particular incident would
> >>> never have happened.  However, I like to have access to tcpdump to
> >>> check for things like ping floods, and trafshow to see where bytes are
> >>> being sent.
> >>
> >>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.
> 
> What am I overlooking? What makes BPF dangerous as long as noone has
> root access to the machine?

Not having to reboot or install a new kernel makes things a WHOLE lot
easier. If you notice your machines uptime has changed all of the sudden,
you know something is up.

The goal is to force the intruder to go through as much trouble as
possible in order to sniff on your machine. The more steps he/she has to
go through, the greater chance of being detected.

> 
> And in what way can BPF make spoofing easier?

BPF lets you send and recv raw packet frames.


Brian Mitchell / brian@saturn.net