[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] [Tails-dev] secure and simple network time (hack)



intrigeri:
> Jacob, are you interested in implementing something like our current
> multiple pool -based approach [2], or something else with similar
> security properties?

What version of htpdate are you shipping currently? I've just been
reading the source for htpdate-1.0.4 - is that the right version? I
didn't find an htpdate package in Debian, where is the version Tails
uses? Is it the perl version? Or perhaps htpdate-1.0.5?

My initial thoughts from reading 1.0.4 very quickly are:

  It is written for HTTP services only
    I thought surely that it used TLS, am I auditing the wrong version?
    It is trivial to fingerprint
  It isn't written with defense in depth as a solid programming paradigm
  It looks like it might leak DNS (which in Tails probably won't matter)
  It has a static and easy to fingerprint user-agent:
    'User-Agent: htpdate/"VERSION"'
  If called with long urls/host names:
    the HTTP HEAD request will be truncated
  It has a hand rolled HTTP parser
  It assumes no day light savings time
    Is this absolutely certain?
  It doesn't appear to be optimized for speed
    it creates and initializes data structures while parsing HTTP
  It has an interesting way of doing rtt calculation:
    "rtt * 1e-6"
  It may use adjtime which is kinder and gentler
    it also uses settimeofday()
    htpdate_adjtimex() is a reasonably interesting idea
  It does basically everything setting euid/guid as 0
    it doesn't really privsep
  It runs as root by default
    why not ensure that an unprived user/group is required?
    the code allows for dropping to user:group root:root
  The priv dropping code is not safe:
      641 »·if ( sw_uid ) seteuid( sw_uid );
      642 »·if ( sw_gid ) setegid( sw_gid );
  The programmer is funny:
      750 »·if ( goodtimes )

I didn't see anything obviously exploitable but I did see that if some
things fail to happen... all bets are off about things like not being
root and there are no checks to catch such failures.

All the best,
Jacob
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk