New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
platform._uname_cache is writeable #67936
Comments
>> import platform
>>> print 'Actual =>',platform.uname()
Actual => ('Linux', 'toshiba-laptop', '3.13.0-24-generic', '#47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014', 'x86_64', 'x86_64')
>>> import hack_uname
# Someone imports my module unaware of the hack (see attached file)
>>> platform.uname()
('Limux', 'hacker-laptop', '11.15.0-28000-absurd', '#10000 - FunkyDistro SMMP Fry Feb 30 2015 23:59:00 UTC 2015', 'x866_64', 'x866_64') Fix - Make the global _uname_cache inaccessible via the module and hence unwriteable. I can provide a patch - it is kind of easy fix. I think this might also be a security issue since if someone is writing a significant piece of code based on the platform it can screw up the system - or his web application if a piece of code like this is introduced in a module via his chain of imports by a malicious hacker. |
I am changing the type to security as I dont think this is a behaviour issue. |
we are all consenting adults here. Why do you modify a private attribute?
I don't understand why do you consider that it is a security vulnerability? >>> import hack_uname
# Someone imports my module unaware of the hack (see attached file) Your exploit starts by running untrusted Python code. Never do that. The vulnerability is the ability to load unstrusted Python code, not to modify the platform module. I close the issue as not a bug. |
Hmmm... dear sir - what prevents you from adding an __all__ to the module with these cache variables excluded ? |
Closing is an easy fix, bet on my word this would appear as a different bug, thanks for your quickie fix! |
You didn't understand the general philosophy, we are not hidding internals. For the specific case of platform._uname_cache, it uses the "_" prefix which is an indicator saying that "you are not supposed to modify it except if you really understand what do you". It's useful to have this variable modifiable, for unit tests for example. I don't see how adding __all__ variable to the platform would change anything. Variables prefixed by "_" are already excluded when using "from platform import *". If you don't understand the Python philosophy, please open a thread on python-ideas or even python-dev mailing list, to get a longer explanation. Read also the PEP-20. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: