Dealing with old fixed security issues

Hi everyone,

we recently voted for a security policy which provides a process for handling new security issues we might discover.
Per this process we decided to make the security issue public once they have been fixed and released. However, before this process we fixed a lot of security issues without making them public: we need to decide how we want to handle them.

My opinion is that those security issues should be publicly disclosed now they have been fixed and released. However it’s a huge amount of work to properly create all the needed CVEs for each of them, to find the right impacted version etc.
So instead of doing that work at once, I propose the following rule:

Whenever a public issue needs to be linked to a fixed confidential issue, this confidential issue is made public with the appropriate CVE.

So, for example, if I need to close an issue as a duplicate of a confidential issue, I will create the link to the confidential issue, create the CVE for this confidential issue, and once the CVE is published make the issue public too. (or make it public first and then publish the CVE).

WDYT?

+1, does not make sense to keep them confidential

Definitely.

That process does not make much sense to me, there is nothing special about old issues that were missed when the bug was fixed and that we only notice now.
It’s also not going to help handling these old issues anyway since I doubt there is much of this use case.

In there, there’s:

Remove the confidential label on the Jira issue. Publish the advisory once the CVE ID has been received.

I’m worried about one point: in the confidential jira issue we give the max detail to reproduce the problem and thus making it public (removing “confidential”) makes it real easy for someone nasty to check public xwiki instances that have not been upgraded and trying what’s listed (for ex). Basically, we make it easy.

I was wondering if we should do something about it and explain the issue but without going to the level of detail of explaining how to exploit it.

Is the suggestion to remove the “confidential” field to all past jira issue that have been fixed for more than 3 months?

I agree that we should follow the same rules as for new ones.

So one idea is the one suggested by Thomas which is simply to remove the “confidential” field. See my little comment about that above.

Another idea is to take the 2-3 most important and past security issues and creates a few CVEs for them.

Note really, I was just agreeing that they should visible in general. Now I don’t know if we want CVE for them or not (I feel it’s simply not doable).

Well our security policy currently says to remove the confidential field so it would make sense to do that for past issues too, for consistency. I just have the issue I mentioned about explaining too much but that’s true for old or new security issues.

Not really sure what is your point. Yes of course we should remove the confidential field, the only question is should we create CVE or not.

My point is that:

  1. it was never mentioned in Simon’s proposal so I’m asking if we want do that (to be clear Simon only mentioned to do that in some cases but not all). I also added the 3 months condition.
  2. it creates some additional security risks, see my explanation above.

Again my worry is:

I’m worried about one point: in the confidential jira issue we give the max detail to reproduce the problem and thus making it public (removing “confidential”) makes it real easy for someone nasty to check public xwiki instances that have not been upgraded and trying what’s listed (for ex). Basically, we make it easy.

I was wondering if we should do something about it and explain the issue but without going to the level of detail of explaining how to exploit it.

The CVE does explain how to exploit it too, it’s part of its job.

hmm. I’ve just checked and it’s not the case for the issue I checked:

The CVE doesn’t explain much while the JIRA issue gives lots of details.

Also I see no section in the CVE that explains how to reproduce. I see:

  • Impact
  • Patches
  • Workarounds
  • References

In any case you seem to be saying that from your POV it’s not a problem to give very precise details on how to exploit the security issue. Is that something generally found elsewhere? I find it really dangerous for our users and I’m pretty sure that the instances in the wild won’t get updated after 3 months (takes years to happen).

PS: I’m just asking the question to make sure we agree to disclose all the nasty details.

Another point: I think the CVE should be self standing, i.e. all the public info should be in there and not in a jira issue (which is a work and temporary place which can go away in the future).

Others CVE give more details but the point is that there was not intend to hide anything in this CVE since the jira issue is linked and public.

It always been clear in my mind that disclosing security vulnerability meant fully disclosing it. That’s why we wait 3 months after all supported branches have been fixed.

Rebooting the proposal since I happened to encounter again an old fixed security issue marked confidential.
So the proposal is now the following:

  1. to mark all fixed JIRA security issues as public (said otherwise to reset the confidential field) when they concerns versions with more than 3 months old and they do not link to a draft advisory (if we have a draft advisory it means they are already handled by our standard process)
  2. to not create CVEs for them: the rationale is that it’s lot of work and the users should already have upgraded the issue.

Note that we can ponderate it a bit and chose to only do that for issues fixed before previous LTS (so before 11.10.10): we might consider that we still have possibly lots of users on 11.10.10 that might get impacted if we disclose issues. If we decide that, we’ll probably need to do the proposed process again in one year for the remaining ones.

wdyt?

+1 to remove the confidential tag in all the fixed jira issues too old to be part of the current security process

I would suggest to “inject” those in the current security process as if they were just fixed issues (so create CVE, etc.) if they are of high level. There should not be many.