Disclaimer: I have zero knowledge on security studies and very little knowledge on our internal security workflow. The idea popped out from the observation on my daily work which includes backporting security fixes, occasionally a couple of which are embargoed. Lashes are welcome if you find the idea stupid.

When an embargoed vulnerability reaches SUSE, the related bugs / fixes are usually only exposed to a small group of people including maintainers of the affected package. While bugzilla can made an issue private for that purpose, For OBS I'm unaware of an option like "private project / package" that blocks unwanted access (please correct me if it does exist).

Another observation is that it is somewhat a convention CVE patches have "CVE" and the ID in the patch names (e.g. CVE-2018-7169.patch, cairo-CVE-2017-9814.patch).

Those combined, results in my concern that a malicious SUSE engineer (which of course will never, ever exist! ;-) could just scan the IBS projects, be it home projects or the maintenance projects, at intervals for any newly added CVE patches, and search the found ID on the public CVE database. When an ID is not found, the attacker knows an unreleased vulnerability, and what's worst, the patch for the vulnerability. All those happen before the fix released, or even vulnerability disclosed. Potentially leading to something worse than a 0-day attack.


Comments

  • dmaiocchi
    about 1 year ago by dmaiocchi | Reply

    +1 for humility and openess good luck add-emoji

  • zhangxiaofei
    about 1 year ago by zhangxiaofei | Reply

    A closer look at the osc manpage shows the osc bco --noaccess option offers a private ACL. Hopefully I'm the one ignorant at this, and it might worth being documented as a best practice for everyone fixing embargoed vulnerabilities.

Similar Projects

This project is one of its kind!