Roundup Robot added the comment:
New changeset c39f42f46a05 by Georg Brandl in branch '3.1':
Fix tkinter regression introduced by the security fix in #16248.
http://hg.python.org/cpython/rev/c39f42f46a05
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
Fix backported to 3.1, closing.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
___
Georg Brandl added the comment:
Should be fixed now in 3.2 too.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
___
Roundup Robot added the comment:
New changeset c18c18774e24 by Georg Brandl in branch '3.2':
Fix tkinter regression introduced by the security fix in #16248.
http://hg.python.org/cpython/rev/c18c18774e24
--
___
Python tracker rep...@bugs.python.org
Arfrever Frehtes Taifersar Arahesis added the comment:
Fix still needs to be applied on 3.1 branch.
--
priority: deferred blocker - release blocker
status: closed - open
versions: +Python 3.1 -Python 3.2
___
Python tracker rep...@bugs.python.org
Roundup Robot added the comment:
New changeset 84f40562669f by Barry Warsaw in branch '2.6':
Fix UnboundLocalError regression due to previous incorrect fix for
http://hg.python.org/cpython/rev/84f40562669f
--
___
Python tracker rep...@bugs.python.org
Barry A. Warsaw added the comment:
Applied the fix to 2.6 and null merged into 2.7. This didn't need a NEWS entry
because the regression hadn't been released yet. I'll remove 2.6 from the
Versions now.
--
___
Python tracker rep...@bugs.python.org
Changes by Barry A. Warsaw ba...@python.org:
--
versions: -Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
___
___
Benjamin Peterson added the comment:
3.2 is owned by Georg.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
___
___
Python-bugs-list
Benjamin Peterson added the comment:
As for 3.1, feel free to apply. There will likely be a source release of it at
some point.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
___
Roundup Robot added the comment:
New changeset 00bcf202cc3f by Antoine Pitrou in branch '2.7':
Add NEWS entry for 0f17aed78168 (issue #16248)
http://hg.python.org/cpython/rev/00bcf202cc3f
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
That fix does work, but it should probably get a NEWS entry since it
fixes a regression from 2.7.3 to 2.7.5.
Done, thank you?
Also, I think the same fix should be backported to all three of 2.6,
3.1, and 3.2.
Benjamin and Barry will have to decide what to
Zachary Ware added the comment:
Antoine Pitrou wrote:
I've committed a fix to 2.7 (I hope it's really a fix, since I don't know how
to test it).
I'll let Benjamin and Barry decide whether to backport to 2.6 and 3.2.
As for 3.1, it's pretty much dead.
That fix does work, but it should
Arfrever Frehtes Taifersar Arahesis added the comment:
The fix in 2.6, 2.7, 3.1 and 3.2 branches introduced UnboundLocalError
occurring when a non-None baseName parameter is passed.
At least a part of fa82071bb7e1 should be backported to 2.6, 2.7, 3.1 and 3.2
branches.
$ python2.7 -c 'import
Larry Hastings added the comment:
You're talking about a new bug. Please open a new issue.
I'm closing this issue right now because I want to cut a Python 3.4 alpha
release tomorrow, and this bug is marked Python 3.4 and release blocker.
--
resolution: - fixed
status: open - closed
Arfrever Frehtes Taifersar Arahesis added the comment:
UnboundLocalError is effect of partially incorrect fix for this bug.
It is better to update Versions field.
--
resolution: fixed -
status: closed - open
versions: +Python 3.1 -Python 3.3, Python 3.4
Roundup Robot added the comment:
New changeset 0f17aed78168 by Antoine Pitrou in branch '2.7':
Fix tkinter regression introduced by the security fix in #16248.
http://hg.python.org/cpython/rev/0f17aed78168
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
I've committed a fix to 2.7 (I hope it's really a fix, since I don't know how
to test it).
I'll let Benjamin and Barry decide whether to backport to 2.6 and 3.2.
As for 3.1, it's pretty much dead.
--
priority: release blocker - deferred blocker
stage:
Ramchandra Apte added the comment:
I suppose this should be closed.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
___
Christian Heimes added the comment:
The bug hasn't been closed deliberately. We need to announce the security fix
and possibly acquire a CVE, too.
--
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
Zachary Ware added the comment:
I believe we're also waiting on input from Barry about whether to apply the
patch to 2.6.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
___
Barry A. Warsaw added the comment:
Does the 2.x patch apply cleanly to 2.6? If so, then I think it should be
applied (though I'd like to review it first). 2.6 is still under security
maintenance until October 2013. I'm thinking we'll probably do one last
security release around that time.
Zachary Ware added the comment:
Does the 2.x patch apply cleanly to 2.6?
It should, if I remember correctly, though I haven't checked since
uploading it. I believe there were actually very few or no changes to the
file the patch is for between 2.6 and 2.7.
--
Changes by Barry A. Warsaw ba...@python.org:
--
versions: +Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
___
___
Python-bugs-list
Barry A. Warsaw added the comment:
Release blocking for 2.6.9 (oh how I wish we could release block for specific
Python versions).
--
nosy: +georg.brandl, larry
priority: normal - release blocker
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
Barry A. Warsaw added the comment:
Does the 2.x patch apply cleanly to 2.6?
Perhaps it's your job as a release manager to check that ;-P
--
___
Python tracker rep...@bugs.python.org
Barry A. Warsaw added the comment:
I'm working on applying the 2.x patch to 2.6, but one thing interesting of
note: sudo, at least on Debian and derivatives going back at least to Squeeze,
generally reset the environment by default (i.e. env_reset). So you'd have to
either have disabled
Antoine Pitrou added the comment:
I'm working on applying the 2.x patch to 2.6, but one thing
interesting of note: sudo, at least on Debian and derivatives going
back at least to Squeeze, generally reset the environment by default
(i.e. env_reset). So you'd have to either have disabled
Roundup Robot added the comment:
New changeset 936621d33c38 by Barry Warsaw in branch '2.6':
- Issue #16248: Disable code execution from the user's home directory by
http://hg.python.org/cpython/rev/936621d33c38
--
___
Python tracker
Changes by Antoine Pitrou pit...@free.fr:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
___
___
Python-bugs-list
Barry A. Warsaw added the comment:
I think this has now been applied to all of 2.6, 2.7, 3.1, 3.2, 3.3, and 3.4.
So, closing.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
___
Roundup Robot added the comment:
New changeset d8300842a0e9 by Antoine Pitrou in branch '3.2':
Issue #16248: Disable code execution from the user's home directory by tkinter
when the -E flag is passed to Python.
http://hg.python.org/cpython/rev/d8300842a0e9
New changeset 10d04bdb05ab by
Roundup Robot added the comment:
New changeset 822b472eff13 by Antoine Pitrou in branch '2.7':
Issue #16248: Disable code execution from the user's home directory by tkinter
when the -E flag is passed to Python.
http://hg.python.org/cpython/rev/822b472eff13
--
Antoine Pitrou added the comment:
Fixed. I will let Benjamin and Barry decide whether this deserves backporting
to security branches. Benjamin, Barry, please do your job :)
--
nosy: +barry, benjamin.peterson
resolution: - fixed
stage: - committed/rejected
status: open - pending
Roundup Robot added the comment:
New changeset 03b3124e9ea3 by Antoine Pitrou in branch '3.1':
Issue #16248: Disable code execution from the user's home directory by tkinter
when the -E flag is passed to Python.
http://hg.python.org/cpython/rev/03b3124e9ea3
--
status: pending - open
Zachary Ware added the comment:
Here are a pair of trivial patches that implement Antoine's suggestion of not
executing readprofile() if the -E flag is set. Current tests seem to pass, but
there are no new tests included because frankly I'm not sure of either how to
test it or where. Also,
Changes by Zachary Ware zachary.w...@gmail.com:
Added file: http://bugs.python.org/file27938/issue16248-3.x.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
___
Christian Heimes added the comment:
I'm all with Antoine's suggestion. readprofile() should not be executed when
sys.flags.ignore_environment is set.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
Stefan Krah added the comment:
Ramchandra Apte rep...@bugs.python.org wrote:
Almost nobody knows that when using tkinter, code in .Tk.py is executed.
(readprofile is not even documented!)
While in your example, it is quite easy to see that it will run .bashrc
The point of the example is that
Antoine Pitrou added the comment:
I'm gonna point people to the discussion about the -s flag of the Python
interpreter (added as part of PEP 370), since the issue is conceptually
identical:
http://mail.python.org/pipermail/python-dev/2008-January/076130.html
Adding Christian to the discussion
Christian Heimes added the comment:
It's gonna take a while to read this ticket ...
Some comments:
The code in site.py already does some checks, for example getuid() ==
geteuid(). System code and code that is run with administrator privileges shall
be run with -Es to prevent code injection.
Mark Dickinson added the comment:
Ramchandra: can you give an example of a realistic situation where the
existence of this code in tkinter allows users to execute code *that they
wouldn't be able to execute otherwise*?
--
nosy: +mark.dickinson
___
Changes by Andrew Svetlov andrew.svet...@gmail.com:
--
nosy: +asvetlov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
___
___
Ramchandra Apte added the comment:
@Mark Dickinson
Run the attached file, exploit.py, with normal priveleges and then run IDLE
with sudo (something I did to actually uncover this bug!).
Then the file /root/exploited should contain Exploit succeeded!
--
Added file:
Mark Dickinson added the comment:
Okay, but if a user can run IDLE with sudo, they presumably *already* have many
other ways to use sudo to create files in /root, without using IDLE or tkinter.
That's why I said: *that they wouldn't be able to execute otherwise*. I
don't see the security
Zachary Ware added the comment:
If I understand correctly, I think what Ramchandra is getting at is that if an
attacker could manage to get a .Tk.py file into a user's home directory
somehow, then the next time that user happens to do 'sudo idle', the attacker's
code is executed with root
Antoine Pitrou added the comment:
As Zachary and Ramchandra explained, the security issue is obvious: a
non-sudoer user A can make a sudoer user B execute arbitrary code, simply by
placing a file where IDLE will be run from.
This is the same reason Python has -s and -E options. The least we
Mark Dickinson added the comment:
And then user A is relying on user B executing IDLE via sudo? Is that a normal
thing to do?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
___
Antoine Pitrou added the comment:
And then user A is relying on user B executing IDLE via sudo? Is that
a normal thing to do?
Well, I suppose that could be any Tk app, not just IDLE.
And I also suppose you could use IDLE to edit some file that is only
root-writable.
--
Mark Dickinson added the comment:
So if this is a security issue, should Python 2.6 also be fixed?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
___
Antoine Pitrou added the comment:
So if this is a security issue, should Python 2.6 also be fixed?
Probably, if it's deemed important enough by our security RMs.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
Stefan Krah added the comment:
Isn't IDLE supposed to be a Python shell? As I understand this issue,
you'd have the same exploit by adding this to your .bashrc:
echo EXPLOIT /root/exploit
Then, as a normal user, run:
sudo bash
It would be nice to get rid of the exec, but why is this an
Antoine Pitrou added the comment:
As I understand it, this is not specifically about IDLE. Any Tk app would be
vulnerable.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
___
Guilherme Polo added the comment:
It is not IDLE specific. But I still fail to see how this actually is a
security bug. It doesn't give more power to the user than the user already
gave to it. If you are recklessly installing untrusted libraries or
anything for the matter, then you already have
Stefan Krah added the comment:
I also don't find the scenario where an attacker has write privileges
to a user's home directory so disturbing -- there are juicier targets
(like .bashrc).
This constructed example using /tmp is a little more troubling:
$ cd /tmp
$ echo 'print(exploit)' .Tk.py
Ramchandra Apte added the comment:
On 2 November 2012 01:48, Stefan Krah rep...@bugs.python.org wrote:
Stefan Krah added the comment:
Isn't IDLE supposed to be a Python shell? As I understand this issue,
you'd have the same exploit by adding this to your .bashrc:
echo EXPLOIT
Ramchandra Apte added the comment:
It is possible with this bug to make a sudo IDLE edit a root-file.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
___
Ramchandra Apte added the comment:
oops ignore last msg
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
___
___
Python-bugs-list mailing
Guilherme Polo added the comment:
I can ignore it, but let us be honest. If you got sudo privilege already, why
are you bothering to break (or whatever else) the system using IDLE ? The issue
here did not give you the sudo privilege. If it did, then we have an actual
security bug.
--
Ramchandra Apte added the comment:
I think this is a legitimate security bug.
the malicious program needs to create a file with a certain name in the home
dir.
If a user runs say IDLE (or another tk app) with root priveleges using sudo,
the file will be run with root priveleges.
--
Changes by Terry J. Reedy tjre...@udel.edu:
--
nosy: +terry.reedy -Want to Delete This Account
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
___
Guilherme Polo added the comment:
For something that has been around for so long, I would be a little more
careful.
My suggestion is: no longer declare readprofile as an internal function; remove
the direct call to readprofile from Tk.__init__; tell users about the new
behavior, and the need
Changes by Ramchandra Apte maniandra...@gmail.com:
--
title: Security bug in tkinter allows for untrusted code execution. - Security
bug in tkinter allows for untrusted, arbitrary code execution.
___
Python tracker rep...@bugs.python.org
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever, gpolo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
___
Guilherme Polo added the comment:
It is a well known fact that the readprofile function uses exec, and it has
been like that for more than 18 years. The parameters baseName and className
defines the execution of the files $HOME/.{className}.tcl,
$HOME/.{className}.py, $HOME/.{baseName}.tcl,
mani and ram added the comment:
On 17 October 2012 23:46, Guilherme Polo rep...@bugs.python.org wrote:
Guilherme Polo added the comment:
It is a well known fact that the readprofile function uses exec, and it
has been like that for more than 18 years. The parameters baseName and
className
Ramchandra Apte added the comment:
Apparently when replying by email my old account name is shown (mani and ram)
Just so you know that mani and ram is me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
67 matches
Mail list logo
