Security update: CVE-2017-5870 and CVE-2017-6086

[Fmstrat]

It seems there are multiple cross-site request forgery (CSRF) vulnerabilities within the latest version of ViMbAdmin. Can we get a status on these fixes?

Seems the timeline states that you don't have time to fix bask in 2017, but wondering if any solution is in place now?

• 22/01/2017 : Initial discovery.
• 16/02/2017 : First contact with opensolutions.io
• 16/02/2017 : Advisory sent.
• 24/02/2017 : Reply from the owner, acknowledging the report and planning to fix the vulnerabilities.
• 13/03/2017 : Sysdream Labs request for an update.
• 29/03/2017 : Second request for an update.
• 29/03/2017 : Reply from the owner stating that he has no time to fix the issues.
• 03/05/2017 : Full disclosure.

References:

• https://nvd.nist.gov/vuln/detail/CVE-2017-5870
• https://nvd.nist.gov/vuln/detail/CVE-2017-6086

[barryo]

No solution yet in place and no immediate free time to look at this. However this issue has bumped it back into my list of priorities.

If anyone wants to contribute to pushing this further up the list, the commercial support route would be a practical way of doing this.

ViMbAdmin is used by the vast majority of users as an in-house single-organisation tool and as such the exposure of both if these CVE's is - to my mind - much less than the CVE assigned scores.

[Fmstrat]

@barryo As both of these are CSFR issues, I would certainly say they warrant the level of CVE assignment, even if they are in-house single-organization installs. These smaller systems mean smaller teams, and impact could be catastrophic for a small organization (or person) that can't figure out what's going on. That being said, CSFRs are easy to fix.

In any PHP header file that has a form in it, just add:

session_start();
if (empty($_SESSION['token'])) {
    if (function_exists('mcrypt_create_iv')) {
        $_SESSION['token'] = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
    } else {
        $_SESSION['token'] = bin2hex(openssl_random_pseudo_bytes(32));
    }
}
$token = $_SESSION['token'];

In the <form> itself, add:

<input type="hidden" name="token" value="<?php $_SESSION['token']; ?>">

And after submit, before any functions are called, add:
edit Oops, cut and paste error below, fixed!

if (empty($_POST['token'] || (!empty($_POST['token'] && !hash_equals($_SESSION['token'], $_POST['token']))) {
         // Place code here to redirect to the login page.
}

This would eliminate both CVEs.

[Fmstrat]

I should note, the above solution uses hash_equals for checking the token, which is in PHP 5.6+ only, but available to earlier versions with the hash-compat library: https://github.com/indigophp/hash-compat

Some saying just using == or === is OK, but hash_equals is the true "secure" way to do it.

[Fmstrat]

I'm about to fork and work on a PR.

[Fmstrat]

OK, I've started CSFR fixes on POSTS, but I realize the CVE also has GET issues, too. I wasn't sure of the details on your Zend implementation since much of it looks custom in your framework, so I did it the old fashion way, but it's clean, matches your code structure, and works.

Here's a commit with one form fixed. Let me know if you have issues with this structure as I'm going to use it across all forms, and then address the GET issues.

Fmstrat@e82386f

EDIT
This is for reference. I'll likely make createToken include all of the code to centralize, and centralize the token check. It's just to make sure you don't have any reason to not implement this way.

EDIT 2
Consolidated, see full diff: master...Fmstrat:master

EDIT 3
Since I'm not familiar with the full structure of things, I could keep moving with things, but let me know if you look at this and are like "Oh I could do this in an hour" because it would likely take me much longer.

[barryo]

Hi @Fmstrat - thanks for the effort here.

Unfortunately, the way you've done it is not how we'd go about it (but it's close). We've already solved this in another project using the same backend code. Here are some links:

• inex/IXP-Manager@47e2d7d
• inex/IXP-Manager@5a3ccfe
• inex/IXP-Manager@bc824f8
• inex/IXP-Manager@75d82db
• inex/IXP-Manager@2058294#diff-49a23926d7ee71088d195d0367393668

I've no issue looking at this when I have time, but if you want to look at it, the above should help.

To accept a more significant piece of code like this into the project, I'd also need you to sign an as yet unwritten CLA but something like this: https://github.com/inex/IXP-Manager/wiki/Contributor-License-Agreement

(side note: mcrypt is deprecated, please use random_bytes())

[Fmstrat]

@barryo Yeaaaaa since I'm not that familiar with Zend, sounds like it would take me waaaaayyyy longer than makes sense given you already have a solution in place elsewhere. I'd love to help, but I might not be the right person (given the time I have currently).