rubysec / ruby-advisory-db Goto Github PK

https://github.com/codahale/bcrypt-ruby states:

Note: JRuby versions of bcrypt-ruby <= 2.1.3 had a security vulnerability that was fixed in >= 2.1.4. If you used a vulnerable version to hash passwords with international characters in them, you will need to re-hash those passwords. This vulernability only affected the JRuby gem.

http://www.mindrot.org/files/jBCrypt/internat.adv

Should a non_affected_versions attribute be added?

For example 2012-2661.yml doesn't affect Rails v2.3. This would allow an automated tool to look over a Gemfile and work out whether any advisories affect your gems.

Should use Travis CI / Circle CI to automagically update the rubysec.github.io repository and push changes live as new advisories are added to the ruby-advisory-db repository.

Right now, http://rubysec.com is woefully out of date. :(

Happy to help here if I can...

Similar to #20, would be great if vulnerabilities in rubygems could be tracked as part of this project. Right now, there isn't a good way to track that, and stuff gets missed. People rarely remember to upgrade rubygems.

We were talking about automating the process of generating a feed from this data automatically.

@phillmv you were saying we can use github-pages for this?

Add an API for interacting with the database.

• Searching for advisories by CVE or gem.
• Testing if a Gem::Version is vulnerable.
• Downloading and updating a copy of the database.

We should add a workarounds: text section, for when there is no upgrade or the developers cannot upgrade.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-2538

not sure how this slipped by, but would be nice to have some automated tools to catch these

Do we add an advisory on this?

http://osvdb.org/show/osvdb/118954
rails/rails#19055
rails/rails#19050

• http://otiose.dhs.org/advisories/ftp-0.2.1-remote-exec.html
• http://osvdb.org/show/osvdb/90784

To counter people's fears of malicious YAML somehow getting into the DB (an attacker compromises our GitHub account or ssh keys), we should consider adding PGP signed tags for when a new advisory is added to the DB. This would allow consumers of the DB to update to the latest tag and verify it (git tag -v $TAG).

• https://support.cloud.engineyard.com/entries/22915701-january-14-2013-security-vulnerabilities-httparty-extlib-crack-nori-update-these-gems-immediately
• http://direct.osvdb.org/show/osvdb/90740

Still needs a CVE.

Just discovered today:

resque/redis-namespace@6d83951

-Bryan

• https://support.cloud.engineyard.com/entries/22915701-january-14-2013-security-vulnerabilities-httparty-extlib-crack-nori-update-these-gems-immediately
• http://direct.osvdb.org/show/osvdb/90741

Needs a CVE first.

• http://osvdb.org/show/osvdb/90718
• http://osvdb.org/show/osvdb/90716
• http://osvdb.org/show/osvdb/90717
• http://osvdb.org/show/osvdb/90715

Thought: Would it be beneficial to have a date of first known disclosure associated with advisories? This may be different from an OSVDB date, right?

Change url: to point to the original Advisory. Also add a osvdb: field.

Should we list vulnerabilities on ruby versions/implementations? If so, how?

It would be good to include a LICENSE file clarifying the intended license for the data in the repo. I had someone ask me today about contributing, but wanted to ensure they would be contributing to a properly licensed OSS project so their contributions would always be able to be re-used.

MIT?

Some of the rails vulnerabilities actually affect rails components that can be used outside of rails. For instance, CVE-2013-0156 is a vulnerability with action_pack which can be used with any Rack application, not just rails.

What's the best way to re-categorize these?

While https://github.com/rubysec/ruby-advisory-db/tree/master/gems/sup have different CVEs, it's the same vuln with the same fixed versions

Maybe we should merge them?

Hi there, I really want to move dawnscanner to consume this, but I'm puzzled on to do this in an elegant way since it's a very dynamic archive.

My need is that dawnscanner has to check if this archive is updated, download signatures (the YAML files) and than consume them in a review.

How do you suggest me to act? Make a clone each scan can be very bandwith consuming. Having a copy offline and pulling from the scanner sometime it requires me to understand how much updated is the copy.

What do you think packing up the db in a gem or as alternative having an archive version number stored and updated somewhere?

Hey folks,

So last few days I've noticed that we often offer more information than the equivalent OSVDB links we point to.

