RFC: ntp behavior with spoofed source IPs

[Fiedler Roman <Roman.Fiedler () ait ac at>]

Hi,

While changing from openntpd (Ubuntu/universe) to ntp (main), a short evaluation of ntp configuration options was 
performed. Older ntp-versions on Ubuntu lucid do not support to disable ntp listening on all interfaces, even when 
using it just to synchronize with servers, but machine not delivering NTP services itself (see [1]). Newer versions 
come with a default configuration listening on all interfaces ([2]).

I would like to hear comments on following scenarios using NTP requests with spoofed source IP, especially regarding 
the fact, that receiving of such packets could be considered to a higher degree a problem of the host base setup 
(rp_filter, firewalling) and not ntp itself, even for embedded devices (WLAN router).


Example configuration: A device between LAN and internet (firewall but might be also some embedded WLAN router with NAT 
support) is running a ntp server. The configuration uses "restrict" statements to restrict querying and modification to 
LAN side only. External interface is just used to query upstream servers. Following scenarios come to my mind with the 
interfaces default configuration, I'd like to know if they are possible and if yes relevant:

* Processing of spoofed requests (I do not known, what permission "modify" would allow, but might be annoying): If host 
TCP-stack will deliver it, ntp will process it.

* Flooding host with NTP-replies: If NTP server responds to faked request on external interface, it will reply to the 
internal interface. Since there is no amplification, this might be problematic only for slow, e.g. embedded devices. 
Use of broadcast-address for reply was not tested.

* Directing UDP response to any device IP/port behind firewall: It might be interesting if SIP-phones, embedded 
DNS/DHCP servers et al. survive this, but could be counted vulnerability of device only and no problem of ntp. I have 
not tested, if NTP reply could be mapped to any other UDP protocol.

* Building of NTP-based tunnels: Use NTP packets forwarded/mangled via server. If just some bits from request to 
response are preserved, information can be transmitted.

* Subversion of UDP-packet filtering (minor, only NTP-port can be exposed): Since UDP-filtering does not know state in 
same way than TCP, any allowed UDP packet may establish connection tracking entry. Scenario: firewall can send UDP via 
one interface but input not allowed via that if. By sending an NTP-request with spoofed source IP/port, ntp will send 
request (which is allowed), thus punching hole into firewall from that client to NTP daemon port.

* Detection of allowed NTP IPs (hypothetical): If there is any useable feedback in form of packet IDs or timing that 
ntp server received response, sending NTP requests could be used to detect which hosts are up behind on the other 
interfaces of the NTP-machine. Example: use different traffic to NTP-machine (e.g. ICMP) to observe timing or 
IP-packet-ID-use, then send rogue NTP-packets: if NTP-machine sends NTP-response (ARP-query OK) to spoofed IP and 
receives ICMP-unreachable, this may change IDs/timing and show, that machine is up and perhaps if firewalled or not.


Any opinions?

Thanks,
Roman

[1] http://archive.ntp.org/ntp4/ChangeLog-stable  Change adding support for listening only on defined interfaces: 
(4.2.5p212) 2009/09/15 Released by Harlan Stenn: [Bug 983] add interface [listen | ignore | drop] ... directive.
[2] https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/858493


DI Roman Fiedler
Engineer
Safety & Security Department
Assistive Healthcare Information Technology

AIT Austrian Institute of Technology GmbH
Reininghausstrae 13/1  |  8020 Graz  |  Austria
T +43(0) 50550 2957  |  M +43(0) 664 8561599  |  F +43(0) 50550 2950
roman.fiedler () ait ac at | http://www.ait.ac.at/

FN: 115980 i HG Wien  |  UID: ATU14703506
This email and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain 
legally privileged and/or confidential information. If you are not the intended recipient, please notify the sender by 
return e-mail or by telephone and delete this message from your system and any printout thereof. Any unauthorized use, 
reproduction, or dissemination of this message is strictly prohibited. Please note that e-mails are susceptible to 
change. AIT Austrian Institute of Technology GmbH shall not be liable for the improper or incomplete transmission of 
the information contained in this communication, nor shall it be liable for any delay in its receipt.