openerp-india team mailing list archive

["Olivier Dony \(OpenERP\)" <928376@xxxxxxxxxxxxxxxxxx>]

On 02/07/2012 08:01 PM, Florent wrote:
> You could image a specially crafted "/.zip" or "/home.zip" file which
> includes a python module which matches an openerp file name, and contain
> malicious code.

Yes that is possible indeed, but it seems it would require some very exotic
conditions to be exploitable - or a situation where the attacker has full
control on the disk space from which OpenERP is running (in which case there
are much easier methods to attack the system, obviously).


> To be sincere, I am not really concerned about the security implications.

Exactly, I'm also much more concerned by the number of useless I/O syscalls
that are triggered by this logic. This stems from 2 things:

1. zipped modules currently have a higher precedence than extracted versions,
which I think is a legacy behavior - and probably a bad choice
2. the code trying to locate the zipped modules escapes the "chroot" of the
addons path, which makes no sense - modules are not supposed to be loaded
outside of it


> I will probably propose a patch to improve the file_open utility a
> little bit.

Thanks. As you seem to be working on the second issue, I will probably push a
fix for the first issue in parallel, so be careful because this could cause a
number of conflicts in your own work.
I think the behavior must be changed to give precedence to extracted/directory
versions of modules. Firstly, this the default case and also the most common
case, so it is a sane choice for the highest priority (performance-wise).
Secondly, keeping a zipped module next to an extracted module with the same
name is not a documented/supported feature. Thirdly, even if you were relying
on this features, having the extracted version take precedence is more
practical (you could simply extract the zip and try a quick fix in the
extracted version - much harder the other way around)

-- 
You received this bug notification because you are a member of OpenERP
Indian Team, which is subscribed to OpenERP Server.
https://bugs.launchpad.net/bugs/928376

Title:
  file_open is not safe and performs too many useless syscalls

Status in OpenERP Server:
  In Progress

Bug description:
  It happens with 5.0 and certainly with 6.1 too.

  When you update the list of modules, the application calls:
    tools.file_open(terp_file)

  And file_open will browse all the parents of the "addons_path" for a zip file ... 
  I've added a statement to trace the call to "open()" :

  open('/home/florent/erpdemo/parts/openerp-server/bin/addons/account.zip', 'rb')
  open('/home/florent/erpdemo/parts/openerp-server/bin/addons.zip', 'rb')
  open('/home/florent/erpdemo/parts/openerp-server/bin.zip', 'rb')
  open('/home/florent/erpdemo/parts/openerp-server.zip', 'rb')
  open('/home/florent/erpdemo/parts.zip', 'rb')
  open('/home/florent/erpdemo.zip', 'rb')
  open('/home/florent.zip', 'rb')
  open('/home.zip', 'rb')
  open('/.zip', 'rb')

  This behaviour is seen on module installation or upgrade too.
  It is probably a security issue which impacts performance as well.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-server/+bug/928376/+subscriptions