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

Ben Schwarz bschwarz at EECS.berkeley.EDU
Wed Aug 31 20:49:22 UTC 2005



>> 
>> URL with program traces for this package:
>> https://taverner.cs.berkeley.edu/traces/tmpfile/ntp-4.1.2-0.rc1.2/HTMLtrace/ 
>> 
>> Programs with bugs:
>> ntp-genkeys (ntp_config.c line 2088)
>> 
>> We believe this program re-uses the template from mkstemp(),
>> and suspect there may be a race condition with another system call.
>>


>
> I reviewed this report. The are a large number of erroneous assumptions
> made in this report. I will enumerate the obvious ones:
>
> 1) ntp 4.1.2 is ancient and hasn't been shipped by the NTP project for
> years.
>
> 2) Never use a release candidate (rc1.2) for testing. That's not what
> gets shipped.

We understand that many of the packages we tested from the Redhat 9
Linux distribution may now be out of date, but it was not practical
to maintain current versions for all 800+ packages. Our hope is that
even though these reports are for older versions of code, the
reports will still be applicable. If they aren't, I apologize
and you can ignore these emails.

> 3) The NTP project has no control over what Redhat ships. All such
> problem reports should go first to the vendor.

True, but our hope is the reports will actually get looked at,
and if deemed to be buggy, fixed. It seems better to send out
individual emails to the authors of these packages than to
send Redhat 100 emails which will likely be ignored.

> 4) There is no program named ntp-genkeys in ntp. There IS a program
> named ntp-keygen but this is a command-line-only app that generates keys
> and is never used as a server app.

I downloaded the newest source, and it looks like 'ntp-genkeys' has been
renamed to 'ntp-keygen'.

> 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.

> 6) automatic generation of a bug report should be followed by a manual
> analysis of the problem to ensure that it's accurate. The results above
> show that it was wildly off and raises questions of the methodology used
> to analyze the code.
>
> 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.

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

Ben Schwarz


More information about the security mailing list