[ntp:security] Re: Concerning a possible bug in the 'ntp' package

Danny Mayer mayer at ntp.isc.org
Thu Sep 1 21:28:55 UTC 2005


Ben Schwarz wrote:
> 
>> 5) ntp_config.c is not used by ntp-keygen, but is a part of ntpd which
>> is a server app.
> 
> 
> True, the dependencies were changed between the current version and
> the one we tested.
> 

That may be true, but ntp_config.c is only part of ntpd and nowhere else 
  so your methodology is pointing to the wrong areas. It begs the 
question as to what else is wrong.

>> 7) You finding of mkstemp() is not followed up by an analysis of how and
>> why it is used. Just because it's being used does not indicate a
>> problem. Please send an analysis of why it is incorrect to use this
>> function in the context of the application and function calling it.
> 
> 
> I looked over the newest source briefly, and the code in question
> is still in ntp_config.c:
> 
> 
> #else
>         (void) mktemp(res_file);
>         res_fp = fopen(res_file, "w");
> #endif
> 
>                        ...
> 
> 
>     (void)fprintf(res_fp, "%s %d %d %d %d %d %d %u %s\n", name,
>         mode, version, minpoll, maxpoll, flags, ttl, keyid, keystr);
> 
> The possible problem is instead of opening /tmp/ntpXXXXXXX
> for writing, which is what the program tries to do, it may actually
> be opening another sensitive file. For instance, an attacker
> might predict the name of the tempfile and create
> a symlink before ntpd opens it, and then cause log information
> to be written to the file. This could be potentially dangerous
> especially if an attacker can influence the contents of this
> log information.
> 

Well in this instance, ntpd is opening the file for write, thereby 
overwriting any original contents so it does not matter what an attacker 
may have written into it. In this case it happens to be for a DNS 
lookup. The attacker is welcome to the information if he can get it 
since then he'd have to mount a DNS attack which is a different kind of 
challenge. So you'd end up with the attacker having to deal with two 
attacks instead of one. Is it a risk? Maybe, but it would be pretty 
pointless to attack that file.

> I don't know enough about ntpd to say whether or not this
> is truly a bug. If it's not, we apologize.
> 

It's better than saying nothing. We are always looking for help to 
analyze the code so that we can do better.

Danny
> Ben Schwarz
> 


More information about the security mailing list