fun with the web and security
Here's a fun way to exploit security holes via the web: http://www.cs.berkeley.edu/~daw/js1.html A rough representation of its contents follow. Whee! The web is awfully convenient for exploiting security bugs.... The following URL contacts your sendmail SMTP server and attempts to exploit an old, well-known security hole, trying to gain root access. Click _here_ to try it. As it stands, clicking on the URL above does not do anything harmful to your machine-- but it could! (This is a test of the emergency broadcast system. This is only a test.) ______________ We can get you to send arbitrary text, to an arbitrary port on an arbitrary host, from your machine. (If you are inside a firewall, we can thereby send arbitrary text to any internal machine by getting you to click on the link above.) The technique is simple: we list the host and port in a gopher URL, and encode the text to be sent in the path. For instance, a successful exploit of the hole could leave a backdoor root shell, and inform us via a pseudonym at an anonymous remailer. The exploit could be hidden by use of the JavaScript "width=1,height=1" techniques pioneered at John LoVerso's _JavaScript security hole page_; then you wouldn't even know when you'd been attacked. The exploit could be forced on you via many standard tricks: the Redirect: or META-EQUIV Refresh: or JavaScript mechanisms work fine, for instance. This is most dangerous when you are behind a firewall. Typically, there will be many machines inside a firewall which run insecure software. Normally, that would be safe, since the firewall prevents an outsider from connecting to the unsafe sendmail servers inside-- yet the example URL above allows outsiders like us to exploit security holes on the inside of your firewall. Nothing stops us from putting the IP address of a vulnerable machine inside your firewall in the URL above, and waiting for you to click on it: the firewall doesn't prevent connections from you to the internal vulnerable machine, and thus can't stop this attack. Using JavaScript, we don't even have to wait for you to click on anything. Furthermore, a JavaScript program could systematically and invisibly try all the machines inside your firewall. We could have used many other well-known security holes: there's nothing special about this particular sendmail bug (except that it was convenient for us to implement). ______________ Be afraid. Be very afraid. -- Ian Goldberg and David Wagner.
This has been discussed a lot in the URI working groups since around 92. I think it's actually documented in the RFC Simon
Here's a fun way to exploit security holes via the web: http://www.cs.berkeley.edu/~daw/js1.html A rough representation of its contents follow.
Whee! The web is awfully convenient for exploiting security bugs....
The following URL contacts your sendmail SMTP server and attempts to exploit an old, well-known security hole, trying to gain root access. Click _here_ to try it.
As it stands, clicking on the URL above does not do anything harmful to your machine-- but it could! (This is a test of the emergency broadcast system. This is only a test.) ______________
We can get you to send arbitrary text, to an arbitrary port on an arbitrary host, from your machine. (If you are inside a firewall, we can thereby send arbitrary text to any internal machine by getting you to click on the link above.) The technique is simple: we list the host and port in a gopher URL, and encode the text to be sent in the path.
For instance, a successful exploit of the hole could leave a backdoor root shell, and inform us via a pseudonym at an anonymous remailer.
The exploit could be hidden by use of the JavaScript "width=1,height=1" techniques pioneered at John LoVerso's _JavaScript security hole page_; then you wouldn't even know when you'd been attacked.
The exploit could be forced on you via many standard tricks: the Redirect: or META-EQUIV Refresh: or JavaScript mechanisms work fine, for instance.
This is most dangerous when you are behind a firewall. Typically, there will be many machines inside a firewall which run insecure software. Normally, that would be safe, since the firewall prevents an outsider from connecting to the unsafe sendmail servers inside-- yet the example URL above allows outsiders like us to exploit security holes on the inside of your firewall. Nothing stops us from putting the IP address of a vulnerable machine inside your firewall in the URL above, and waiting for you to click on it: the firewall doesn't prevent connections from you to the internal vulnerable machine, and thus can't stop this attack. Using JavaScript, we don't even have to wait for you to click on anything. Furthermore, a JavaScript program could systematically and invisibly try all the machines inside your firewall.
We could have used many other well-known security holes: there's nothing special about this particular sendmail bug (except that it was convenient for us to implement). ______________
Be afraid. Be very afraid. -- Ian Goldberg and David Wagner.
--- They say in online country So which side are you on boys There is no middle way Which side are you on You'll either be a Usenet man Which side are you on boys Or a thug for the CDA Which side are you on? National Union of Computer Operatives; Hackers, local 37 APL-CPIO
This has been discussed a lot in the URI working groups since around 92. I think it's actually documented in the RFC
Really? Could you give me any pointers to read up on? I searched extensively at www.w3.org, and I did find the following excerpt in RFC1738 under Security Considerations: A URL-related security threat is that it is sometimes possible to construct a URL such that an attempt to perform a harmless idempotent operation such as the retrieval of the object will in fact cause a possibly damaging remote operation to occur. The unsafe URL is typically constructed by specifying a port number other than that reserved for the network protocol in question. The client unwittingly contacts a server which is in fact running a different protocol. The content of the URL contains instructions which when interpreted according to this other protocol cause an unexpected operation. An example has been the use of gopher URLs to cause a rude message to be sent via a SMTP server. Caution should be used when using any URL which specifies a port number other than the default for the protocol, especially when it is a number within the reserved space. I don't think this addresses exactly the same thing I was talking about-- I'm talking about a way to exploit arbitrary security holes, even against machines (normally) protected inside a firewall. It is interesting to see the caution above, though-- I was unaware of its existence. I also found the following in the same RFC: Care should be taken when URLs contain embedded encoded delimiters for a given protocol (for example, CR and LF characters for telnet protocols) that these are not unencoded before transmission. This would violate the protocol but could be used to simulate an extra operation or parameter, again causing an unexpected and possible harmful remote operation to be performed. which Netscape violates in the gopher: protocol. However, I also note that the same RFC specifically addresses the gopher protocol in Section 3.4.9, and concludes that the client needs to decode embedded %-escaped newlines and send them as true newlines to the gopher server; thus, the RFC appears to be self-contradictory, as far as I can tell. Netscape follows Section 3.4.9. Furthermore, I should point out that even if clients were changed so that they didn't unencode %-escaped newlines in URLs for the gopher: protocol, I believe sendmail bugs could still be exploited-- Ian has discovered a way to send arbitrary email messages with arbitrary headers to arbitrary hosts by abusing the mailto: URL, which should be sufficient to exploit several sendmail bugs behind a firewall. So was that what you were talking about, or was there more discussion?
On Wed, 28 Feb 1996, David A Wagner wrote:
This has been discussed a lot in the URI working groups since around 92. I think it's actually documented in the RFC
Really? Could you give me any pointers to read up on?
I searched extensively at www.w3.org, and I did find the following excerpt in RFC1738 under Security Considerations:
I don't think this addresses exactly the same thing I was talking about-- I'm talking about a way to exploit arbitrary security holes, even against machines (normally) protected inside a firewall.
could still be exploited-- Ian has discovered a way to send arbitrary email messages with arbitrary headers to arbitrary hosts by abusing the mailto: URL, which should be sufficient to exploit several sendmail
So was that what you were talking about, or was there more discussion?
This is roughly what was talked about; I seem to remember DEBUG being discussed with this (it's the one that takes the least typing). The URI WG often got so tedious and repetetitive I may have been unconscious and dreaming it :-) Simon --- They say in online country So which side are you on boys There is no middle way Which side are you on You'll either be a Usenet man Which side are you on boys Or a thug for the CDA Which side are you on? National Union of Computer Operatives; Hackers, local 37 APL-CPIO
participants (2)
-
daw＠orodruin.CS.Berkeley.EDU -
Simon Spero