[
Lists Home |
Date Index |
Thread Index
]
Dare Obasanjo wrote:
>
>...
>
> What I'd like to know is WHY he is against SOAP. In the old days I could
> understand why people didn't want various RPC services exposed on their
> machines because they were a security risk due to all the buffer
> overflows and the like that existed in them.
Maybe there was a reason there were all of those buffer overflows. RPC
requires ordinary programmers to take much more control of their own
security model than application protocols do. When you see an SMTP
message going through the firewall there are certain things you know
based on your knowledge of the semantics of the SMTP protocol. When you
see an RPC message it could as easily be a command to shut down the
computer or to accept a purchase order or to frag a Quake competitor.
There's no way you can know from the fact that it is RPC what it is
"about" in even a vague sense.
You COULD make a service to shut down a computer through HTTP or SMTP
but people don't because the applicaion semantics would be so skewed. On
the other hand most or all Windows boxes run an RPC program that DOES
shut down the computer (after authentication, of course, if you trust
the security).
>...
> Nowadays that web servers allow requests that execute server side code
> from servlets to ASP to CGIs, I'm not sure exactly why anyone would be
> opposed to what is simply another mechanism for telling a server to
> execute some preset operation on the server.
The semantics of those server side applications are almost all within
what the Web encourages. People do not regularly use HTTP to shut down
computers or play video games. When they do, it is almost always
tunnelling which is what SOAP does. SOAP is on the side of the bad guys
in that sense.
> Unless Bruce Schneir us simply against all mechanisms that would allow
> clients to execute code on the server even if the code was already
> predetermined.
Bruce says the problem is with RPC. This comes back to what I said
before. The prohibition against exposing arbitrary RPC was, I thought,
deeply engrained in the computer security world so that we don't have to
explain it to each other over and over again.
Bruce:
"Let's continue the DCOM example. So what if DCOM runs over a firewall?
DCOM is Microsoft's main protocol for inter-application communication.
It's not just used by programs that are intended to be servers; it's
used for all sorts of desktop communication and remote access. The
result is that an average machine has dozens of programs using DCOM.
Mine shows 48, ranging from "Microsoft PowerPoint Presentation" to
"logagent" and including the catchily named
"{000C101C-0000-0000-C000-000000000046}"; you may be able to list yours
by bringing up a Command Prompt and typing "dcomcnfg".
Now, there are lots and lots of ways to secure DCOM applications, so
maybe all of those applications are happily responding only to
authenticated requests from the local machine. On the other hand, there
are lots and lots of ways to make DCOM applications insecure, so maybe
one of them is just waiting for somebody to send it an entirely
unauthenticated request to overwrite selected files on my hard disk.
"
RPC over a firewall is okay if you run one or two known services with
well-defined semantics (e.g. NFS or syslog). Then those known
vocabularies are like application protocols and you can ignore the fact
that they happen to have an RPC substrate. Just tunnelling arbitrary
SOAP vocabularies over HTTP is a CIO's nightmare.
Why do you think that firewalls prevent DCOM from going across them in
the first place? How does SOAP syntax help anything?
Paul Prescod
|
