From owner-freebsd-security  Sun Apr 27 19:36:30 1997
Return-Path: <owner-security>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id TAA14035
          for security-outgoing; Sun, 27 Apr 1997 19:36:30 -0700 (PDT)
Received: from utopia.nh.ultranet.com (jbowie@this.wanker.is.a.teensysop.org [207.41.158.32])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA14030
          for <freebsd-security@freebsd.org>; Sun, 27 Apr 1997 19:36:23 -0700 (PDT)
Received: from localhost (jbowie@localhost)
	by utopia.nh.ultranet.com (8.8.5/8.8.5) with SMTP id WAA00427;
	Sun, 27 Apr 1997 22:35:49 GMT
X-Authentication-Warning: utopia.nh.ultranet.com: jbowie owned process doing -bs
Date: Sun, 27 Apr 1997 22:35:48 +0000 (GMT)
From: The Code Warrior  <jbowie@bsdnet.org>
X-Sender: jbowie@utopia.nh.ultranet.com
To: Warner Losh <imp@village.org>
cc: Dmitry Valdov <dv@kis.ru>, freebsd-security@freebsd.org
Subject: Re: SNI-12: BIND Vulnerabilities and Solutions (fwd) 
In-Reply-To: <E0wLexe-0006zz-00@rover.village.org>
Message-ID: <Pine.BSF.3.96.970427222630.417B-100000@utopia.nh.ultranet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-security@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk



On Sun, 27 Apr 1997, Warner Losh wrote:

> I have.  There are some, but not a lot.  I've been trying to plug them
> as I find them.  Most of them have long ago been plugged.
	As have I.
> 
> And the name doesn't need to be spoofed either.  You just need control
> over the in-addr.arpa domain for the IP numbers that you claim to be
> coming from for this attack to work.

I'm well aware of this just commented on it due to the nature of the
thread, wouldn't want to give any "impressionable" young children any
ideas. :) As always I thank you for your imput.  Maybe coming up with a
kernel mod, using a new transport medium might be the answer.  I mean if
you reinvent the packet medium I suppose you could eliminate this sort of
problem with better packet handling on the localhosts and / or routers.
Regardless though, It seems to me that you could just come up with a
version of named in which the server that the request is going to makes a
secondary request to an undisclosed ns verifying the authenticity of
the incoming packet.  Any thoughts?

-Jon Bowie
SysAdmin / Consulting / TeenSysop
		603-436-5698
jobe@insomnia.org	jbowie@taco.net
jbowie@teensysop.org    jbowie@eliteness.org
                jbowie@bsdnet.org