Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #50669 > unrolled thread

Re: Python - remote object protocols and security

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Python - remote object protocols and security Dave Angel <davea@davea.name> - 2013-07-15 07:17 -0400
    Re: Python - remote object protocols and security Irmen de Jong <irmen.NOSPAM@xs4all.nl> - 2013-07-15 18:57 +0200
      Re: Python - remote object protocols and security Irmen de Jong <irmen.NOSPAM@xs4all.nl> - 2013-07-15 19:05 +0200

#50669 — Re: Python - remote object protocols and security

On 07/15/2013 06:20 AM, Jean-Michel Pichavant wrote:
> In text format... sorry for my previous html post
>
> Hello everyone,
>
> I'd like to exchange some simple python objects over the internet.
> I initially planned to use Pyro, after reading http://pythonhosted.org/Pyro4/security.html I'm still puzzled.
>
> I don't mind encrypting data, if someone wants to sniff what I'm sending, he's welcome.
>

I don't think the word you need there is "mind," but I get the idea. 
You don't care who reads the data being sent, but don't want anybody to 
be able to masquerade as somebody else, either by sending with invalid 
credentials or by intercepting and modifying legitimate traffic.

What's needed for that is public/private key encryption, where the 
legitimate user uses his own private key to encode data, and you use 
their public key to decode it.  Anybody can decode it, since the key is 
public, but anyone (especialy you) can be sure who sent it, since they 
presumably keep their private key private.


> What I think I need to care about, is malicious code injections. Because both client/server will be in python, would someone capable of executing code by changing one side python source ?
>

Even if you have a friendly user sending data, you still need to guard 
against code injection because their system may have been compromised. 
And with code injection, you risk trashing not only their own data, but 
other people's and your own as well.  In other words, encryption 
provides you no assurances.

> How do I prevent this and still provide the source to everyone ?
>

Make sure your deserializing logic (on your own machine) is entirely 
under your control, and impervious to such attacks.  In general, the 
more types that can be encoded, the more likely it's vulnerable.  So 
authors of such libraries have two conflicting goals.

I can't tell you if pyro, or any other particular one is safe.  But if 
you decide to roll your own, which is implied when you say you'll be 
publishing your source, then keep it dirt-simple.  Have a very specific 
and finite set of classes which you'll handle, and write rigorous code 
to make sure the types are limited to those.  For example, you could 
restrict yourself to lists of strings, or lists of strings and floats, 
and you have only three decoders to write.

Note that DOS attacks are possible whatever encoding scheme you have. 
Make sure that self-references within the data are well-defined (or 
impossible), and put limits on size per transaction, and transactions 
per minute per legitimate user.

-- 
DaveA

[toc] | [next] | [standalone]

#50701

On 15-7-2013 13:17, Dave Angel wrote:
> On 07/15/2013 06:20 AM, Jean-Michel Pichavant wrote:
>> In text format... sorry for my previous html post
>>
>> Hello everyone,
>>
>> I'd like to exchange some simple python objects over the internet.
>> I initially planned to use Pyro, after reading
>> http://pythonhosted.org/Pyro4/security.html I'm still puzzled.

Hi, Pyro's author here.
I agree that this chapter of the manual can use some cleanup.
Is there anything in particular that you are puzzled about at this time?

>>
>> I don't mind encrypting data, if someone wants to sniff what I'm sending, he's welcome.
>>

I don't quite understand what you're saying in this sentence: is it okay if someone
eavesdrops on your unencrypted data stream?


>> What I think I need to care about, is malicious code injections. Because both
>> client/server will be in python, would someone capable of executing code by changing
>> one side python source ?

Pyro since version 4.20 uses a serialization format that is safe against arbitrary code
execution: https://pypi.python.org/pypi/serpent
That format only encodes and decodes Python literal expressions, and no arbitrary
objects are instantiated. You can also tell Pyro to use JSON (or marshal even), both of
which should be impervious to this type of attack/vulnerability as well.

The problem is with older Pyro versions, which allowed only Pickle to be used as
serialization format. It is pickle that causes the remote code execution vulnerability.
So as long as you don't explicitly tell Pyro (4.20+) to use pickle (a configuration
switch), you should be safe.

> I can't tell you if pyro, or any other particular one is safe.  

Pyro should be, since version 4.20 and provided you don't tell it to use pickle. See above.

> Note that DOS attacks are possible whatever encoding scheme you have. Make sure that
> self-references within the data are well-defined (or impossible), and put limits on size
> per transaction, and transactions per minute per legitimate user.

Pyro doesn't provide anything by itself to protect against this.


Cheers
Irmen de Jong

[toc] | [prev] | [next] | [standalone]

#50703

On 15-7-2013 18:57, Irmen de Jong wrote:

>> Note that DOS attacks are possible whatever encoding scheme you have. Make sure that
>> self-references within the data are well-defined (or impossible), and put limits on size
>> per transaction, and transactions per minute per legitimate user.
> 
> Pyro doesn't provide anything by itself to protect against this.

I'm sorry to follow up on myself, but there is actually one thing: Pyro's choice of
serializers (except pickle, again) don't allow self-references. So that type of DOS
attack (infinite recursion) is ruled out.


Irmen

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web