Paul Rubin wrote:
Yes, that's what I meant, using hmac to authenticate using a shared secret, sending the rest in the clear. Note you should also put sequence numbers in the messages, to stop the attacker from fooling you by selectively deleting or replaying messages.
Thanks for the tip. I'll think about this.
You should not want to expose a Pyro service to the internet because Python doesn't have Java's security model and sandboxing, that are used with RMI. Pyro has a few features that are very powerful but also require the use of intrinsic insecure Python code (namely, pickle, and marshal).
Can you say some more about this? Does RMI really rely on sandboxes, if you don't send code around, but just expose operations on server side objects?
Well, my experience with RMI is very limited (and from a few years ago) but I remember that you are required to set a security manager on your RMI objects. I always used Java's default rmi security manager but I honestly don't know what it actually does :-D
Other than that, it would be interesting to know if the RMP or IIOP protocols have any problems with malicious packets? I don't know them well enough to say anything about this.
I don't think marshal is inherently insecure, since the unmarshaller doesn't itself execute any marshalled code. It apparently has some bugs that can confuse it if you send it a malformed marshalled string, but those can be fixed. Pickle is inherently insecure because of how it calls class constructors.
Yep, that's what I now know too from the other replies in this thread.
Just look at the recent security advisory about the XMLRPC server that comes with Python.... it's much more primitive than Pyro is, but even that one was insecure.
I haven't looked at that bug carefully yet but yes, anything exposed to the internet has to be done very carefully, and XMLRPC missed something.
What I know of it is that you had the possibility to arbitrarily follow attribute paths, including attributes that should rather be kept hidden.
I wouldn't put a Java RMI server or xyz CORBA server or whatever kind of unrestricted API open on the internet anyway. Am I rational or paranoid?
I haven't used Java enough to advise you on this, but I thought they were supposed to be ok to expose to the internet. Certainly the whole idea of .NET is to let you securely provide RPC services (excuse me for a moment while I try to stop laughing for mentioning security and Microsoft in the same sentence). And lots of people use things like SOAP for that.
I label things like SOAP and XML-RPC much different than RMI or Pyro, because they (SOAP) are much more "distant" from the actual programming language and environment beneath them. I don't know if this is good thinking or not but the fact that RMI and Pyro expose language features directly, and SOAP not, makes that I reason about them differently.
Then again, Pyro allows you to use two forms of XML serialization on the wire (instead of pickle), which may or may not move it much closer to SOAP and the likes. But there are other reasons for not wanting a Pyro server exposed on the internet. Such as the lack of a good security analisys of Pyro. Perhaps it suffers from similar holes as XMLRPC until recently...
Furthermore there are practical issues such as having to open a buch of new ports in your firewall. In my experience this is very hard to get done, sadly, in contrast to just exposing a "web-service" (in whatever form) on port 80 HTTP.
--Irmen -- http://mail.python.org/mailman/listinfo/python-list
