https://marc.info/?l=oss-security&m=150760474431546&w=2 "# Unsafe Object Deserialization Vulnerability in RubyGems There is a possible unsafe object desrialization vulnerability in RubyGems. It is possible for YAML deserialization of gem specifications to bypass class white lists. Specially crafted serialized objects can possibly be used to escalate to remote code execution. This vulnerability has been assigned the CVE identifier CVE-2017-0903. Versions Affected: >= 2.0.0. Not affected: < 2.0.0 Fixed Versions: 2.6.14" portage contains only dev-ruby/rubygems-2.6.13, a vulnerable version. I've done a test emerge w/nothing but renaming the ebuild to 2.6.14, and it installed cleanly, although I did not do anything using the new gem yet. "Exploitation" is not all that meaningful or interesting when a client is installing a gem from an untrust(ed|worthy) source, because you're about to be executing their code anyway. But a server/service that processes uploaded gems w/o installing them, could be tricked into executing code.
dev-ruby/rubygems-2.6.14 has been added. Note that the impact of this issue is very low for Gentoo users, because this security bug only applies when running your own rubygems server where you are allowing submissions from unknown sources. Most likely only rubygems.org itself falls in that category.
(In reply to Hans de Graaff from comment #1) >dev-ruby/rubygems-2.6.14 has been added. Thank you, when ready feel free to call for stabilization...
It seems to me that the classification should be C2 because the vulnerability is only relevant when someone runs a rubygems server and this is a very unlikely case (certainly less than 5%).
hppa stable
ia64 stable
ppc/ppc64 stable
x86 stable
Stable on amd64
Stable on alpha.
arm stable, all arches done.
Thank you all. I'm re-assigning to C2 since it's a Remote Code Execution when exploited, even if users must run its own RubyGems server. @Security please vote. GLSA Vote: Yes
Cleanup done.
(In reply to Hans de Graaff from comment #1) > > Note that the impact of this issue is very low for Gentoo users, because > this security bug only applies when running your own rubygems server where > you are allowing submissions from unknown sources. Most likely only > rubygems.org itself falls in that category. Thank you, Hans, for the clarification and background. After double checking the pre-requisites to exploit this vulnerability in Gentoo, we agree that there won't be a GLSA for this specific issue. Tree is already clean and fixed. Closing without a GLSA.