appropriate security restrictions for untrusted client-side code?

From: Adam Megacz (adam@megacz.com)
Date: 08/22/01 

To: secprog@securityfocus.com
Subject: appropriate security restrictions for untrusted client-side code?
From: Adam Megacz <adam@megacz.com>
Date: 21 Aug 2001 16:07:17 -0700
Message-ID: <m3ofp9au6y.fsf@noneofyourbusiness.com>

I'm working on a new approach to remote-display protocols like X11 and
VNC, and I'd like some input from the Bugtraq community as to whether
my approach presents an unacceptable security hazard.

My approach involves the client (the machine the user is sitting in
front of) downloading a UI written in XML and ECMAscript (similar to
Mozilla's XUL/XPFE), and executing the ECMAscript, which communicates
back to the rest of the application residing on the server using
XML-RPC and SOAP calls. The advantage is that you can easily use this
remote-display tactic on very high-latency networks, unlike VNC/X11.

If you've read about Sun's old NeWS system, you're probably getting a
bit of deja-vu...

The problem is that these UI bundles are totally untrusted. We must
assume that a malicious hacker might write malicious ECMAscript, and
somehow trick a user into visiting a UI bundle containing it. The
client software must protect the user from such attacks.

As the first layer of protection, my ECMAscript interpreter is
carefully designed to allow downloaded ECMAscripts to do only two
things:

1) Render GUI components (windows, buttons, lines, scrollbars, etc)
2) Perform XML-RPC or SOAP calls.

The only concern left is that since this code runs on the client, it
might be used by a malicious hacker to circumvent
firewalls. Thankfully, the ECMAscripts are not allowed to make
arbitrary TCP connections -- only XML-RPC/SOAP connections.

Java solves this problem by only allowing unsigned applets to connect
to the server they came from. Unfortunately, I cannot impose a similar
restriction. Flash4 solved this by only allowing HTTP PUT requests in
a certain, Macromedia-specific format. Flash5 does what Java does.

The current solution I have come up with is this:

1) Partition the 32-bit IPv4 space into three realms:

      Realm A: 10.x.x.x
      Realm B: 192.168.x.x
      Realm C: everything else

2) Any UI bundle may make XML-RPC/SOAP calls to servers in realm C.

3) Any UI bundle may make XML-RPC/SOAP calls to servers in the realm
   it was downloaded from.

The only security hazards I see remaining are:

1) Sites that host private XML-RPC/SOAP services behind their
   firewall, and are using public Internet addresses for their private
   network.

2) Sites that have multihomed machines (straddling both the public
   network and their private network), running private XML-RPC
   services bound to both interfaces, which regulate access to the
   service based on the source IP address of the socket, rather than
   by binding the service only to one interface.

IMHO, (2) is a dubious security measure. Sun Microsystems is the only
corporation I know of that does (1)... is this a common scenario?

So, security experts, do you think that these two hazards constitute a
serious threat? Can you suggest a better solution? I can't take the
same approach that Java does, because UI bundles might need to access
third-party, public XML-RPC/SOAP servers. Requiring UI bundles to be
signed would introduce too much overhead and expense for UI bundle
developers, and kill interest in the idea.

Thanks very much for any advice you can provide.

  - a

PS, if you're curious, the initial implementation of the client
    software is a Java applet, signed by me (Adam Megacz), so it's
    trivially easy for anybody with a web browser (well, maybe not
    &@$@*^ IE6) to access these applications. 

-- 
Males, beware: the Digital Millennium Rape Act, signed into law on
June 30, bans "possession of any item or device that makes it possible
to commit the crime of rape."

                http://www.linuxplanet.com/linuxplanet/opinions/3642/1

Relevant Pages