Check requirements class before loading marshalled requirements #4651
Conversation
|
Hi @nobu, thanks! I think this is a good opportunity to move #3797 forward. I do think @hsbt What do you think? |
|
@nobu After having another look at this, even if we remove |
|
Correct, this doesn't fix the risk totally, but just "mitigate" for old ruby versions. |
deivid-rodriguez
force-pushed
the
check-requirements-classes
branch
2 times, most recently
from
8621c7c
to
662b9c6
Compare
|
I do believe that we can remove all |
deivid-rodriguez
changed the title
After reading [this blog post](https://blog.rubygems.org/2011/08/31/shaving-the-yaml-yak.html), published almost 10 years ago already, my understanding is that this problem could come up in two ways: * Rubygems.org serving corrupted gemspecs". As far as I understand this was fixed in rubygems.org a lot time ago, since rubygems/rubygems.org#331. * Clients having a ten years old gemspec cache with some of these bad gemspecs. In this case, there's no easy solution but I think ten years is enough and rebuilding the cache should do the trick. So, I think it's time we remove this.
Mitigate the security risk: https://devcraft.io/2021/01/07/universal-deserialisation-gadget-for-ruby-2-x-3-x.html
deivid-rodriguez
force-pushed
the
check-requirements-classes
branch
from
662b9c6
to
141c2f4
Compare
|
I do believe this shouldn't break anything, so I'll take this opportunity to clean things up and improve security at the same time. I don't think this is really exploitable so I tagged it just as an enhancement. |
|
Thanks @nobu! |
Check requirements class before loading marshalled requirements (cherry picked from commit a75f579)
Check requirements class before loading marshalled requirements (cherry picked from commit a75f579)
Mitigate the security risk:
https://devcraft.io/2021/01/07/universal-deserialisation-gadget-for-ruby-2-x-3-x.html
What was the end-user or developer problem that led to this PR?
Unexpected method (
Kernel#systemin the article) can be called by just loading marshaled data.What is your fix for the problem, implemented in this PR?
Check the classes of
@requirementsand its elements.Maybe
fix_syck_default_key_in_requirementsis no longer used and can be removed, but not sure.Make sure the following tasks are checked