|
Due to a comment on my last posting I changed the PickleRPCHandler to be only enabled when the user explicitely set's a config flag. The reason being the still running discussion wether unpickle is safe for untrusted data. The problem is discussed here. There are several aspects to it: evaling quoted strings (deemed not to be a problem because the strings are inspected before evaluating and Python doesn't have things like interpolation in Perl) and constructor/destructor calls for class instances.
With Python 2.2, only classes with a special attribute could be instantiated, but with Python 2.3 it seems like this security measure was dropped - so an exploit would have to instantiate a class in a way that opens up the system.
In general it's better to play on the safe side and just don't use the PickleRPC mechanism if you expose your toolserver to untrusted systems.
Update: I added a shared secret that you need to set in both the server config and the client constructor call. The shared secret is used to build a secure hash based on the actual call data and the shared secret. That way your calls are signed with your shared secret without transfering itself over the wire. The check on the shared secret is done before any unpickling takes place, so at least you know who to yell at if you get bad code in your pickle 
The shared secret is now used for both the request (so the server can be sure that at least the client knows about the shared secret) and the response (so the client can be sure that the result wasn't tampered with).
|
