While reading the changelog from Common C++ 1.3.0 to 1.3.1 I discovered that 1.3.0 includes two security holes that has been fixed in 1.3.1: - security fix; keydata config file paths can no longer be "relocated" through environment manipulation! "CONFIG_KEYDATA" env gone! - security fix; config files must be root owned or match process uid Reproducible: Always Steps to Reproduce: 1. 2. 3.
Hmm not sure what this is about. Looks like local privilege escalation through configuration file and environment manipulation... Anything in commonc++ running setuid root ? or is it commonc++-enabled SUID executables that could be exploited ? About affected packages: is it dev-cpp/commoncpp2 or dev-libs/commonc++ ?
> About affected packages: is it dev-cpp/commoncpp2 or dev-libs/commonc++ ? It's dev-cpp/commoncpp2 > is it commonc++-enabled SUID executables that could be exploited ? Yes. The Keydata class in commoncpp can be used by applications to provide an easy way to manage a config file.
No metadata.xml, calling last bumper. lanius, could you bump this to 1.3.1 ? Only the following packages depend on commoncpp2 in portage : sys-cluster/gomd sys-cluster/gomd-cvs Anyone knows if it includes any SUID root executable ? Pulling in tantive as gomd maintainer for inputs.
After talking to Heinrich Wendel (lanius) over email I have taken over maintainership of this package. 1.3.1 is in portage marked stable on x86 and amd64. I'm a new to security bugs so should I remove old versions from the tree?
Thx Anders. It is up to the maintainer to remove old vulnerable ebuilds but it is encouraged. For further information on how we do security bugs please consult the vulnerability policy: http://www.gentoo.org/security/en/vulnerability-policy.xml and the coordinator guide for practical matters: http://www.gentoo.org/security/en/coordinator_guide.xml Or just ping one of the security team members. Rating of this vulnerability is not final so going to GLSA decision (koon you're the winner of this lucky bug:-).
We used not to issue GLSAs for fixes in libraries that only affect SUID executables built against it, when nothing SUID in portage depends on it (see the xview precedent) so I vote NO, supposing gomd doesn't include SUID things.
I vote NO also.
Closed without GLSA, please reopen if you disagree
