Yes, but that doesn't mean defense-in-depth isn't worth doing. The article discusses how known gadgets were removed in the past.
ksbd-pls-finish 4 hours ago [-]
It's not a vulnerability, but it's an exploit. Most vulnerabilities in the wild never have an exploit written, because we mostly assume that for example arbitrary write or buffer overflow are dangerous and "can lead to arbitrary code execution", but actually exploiting them is hard.
This is someone who spend some time to write something to actually exploit sites with this vulnerability.
superjan 4 hours ago [-]
You only need one dev with the bright idea to pass data around via a clientside blob or cookie.
sebiw 12 hours ago [-]
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.
sscaryterry 11 hours ago [-]
> 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.
jbverschoor 10 hours ago [-]
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
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.
dorianmariewo 8 hours ago [-]
thanks for your work <3
mono442 10 hours ago [-]
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.
35129ab 7 hours ago [-]
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.
2_foos_in_a_bar 47 minutes ago [-]
I've yet to watch the BlackHat breakdown of how the "hack" (felony) proceeded, but being that it's OpenAI, it is safe to assume that the "sandbox" they speak of was a kitted-out Linux box with unmonitored network access.
The test environment was either intentionally setup to produce the outcome that it did or the sheer incompetence of a slop engineer was the catalyst for the crime. OpenAI is just an unscrupulous, childish company.
rdevilla 6 hours ago [-]
[dead]
jamesgeck0 6 hours ago [-]
So much for coordinated disclosure, I guess.
shevy-java 9 hours ago [-]
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?
You can check the git blame and all the history. Unsurprisingly the function itself is from the 90s.
saadyousfi 10 hours ago [-]
the java ecosystem spent a decade on the same lesson. commons-collections was the first universal gadget library, and attempts to remove gadgets from the classpath were an endless game of catch-up. JEP 290 was the eventual solution: a filter mechanism that enforces which classes are even allowed to be deserialized, rather than trying to audit what classes exist. ruby doesn't have an equivalent. as long as marshal.load on untrusted input exists in the codebase, chasing individual gadgets isn't the fix.
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...
This is someone who spend some time to write something to actually exploit sites with this vulnerability.
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.
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.
And when the sig. changes, you should get a warning
Very similar to the iOS entitlements
I think the better lesson is "use safe codecs"
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.
> Marshal.load is not suitable as a general purpose serialization format and you should never unmarshal user supplied input or other untrusted data.
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.
The test environment was either intentionally setup to produce the outcome that it did or the sheer incompetence of a slop engineer was the catalyst for the crime. OpenAI is just an unscrupulous, childish company.
You can check the git blame and all the history. Unsurprisingly the function itself is from the 90s.