David A. Wheeler
One component we use (omniauth) has a publicly-known vulnerability (CVE-2015-9284) that is still not fixed. To deal with this, we’ve taken unusual steps to eliminate the vulnerability’s effect in the BadgeApp. Below are the details, in case you want to know more.
--- David A. Wheeler
As you know, the best practices badge is implemented by the “BadgeApp”. Various mechanisms warn us when there’s a publicly-known vulnerability in a component used by the BadgeApp (directly or indirectly), and we normally quickly update, test, and ship the update.
Unfortunately, we’ve had a complication. One component we use is “omniauth”, which has vulnerability CVE-2015-9284. Unfortunately, while they continue to discuss it, they have *NOT* fixed it, and this vulnerability has become publicly known. What’s more, as you can tell by the CVE number this was reported back in *2015*. I think it’s embarrassing that it’s still not fixed.
My patience is exhausted. This is not a trivial exploit to pull off, but it’s a dangerous one: it allows an attacker to take over another’s account. And since the omniauth developers have failed to fix it for 4 years, I don’t have high hopes that they will fix it soon. There is a third-party fix named omniauth-rails_csrf_protection. I’m always leary of third-party fixes, but I think it’s our best option. I reviewed its code & it appears okay. I’ve incorporated the third-party fix by locking our download to the commit cryptographic hash that I reviewed; the hash lock counters tricks like “the RubyGems version is different from the one on GitHub” and “we silently upgraded/switched to a malicious version.” So among our options I think this is the best one, and I think I’ve mitigated the biggest risks of this option. We may look more seriously at removing omniauth in the longer term (since security components should be responsive to security issues), but for the moment I want to immediately resolve the *known* problem.
For more detail see: