Several security flaws

[Albert Cervera i Areny - http://www.NaN-tic.com]

Any user that must be able to create a document with a workflow such as 'sale.order' must have write/create rights on workflow item and instance models. This means the user will be able to modify the workflow step of any document in the system such as invoices even if he has no rights on invoices. This will desynchronize model's 'state' field with the workflow step leaving a messy system.

'ir.attachment' already has this point solved so the same solution should be applied here for 'instance' and 'workitem' models.

I think similar issues apply to other models that affect the way OpenERP works (haven't deeply checked them):

- In 'ir.rule': one must give read access to 'ir.rule' to all users. Do we really want to let users know what restrictions are being applied to them?
- In 'ir.property': Isn't it possible for any user access any information only because it must be given read access to 'ir.property' model?
- In 'ir.sequence': If a user must have access to a sequence to create 'sale.order', he will have access to other sequences as well. (Right, you can create rules for that but it really is not sensible to ask that to administrator).
- In 'ir.default': Do we want to let users see what other users set as default value for themselves?
- In 'ir.model.access': Do we want to let users see what other users are allowed to see and what not?
- In 'ir.translation': We're letting any user read and probably overwrite information of data they may not be allowed to access.

And basically any model that is given at least read access to all users should be analyzed.

[Olivier Dony (Odoo) (odo-openerp)]

Interesting point Albert, though I'm not sure the proposed solution (a la ir.attachment) is applicable for many cases... sometimes with subflows you may need to trigger chained transitions on object on which you don't have read access. Just think of an Accountant closing an invoice linked to a sale.order : the closing of the invoice finished the subflow and moves a transition on the parent flow (to which the accountant may not have access).
There may be other solutions, such as giving read/write access to workflow tables only to admin and patching the workflow engine to always access these tables as admin.

Important mitigation factors to this security issue:

It requires users to have a valid login on the system, and can only be exploited by bypassing the OpenERP Clients and accessing XML-RPC directly. This is not something regular users can/will do, and is also not exploitable by "the world", even if your server is on not in a private network (like SaaS). Some cases can also be restricted by adding appropriate ir.rules to your database.

Do you have a specific case in mind where this situation causes an immediate and real threat to one of your OpenERP systems?

Note: this is just a comment to let you know my thoughts, we are analyzing the issue with the R&D team.

Thank you for reporting this!

[Albert Cervera i Areny - http://www.NaN-tic.com (albert-nan)]

Hi Olivier,
I agree with you this is not an issue with most of our customers either. I don't see any issues beyond that, but of course, we cannot say the system is secure.

Talking about workflows, if I remember correctly all steps in the workflow service use direct access to the database (SQL statements) so simply raising an exception if non-admin users try to access the model should do the trick.

For the rest of cases, just must be analyzed and raising an exception may work in some cases too. You may consider throwing the exception if it's being called directly with the web service, and allow access if it's being queried by another model of the system in the system, for example.

[Vinay Rana (OpenERP) (vra-openerp)]

We Let the Framework team decide.

Thanks.