> Upgrading to GitLab 19.3.6 on October 22 didn’t fix the vulnerability. The fix isn’t in GitLab’s own code but in a patch to Ruby, which GitLab applies only in its official packages. Our image used standard Ruby, so it didn’t get the patch.
> The bug is in Ruby’s regular expression engine, so any program that compiles regular expressions from untrusted input is exposed, not only GitLab.
I feel like this era of constant exploits/patches is really bad for those who build from source or make their own images vs those who rely on provided images and upgrade them often. I really can't think of a decent solution for those people other than being plugged in 24/7 to the latest news which is really unfortunate and must be exhausting...
esseph•50m ago
It's not maintainable unless you autobuild, and yes, upgrade treadmill.
Gigachad•6m ago
The patch for Ruby came out 6 days ago. Most Rails apps do not use the Ruby from the package manager but have a hardcoded version in the repo. So unless you have developers releasing a PR to update ruby the moment it comes out, you aren't safe.
This might feel like a "Yeah obviously" moment, but the fact is that very few Rails apps are running the latest ruby release the moment it comes out.
edoceo•47m ago
The PHP2Shell one was both lucrative and exhausting. I maintain a bunch of legacy PHP apps.
Gigachad•14m ago
At this point if you are self hosting you should have everything behind a VPN. Only companies with their own security and development teams should be putting things on the public internet.
awesome_dude•8m ago
> build from source or make their own images vs those who rely on provided images and upgrade them often.
I mean - this incident brings it into sharper focus - but it's always been thus.
As a Go developer I often tell people "Be wary of vendoring, you are creating a cache of dependencies that need to be managed and maintained"
Or people that "pin" dependencies, they face the same difficulty.
Why not just use "official" (in this case) images - sometimes they lag too - hell, most Linux distributions lag so much with Go compiler packages that, again, I routinely tell people to avoid them in favour of watching the Go official page
weinzierl•6m ago
At the beginning of the industrialization there were many accidents with steam boilers.
We've git that under control with regulation and the help of organizations, some of which still exist today.
This "era of constant exploits/patches" is not normal and can't go on. Currently it is an ongoing cat and mouse game, but it doesn't have to be.
rconti•5m ago
The world has changed but 15 years ago we thought it was utterly insane to just pull whatever $latest from $internetsite.probablytrusted.org as part of your build and deployment process.
cowlevel•11m ago
The bug is integer overflow in a random C data-processing library (specifically regexes) leading to RCE.
Who else is tired of C libraries since this week?
Gigachad•9m ago
I've been calling this out for forever now and have been repeatedly told that actually, competent devs with C are fine and the C software we use has been battle tested so it's largely secure.
JLO64•53m ago
> The bug is in Ruby’s regular expression engine, so any program that compiles regular expressions from untrusted input is exposed, not only GitLab.
I feel like this era of constant exploits/patches is really bad for those who build from source or make their own images vs those who rely on provided images and upgrade them often. I really can't think of a decent solution for those people other than being plugged in 24/7 to the latest news which is really unfortunate and must be exhausting...
esseph•50m ago
Gigachad•6m ago
This might feel like a "Yeah obviously" moment, but the fact is that very few Rails apps are running the latest ruby release the moment it comes out.
edoceo•47m ago
Gigachad•14m ago
awesome_dude•8m ago
I mean - this incident brings it into sharper focus - but it's always been thus.
As a Go developer I often tell people "Be wary of vendoring, you are creating a cache of dependencies that need to be managed and maintained"
Or people that "pin" dependencies, they face the same difficulty.
Why not just use "official" (in this case) images - sometimes they lag too - hell, most Linux distributions lag so much with Go compiler packages that, again, I routinely tell people to avoid them in favour of watching the Go official page
weinzierl•6m ago
We've git that under control with regulation and the help of organizations, some of which still exist today.
This "era of constant exploits/patches" is not normal and can't go on. Currently it is an ongoing cat and mouse game, but it doesn't have to be.
rconti•5m ago