Summary: | sys-apps/portage < 2.1.3.11 File disclosure when when merging with etc-update (CVE-2007-6249) | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | SpanKY <vapier> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dev-portage |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | A3 [glsa] | ||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 194041 |
Description
SpanKY
![]() (In reply to comment #0) > the exact fix is: > http://sources.gentoo.org/viewcvs.py/portage?rev=7799&view=rev > any input on how i fixed it would of course be welcomed, but the details are > merely: > - create tmpdir > - force permission of tmpdir to 0700 > - force ownership to user running `etc-update` > - store temp merged file in the tmpdir > - change the permission/ownership of merged file before overwriting old file >=sys-apps/portage-2.1.3.11 has that fix. the code actually in 2.1.3.11 is the following, which is very unlikely to work: # # Run the script # scriptname=$(basename $0) TMP="${PORTAGE_TMPDIR}/etc-update-$$" trap die term type portageq > /dev/null || exit $? eval $(portageq envvar -v CONFIG_PROTECT \ CONFIG_PROTECT_MASK PORTAGE_CONFIGROOT PORTAGE_TMPDIR ROOT USERLAND) export PORTAGE_TMPDIR I suggest setting PORTAGE_TMPDIR before trying to use it ;). (In reply to comment #2) > I suggest setting PORTAGE_TMPDIR before trying to use it ;). That's fixed in svn already. It still works, it's just that /etc-update-$$ is used as the temp dir, which is kind of weird. Just to be sure: This is fixed without known regressions in portage-2.1.3.16 which is going stable per bug 197165? Because it is not listed as blocking bug 194041. (In reply to comment #4) > Just to be sure: This is fixed without known regressions in portage-2.1.3.16 > which is going stable per bug 197165? That's right. This one is ready for glsa decision. It somehow slipped through because of the wrong component :-/ I tend to vote YES here. voting yes too, and this way, we'll be able to safely close #149062. (In reply to comment #7) > voting yes too, and this way, we'll be able to safely close #149062. Do you plan to release a combo-glsa, because otherwise these two are unrelated. GLSA 200712-11 |