A couple of days ago, on Italian Ruby mailing list, Paolo Montrasio reported two security issues occured in the ruby world.
Let’s see them in detail and add codesake-dawn checks for them.
CVE-2013-4164: ruby interpreter heap-based buffer overflow
Sometime they are back. In a world where modern programming languages take care about memory it’s uncommon to talk about buffer overflows.
As described in the original post, a special crafted string when converted to its floating point representation, it can cause an heap based buffer overflow.
Buffer overflows can cause the program to stop due to segmentation fault error (and this can be seen as a denial of service to the target application) or to arbitrary code execution if the instruction pointer register is successfully overwritten by the address of the malicious code.
Writing shellcodes is an art. I’m not that good in writing shellcodes but we will go deep in understanding what a buffer overflow is in future posts.
More importan is that “…any program that converts input of unknown origin to floating point values (especially common when accepting JSON) are vulnerable.”
This means that every code taking output from the external and turning it to a floating pointer number is vulnerable.
Ruby interpreters affected by this vulnerability are:
- All ruby 1.8 versions
- All ruby 1.9 versions prior to ruby 1.9.3 patchlevel 484
- All ruby 2.0 versions prior to ruby 2.0.0 patchlevel 353
- All ruby 2.1 versions prior to ruby 2.1.0 preview2
- prior to trunk revision 43780
Please note that accordingly to ruby roadmap, there is no further support to ruby 1.8 since it’s marked as end of life. Solution is to upgrade to Ruby 1.9.3 patchlevel 484, ruby 2.0.0 patchlevel 353 or ruby 2.1.0 preview2. If you are using ruby 1.8 version you really want to upgrade it now.
Fixing with codesake-dawn
I’m a lazy security guy and when I first designed codesake-dawn I spent the first two months coding the underlying security check API. The original idea was that most of the security checks I want to implement can be described by some very few general security checks implementing all the testing logic.
A new control in the knowledge base must contain just the parameters the underlying API needs to say if your code is vulnerable or not.
So, checking for CVE-2013-4164 means adding in codesake-dawn another ruby class including Codesake::Dawn::Kb::RubyVersionCheck with the information about the ruby interpreter versions, codesake-dawn has to consider as safe.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
CVE-2013-4562: the omniauth-facebook gem cross site request forgery
omniauth-facebook ruby gem introduced in the vulnerable version an anti-CSRF mechanism that it’s broken. Since the gem supports setting a per-request state parameter by storing it in the session, it is possible to circumvent the automatic CSRF protection.
Versions prior 1.4.1 are not vulnerable since they don’t implement such kind of security mechanism, so you must not downgrade your gem in order to fix this vulnerability. The only way to mitigarte the vuln is to upgrade the gem to version 1.5.0.
Fixing with codesake-dawn
Implementing a check against a particular version of a ruby gem with codesake dawn is easy. You must create a new class, implementing the checks and including the Codesake::Dawn::Kb::DependencyCheck class.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
All the changes to codesake-dawn are already online with this commit.
While preparing the post I noticed I missed also a cocaine ruby gem security announce. The Cocaine gem 0.4.0 through 0.5.2 for Ruby allows context-dependent attackers to execute arbitrary commands via a crafted has object, related to recursive variable interpolation.
The CVE it was assiegned is CVE-2013-4457 and the implementation in codesake-dawn is done this way:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30