[Twisted-Python] Potential PB Security Problem (And Solution)

[Glyph Lefkowitz]

On Fri, 2002-02-15 at 20:11, Kevin Turner wrote:
> On Fri, 2002-02-15 at 15:44, Glyph Lefkowitz wrote:
> > My proposed solution is to change the way remote methods are invoked:
> > instead of emulating regular Python methods, they would be accessed
> > through a 'callRemote' method
> 
> It's not "slightly more typing", it's a massive blow to the elegance and
> transparency of spreadable object code.  I guess you're saying that the
> transparancy has become a liability, as you can't necessarily tell if
> you're invoking a local or remote object (...but I thought that was the
> point?).  I'm also a little suprised because this is the first time I've
> seen you vouch for any sort of "safety" mechanism to protect the
> programmer from doing wayward things with eir data.

It was never my intention that remote object communication be
transparent, only convenient.  (The party line is "translucent".)  In
fact, one of the use-cases that radix and I discussed on IRC was the
ability to have locally-callable asynchronous objects that behave like
PB references.  Since a PB object's semantics will differ slightly if it
is local or remote if you were to just wrap its results in a deferred
(thanks to serialization, and such) it would be desirable to have a
local interface as well, which could perform the necessary mutations on
the data to make it look as though it'd been serialized.

As it stands now, this wrapper would be pretty thick, creating at least
3 separate instances for a single method invocation.  In the case that
I'm proposing, though, all you'd need is to subclass a mixin that
implements callRemote and dispatches to "async_" prefixed method
instead.  From the user code point of view it would be about the same,
but it would simplify the implementation a lot.

> It also sounds like that this use case is inherently insecure.  You're
> passing privledged information to
> some-object-passed-to-you-from-who-knows-what.  I'm not sure there's
> really anything you can do about that.

Well, what I propose to do about it <0.5 wink> is make it explicit that
the information you're sending *may* be going to a remote source.  This
causes the broken case -- where the client is trying to masquerade a
reference somewhere bad -- blow up, rather than merrily send your
information somewhere it shouldn't go.

If we intend to use this API for a general basis for client<->server
communication, it is desirable that we make it require as *little
thinking as possible* to write secure code.  Buffer overflows are, after
all, something that can be easily prevented in C; it's just that the
fact that it's hard makes it a common mistake.

-- 
"Cannot stand to be one of many -- I'm not what they are."
        -Guster, "Rocketship"
                glyph lefkowitz; ninjaneer, freelance demiurge
    glyph @ [ninjaneering|twistedmatrix].com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part
URL: </pipermail/twisted-python/attachments/20020215/ca272d98/attachment.sig>