NethServer vulnerability disclosure process

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

1 Like

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)?

hi @davidep

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?

1 Like

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?


That’s a good compromise. Indeed the fix can be cherry-picked and installed on 7.3 with just one command.

It could be sent by yum-cron, by installing the Steph’s contrib.

Yes, but to incorporate this feature in new versions, let NethServer tell us that there are security updates pending.

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.

1 Like

you’re right.


Is the vulnerability descovery throught a bug report, or not?

My toughts:

  • If the discovery is through a bug report, do the communication thought the bug resolution.

  • if not, make the communication throught all channels ( newsletter, forum…) when the patch was published in the repository…

1 Like

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:

  1. Notification on server-admin for NethServer-specific security updates
  2. Opt-in auto-update mechanism and notification (steph’s yum-cron)
  3. 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…)

Image source:

Research for guidelines and look how other projects are doing:


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!


IMO, if the bug is discovered and not published

  1. develop and QA fix without disclosing anything

  2. notify community about a security fix incoming, without spreading panic or giving any details about vulnerability

  3. wait a few time

  4. release fix and backports

  5. Notify community about security fix, affected version and fixed version. I’d also like auto-update and server-manager notifications

  6. wait some days or weeks (no hurry here)

  7. Full Disclosure

  8. credits and bounty

In case of a 0-day, skip 2. 3. and 8.


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!)

1 Like

Yes but to make it work we (developers) must add some metadata to our releases…


And having (consistent) metadata is always a good idea… :wink: