>I would like to see HTTP removed from vendor's list of places to "punch
>holes through firewalls". Mark Ryland (mailto:markry @
microsoft .
com), a
>Technical Evangelist in Microsoft's DRG group, commented that
>(paraphrased) HTTP be used as a transport for DCOM so people can (if
>they want to) take advantage of punching through port-based firewalls.
This feature has been requested by many customers. The inability of
DCOM to be used through HTTP-passing firewalls is considered by some to
significantly reduce its utility as an Internet technology, since they
want to use DCOM to talk directly between the COM objects making up the
ActiveX web browser and the objects extending the ActiveX web server.
Only admins can configure an NT server to use a new DCOM transport, so
use of HTTP as a DCOM transport can be controlled by security-conscious
users.
>If, for example, every standard HTTP proxy recognized images, which
>typically have some sort of header text, and ASCII text, then the proxy
>could prevent any code blocks that contain anything else. This would
>eliminate the need to constantly modify the proxy for new innovations.
This is a chimera -- there is no way you can hope to restrict the use of
HTTP by these schemes such that malicious people can't use it
maliciously. ASCII text is just source code for script engine, right?
It is impossible in principle to write filters that can recognize all
"bad code/data" coming through on a given port. If code can be place on
the inside of the firewall (or a bad person can get access to the
network to turn sent data into code, either directly or with some kind
of VM/interpreter), then any data coming through can be malicious,
period.
>creating corresponding parsing logic. IMHO, any executable type allowed
>through conceptually permits an intelligent hacker to pass any other
>type". With DCOM, we're not trying to screen executables, but instead,
>instructions, which could yield far more than an executable could ever
>gain.
I don't understand what this comment means. DCOM does not pass
"instructions" in the sense that you seem to mean over the wire, it
passes a packet with an method number and (typically) an opaque blob of
marshaled that can't do anything unless there is, on the other side of
the connection, a complex set of machinery (the DCOM runtime) as well as
an instantiated object and stub corresponding to the requested method
(and capable of unmarshaling the data, if any). It's just an
object-enhanced RPC system, no different from a security perspective
than ONC or DCE RPC. Unlike "mobile code" technology, there is no way
in the base DCOM system to pass arbitrary instructions over the network
that will blindly be executed by the runtime on the remote system.
There must be corresponding code on the remote system that is ready and
willing to perform the requested operations.
HTTP itself is essentially an RPC system. It encodes requests and
replies, allows arbitrary commands and data to be sent both ways, etc.
(It just doesn't do automatic data marshaling.) If you have malicious
or buggy code on either or both sides of a "standard" (whatever that is)
HTTP connection, then a malicious person may be able to do nasty things.
Running DCOM over HTTP adds absolutely zero new security risks -- an
RPC system running over an RPC system is not less secure than just an
RPC system alone.
>The "build it and they will secure it" idea is not a Bad Thing(tm), but
>when you don't give us anyway to secure it what are we supposed to do?
>When its on its own port, at least it can be explicitly denied if
>desired. When you throw it into HTTP you intentionally destroy the
[...]
>network...buyer beware seems to be all they'll admit to. I think its
>necessary to speak out against foolish and potentially malicious
>recommendations from major vendors with regards to "punching through
>port-based firewalls", and make them think about security first and
>functionality second.
Fundamental fact is that port-base firewalls are of limited utility for
creating a truly secure environment. The main reason is that it is
impossible in principle to prevent people from using assigned ports for
a completely different purpose. Let's suppose you decide to let only
HTTP traffic through and, further, suppose you somehow mesmerize the
vendors into not using HTTP for anything "illegitimate" other than
"true" HTTP (whatever that means -- it whole point of these protocols is
extensibility). So what -- a malicious person on the inside of the
firewall will simply open the HTTP port with an entirely different
program, and send/receive all the nasty things in the world to their
accomplices outside. Worse yet, the nasty person sends their innocent
friend within the organization a nice little "chess program" on a floppy
that does everything the nasty person needs surreptitiously.
(True, if you have a secure environment where only secure operating
systems are allowed to connect to the network, and you configure those
operating systems to allow only admins to installed executable code, and
you don't allow your users to be admins of their machines, and you test
all the executable code you install carefully to make sure it doesn't
have any backdoors, then you have a fighting chance. But how many
organizations don't allow DOS/Windows/Mac on their networks? And how
many don't allow NT and UNIX users to admin their own machines?)
Port-based firewalls prevent some bad behavior by UNSOPHISTICATED users
and hackers. Like car door locks, they're very worthwhile for that
reason. But the a pro can get through your port firewall as fast has a
pro can get into your car with a slim-jim.
Mark Ryland
Senior Technical Evangelist
Microsoft Corp.
markry @
microsoft .
com
|
|
