From Martin.Kraemer@Fujitsu-Siemens.com  Mon Mar 11 04:38:24 2002
Return-Path: <Martin.Kraemer@Fujitsu-Siemens.com>
Received: from naxos.pdb.sbs.de (naxos.pdb.sbs.de [192.109.3.5])
	by hub.freebsd.org (Postfix) with ESMTP id 627C237B402
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 11 Mar 2002 04:38:23 -0800 (PST)
Received: from trolli.pdb.fsc.net (ThisAddressDoesNotExist [172.25.97.20] (may be forged))
	by naxos.pdb.sbs.de (8.11.2/8.11.2) with ESMTP id g2BCcMt01195
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 11 Mar 2002 13:38:22 +0100
Received: from deejai2.mch.fsc.net (deejai2.mch.fsc.net [172.25.124.236])
	by trolli.pdb.fsc.net (8.9.3/8.9.3) with ESMTP id NAA13420;
	Mon, 11 Mar 2002 13:38:20 +0100
Received: (from martin@localhost)
	by deejai2.mch.fsc.net (8.11.6/8.11.6) id g2BCcKD49193;
	Mon, 11 Mar 2002 13:38:20 +0100 (CET)
	(envelope-from martin)
Message-Id: <200203111238.g2BCcKD49193@deejai2.mch.fsc.net>
Date: Mon, 11 Mar 2002 13:38:20 +0100 (CET)
From: <martin.kraemer@Fujitsu-Siemens.com>
Reply-To: <martin.kraemer@Fujitsu-Siemens.com>
To: FreeBSD-gnats-submit@freebsd.org,
	martin.kraemer@Fujitsu-Siemens.com
Cc:
Subject: [SECURITY] Suboptimal auditing possibilities for network access
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         35774
>Category:       kern
>Synopsis:       [libutil] logwtmp: Suboptimal auditing possibilities for network access
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Mon Mar 11 04:40:01 PST 2002
>Closed-Date:    
>Last-Modified:  Mon Oct 24 00:31:41 GMT 2005
>Originator:     
>Release:        FreeBSD 4.5-STABLE i386
>Organization:
Fujitsu-Siemens
>Environment:
System: FreeBSD deejai2.mch.fsc.net 4.5-STABLE FreeBSD 4.5-STABLE #6: Thu Jan 31 21:40:04 CET 2002 martin@deejai2.mch.fsc.net:/usr/src/sys/compile/DEEJAI4B i386


>Description:
	When logging in from a remote machine, the IP address of which
	is not in the DNS, a utmp/wtmp entry is created with a
	ut_host/ll_host hostname of the IPv4 address preceded by ::ffff:
	(IPv6 syntax for mapped addresses). Because of the very small
	size of the hostname field (historic: UT_HOSTSIZE 16), the IP address
	gets truncated. The resulting "last" output...
           (user   ttyp5    ::ffff:172.25.18 Mon Mar 11 09:20   still logged in)
        hides the most important information (from WHICH machine in the
	subnet 172.25.18*.* did the login occur?).

>How-To-Repeat:
	log in from a remote machine, the IP address of which is not in DNS.

>Fix:
	(short-term fix) truncate a numeric IP address on the left rather
	than on the right. That does not really help with true IPv6
	addresses, but it greatly improves the usefulness when IPv4-mapped
	IPv6 addresses are used, which is still the majority of cases IMHO.
	For such a login, 16 bytes would be enough to store
	":<ipv4>" which unambiguously describes the remote host, as it
	can only be "::<ipv4>" (compatible) or "::ffff:<ipv4>" (mapped),
	because all other IPv6 addresses would not be rewritten to
	"<something>:<ipv4>".

	(long-term fix) make the UT_HOSTSIZE 45 (there exists a constant for
	sizeof("ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255" somewhere in IPv6,
	but I forgot its name)
>Release-Note:
>Audit-Trail:
>Unformatted:
