is there a safe marshaler?

[Paul Rubin]

Re: is there a safe marshaler?

"guido@python.o rg" <gvanrossum@gma il.com> writes:[color=blue][color=green]
> > Pickle and marshal are not safe. They can do harmful things if fed
> > maliciously constructed data. That is a pity, because marshal is fast.[/color]
>
> I think marshal could be fixed; the only unsafety I'm aware of is that
> it doesn't always act rationally when confronted with incorrect input
> like bad type codes or truncated input. It only receives instances of
> the built-in types and it never executes user code as a result of
> unmarshalling.[/color]

There's another issue with marshal that makes it unsuitable for Pyro,
which is that its data format is (for legitimate reasons) not
guaranteed to be the same across different Python releases. That
means that if the two ends of the Pyro application aren't using the
same Python version, they might not be able to interoperate.

I don't remember if marshal strings contain a version number. If they
do, then the non-interoperating versions can notice the
incompatibility and raise an appropriate error. If they don't, then
undefined behavior and possible security holes could result, unless
Pyro takes special measures to notice the possibility.

See SF bugs #467384 and #471893 for some further discussion.

[Irmen de Jong]

Re: is there a safe marshaler?

Paul Rubin wrote:[color=blue]
> There's another issue with marshal that makes it unsuitable for Pyro,
> which is that its data format is (for legitimate reasons) not
> guaranteed to be the same across different Python releases. That
> means that if the two ends of the Pyro application aren't using the
> same Python version, they might not be able to interoperate.[/color]

Paul, the default serialization protocol that Pyro uses is pickle
(with the highest available protocol number). So there is a risk
already that it doesn't interoperate with older Python versions,
unless you configure the max pickle protocol or switch to using
one of the supported XML serializations.
For mobile code, Pyro relies on the transfer of the actual
bytecode and this won't work at all no matter what if you use
different Python versions. Unless the bytecode happens to be
the same (consider yourself lucky).

--Irmen

[Paul Rubin]

Re: is there a safe marshaler?

Irmen de Jong <irmen.NOSPAM@x s4all.nl> writes:[color=blue][color=green]
> > There's another issue with marshal that makes it unsuitable for Pyro,
> > which is that its data format is (for legitimate reasons) not
> > guaranteed to be the same across different Python releases. That
> > means that if the two ends of the Pyro application aren't using the
> > same Python version, they might not be able to interoperate.[/color]
>
> Paul, the default serialization protocol that Pyro uses is pickle
> (with the highest available protocol number). So there is a risk
> already that it doesn't interoperate with older Python versions,
> unless you configure the max pickle protocol or switch to using
> one of the supported XML serializations.[/color]

Yes, however, you can at least set the protocol level. Marshal doesn't
give you that option.

What do you do about the security issue if you're using pickle? Do
you have to trust the other end to not send you malicious pickles?

[Irmen de Jong]

Re: is there a safe marshaler?

Paul Rubin wrote:[color=blue]
> Yes, however, you can at least set the protocol level. Marshal doesn't
> give you that option.[/color]

That's right. So good for Pyro then :)
It works most of the time, even across different Python versions,
unless using mobile code.
[color=blue]
> What do you do about the security issue if you're using pickle? Do
> you have to trust the other end to not send you malicious pickles?[/color]

I do nothing about it.
Yes, you have to trust the other end.
So you have to use your own -or Pyro's- authentication/authorization
logic to make sure that the other end can be trusted.
You could use SSL with certificates for instance.

In fact, this is the reason why I started this thread.
I wanted to discover some possibilities to replace pickle
by another thing, so that Pyro becomes 'safe' at the wire
protocol level.
But further discussion on the Pyro mailing list sort of
made it clear that this is not desirable.

--Irmen

[Paul Rubin]

Re: is there a safe marshaler?

Irmen de Jong <irmen.NOSPAM@x s4all.nl> writes:[color=blue][color=green]
> > What do you do about the security issue if you're using pickle? Do
> > you have to trust the other end to not send you malicious pickles?[/color]
>
> I do nothing about it.
> Yes, you have to trust the other end.
> So you have to use your own -or Pyro's- authentication/authorization
> logic to make sure that the other end can be trusted.
> You could use SSL with certificates for instance.[/color]

Well, ok, if you trust then other end then I think it's enough to just
authenticate all the pickles (say using hmac.py) without needing
something as heavyweight as SSL. If you use SSL you need something
like m2crypto since the SSL option in the socket module doesn't check
certificates, IIRC.
[color=blue]
> In fact, this is the reason why I started this thread.
> I wanted to discover some possibilities to replace pickle
> by another thing, so that Pyro becomes 'safe' at the wire
> protocol level.
> But further discussion on the Pyro mailing list sort of
> made it clear that this is not desirable.[/color]

Why do you say it's not desirable? Don't competing protocols like RMI
try to stay safe from malicious peers? Why should I not want to
expose a Pyro service to the internet? It's a natural thing to want
to do.

[Irmen de Jong]

Re: is there a safe marshaler?

> Well, ok, if you trust then other end then I think it's enough to just[color=blue]
> authenticate all the pickles (say using hmac.py) without needing
> something as heavyweight as SSL.[/color]

An interesting idea that hadn't crossed my mind yet.
Pyro *does* already have connection authentication that uses md5
(and hmac since 3.5beta) with a shared secret, but after that,
the communication is done in plaintext so to speak.
[color=blue]
> If you use SSL you need something
> like m2crypto since the SSL option in the socket module doesn't check
> certificates, IIRC.[/color]

I'm using m2crypto for this kind of SSL, yes.
(sadly it has a bug in its API that is triggerd by the current
Pyro version on some platforms like Linux).
[color=blue][color=green]
>>In fact, this is the reason why I started this thread.
>>I wanted to discover some possibilities to replace pickle
>>by another thing, so that Pyro becomes 'safe' at the wire
>>protocol level.
>>But further discussion on the Pyro mailing list sort of
>>made it clear that this is not desirable.[/color]
>
>
> Why do you say it's not desirable? Don't competing protocols like RMI
> try to stay safe from malicious peers? Why should I not want to
> expose a Pyro service to the internet? It's a natural thing to want
> to do.[/color]

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).
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 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?

--Irmen

[Paul Rubin]

Re: is there a safe marshaler?

Irmen de Jong <irmen.NOSPAM@x s4all.nl> writes:[color=blue][color=green]
> > Well, ok, if you trust then other end then I think it's enough to just
> > authenticate all the pickles (say using hmac.py) without needing
> > something as heavyweight as SSL.[/color]
>
> An interesting idea that hadn't crossed my mind yet. Pyro *does*
> already have connection authentication that uses md5 (and hmac since
> 3.5beta) with a shared secret, but after that, the communication is
> done in plaintext so to speak.[/color]

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.[color=blue]
>
> 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).[/color]

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?

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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?[/color]

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.

[Irmen de Jong]

Re: is there a safe marshaler?

Paul Rubin wrote:
[color=blue]
> 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.[/color]

Thanks for the tip. I'll think about this.

[color=blue][color=green]
>>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).[/color]
>
>
> 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?[/color]

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.
[color=blue]
> 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.[/color]

Yep, that's what I now know too from the other replies in this thread.

[color=blue][color=green]
>>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.[/color]
>
>
> 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.[/color]

What I know of it is that you had the possibility to arbitrarily follow
attribute paths, including attributes that should rather be kept hidden.

[color=blue][color=green]
>>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?[/color]
>
>
> 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.[/color]

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

[Fredrik Lundh]

Re: is there a safe marshaler?

Irmen de Jong wrote:
[color=blue][color=green]
>> I haven't looked at that bug carefully yet but yes, anything exposed
>> to the internet has to be done very carefully, and XML-RPC missed
>> something.[/color]
>
> What I know of it is that you had the possibility to arbitrarily follow
> attribute paths, including attributes that should rather be kept hidden.[/color]

the bug had nothing to do with the XML-RPC protocol itself; it was a
weakness in the SimpleXMLRPCSer ver framework which used reflection
to automatically publish instance methods (if you use getattr repeatedly on
an instance, you can access a lot more than just attributes and methods...)

how do you publish "RPC endpoints" in Pyro?

</F>

[Irmen de Jong]

Re: is there a safe marshaler?

Fredrik Lundh wrote:
[color=blue]
> the bug had nothing to do with the XML-RPC protocol itself;[/color]

True, sorry for the confusion. I should have written it more precisely.
[color=blue]
> it was a
> weakness in the SimpleXMLRPCSer ver framework which used reflection
> to automatically publish instance methods (if you use getattr repeatedly on
> an instance, you can access a lot more than just attributes and methods...)
>
> how do you publish "RPC endpoints" in Pyro?[/color]

By reflection :-) return getattr(self,me thod) (*args,**keywor ds)
But Pyro currently treats attribute lookups differently.
It either ignores them completely (you have to enable remote-attribute
access explicitly) or returns attributes as 'local' objects.
What I mean is that you can access a remote attribute of a Pyro object,
but only one level deep. There is no repeated (nested) remote attribute
lookup. It's quite difficult to explain, if you want more details please
read the relevant section in the Pyro manual:

http://pyro.sourceforge.net/manual/7-features.html#nestedattrs

As far as I can see, Pyro is safe from the XMLRPCServer weakness.

Interestingly, I have been thinking for a long time to add nested
remote attribute lookup to Pyro. I know know that this is perhaps
not a really good idea :)


--Irmen

[Paul Rubin]

Re: is there a safe marshaler?

Irmen de Jong <irmen.NOSPAM@x s4all.nl> writes:[color=blue][color=green]
> > Note you should also put sequence numbers in the messages, to stop
> > the attacker from fooling you by selectively deleting or replaying
> > messages.[/color]
>
> Thanks for the tip. I'll think about this.[/color]

Hmm, you also want a random blob in each packet (including the session
start) included in the authentication of the next packet, so the
attacker can't cut and paste messages from old sessions into the
current ones. You know, by the time you're through designing this you
may be better off just using SSL and getting it over with. It's very
easy to make mistakes designing these types of protocols. There are
some reasonable examples in "Applied Cryptography", but maybe you
don't want to deal with this stuff.
[color=blue]
> 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[/color]

Thanks, I should try to find out more about this. I'm about to be
doing some stuff with an existing RMI app and I better make sure it's
not already vulnerable.
[color=blue]
> 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.[/color]

Hmm, I sort of understand this, but not completely. Does DCOM or .NET
expose language features directly?
[color=blue]
> 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...[/color]

I've been meaning to look at Pyro and will certainly let you know if I
spot any problems, but of course there might be some that I don't find.
[color=blue]
> 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.[/color]

Yes, though RMI requires the same.

[Irmen de Jong]

Re: is there a safe marshaler?

Paul Rubin wrote:
[color=blue]
> Hmm, you also want a random blob in each packet (including the session
> start) included in the authentication of the next packet, so the
> attacker can't cut and paste messages from old sessions into the
> current ones. You know, by the time you're through designing this you
> may be better off just using SSL and getting it over with. It's very
> easy to make mistakes designing these types of protocols. There are
> some reasonable examples in "Applied Cryptography", but maybe you
> don't want to deal with this stuff.[/color]

Heh, indeed I rather don't.
I know a bit about this stuff, but not nearly enough to come
up with a water tight design by myself, so it's much easier
and safer to rely on trusted work by others.

[color=blue][color=green]
>>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 .[/color]
>
>
> Hmm, I sort of understand this, but not completely. Does DCOM or .NET
> expose language features directly?[/color]

..NET: no idea
DCOM: as it is based on DCE/RPC, I would say: no. There's this MIDL
thing sitting in between and stuff like that. There's no such thing
as a specific class id and/or method name and/or parameter list that
directly maps onto an object.method in the programming environment.

I must confess, this stuff is getting all rather messy and probably not
worth to try to make such a distinction between all the RPC protocols :-)
[color=blue]
> I've been meaning to look at Pyro and will certainly let you know if I
> spot any problems, but of course there might be some that I don't find.[/color]

I would appreciate it.

[color=blue][color=green]
>>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.[/color]
>
>
> Yes, though RMI requires the same.[/color]

Precisely. There is this tunneling thing, but I never got it to work.
In the end, using a SSH tunnel may prove to be even easier :-D
(just let sshd listen on port 80 and you're set)


--Irmen

[Paul Rubin]

Re: is there a safe marshaler?

Irmen de Jong <irmen.NOSPAM@x s4all.nl> writes:[color=blue]
> I know a bit about this stuff, but not nearly enough to come
> up with a water tight design by myself, so it's much easier
> and safer to rely on trusted work by others.[/color]

Yeah, at this point I think it's safest to just use SSL. If I use
Pyro for anything I'll probably do it that way.
[color=blue]
> DCOM: as it is based on DCE/RPC, I would say: no. There's this MIDL
> thing sitting in between and stuff like that. There's no such thing
> as a specific class id and/or method name and/or parameter list that
> directly maps onto an object.method in the programming environment.[/color]

Hmm, ok, maybe we need something like that for Python, perhaps as a
Pyro extension.
[color=blue]
> Precisely. There is this tunneling thing, but I never got it to work.
> In the end, using a SSH tunnel may prove to be even easier :-D
> (just let sshd listen on port 80 and you're set)[/color]

I think if you want to get serious about authentication, SSL has more
of a developed infrastructure. Frankly I've never understood why ssh
caught on instead of telnet over SSL. See stunnel.org for a simple
SSL tunnel.