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 _______________________________________________ Mailing list: https://launchpad.net/~openerp-india Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-india More help : https://help.launchpad.net/ListHelp
