>From: Frederick M Avolio <avolio @
tis .
com>
>Subject: Re: Mosaic and ANS Interlock
>Date: Tue, 29 Mar 94 09:40:28 -0500
>
>Is there anyone who has analyzed this for security implications? Why
>buy a nice, strong, iron door and then cut big holes in it? Scary
>stuff, I think... I'd love to see anyone's work on examining this
>sort of thing through a firewall (anyone's).
Well, to continue the analogy, the whole point of having a door instead
of a wall is to be able to open it, when you want to. The point of a
big iron door is not to let the other guy cut the holes.
I've done a bit with gopher though a firewall (not ANS, just filters)
and can make a couple of basic comments.
First, as has been said many times before, a firewall is an instantiation
of a policy. What you allow depends on what policy you are trying to
implement. The policy I was implementing was "don't let people do things
which might open an exposure to the outside, but trust them not to subvert
the company security intentionally" (no flames please, I don't make policy).
If your policy is otherwise, then it might be a very bad idea to cut such
a hole.
The big problem I see with things like Mosaic and Gopher is that the user
is insulated from the actual network activity in a way not seen with
protocols such as FTP and Telnet, in fact most users may not even be
network literate; it's just a menu to them. Why this is a problem is
that the user probably does not realize what's going on under the hood when
he clicks on something.
With xgopher, it is possible to define a "type" which causes the data item
being fetched to be executed as a script, which might cause no odd behavior
as far as the user was concerned, but could obviously subvert security (I'll
leave the details to your imagination, but I can think of lots of ways to
exploit such a hole). Fortunately this is not the default, and it would
require explicit activity by the user to create it, and the users we most
worry about are the ones least likely to be capable of defining an X resource.
However, the point is that with these kinds of clients, you are delegating
some of the responsibility for your security to end users, becase each new
application could add a similar hole that was open by default. Central
support for applications helps here, since you can check out the defaults, and
even change them, before releasing code to users. Of course, this would only
work as long as you can trust the users not to install arbitrary code they
found somewhere. And equally, the very users you are delegating responsibility
to are the ones least likely to understand the issues.
In my opinion, it comes down to a policy decision. If you think that you
can prevent the "default holes", and your users are either sufficiently
trustworthy (or network illiterate) not to bypass security on purpose, then
you can make a case for making such a service available. Then all you have
to do is get management to make a policy decision. :-)
A second point is that it's not easy to judge client vulnerabilities. You
need to have the time to read the code and understand it, or something may
slip by. The xgopher bit was quite a shock when I found it, as I'd already
had a few people using it. Moral: trust nothing.
Ken
-----
Ken Shores, Sr. Network Analyst The Charles Stark Draper Laboratory, Inc.
kshores @
draper .
com 555 Technology Square, Cambridge, MA 02139-3563
(617) 258-2529 Mail Stop 33
Follow-Ups:
|
|
