Re: [gpsd-dev] Updated docs on NTP segment management

[Gary E. Miller]

Yo Harlan!

On Wed, 18 Feb 2015 06:27:46 +0000
Harlan Stenn <address@hidden> wrote:

> I thought that there was a time when the two sides did some sort of
> "handshake" thru the SHM segment, and that was apparently useful to
> let each side know the other side was paying attention.

Been a while for me, but looking at the code just now I see that
ntpd does write to the shmid.

30 seconds looking, after wine, leads me to believe that some, but not
all the writing is required for a full handshake.

> If there is no reason for this anymore, cool, and that means that it's
> fine for the "consumer" to have read-only access.

I do not see any benefit to breaking the legacy interface.  And huge
benefits to keeping it.
 
> I remember (perhaps correctly) that one of the reasons either ntpd or
> the "provider" of time could open the SHM segment was to avoid startup
> ordering problems.

Yup.

> I can see the bit of danger if the segment is 666, and part of me
> wonders how dangerous that really is.  On the one hand, 666 gives a
> cracker a way to mess with time and make more progress on their
> attack. This is bad.  OTOH, and my lack of infosec paranoia is
> showing, what's the cost/benefit layout of making it that much harder
> for anybody to write to the segment?  How much of a hurdle is it for
> a bad actor to get write access to a 660 SHM segment, or 6xx access?

I feel the cost to going to 660 is trivial, and the benefits huge.

My personal experience is that it is very common for a hacker to mess
with time on a pwned server as soon as he can.  There are many reasons
to do so that I have seen personally, including, but not limited to:
interfereing with logging, causing VPNs to fail or drop to a fail open
mode, breaking DNSEC, allowing files to be replaced leaving no timestamp
traces, confusing cron jobs, etc.

Time and again hackers have turned crazy theoretical attacks into
peoples real exploits.  Just the appearance that ntpd may have
exploitable holes will cause people to look for alternatives.

Crazy not to make a small fix that seriously narrows the hole.

> How difficult would it be (I'm not saying it's a good idea) to write a
> program that monitors the SHM segment and alerts when it seems that
> something nefarious is going on?

Impossible.  A subtle time shift persisting for hours would soon
cause havok with IPSEC, VPNs, and DNSSEC.  Just the DoS potential
makes me cringe.

>  It seems to me that such a program
> would be a big waste of time/effort, but hey, if you're at tangible
> risk for somebody messing with *any* malicious writing to the SHM time
> segment, it might be worth it.

A lot of work for little gain, when a fix is trivial.
 
> And I still need to get ESR's comments added to:
> 
>  http://support.ntp.org/bin/view/Dev/RefclockShmV2

I'll add my $0.02 now.  The mode bits are the path to madness.  It confuses
the user and encourages bad decision making by him.  Just do it one
way and do iit right, or figure out an auto config scheme.

And this statement is nonsensical:

"Using a fixed-point format for the fraction of seconds. This oblivates
the usec vs. nsec coding the driver uses currently. (It's a bit harder
on the clients. But it might keep the server more stable.)"

The current format IS a fixed point format!  The only change needed is
to only not allow uSec and only allow nSec.  Or go further in future
proofing and go to pSec. 

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
        address@hidden  Tel:+1(541)382-8588