a quick & dirty fix would be to ban underscores as a whole. While you can create strings with underscores, I think you can't use __getattr__ or similar and therefore can't use your string with underscores.
Note that this would be an easy fix and is probably breakable with a few hours time investment
I agree that getting rid of safe_eval is the best solution by far.
That said, calling it "not 100% safe" is an understatement, its not safe at all. (see "executing arbitrary commands is also possible")
I can't tell which code is really run, but authenticated tryton users being able to own the server is an issue (in my opinion)
On 06 Sep 16:34, duesenfranz wrote:
> That said, calling it "not 100% safe" is an understatement, its not safe at all. (see "executing arbitrary commands is also possible")
- convert.py for XML evaluation (no security issue)
- action.py for some field evaluation (by default only admin has write access) *
- cron.py: idem *
- lang.py: idem *
- model.py only for migration (no security issue after migration)
- rule.py: idem *
- trigger.py: idem *
- view.py: idem *
- modelview.py: same as for view.py
- currency.py: idem *
- price_list.py: write access to product admin user
- webdav.py: any user has write access
So for me, there are 2 weak points price_list and webdav.
Is there any sane reason to use double underscore for things that get safe_eval'd?
While not fixing the underlying problem, disallowing them would make something like that a magnitude harder.
To clarify: I just wanted to disallow eval'ing any string that contains a double underscore - as we already do with the string "__subclasses__".
Since I don't really know the use cases, I also don't know wether this could be a problem. If there are cases where this doesn't work, maybe we could introduce a new optional argument "allow_double_underscores=True" that gets set to False in most uses.
Yes, you can still create strings that include double underscores.
But since you can't use __getattribute__ or __setattribute__, these strings are rather worthless. So can even access these attributes with str.format, but then you only have their string representation.
The problem for me is that we still trust every usable class (list, str, int, float, etc.) that they don't "leak" internals, but it's much more unlikely for every of them to leak them with attributes that don't include double underscores.
So while still unsafe (because basically impossible to verify as "safe"), it would be a lot harder to exploit.