We don't want to duplicate ID efforts; clearly we should stick to OSVDB and CVE values. But given the choice between a github issue/an advisory published by the author(s)/maintainers and a sparse OSVDB, it seems like it would make more sense and be more informative to point to the original upstream announcement.

Given the OSVDB, one can always regenerate that link. Alternatively, we can modify the schema to add multiple urls in case there are multiple pieces of context.

Does anyone have any thoughts or objections on this?

Hey there. Is this something that needs to be added in some way, or is it nonrelevant?

http://blog.plataformatec.com.br/2013/08/csrf-token-fixation-attacks-in-devise/

If you visit:

http://www.ruby-doc.org/

You will see:

"There was 1 Ruby vulnerability reports in the last 14 days. 1 undetermined. Most recent: CVE-2013-1656. See details."

You are presented with a friendly reminder of recent Ruby security vulnerabilities! Seems good!

PROBLEM: this goes to http://web.nvd.nist.gov/

Shouldn't this go to ruby-advisory-db in some form or another?

Some vulnerabilities don't have a CVE associated with them

• omniauth-oauth2 omniauth/omniauth-oauth2#25
• newrelic_rpm https://newrelic.com/docs/ruby/ruby-agent-security-notification
• nori savonrb/nori@818f526 (related to 2013-0156)

So,

1. We should get some CVEs issued for these, and get them up on OSVDB
2. To me, this is a good reason to reconsider CVE ID's as filenames, especially if as in the case of nori, the same CVE appears multiple times in our DB (I can create a separate issue about this).

It would be nice if we imported some (maybe not all) of the classification information for advisories. This would provide the user with a more detailed breakdown of the advisory, than say CVSSv2 score.

Example

classification:
  location: remote
  attack_type: input_manipulation
  impact: loss_of_integrity

We moved all the rails vulns to the respective gems (actionpack, activerecord, etc), but from the user's perspective it would be nice if our tools detect that they have rails and tell them that rails is what they should upgrade.

We could add a field to communicate that.

To avoid confusion, all files should have a CVE- prefix. This also allows us to add advisories when no CVE exists yet (instead using a vendor specific advisory ID).

sparklemotion/nokogiri#693

Network vulnerability fixed in Nokogiri v1.5.4:

http://www.ruby-forum.com/topic/4402659

Not sure when local filesystem vulnerability was fixed.

lib/scrape.rb is useless right now since http://osvdb.org is constantly in CloudFlare's "I'm under attack" mode.

Need to incorporate the use of https://github.com/Anorov/cloudflare-scrape or https://github.com/jeremyhahn/cloudflare-scraper to bypass the checks and allow the scraper to work.

