Which brings us to the old saying: Do not deserialize untrusted data.
In the context of Rubygems and their specs this obviously is harder to manage but dependencies such as Rubygems are and will always be part of your app's Trusted Computing Base.
> dependencies such as Rubygems are and will always be part of your app's Trusted Computing Base
This mindset is changing, in the npm ecosystem, managing and updating dependencies have become somewhat of a gamble. It is no longer if, its when you are compromised.
Look at TOB-RGM-9 (an informational, largely out-of-scope finding) if you want to understand what could be done to mitigate some of these concerns. Nearly all of these gadget chains rely on Gem library functionality, which has this wonky .gemspec.rz metadata file that sits alongside the actual gem file. I understand that it'd be a challenging, backwards-incompatible change, but moving this file from Marshal to JSON would break a lot of these gadget chains. Perhaps there would be others, but it would raise the bar.
Did the OpenAI "sandbox" have Ruby available or a "sandboxed Ruby", which is an idiotic idea that would be fully expected from slop companies?
We are living in a post-fact society where we have to guess bits of information from YouTube videos and OpenAI slop statements. Maybe there should be a Senate hearing about the hack if that is what it takes.
That's actually crafty. I wonder what the rationale was for the C function time_mload(). Anyone able to find out? How can we see which person created it first?
Doesn't this already require to be "on the other side of the airtight hatchway", or am I missing something?
The Marshal.load docs explicitly have a warning that you should not pass it untrusted data: https://docs.ruby-lang.org/en/master/Marshal.html#module-mar...
Yes, but that doesn't mean defense-in-depth isn't worth doing. The article discusses how known gadgets were removed in the past.
Which brings us to the old saying: Do not deserialize untrusted data.
In the context of Rubygems and their specs this obviously is harder to manage but dependencies such as Rubygems are and will always be part of your app's Trusted Computing Base.
> dependencies such as Rubygems are and will always be part of your app's Trusted Computing Base
This mindset is changing, in the npm ecosystem, managing and updating dependencies have become somewhat of a gamble. It is no longer if, its when you are compromised.
Gems/packages should explicitly declare what kind of features they need/want (file, net, deserialization, execute)
And when the sig. changes, you should get a warning
Very similar to the iOS entitlements
Checksumming the dependencies in the Gemfile may help. https://blog.rubygems.org/2024/12/19/bundler-v2-6.html
I have to use several gems that download and compile C sources from github at install time.
> Do not deserialize untrusted data.
I think the better lesson is "use safe codecs"
LLMs: hold my beer
I wrote one of the referenced posts describing the history here: https://blog.trailofbits.com/2025/08/20/marshal-madness-a-br...
I was also part of the team that audited RubyGems.org: https://github.com/trailofbits/publications/blob/master/revi...
Look at TOB-RGM-9 (an informational, largely out-of-scope finding) if you want to understand what could be done to mitigate some of these concerns. Nearly all of these gadget chains rely on Gem library functionality, which has this wonky .gemspec.rz metadata file that sits alongside the actual gem file. I understand that it'd be a challenging, backwards-incompatible change, but moving this file from Marshal to JSON would break a lot of these gadget chains. Perhaps there would be others, but it would raise the bar.
thanks for your work <3
Did the OpenAI "sandbox" have Ruby available or a "sandboxed Ruby", which is an idiotic idea that would be fully expected from slop companies?
We are living in a post-fact society where we have to guess bits of information from YouTube videos and OpenAI slop statements. Maybe there should be a Senate hearing about the hack if that is what it takes.
Quoting the ruby documentation:
> Marshal.load is not suitable as a general purpose serialization format and you should never unmarshal user supplied input or other untrusted data.
That's actually crafty. I wonder what the rationale was for the C function time_mload(). Anyone able to find out? How can we see which person created it first?
The source code for that function is at https://github.com/ruby/ruby/blob/a75a8ccd9d2fa46eb68fe21469...
You can check the git blame and all the history. Unsurprisingly the function itself is from the 90s.