[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 26 Sep 2012 12:34:09 +0200
From: Fiedler Roman <Roman.Fiedler@....ac.at>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Subject: RFC: ntp behavior with spoofed source IPs
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@....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.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
