Buggy debug output from nrpe since 2.1

[Andreas Ericsson]

sean finney wrote:
> hey andreas,
> 
> On Fri, Feb 24, 2006 at 11:38:46AM +0100, Andreas Ericsson wrote:
> 
>>>      seed=(int)time(NULL)*311-getpid()*359+getppid()*383;
>>>
>>>which makes remote attacks on the prng more or less impossible, and local
>>>ones difficult at best.  i'm not sure why you would need to call it
>>>multiple times.
>>>
>>
>>Unfortunately it doesn't. It's possible to determine what a hosts system 
>>clock is set to by either watching ntp traffic to/from the host (with 
>>great accuracy), or by watching arbitrary packets sent from the host 
> 
> 
> but the remote attacker would not know the pid/ppid, correct?
> or did you mean that it doesn't for the local attacker?  it's still
> within the realm of feasibility, though i'd posit it's still a
> modest improvement over a 1-byte seed value.
> 

Ah, sorry for not explaining that. pid and ppid can usually be guessed 
with some accuracy by checking what sort of system it's running 
(preferrably what distribution it is), and then installing or checking 
on a similar system what pid and ppid it would get when booted. Most 
daemons are started at boot-time, so it's usually a fairly close guess, 
and then start trying brute-forcing with guessed_value +- 50.

With enough computer power one could simply guess at pids between 300 
and 600. Usually it's within that range. If SNMP is running with 
read-only "public" enabled (fairly common in corporate networks), the 
pid can usually be determined exactly.

> 
>>True. It would be far better to read a full int. For time-seeding it's 
>>preferrable to xor-fold a timeval-struct into an int, like so:
>>
>>gettimeofday(&tv);
>>sec = (int)(tv.tv_sec ^ tv.tv_sec >> (__WORDSIZE - 32));
>>usec = (int)(tv.tv_usec ^ tv.tv_usec >> (__WORDSIZE - 32));
>>seed = sec ^ usec;
> 
> 
> agreed--that's a nice trick i hadn't heard of.  would it be worth
> putting in some local information as well (getpid()?), or is the
> granularity of the usec field enough that a remote attacker couldn't
> estimate the value?  anyway i'm putting that down in in my notes for
> future reference :)
> 

It could be extended by
pid_seed = getpid() << 16 | getpid();
pid_seed ^= getpid() << 8 ^ (getpid() << 24 & 0x00ff0000);
seed ^= getpid();
seed *= large_random_prime;

If the system does truly implement 32-bit pids the xor-folding of the 
pid can be done away with, although it's not entirely useful since the 
pid can be guessed with reasonable accuracy. Adding both ppid and pid is 
usually less than good, because ppid is usually either 1 or pid - 1.

Note that the code assumes that sizeof(int) == 32 (true on all 32 and 
64-bit archs I've come across).

> 
>>You would have to read an exceedingly large data-set from the random 
>>devices to drain it of entropy. The PRNG (in Linux at least) loops after 
>>2^64 bytes unless the state is continuously and additively seeded (which 
>>it is).
> 
> 
> i don't know enough about random devices, but had recieved complaints
> from a couple folks about the issue of "useless entropy draining".  not
> knowing more, and seeing a problem i did understand (1-byte seeding)
> i went ahead and applied the patch.
> 

Understandable. I had this same view before I read the PRNG-code in the 
kernel (and before I tried my hand at writing a couple of them in some 
daemons). The timeval xor-folding is actually pretty neat. Most kernels 
don't have true microsecond-precision (although they try to pretend they 
do), so the value fluctuates and is hard to determine for both remote 
and local attackers.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642