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