Re: SVG1.2 and network sockets was: SVG1.2 and web applications

Thomas DeWeese wrote:
> Robin Berjon wrote:
>> Providing the ability to open sockets does not open such security 
>> issues as Randy or you describe. It takes opening a more than that to 
>> get something as insecure as Outlook.
> 
>     Don't be so sure.  It is quite common for socket requests from
> a 'secure' set of hosts to be treated differently from socket
> requests from other 'outside' hosts.  If an SVG application can open
> arbitrary sockets from a machine it means that among other
> possabilities the machine can almost certainly be used as an
> 'open mail relay' (just open a connection to port 25 on the
> associated mail server), downloading of internal corperate web
> sites, many environments would allow rlogin from a 'trusted' host
> given an appropriate login with no password.  Perhaps these are
> not as bad as 'Outlook' but they would be more than enough to
> ban SVG from every corporate network that had an IT department
> that knew anything.

Yes. Sorry if I was unclear, I didn't mean to say that there were *no* security 
issues, just trying to point out that it didn't lend itself to Outlook-style 
trojans and such.

I am quite concerned in getting this "right", which is why I try to claims that 
I believe are false. The feature-set that is made available by a simple socket 
API is such that imho it's well-worth considering it very seriously as it could 
bring many new users to SVG. That's why I asked for input on this.

>     The Java Sandbox permissions are the way they are for very good
> reasons (connect back only to the server you came from) - lots of people
> have looked at them and I believe they have been made as permissive as
> possible without involving a knowlegable person (and often the person
> at the computer can't be counted on to be  knowlegable - remeber most
> Outlook trogan horses/viruses require user action! :)

I'll grant eagerly you that "prompt the user to accept" doesn't satisfy me. 
People buy enough herbal penis enhancing medicine to make spam profitable, 
people will probably hit "yes" for "do you want to connect to evilcrackers.com:25?".

The Java Sandbox approach is limiting but certainly better than the "everything 
must go through a small subset of HTTP" approach that getURL/postURL currently 
offer. It only takes a few lines of code to write a proxy that redirects all 
traffic to port X to foo.com:X, and that is much better than converting 
everything to HTTP. I could live with that.

>     It concerns me that you seem to consider this such a minor issue.
> Honestly, one small misstep here can very effectively kill SVG.

Sorry if I was unclear, I was concerned with trojans all of a sudden becoming 
portable to wherever SVG works or DDoS attacks not previously possible, two 
claims that I believe to be untrue. I do not in any way consider this a minor 
issue, which is also why I am ready to put energy into separating the real 
issues from the false ones.

>     I agree that a highly restrictive set of protocols is probably
> bad, but one must also remember that in a web context you are often
> restricted to http as many corporate firewalls will block anything
> else.  This doesn't mean that you shouldn't offer anything else, but
> it does mean that HTTP and HTTP based protocols deserve extra attention.

Yes, but possibly not for long. People have naturally noticed that many things 
can now be done over HTTP that weren't done before, and there are HTTP-filtering 
proxies that block some forms of traffic. If a company wishes to block IM/IRC 
and someone writes a client that does that over HTTP, it won't be long before 
you find products to intercept that :)

-- 
Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway        http://expway.fr/
7FC0 6F5F D864 EFB8 08CE  8E74 58E6 D5DB 4889 2488

Received on Monday, 18 August 2003 13:44:32 UTC