Another option is to use OSVDB's API, but you can't seem to sign-up for it nowadays (see https://osvdb.org/account/signup).

Sorry if i have to add an issue for this question, but what exactly does the file "#CVE-2012-3424.yml#" do (commit: da3fd5c)?

https://groups.google.com/forum/?fromgroups=#!searchin/nokogiri-talk/vulnerability/nokogiri-talk/PZK-KcxC_gE/EmB7DFYGGp8J

Heya,

The file at https://github.com/rubysec/ruby-advisory-db/blob/master/gems/actionpack/2012-3424.yml reports the following patched versions:

• ~> 3.0.16
• ~> 3.1.7
• ">= 3.2.7"

Whereas http://www.osvdb.org/show/osvdb/84243 lists the patched versions as:

• 3.0.16
• 3.1.7
• ">= 3.2.7"

The use of the spermy operator seems wrong here (and in other places as well). Is this intentional or am I misinterpreting something?

Many thanks for the otherwise brilliant work,
Tom

http://spreecommerce.com/blog/multiple-security-vulnerabilities-fixed

I've updated all the advisodies with OSVDB IDs. We now have one advisory in the database (loofah/OSVDB-90945.yml) and several vulnerabilities in the queue that have OSVDB IDs but not CVE IDs. Based on Jericho's comments in the mailing list that is going to continue to be the case.

Would it make sense to switch to OSVDB as the canonical ID?

Alternatively we can implement a RUBYSEC-XXXX ID scheme. The only downside would be with conflicts when multiple people submit the same vulnerability, but I think this is actually non-issue since we have only a few people with commit-rights, we can just quickly resolve RUBYSEC-XXXX ID conflicts over github.

Thoughts?

What's the best way to handle OSVDB entries / CVE assignments for ruby gems with unfixed vulnerabilities? Specifically, maybe a gem is obsolete / unmaintained and won't ever have a new fixed version, but we want to let people know they are using a vulnerable gem. Another case is when a gem takes too long to fix an issue, but we want to warn users so they are aware (maybe not cause a failure, but at least a warning in those cases).

Add a CONTRIBUTING.md for people who want to add advisories.

Replace cve: with advisories:, containing fully qualified advisory IDs. This allows us to list multiple advisory IDs per advisory. By switching to Fully Qualified Advisory IDs, we prevent people from mistakenly importing cve: 2013-0123 as 2013-0123 into some Database.

Example

advisories:
 - CVE-2013-0123
 - OSVDB 1234

This vulnerability
https://github.com/rubysec/ruby-advisory-db/blob/master/gems/passenger/OSVDB-90738.yml
affects versions 4.0.0.beta1 and 4.0.0.beta2 ( see http://old.blog.phusion.nl/2013/03/05/phusion-passenger-4-0-beta-1-and-2-arbitrary-file-deletion-vulnerability/)

The current patched_versions and unaffected_versions don't cover that.

Is it possible to write the conditions that will capture this vuln using only patched_versions and unaffected_versions, or do we need to add a vulnerable_versions field?

(cc @postmodern I ran some test cases with bundler_audit and it fails as well).

Although the announcement didn't mention it, rack 1.4.6 also fixes the vulnerability as can be seen from the changes: https://github.com/rack/rack/commits/1.4.6

The current db entry doesn't list 1.4.6 as a fixed version.

The advisory files may be copied or renamed. Perhaps we should include CVE / OSVDB IDs in the YAML? This could also be used to derive CVE / OSVDB URLs.

This CVE is also fixed in rails 3.2.22 as noted int he release notes:
http://weblog.rubyonrails.org/2015/6/16/Rails-3-2-22-4-1-11-and-4-2-2-have-been-released-and-more/

Currently 3.2.22 is missing from the list of fixed versions.

https://rubygems.org/gems/bcrypt and https://rubygems.org/gems/bcrypt-ruby are the same gem (renamed in bcrypt-ruby/bcrypt-ruby@aadbef4), but we only track vulnerabilities for the latter. Should we just duplicate the directories somehow, or what's the best way to deal with this issue?

Does the database need to have a more detailed recording of affected version numbers.

for example the CVE-2013-0284 for newrelic_rpm gem has the configuration:

patched_versions: 
  - ">= 3.5.3.25"

However the vulnerability only affects versions 3.2.0 -> 3.5.2.
Someone with a newrelic_rpm gem version prior to 3.2.0 is not affected by the vulnerability.

Perhaps as well as the patched_versions it is necessary to record the affected versions? This may be handy in the cases when no patched_version is available yet.

e.g

affected_versions: 
  - ["< 3.5.3.25",">= 3.2.0"]

In the example above a gem version would need to be true for any conditions to be considered affected. if the condition is an array (like above) then it must be true for each condition in the array to be considered to have met the overall conditions.

another example say for active-record CVE-2013-0155
e.g

affected_versions: 
  - [">= 3.0.0","< 3.0.19"]
  - [">= 3.1.0","< 3.1.10"]
  - [">= 3.2.0","< 3.2.11"]

If no affected_versions are recorded I guess one can assume all version not matching patched_versions are affeceted.

This issue is very similar to issue #4 , but implemented differently

• https://support.cloud.engineyard.com/entries/22915701-january-14-2013-security-vulnerabilities-httparty-extlib-crack-nori-update-these-gems-immediately
• http://direct.osvdb.org/show/osvdb/90742

Needs a CVE first.

"A vulnerability in the API was discovered which could allow an attacker to commit CSRF gaining access to private information." https://spreecommerce.com/blog/security-updates-2015-3-3

I didn't found any official identifier.

Rename to ruby-vuln-db, to avoid confusing this Database with a place to report Advisories. Thoughts?