- From: Thomas Roessler <tlr@w3.org>
- Date: Fri, 18 Jan 2008 18:07:13 +0100
- To: public-appformats@w3.org
interesting... -- Thomas Roessler, W3C <tlr@w3.org> ----- Forwarded message from Tavis Ormandy <taviso@sdf.lonestar.org> ----- From: Tavis Ormandy <taviso@sdf.lonestar.org> To: bugtraq@securityfocus.com Date: Fri, 18 Jan 2008 16:40:58 +0000 Subject: common dns misconfiguration can lead to "same site" scripting List-Id: <bugtraq.list-id.securityfocus.com> X-Spam-Level: Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.6 Hello, I'd like to document what appears to be a common named misconfiguration that can result in a minor security issue with web applications. It's a common and sensible practice to install records of the form "localhost. IN A 127.0.0.1" into nameserver configurations, bizarrely however, administrators often mistakenly drop the trailing dot, introducing an interesting variation of Cross-Site Scripting (XSS) I call Same-Site Scripting. The missing dot indicates that the record is not fully qualified, and thus queries of the form "localhost.example.com" are resolved. While superficially this may appear to be harmless, it does in fact allow an attacker to cheat the RFC2109 (HTTP State Management Mechanism) same origin restrictions, and therefore hijack state management data. The result of this minor misconfiguration is that it is impossible to access sites in affected domains securely from multi-user systems. The attack is trivial, for example, from a shared UNIX system, an attacker listens on an unprivileged port[0] and then uses a typical XSS attack vector (e.g. <img src=...> in an html email) to lure a victim into requesting http://localhost.example.com:1024/example.gif, logging the request. The request will include the RFC2109 Cookie header, which could then be used to steal credentials or interact with the affected service as if they were the victim. Another attack vector exists where a victim connects to a site from (or via) a machine that hosts another website, any XSS-like flaw or reflective web service on the hosted website can therefore be exploited in the context of the misconfigured domain. This would also affect users who connect via a shared caching http proxy machine, that also hosts an http daemon. An excellent example of exploiting this misconfiguration was discovered by my colleague, Will Drewry, in CUPS. http://localhost.example.com:631/jobs/?job_id=&job_printer_name=Click%20Me&job_printer_uri=javascript:alert(document.cookie) This misconfiguration allows any of the domains affected to be vulnerable to this issue via CUPS (installed on most UNIX, Linux, Mac systems). The bug requires a click to be exploited, but illustrates the problem nicely. Initial analysis shows that some of the worlds most popular websites are affected. The administrators of the example domains listed below were sent a draft of this email 7 days before release, so some (or all) may have been corrected, these examples are simply intended to demonstrate how widespread this problem is. localhost.microsoft.com has address 127.0.0.1 localhost.ebay.com has address 127.0.0.1 localhost.yahoo.com has address 127.0.0.1 localhost.fbi.gov has address 127.0.0.1 localhost.citibank.com has address 127.0.0.1 localhost.cisco.com has address 127.0.0.1 etc. Recommendations It is advised that non-FQ localhost entries be removed from nameserver configurations for domains that host websites that rely on HTTP state management. Of course, any other records that return RFC1918 or RFC3330 reserved addresses should also be carefully examined for similar issues. Additionally, those practising blackhole routing via dns to mitigate denial of service attacks against specific hostnames should avoid the temptation to resolve targets to 127.0.0.1 or similar addresses for sensitive domains. [0] It appears to be a common mistake to confuse the JavaScript SOP and the HTTP originating host definition for Cookies with regard to port number. The JavaScript SOP (http://www.mozilla.org/projects/security/components/same-origin.html) does include the port number, where as RFC2109 (http://www.ietf.org/rfc/rfc2109.txt) explicitly does not. This behaviour is arguably incorrect, making it impossible to securely host a website from a multi-user machine, but nevertheless is the case, and is implemented by most major browsers. Thanks to Will Drewry, Robert Swiecki, and Filipe Almeida for their valuable assistance researching this topic. -- ------------------------------------- taviso@sdf.lonestar.org | finger me for my gpg key. ------------------------------------------------------- ----- End forwarded message -----
Received on Friday, 18 January 2008 17:07:22 UTC