Here follows the discussion about how to disclose NethServer security flaws, originally started as a private thread with @ambassadors_group on Oct 26, 2017 at 17:18. We faced a real case here and we needed take a decision
I want to start this conversation in private but I hope we’ll turn it public soon.
A security issue has been found in Server Manager and I’d like to hear your opinions before releasing a full disclosure.
The vulnerability allows a local user to escalate privileges and take control of the whole system through the Server Manager. It affects only NethServer 7 systems.
The fix has already been pushed to 7.4.1708 repositories.
How can we push people to update before revealing sensible information (and creating fear)?
You shouldn’t really create fear, since the solution is ready, is there any way to add to nethserver the update notification from the system without going to the software center?
I think that we are living a “strange” moment now, with the upcoming release of 7.4 which is making everybody a bit nervous about updates. If the issue were found in a “calm” moment, nobody would have had problems updating.
Could we suggest to issue a custom yum command to install this single update?
Just some thoughts on this:
If we look at professional environments, it is a good practice to test updates before they are rolled out. There can be introduced a lot of problems with updates.
So having a fix is IMO not enough. If, for whatever reason, a service gets broken because of an update, the update can’ t be rolled out in a mission critical environment. Then testing, fixing and re-testing is needed.
The fix for this problem is available for NS7.4 So 7.3 users have to push the 7.4 updates. There we land on my point: the fix needs updates to be implemented.
If possible, have a fix for 7.3 too before disclosing the vulnerability to the public.
Remember that those who have NethServer are system administrators with sufficient knowledge or moderate.
As a system administrator, changes must be made for improvements or for testing in non-productive modes.
The fact of finding a security flaw should be notified, and should not be subject to global alert as several methods of security must be implemented within NethServer so that from the outside is not vulnerable by this flaw, and if it happens from the administrator’s local network.
@Jim and @robb are right in their comments. I would vote to optimize NethServer and place a module already configured from its installation to be notified when a security update of the system is found.
Haven’t thought deeply about it but if it’s not remotely exploitable, publish advisory, community post and newsletter, holding out sensitive information for a few days/weeks.
If that’s not an option due to abuse concerns, create a post only visible to community members + private message to all. As an exceptional measure, public disclosure after 4-7 days? (usually patch release and advisory go together, IINW. Downside: some members could spread it before public disclosure). “Fear” could arise on some users. A clear statement about impact, public disclosure dates, mitigation… with proper wording could alleviate it.
For future implementation:
Notification on server-admin for NethServer-specific security updates
Opt-in auto-update mechanism and notification (steph’s yum-cron)
Set a vulnerability disclosure process/policy (evaluate vuln. severity to consider if an early-announcement with countermeasures or manual fix is worth before patch-release availability; internal QA, patch pre-release to a group of trusted early-adopters/crash test dummies, commits and filed issues can leak vuln. info; full disclosure or coordinated/responsible disclosure model…)
For the future I think it would be nice if you could install security updates without installing the other updates from software center.
At the moment I would say it is ok if the single security update could be installed at the command line. If this is possible, you could post a short howto and inform everybody about it per pm.
We don’t have minor version branches. There’s a single repository version, that is “7”. Since monday we reached (say) milestone 7.4. But the latest 7.3 is almost equal to the first 7.4: it’s a continuum, rolling release.
In short the question is
What to do on systems that are not updated to the latest version?
The fix can be installed on any ns7 updated to September 8. That day we released another important security fix (CSRF token) and any subsequent update must include it to avoid breaking dependencies.
So the solution for non-updated systems is to cherry-pick the fix with
yum localinstall http://....
I agree, and we have also the solution, I think: the Stephan’s contrib, based on yum-cron!
Do I understand correctly that it will be possible to cherrypick updates this way? Like you have in the MS world with WSUS? (I would love to have such a feature!)