Charles Sprickman wrote:
>
> On Wed, 4 Apr 2001, Przemyslaw Frasunek wrote:
>
> > /* ntpd remote root exploit / babcia padlina ltd. <[EMAIL PROTECTED]> */
>
> Just a quick note to save others a bit of legwork... If you are running
> ntpd on a machine simply as a client, the following line in /etc/ntp.conf
> should keep people away:
>
> restrict default ignore
>
> Before adding this (I actually had the wrong syntax), the exploit crashed
> ntpd. Afterwords, not a blip, and ntpdate shows that ntpd is not
> answering anything...
One more thing you can do is,
restrict <server IP> noquery
To a server that you are sync'ing from. This protects you from this
exploit, but you can still sync to it. (At least my logic and quick
tests agree with this.)
This is good for the situation where one might be syncing to a public
NTP server (clock.nist.gov, etc.). Since anyone could craft a packet
with that source, you want to deny queries from it, but you can still
sync to it. You can even do,
restrict 127.0.0.1 noquery
To prevent the local exploit on multi-user machines. Your clock will
still sync, but you cannot use 'ntpdc,' 'ntpq,' etc. to check on your
NTP status.
This is not good for your server peering with other hosts or answering
client queries. Besides getting patched software (which is not yet widely
available), using authorization keys should protect you. However, if the
peers or clients are not trusted... Yer hosed.
--
Crist J. Clark Network Security Engineer
[EMAIL PROTECTED] Globalstar, L.P.
(408) 933-4387 FAX: (408) 933-4926
The information contained in this e-mail message is confidential,
intended only for the use of the individual or entity named above. If
the reader of this e-mail is not the intended recipient, or the employee
or agent responsible to deliver it to the intended recipient, you are
hereby notified that any review, dissemination, distribution or copying
of this communication is strictly prohibited. If you have received this
e-mail in error, please contact [EMAIL PROTECTED]
