CVE-2008-5374 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-5374): bash-doc 3.2 allows local users to overwrite arbitrary files via a symlink attack on a /tmp/cb#####.? temporary file, related to the (1) aliasconv.sh, (2) aliasconv.bash, and (3) cshtobash scripts.
I tested =app-shells/bash-3.2_p48 with USE=examples, and it installs these files: ./usr/share/doc/bash-3.2_p48/examples/misc/aliasconv.bash ./usr/share/doc/bash-3.2_p48/examples/misc/aliasconv.sh ./usr/share/doc/bash-3.2_p48/examples/misc/cshtobash
unless i'm mistaken, this is only an issue when USE=examples, and if the person actually takes the example code and starts using it themselves. in other words, the affected scope is quite minor ... we can just `rm` the files for now ...
(In reply to comment #2) > unless i'm mistaken, this is only an issue when USE=examples, and if the person > actually takes the example code and starts using it themselves. in other > words, the affected scope is quite minor ... Indeed and it only affects ~arch ebuilds. I'd be in favor of tracking this issue upstream, bumping as they do and use this bug as a blocker for stabilization of the >=3.2_p39 ebuilds.
or we can just disable USE=examples when moving to stable. but otherwise, that sounds good to me.
Indeed I can confirm =bash-3.2_p51 (still in the tree) is affected by this issue with USE="examples". Now it gets more interesting because =bash-4.0_p37 (old stable) is also affected. =bash-4.0_p38 is affected. >=bash-4.1 is not affected. The choices I see are: - remove vulnerable ebuilds from the tree - mask the "examples" USE flag for vulnerable versions - remove the "examples" USE flag for vulnerable versions - patch the vulnerable versions to use mktemp instead
older versions no longer have USE=examples http://sources.gentoo.org/app-shells/bash/bash-3.2_p51.ebuild?r1=1.1&r2=1.2 http://sources.gentoo.org/app-shells/bash/bash-4.0_p38.ebuild?r1=1.1&r2=1.2
Looks like 4.1_p7 was the first unaffected, stable version. =app-shells/bash-3.1_p17 is the only vulnerable version left to be cleaned. Adding to existing GLSA request.
This issue was resolved and addressed in GLSA 201210-05 at http://security.gentoo.org/glsa/glsa-201210-05.xml by GLSA coordinator Sean Amoss (ackle).