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

[Sean Riley]

well, as someone who HAS written a lot of spread code I'd say that the
current interface that assumes method calls on remote objects are remote can
be confusing. In a few cases I have found my code doing strange things on
the network when I was expecting local behavior.

The "callRemote" syntax would make remote operation explicit - which I am in
favor of.

Another observation from writing lots of spread code is that the remote
interfaces for objects tend to be very small.  This reduces the impact of
the "more typing required" argument against this change. In my current
application that uses pb which is 4300 lines of python and about 70 classes,
there are only 19 remote methods defined. Changing my code over to use the
"callRemote" syntax would take a couple of hours at most. (i have unit tests
:) ).

BTW, I was the other person that Glyph mention who had written code
exploitable by this issue.


-----Original Message-----
From: twisted-python-admin at twistedmatrix.com
[mailto:twisted-python-admin at twistedmatrix.com]On Behalf Of Kevin Turner
Sent: Friday, February 15, 2002 10:05 PM
To: Twisted List
Subject: Re: [Twisted-Python] Potential PB Security Problem (And
Solution)


On Fri, 2002-02-15 at 19:12, Christopher Armstrong wrote:
> For as long as I remember, that was *never* the point. Haven't you ever
> heard glyph shouting from on high, "Explicit is better than implicit!"?

Funny words for a sect which celebrates in masqurading objects and
generally deplores strict type checking.

> Well, the point was, the code wasn't *meant* to pass privelaged
> information to an object across the wire - notice that it was a Copied.
> This could also be done for more things than Copied - imagine a method
> that takes a list as one of its arguments and appends some secure data
> to it. You could spoof a list with a remote object that has an append()
> method.

What do you mean, "wasn't meant to pass privledged information"?  Your
example has you appending the "secure data" to a list that's from who
knows where!  You have no idea who holds a reference to that list, or
who will hold references to the list (or certain items on the list) in
the near future.  And, as a happy little object, I don't see why you
should care.  You perform your operation with the given parameters, and
that's all your job is, isn't it?

I guess there's the "Referenceable vs Copyable" facet which I haven't
been paying a lot of attention to in this discussion.  When I choose
between those two spreadable flavours (the module name is spelled wrong,
BTW), I am thinking about what goes over the wire, but only in terms of
how much it will change, how much the states of the objects need to be
synchronized, how much traffic it's generating, etc.  But I've never
seen the use of Copyable as a security option.  If I had data I did not
want getting outside, I do not think I should entrust it to *any* object
which came from Outside, whether it be a RemoteCopy or RemoteCache or a
list-like object with whiskers.

I guess it's only fair to admit that I've written very little
application code with twisted.spread and read even less, so it's
entirely possible that I lack the experience to understand the issues
here...  but some things bein' said just don't ring true to me.

"So-at-least-ONE-of-us-has-been-replaced-by-an-evil-robot"-ly yours,

  Kevin

--
The moon is waxing crescent, 10.8% illuminated, 3.1 days old.