Firefox3.1/DNS Prefetching Security Review

From MozillaWiki
Jump to: navigation, search

Overview

The goal is improved latency response in situations using DNS by starting the high latency DNS transaction earlier than than normal. Because DNS is low bandwidth it is sometimes advantageous to start these lookups speculatively in order to overlap them with idle time.

early lookups apply to anchor href attributes, a specific dns-prefetch type of link element, and any queued http requests.


Security and Privacy

  • Is this feature a security feature? -- No.
  • What potential security issues in your feature have you already considered and addressed? -- lookups require acquiesence of both client and server. Client via pref (default on for http, default off for https contexts), server via http header or meta element (default on). Defaulting to off in an SSL context is part of the security considerations.
  • Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing? -- I do not believe so
  • Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project. -- the primary issue is information leakage, addressed as mentioned above. The Kaminsky DNS issue is triggered by forcing a large number of lookups, typically via inclusion of a run of img, css, or javascript tags. WRT images the impact is unchanged modulo the fact that they may happen a little earlier. The technique can now theoretically be expanded to a large run of hrefs as well. I am not especially concerned about this as it does not extend the vulnerability in any new way - just to a new context for which there are many fundamental ones already. Furthermore, because the prefetch DNS code queues via a fixed size FIFO and drops overruns this would be a less reliable exploit than already avaialable, and intrinsic, paths.
  • How are transitions in/out of Private Browsing mode handled? -- no impact as there is no audit trail.

Exported APIs

largely NA, except for

  • Does it change any existing interfaces? -- the nsIDNSListener idl accepts two new flags for setting priorities on DNS lookups. Calls not using these flags run at the highest priority. (previously there was only one priority)

Module interactions

  • What other modules are used (REQUIRES in the makefile, interfaces)? -- nsIDNSListener, nsIWebProgressListener (used for determining idle browser)

Data

  • What data is read or parsed by this feature? -- hrefs, link elements, http headers
  • What is the output of this feature? -- a populated dns cache. The calls are all fire and forget
  • What storage formats are used? -- the existing DNS cache is unmodified. A fixed size in memory fifo is introduced for queueing until pageload is complete, and the DNS service queue is divided into three (high, med, low).

Reliability

  • What failure modes or decision points are presented to the user? -- none
  • Can its files be corrupted by failures? Does it clean up any locks/files after crashes? -- n/a

Configuration

  • Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables? -- only about config, see the blog post for referneces.
  • Are there build options for developers? [#ifdefs, ac_add_options, etc.] -- no
  • What ranges for the tunable are appropriate? How are they determined? -- boolean, defaults are set for security and efficiency
  • What are its on-going maintenance requirements (e.g. Web links, perishable data files)? -- none. Caches are all ram based.

Relationships to other projects

Are there related projects in the community? -- not that I am aware of. Initiated on my end by bug asa filed and my interest in mobile network performance.

Review comments

Retrieved from "https://wiki.mozilla.org/index.php?title=Firefox3.1/DNS_Prefetching_Security_Review&oldid=119634"