** Please note that this issue is confidential and no information should be disclosed until it is made public, see "Whiteboard" for a date ** python-updater since at least 0.5 and including 0.7 (old and new stable) are a bash script that calls: /usr/bin/python -c 'import portage' This will include the current working directory in the module search path and can be exploited by a malicious user that triggers another user (typically root) to call "python-updater" from a directory containing a trojan horse python module. The python call should include code to clean the cwd from sys.path. Please propose a patch and attach it to this bug. We would like to do prestable testing under embargo and coordinate a new python-updater release with a GLSA.
Firstly, this bug seems to be a duplicate of bug #224925. Secondly, 'python -c "import sys; sys.path.remove(''); import portage"' can be used. Thirdly, the get_portage_python() function seems to be a part of never finished support for Portage installed in site-packages directory. The output of this function is assigned to PORTAGE_PYTHON variable which is never used. There is also '[[ $? != 0 ]] && exit 1', so if 'portage' module wasn't found anywhere, then python-updater would exit. 'portage' module isn't installed in site-packages directory, so this code (get_portage_python() function, all assignments of PORTAGE_PYTHON variable and '[[ $? != 0 ]] && exit 1') could be safely removed. Zac, are there any plans to install 'portage' module in site-packages directory in future versions of Portage?
(In reply to comment #1) > Zac, are there any plans to install 'portage' module in site-packages directory > in future versions of Portage? No, because /usr/lib/portage works smoothest for python upgrades (python3 even).
Arfrever, can you please attach a patch against python-updater 0.7 to this bug so we can prepare stabling of this version here?
(In reply to comment #3) Yes, I will create attachment. I was very busy recently.
Created attachment 214227 [details] Updated python-updater I'm attaching updated python-updater file, which will be included in app-admin/python-updater-0.8 probably without additional changes.
Created attachment 214636 [details] Updated python-updater
Arch Security Liaisons, please test the attached file and report it stable on this bug. Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86" CC'ing current Liaisons: alpha : armin76, klausman amd64 : keytoaster, chainsaw hppa : jer ppc : josejx, ranger ppc64 : josejx, ranger sparc : armin76, tcunha x86 : fauli, maekke If you (esp. armin76, maekke) want to do any of your other arches as well, feel free to.
Seems to do what it should on x86.
I get this and I don't get it: elmer ~ # sh /keeps/gentoo/bugs/288361/python-updater.txt * Starting Python Updater [New main active Python version: 2.6] /keeps/gentoo/bugs/288361/python-updater.txt: command substitution: line 530: syntax error near unexpected token `<' /keeps/gentoo/bugs/288361/python-updater.txt: command substitution: line 530: `scanelf -qF "%F %n" < <(grep -E "^obj" "${content}" | cut -d" " -f2) | grep -E "( |,)${OLD_PYTHON_SHARED_LIBRARIES_REGEX}(,|$)")"' * No packages need to be reinstalled.
Also, the diff between stable 0.7 and the attached version is HUGE: elmer ~ # diff -u /usr/sbin/python-updater /keeps/gentoo/bugs/288361/python-updater.txt | diffstat python-updater.txt | 468 ++++++++++++++++++++++++++++++++++------------------- 1 file changed, 306 insertions(+), 162 deletions(-) Shouldn't you issue a version that branches out to simply fixes this security problem and /then/ focus on development again?
(In reply to comment #10) > Shouldn't you issue a version that branches out to simply fixes this security > problem and /then/ focus on development again? > Yes. Arfrefer, please prepare another version.
(In reply to comment #9) You probably have POSIXLY_CORRECT set in environment. `set -o posix` would also set it. You should disable it.
(In reply to comment #12) > (In reply to comment #9) > > You probably have POSIXLY_CORRECT set in environment. `set -o posix` would also > set it. You should disable it. No I don't. But I was running it through `sh '. Marking it executable and running it without `sh ' prefixed makes the problem go away. Still, I don't know how many 9999 users you have out there, but I still think it's safer to apply the security patches to the current stable.
(In reply to comment #13) > Still, I don't know how many 9999 users you have out there, but I still think > it's safer to apply the security patches to the current stable. > Arfrefer, please provide the 0.7-r1 as discussed on IRC *immediately*.
Created attachment 215099 [details] python-updater-0.7-r1.ebuild.patch
Created attachment 215151 [details, diff] Changes generated by sed For easier review, I'm attaching the patch containing changes generated by sed.
HPPA seems to be OK (and PPC too, josejx).
As stated in a #gentoo-security discussion, there are concerns raised by craig, and supported by Chainsaw, myself, and QA to the nature of the fix propagation method (sed), we expect an ebuild that uses the diff attached here and epatch. I am postponing the CRD by seven days. Sorry, arch guys for the inconvenience.
Created attachment 216245 [details, diff] python-updater-0.7-r1.ebuild.patch Each Gentoo developer should be able to imagine this patch. Additional delaying seems to be unreasonable.
I'm planning to add app-admin/python-updater-0.7-r1 to the tree maybe tomorrow.
app-admin/python-updater-0.7-r1 is now in the tree. It's currently stable on hppa and ppc.
x86 done
Wow, nothing happened for more than a month?
I've marked it ppc64 stable as well.
GLSA request filed.
0.8 stable, is this still needed? Or at least the arch liaisons need to be cc'ed?
GLSA 201009-08, thanks everyone.
