CodeIgniter security and CVE database

JaneX8 commented 9 years ago

Hello CodeIgniter developers,

I noticed a few known security vulnerabilities (CVE-numbers) that apply to the CodeIgniter project (official CPE name cpe:/a:codeigniter:codeigniter).

For cpe:/a:codeigniter:codeigniter:1.5.3 are four registered CVE reports:

CVE-2007-3709
CVE-2007-3708
CVE-2007-3707
CVE-2007-3706

For cpe:/a:codeigniter:codeigniter:1.7.2 is just one known security report:

CVE-2011-3719.

Source: http://www.cvedetails.com/vulnerability-list/vendor_id-6918/product_id-11625/Codeigniter-Codeigniter.html

I read some CVE related posts and I noticed that the value of a CVE database is not always appreciated or understood. Source:

Nevertheless I'm wondering why there are not more CVE's reported so far. I've been pretty active in following the CodeIgniter development and noticed last years that some security bugs have been fixed but are never reported to the CVE database.

I'm happy that CodeIgniter is an open-source project and like to contribute to that. Especially using my IT security expertise. For that reason I'd like to work out some CVE reports about different security bugs in previous versions that are currently fixed. This way there will be a clear and open view about the amount of security vulnerabilities per version and hopefully this will encourage the developers who didn't upgrade, to upgrade to the latest version of CodeIgniter.

For people who are unfamiliar to this world. In comparison and as an example this are the CVE lists of some other PHP frameworks and WordPress.

Yii: http://www.cvedetails.com/vulnerability-list/vendor_id-13516/product_id-28088/Yiiframework-Yiiframework.html

Zend: http://www.cvedetails.com/vulnerability-list/vendor_id-5025/product_id-18532/Zend-Framework.html

Symfony: http://www.cvedetails.com/vulnerability-list/vendor_id-11981/product_id-22402/Sensiolabs-Symfony.html

WordPress: http://www.cvedetails.com/vulnerability-list/vendor_id-2337/product_id-4096/Wordpress-Wordpress.html

I'd like to hear some thoughts about this and especially I'm wondering if I should just work out some PoC's and just submit the bugs to the CVE database, or to discuss those bugs here before submitting them, just to make sure. Any thoughts?

Also I'm working on a small concept for the same purpose. To try to detect the used CodeIgniter version on a website or application. https://github.com/Calico90/codeigniter-version-scanner

Greetings!

narfbg commented 9 years ago

Maybe CVE databases are indeed underappreciated by us, but even if that's the case, I don't think I can ever see the value in bulk-submitting issues from long-forgotten CI versions to a CVE database, especially for pre-2.1.x versions.

There are a few reasons for that, but most notably - most of our users are beginners who don't know what a CVE database is in the first place. I'm very confident in saying that the ones who would pay attention to CVEs have already upgraded to the latest CI release.

JaneX8 commented 9 years ago

@narfbg Thanks for sharing some thoughts. How do you feel about registering (some of) the already fixed vulnerabilities to this databases?

narfbg commented 9 years ago

I've got nothing against that, which ones do you have in mind?

@benedmunds @jim-parry You should be in the loop on this one too. :)

JaneX8 commented 9 years ago

Thanks @narfbg sounds great, I'm diving into some old bugs now. I'd like to start with a old SQL injection that is fixed on 7 Sept 2011 in system/database/DB_active_rec.php CI version 2.0.3 (commit f08548b2b88324c36729a7dd4d179a9e1076dc14). It's a SQL injection reported on several places. I just played around with a successful proof of concept in version 2.0.3. I didn't test older versions yet, but I guess (but didn't verify yet) they are also vulnerable since the introduction of Active Queries.

It has been noted on several issues. #36, #199, https://github.com/bcit-ci/CodeIgniter/pull/370 and https://github.com/bcit-ci/CodeIgniter/pull/401

Some thoughs from @benedmunds and @jim-parry?

jim-parry commented 9 years ago

I would find it much more useful to find (& fix) security flaws in the current (3.0.x) or legacy (2.2.3) versions of CodeIgniter. Knowing that there is a flaw in an earlier, no longer supported version if CI might be interesting, but won't result in changes, and should not be raised on gihub as an issue, IMHO.

The CVE database is interesting, but it does not appear to distinguish between versions of a product, like CI. If that is indeed th case, and products are "rated" by the total number of vulnerabilities, relevant or not, than reporting old bugs would seem irresponsible.

JaneX8 commented 9 years ago

@jim-parry Thanks for your view. I can stop posting about these on github since I agree that this is not an current issue of the latest release. But I figured it would be polite to discuss/notify about this subject, before just adding vulnerabilities it to a database.

Luckily the CVE structure allows us to distinguish versions. For example see: http://www.cvedetails.com/version-list/6918/11625/1/Codeigniter-Codeigniter.html for vulnerabilities per version. For an overview of type and date see: http://www.cvedetails.com/product/11625/Codeigniter-Codeigniter.html?vendor_id=6918

Every CVE is linked to one or multiple CPE's. Every own version get's is own CPE. Like:

cpe:/a:codeigniter:codeigniter:1.5.3
cpe:/a:codeigniter:codeigniter:1.7.2

I'm also interested in researching the latest CodeIgniter and I probably will later, but I just noticed that still some critical vulnerabilities are maybe not known. And potentially not flagged by automated security scanners (since they also base there findings partly on the CVE database). It would be nice if I ran a scan and on my website and it warns me to update my CodeIgniter version because it detected that I'm using an outdated version.

I understand you are more interested in finding of the current release, but unfortunately that doesn't make the old risks less dangerous/vulnerable or serious. Are you completely against posting such reports about old versions or do you feel like it can be helpful somehow?

narfbg commented 9 years ago

@Calico90

Thanks @narfbg sounds great, I'm diving into some old bugs now. I'd like to start with a old SQL injection that is fixed on 7 Sept 2011 in system/database/DB_active_rec.php CI version 2.0.3 (commit f08548b). It's a SQL injection reported on several places. I just played around with a successful proof of concept in version 2.0.3. I didn't test older versions yet, but I guess (but didn't verify yet) they are also vulnerable since the introduction of Active Queries.

It has been noted on several issues. #36, #199, #370 and #401

Seems appropriate. However, I'd like to take on a full list rather than processing them one by one - can you do that?

@jim-parry

Yes, this is not a discussion that we'd typically have here, but I thought some transparency may help in this case ... actually, transparency is at the core of this topic. :)

We may still move this to mail though, I'm indifferent on that.

JaneX8 commented 9 years ago

Thanks @narfbg, I will make an inventory of bugs that can eligible for a official CVE report.

CVE-2013-4891 happen to be reserved for this bug https://nealpoole.com/blog/2013/07/codeigniter-21-xss-clean-filter-bypass/ but is not yet assigned to the right CodeIgniter CPE and not supplied with all the details. I will contact the blog poster and MITRE about that.

CVE-2014-8686 happen to be reserved for this bug https://github.com/Dionach/CodeIgniterXor earlier described in this blog post https://beyondbinary.io/advisory/seagate-nas-rce/ and here: https://www.mehmetince.net/codeigniter-object-injection-vulnerability-via-encryption-key/ and here https://www.dionach.com/blog/codeigniter-session-decoding-vulnerability but is also not assigned to the right CodeIgniter CPE and not supplied with all the details. I will contact the blog poster and MITRE about that one too.

MITRE reserved CVE-2015-5725 for the above described SQL injection in the LIMIT clause of the Active Records class. I will provide MITRE later this week with a correct report, detail and classification about this. Currently they just reserved this CVE number and don't have any information about this vulnerability yet.

Any other suggestions to look into?

JaneX8 commented 9 years ago

Hereby the official announcement of CVE-2015-5725 about the above described SQL injection:

The Common Vulnerabilities and Exposures (CVE) project has assigned
the name CVE-2015-5725 to this issue. This is an entry on the CVE
list (http://cve.mitre.org), which standardizes names for security
problems.

I will publish information and a PoC about this vulnerability here: https://github.com/Calico90/CVE-2015-5725_PoC

narfbg commented 9 years ago

Great, I'd just like to ask you to avoid publishing related info outside of this thread until we verify the list that you have. In fact, I'd like to move this to a private channel now ... would you write the next message to security -at- codeigniter.com?

Some feedback on the issues that you linked:

2956 - I don't understand how this is a vulnerability or even remotely related to XSS; did you write the wrong ID there?
3292 is ... let's say I'd give it a severity level lower than LOW :)
606 - PDO support in pre-3.0 versions of CI was experimental and largely broken; I personally don't regard code with experimental status worthy of note. Still, there probably is already a CVE number for that issue and it also probably counts for the mysql_escape_string() issue that caused the 2.2.3 release. That is - character set based SQLi.

As for more suggestions - you can look at the changelog for the 2.x version tree after 2.0.3 (excluding 3.0 of course). It's really small, because most of these were security releases.

JaneX8 commented 9 years ago

@narfbg Sorry about 2956, that should be https://github.com/bcit-ci/CodeIgniter/issues/2965. I removed the reference to 2956 (in above answer). I will answer on the other subjects later.

Update: E-mail to MITRE about CVE-2013-4891 and CVE-2014-8686 is send.

narfbg commented 9 years ago

No harm done, but I hope you had already sent that email and didn't just ignore my request. :)

Seriously, I'd like to discuss something in private before you go with more public disclosures ... Please email security@ our domain.

JaneX8 commented 9 years ago

@narfbg I've just send an e-mail to security@ ..

mdisec commented 9 years ago

Dear all,

I'm the one who did this research https://www.mehmetince.net/codeigniter-object-injection-vulnerability-via-encryption-key/ . How may I help you ? If you have any questions, please ping me with mehmet@mehmetince.net email address.

narfbg commented 9 years ago

Sorry, but "you can try to brute-force the key or look if somebody pushed it to github" is not a vulnerability ...

JaneX8 commented 9 years ago

@mmetince Thanks for your answer on this topic. I will investigate your article and github project later. A working proof of concept can be incredibly helpful. Can you provide that? Or should I be able to find everything needed in here https://github.com/mmetince/codeigniter-object-inj to see a working vulnerability?

I agree with @narfbg, being able to brute-force doesn't make CI vulnerable. If that is the case, please let me know because it will save me a lot of research time.

You describe in your article "Like I explained before, use weakness of md5 and failed design of CI’s session data integrity together. Brute force it! I suggest you do that when you believe encryption_key is not too long." @mmetince, what exactly makes the CI session data integrity weak and can you suggest a solution to prevent this?

@narfbg Is it an idea to trigger a CI error when a short length (< 64 char) encryption key, is used?

narfbg commented 9 years ago

@Calico90

There was a data integrity flaw in CI <= 2.1.4 Sessions in that it used a simple MD5 hash to verify integrity instead of a HMAC and that's one of the two security issues fixed with version 2.2.0, but I doubt that @mmetince is referring to that. If he did, he would be concluding with lack of proper data authentication mechanism instead of what he wrote.

More info about that issue is available from the researcher(s) that reported it: https://www.dionach.com/blog/codeigniter-session-decoding-vulnerability

As for triggering errors for short keys ... Unfortunately, that would be a massive BC break for current CI2 users, while CI3 is unaffected as it doesn't store session data in cookies. And encryption doesn't work with randomly chosen lengths like 64 anyway; every algorithm has its own requirements for key length, which is often a fixed one instead of a low barrier.

JaneX8 commented 9 years ago

@narfbg Thanks for clearing that up. I noticed this session decoding vulnerability I think this is all about the same described vulnerability as I wrote above (CVE-2014-8686). But I still need to verify that.

I understand it will break backwards compatibility and for the encryption part you are right about that length. Assuming that hashing was used (md5) instead of encryption as @mmetince described, the length will actually matters and drastically slowdown brute-force attacks.

As for "security warnings or improvements". It might be overkill but, is it an idea to log such warning on the "Informational Messages" error level and keep backwards compatibility this way. We can suggest messages like "Default application folder name is used, we would recommend to change it into a custom name.", "System folder is inside public folder, we would recommend to move it outside the public folder.", "The file index.php has chmod permission 777, we would recommend to use 644.", "Default setting ... is used, we recommend ...", and so on...

JaneX8 commented 9 years ago

Also (other topic) I'm doubting if CVE-2014-8684 applies directly on CodeIgniter or on the Seagate NAS. I didn't mention it before but this CVE is about "timing attacks and object injection" in a Seagate NAS as described here https://beyondbinary.io/advisory/seagate-nas-rce/. But I think it might apply on CodeIgniter too.

JaneX8 commented 9 years ago

As for the e-mail (10 days ago) regarding "Question about CVE-2013-4891 and CVE-2014-8686", I didn't get a reaction from MITRE yet. I just send a reminder to them.

narfbg commented 9 years ago

The MD5 hash thing is a moot point ... I don't know if the used key's length would qualify for publishing as a CVE, but even if it does, it would be superseded by the issue of using a simple hash as opposed to a HMAC. And the solution to that problem also resolved what was published as CVE-2014-8684.

Logging some warnings may be appropriate, yes.

JaneX8 commented 9 years ago

I just send a third reminder to MITRE regarding "Question about CVE-2013-4891 and CVE-2014-8686".

JaneX8 commented 9 years ago

The full CVE report has regarding CVE-2013-4891 been posted here: https://github.com/Calico90/codeigniter-CVE-2013-4891.

JaneX8 commented 9 years ago

The full CVE report has regarding CVE-2015-5725 been posted here: https://github.com/Calico90/codeigniter-CVE-2015-5725.

narfbg commented 9 years ago

Closing this now. We can discuss it elsewhere if necessary.

bcit-ci / CodeIgniter

CodeIgniter security and CVE database #4020

2956 - I don't understand how this is a vulnerability or even remotely related to XSS; did you write the wrong ID there?

3292 is ... let's say I'd give it a severity level lower than LOW :)