NET-RPC client-side stack should sanitize pickled data

I'll open this bug to the community because one month without response and I think this is a critical issue.

Here is a patch to apply:

Web clients needs the same patch

Hello Eduard,

Indeed, the current GTK and Web clients are vulnerable to this type of specially crafted NET-RPC payload. Fortunately this is mitigated by the fact that modified server/addons are required to be able to exploit this, so users are safe as long as they connect to trusted servers, which is usually the case in business contexts or for SaaS contexts (unless a man-in-the-middle attack is involved as well)

Users should also always keep in mind that NET-RPC itself is not a secure protocol, and should be used only in local networks if security is a concern.

The fix suggested by Stephane can be applied on Web/GTK clients of all versions, for users who want to apply it on their client directly

Thanks a lot for reporting!

Try this one, previous was wrong ! sorry, to many things to do in same time.

Not sure but, with find_global = None maybe the exceptions won't be raised, I better write a check function like in tryton[1] or nadina's blog[2]

[1] http://hg.tryton.org/tryton/file/6bd9a2618cf4/tryton/pysocket.py
[2] http://nadiana.com/python-pickle-insecure#How_to_Make_Unpickling_Safer

Will check and provide a patch

Stéphane

trunk/openobject-server/bin> find . -name "*py" |xargs grep -i pickle
returns some modules where pickle is used instead of cPickle
I assume at least speed improvement could be achieved at no cost.
see performance at the end of
http://home.gna.org/oomadness/en/cerealizer/benchmark/index.html

So, NET-RPC is dangerous and Secure XML-RPC doesn't work (cf. bug #673775)...
What is left ???

@Open Net Sàrl:
I beg to differ. If you read the description and comments carefully, you will see that:
1. NET-RPC is not a secure protocol, so it cannot be compared to secure XML-RPC at all. This vulnerability has nothing to do with the transmission of unencrypted data.
2. This NET-RPC vulnerability is not exploitable if you are connecting only to trusted servers. Presumably, production end-users are always connected to trusted production servers, so they are not exposed to this.
This perhaps explains why this bugs looks much more critical than it really is.

If you are connecting to non-trusted servers, you are probably not sending sensitive data, so you should be fine using unencrypted XML-RPC.
Now if you really want to use Secure XML-RPC and are in a Windows-only world, you might want to start by analyzing the problem in bug 673775... you might be able to help find a workaround or even a fix.

Hello,

Thanks for reporting !

It has been fixed at lp:~openerp-dev/openobject-client/trunk-bug-671926-nch and will be merged soon to the trunk client.

Thanks !

Hi,
as a security fix can be aplied to stable clients too? 5.0.X and 6.X

Thanks

--
Eduard Carreras i Nadal

On 04/07/2011, at 7:46, "Naresh\(OpenERP\)" <email address hidden> wrote:

> Hello,
>
> Thanks for reporting !
>
> It has been fixed at lp:~openerp-dev/openobject-client/trunk-
> bug-671926-nch and will be merged soon to the trunk client.
>
>
> Thanks !
>
> ** Changed in: openobject-client
> Status: In Progress => Fix Committed
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/671926
>
> Title:
> NET-RPC client-side stack should sanitize pickled data
>
> Status in OpenERP GTK Client:
> Fix Committed
> Status in OpenERP GTK Client 5.0 series:
> Confirmed
> Status in OpenERP Web Client:
> Confirmed
> Status in OpenERP Web Client 5.0 series:
> Confirmed
>
> Bug description:
> It's possible to execute arbritrary code on client using net-rpc
> (pickle protocol) see http://nadiana.com/python-pickle-insecure
>
> If you use the client to connect to some demo server and this demo
> server is malicious, it can send malicious code which is executed in
> client side.
>
> I attach a exploit server who sends code to execute to client. Run a
> ls -l and redirect the output to proof_of_exploit.txt file.
>
> This bug was fixed in the server, but not in the client.
> Affects versions 4.2, 5.X and 6.X
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-client/+bug/671926/+subscriptions

Eduard, you're right, this will be backported to 5.0 and 6.0 series once the fix is validated and merged in trunk.

Hello,

Thanks for reporting !

The fix has been merged in Trunk client @ 1923 <email address hidden>

Thanks,