Great Circle Associates Firewalls
(April 1995)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: NTP and SATAN
From: Dave Katz <dkatz @ cisco . com>
Date: Thu, 13 Apr 1995 10:05:11 -0700
To: romig @ net . ohio-state . edu
Cc: cisco @ spot . colorado . edu, firewalls @ GreatCircle . COM
In-reply-to: Steve Romig's message of Thu, 13 Apr 1995 12:36:44 -0400 <199504131636 . MAA12266 @ bedbugs . net . ohio-state . edu>

Yes, the problem stems from the NTP shim to DTS (which really has no
business calling itself NTP, as it doesn't implement the protocol in
RFC1305--if it did, this wouldn't happen).

Feb 7, 2036 is an alias for Jan 1, 1900 (the point at which the NTP
timestamp rolls over).

   Date: Thu, 13 Apr 1995 12:36:44 -0400
   From: Steve Romig <romig @
 net .
 ohio-state .
 edu>

   >There have been some rumors making the rounds on the net recently that
   >the Network Time Protocol, NTP, has a vulnerability to one of the
   >tests that SATAN performs.  The rumor states that one of SATAN's tests
   >will cause the time to suddenly shift by several years.

   That rumor probably stems from HPs Satan announcement (see below),
   which mentioned that DCE time services that get their time through an
   NTP could be affected by Satan scans (in the cases I saw, the date was
   always set to Feb 7, 2036, yeeha).

   >Real NTP daemons, including cisco's implementation and the freely available
   >Unix implementation "xntpd" do *not* have this vulnerability, due to extensive
   >format checking of incoming packets, and due to the statistical selection
   >mechanisms used (a packet with wildly incorrect time would be discarded
   >as an outlier).

   We only encountered problems with DCE cells that got their time
   through some DCE/NTP client.  We couldn't reproduce this sort of
   problem on servers running ntpd and xntpd.

   Here's excerpts from the HP announcement:

   Document Id: [HPSBUX9504-026]
   Date Loaded: [04-04-95]

   Description: Preparing Your HP-UX System for SATAN
   [...]
   ISSUE #3: NTP should not be used as the time source for HP-DCE/9000
	     until further notice.
   [...]
   K. NTP vulnerabilities and HP-DCE/9000

      1. The Problem

      When Satan is run to analyze the vulnerabilities of an HP-UX system
      whose time is synchronized by NTP, the time of the system can be set
      forward by several years.  This vulnerability can affect DCE cells that
      use NTP as a time source, either with the dts_ntp_provider or with the
      dts_null_provider running on an NTP client.  In this event, the Cell
      Directory Service (CDS) can become locked at this future date,
      rendering the DCE cell inoperable.

      2. Fixing the Problem

      Hewlett-Packard recommends you configure your HP-DCE/9000 systems to
      use either the dts_spectracom_provider or to use the dts_null_provider
      without NTP. Further information on how to use NTP in conjunction
      with DTS is available from your HP support contact.




References:
Indexed By Date Previous: Re: NTP and SATAN
From: Steve Romig <romig @ net . ohio-state . edu>
Next: NTP
From: stan @ dot . ca . gov ( )
Indexed By Thread Previous: Re: NTP and SATAN
From: Steve Romig <romig @ net . ohio-state . edu>
Next: Re: NTP and SATAN
From: F . Wetzels @ amc . uva . nl (Frank Wetzels)

Google
 
Search Internet Search www.greatcircle.com