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
