Samba Security Process: Difference between revisions

From SambaWiki
(update security release process based on recent experience)
(update template for getting a CVE from RedHat as we sometimes do a CVE for a public issue)
(9 intermediate revisions by the same user not shown)
Line 3: Line 3:
* Only [[Samba_Release_Planning|supported Samba versions]] are eligible for a security release.
* Only [[Samba_Release_Planning|supported Samba versions]] are eligible for a security release.
* Security updates, once public, are listed on [https://www.samba.org/samba/history/security.html Samba Security Releases]
* Security updates, once public, are listed on [https://www.samba.org/samba/history/security.html Samba Security Releases]
* Security issues that are assigned a CVE can be found in [https://bugzilla.samba.org/buglist.cgi?f1=alias&o1=regexp&order=Last%20Changed&product=PIDL&product=Samba%202.2&product=Samba%203.0&product=Samba%203.2&product=Samba%203.3&product=Samba%203.4&product=Samba%203.5&product=Samba%203.6&product=Samba%204.0&product=Samba%204.1%20and%20newer&query_format=advanced&v1=^CVE-.* The Samba Bugzilla]. This will also include some minor issues that do not warrant a full security release.


=Reporting Security Defects in Samba=
=Reporting Security Defects in Samba=


Please report all security issues or defects to '''security@samba.org''' and ''never on'' [https://www.samba.org/samba/irc.html IRC], [https://www.samba.org/samba/archives.html public mailing lists] or in [https://bugzilla.samba.org Bugzilla]!
Please report all security issues or defects in Samba or concerning our infrastructure to '''security@samba.org''' and '''''never on''''' [https://www.samba.org/samba/irc.html IRC], [https://www.samba.org/samba/archives.html public mailing lists] or in [https://bugzilla.samba.org Bugzilla]!


''For clarity, a Samba Team member will create the private Bugzilla issue mentioned below.
=Security Release Process=
''

=A public security process for Samba=

The following process is followed by '''the [https://www.samba.org/samba/team Samba Team Member] working on the security issue'''.

We publish it as a service to the Free Software and broader software development community as a well-worked, practical process for ''responsible disclosure'' and to our aid our Samba community in knowing how we handle serious security issues in our code.


<pre>
<pre>
Line 19: Line 27:


2.) Create a bug report with limited access to "Samba core developers"
2.) Create a bug report with limited access to "Samba core developers"
only! Change the summary so that it starts with
only! This is done by selecting 'Show advanced fields' and at the
very bottom:
"[EMBARGOED][SECURITY]". Add all information including reproducer

etc. to the bug report.
'Only users in all of the selected groups can view this bug:

[x] Samba Core Developers

2a.) Change the summary so that it starts with "[EMBARGOED][SECURITY]"

For example:

"[EMBARGOED][SECURITY] dsdb: time wrap at end of unix time

2b.) Add all information including reproducer etc. to the bug report.


3.) Write an initial advisory and attach it to the bug report. A
3.) Write an initial advisory and attach it to the bug report. A
Line 30: Line 49:
publicly thanked and any affiliation they wish to have noted.
publicly thanked and any affiliation they wish to have noted.


4.) Do a CVSSv3 calculation ([2]) and add it to the bug report and the
4.) Do a CVSSv3.1 calculation ([2]) and add it to the bug report and the
advisory.
advisory.

4a.) Stop and ask for advise on security@samba.org if the CVSSv3.1
score is less than 5.0. This is a heavy-weight process with
costs to many parties.

4b.) Even for a CVSSv3.1 of more than 5.0 we do not do a security
release where the impact is only a Denial of Service (not a use
after free) and the automated internal process restart will allow
other clients to reconnect eventually.

For clarity, the shared LDAP or KDC process in the AD DC will
restart, so a simple NULL de-reference crash there would not
trigger a release. However a similar issue in the main smbd
listener preventing new connections being established may require
a release.

These issues are real, important and should be backported to
maintained releases, but do not justify the costs of coordinated
disclosure or a seperate security release.

This is similar to, but an extension of, our existing rule that
crashing the smbd belonging to the connecting user is not a DoS.

However, we do:
- ask for a CVE (step 5.)
- place the CVE on the bug (step 5b.)
- leave or make the bug public (step 14. and 14a.)
- mark the commits with the CVE (step 6a.)


5.) Ask for a CVE (usually Red Hat Product Security
5.) Ask for a CVE (usually Red Hat Product Security
<secalert@redhat.com> (see [1] for GPG key etc.) does help out on
<secalert@redhat.com> does help out on this one).
this one). After receiving the CVE number, please add it as an
alias to the bug report advisory and to the summary.


To: Red Hat Product Security <secalert@redhat.com>
To: Red Hat Product Security <secalert@redhat.com>
Line 43: Line 88:
Red Hat Product Security,
Red Hat Product Security,


Can I please get a CVE for what will be Samba Bug XXXX?
Can I please get a CVE for what will be Samba Bugzilla:
https://bugzilla.samba.org/show_bug.cgi?id=14706


The Samba team has evaluated this issue and determined that it will
The Samba team has evaluated this issue and determined that it will
require a CVE per our process.
require a security release. Details are confidential for now, but will
https://wiki.samba.org/index.php/Samba_Security_Process
be clearly marked as bug XXXX (so you can connect the threads once

vendors are notified).
Details are confidential for now, but will be clearly marked with that
bug (so you can connect the threads once vendors are notified or the
issue is made public).


Thanks!
Thanks!

If the bug is already public, remove
"are confidential for now, but "
and feel free to describe the issue in cleartext.


DO NOT attach the advisory from step 3. This avoids two issues:
DO NOT attach the advisory from step 3. This avoids two issues:
Line 57: Line 110:
for that (see 3a).
for that (see 3a).
- It keeps all vendors on the same basis.
- It keeps all vendors on the same basis.

See [1] for GPG key etc if the circumstances require it.


5b.) If for any reason Red Hat is unable to assist with obtaining a
5b.) If for any reason Red Hat is unable to assist with obtaining a
Line 63: Line 118:
submission)
submission)


5c.) After receiving the CVE number, please add it as an
6.) Write patches and tests and add them to the bug report.
alias (this is a seperate bugzilla field) on the bug report
and to the summary (title), eg:
CVE-2038-12345 [EMBARGOED][SECURITY]...

6.) Write patches and tests and add them to the bug report. Mark them
WIP in the description until they are 'final'.
(Even 'final' patches may change after being subject to review of
course).


6a.) ALL commits in the patch should have a CVE prefix and a BUG tag eg:
6a.) ALL commits in the patch should have a CVE prefix and a BUG tag eg:
Line 76: Line 139:
Signed-off-by: Time Lord <time@samba.org>
Signed-off-by: Time Lord <time@samba.org>


6b.) Ask for review of your WIP and final master patches ASAP
6b.) Ask for early review of your WIP and final master patches ASAP


6c.) Prepare backports for all affected and supported versions
6c.) Prepare backports for all affected and supported versions
Line 82: Line 145:
(1 file per version, even if identical).
(1 file per version, even if identical).


Files should be named $CVE-$MAJOR-$VERSION.patch
Files should be named $CVE-$DESCRIPTION-$MAJOR-$VERSION.patch


E.g.:
E.g.:
CVE-2018-14629-4.9-01.patch
CVE-2018-14629-timewrap-4.9-01.patch


6d.) Run *private* autobuild (see doc/autobuild.txt) or *private*
6d.) Run *private* autobuild (see doc/autobuild.txt) or *private*
Line 97: Line 160:
6f.) Once each CVE patch and branch has passed, ask for review ASAP.
6f.) Once each CVE patch and branch has passed, ask for review ASAP.


6g.) Get explicit review flags in Bugzilla (two explicit team review
6g.) Get one explicit review flag in Bugzilla (yours, as a team member,
is implicit and CI passed is now a distinct flag).
ticks, including yourself if need be, to indicate the patch is
final).


7.) Once all patches and the advisory are available and reviewed, ask
7.) Once all patches and the advisory are available and reviewed, ask
Line 204: Line 266:
16.) Close out bug report when patches have been pushed to *all* relevant
16.) Close out bug report when patches have been pushed to *all* relevant
branches.
branches.

17.) Now that any regressions etc will have been broadly noticed,
remove samba-vendor from the CC list of the now public bug, ask
that they subscribe individually if still interested.


[1] https://access.redhat.com/security/team/contact/
[1] https://access.redhat.com/security/team/contact/
[2] https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator
[2] https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator

</pre>
</pre>


=Template security advisory=
=Template security advisory=
The template security advisory is here: [[File:Template_security_advisory.txt]]
The template security advisory is here: [[File:Template_security_advisory.txt]]

=In Video=
There is a [https://mirrors.dotsrc.org/fosdem/2019/K.1.105/security_flaws.mp4 Video of a presentation by Jeremy Allison] about this security process in practice.

Revision as of 06:59, 29 March 2022

Below is the process the Samba Team follows to prepare a security release and co-ordinate the disclosure of a security vulnerability.

Reporting Security Defects in Samba

Please report all security issues or defects in Samba or concerning our infrastructure to security@samba.org and never on IRC, public mailing lists or in Bugzilla!

For clarity, a Samba Team member will create the private Bugzilla issue mentioned below.

A public security process for Samba

The following process is followed by the Samba Team Member working on the security issue.

We publish it as a service to the Free Software and broader software development community as a well-worked, practical process for responsible disclosure and to our aid our Samba community in knowing how we handle serious security issues in our code.

Security issues are usually reported via security@samba.org.

1.) Someone should feel responsible and make sure that it's really a
    security defect. If yes, we need one person who is responsible for
    this specific issue beyond this point. This person coordinates the
    further actions and might delegate tasks, of course.

2.) Create a bug report with limited access to "Samba core developers"
    only!  This is done by selecting 'Show advanced fields' and at the
    very bottom:

   'Only users in all of the selected groups can view this bug:

    [x] Samba Core Developers

2a.) Change the summary so that it starts with "[EMBARGOED][SECURITY]"

    For example:

    "[EMBARGOED][SECURITY] dsdb: time wrap at end of unix time

2b.) Add all information including reproducer etc. to the bug report.

3.) Write an initial advisory and attach it to the bug report. A
    template is available here:
    team-info/doc/releases/template_security_advisory.txt

3a.) Confirm with the initial reporter that they are willing to be
     publicly thanked and any affiliation they wish to have noted.

4.) Do a CVSSv3.1 calculation ([2]) and add it to the bug report and the
    advisory.

4a.) Stop and ask for advise on security@samba.org if the CVSSv3.1
     score is less than 5.0.  This is a heavy-weight process with
     costs to many parties.

4b.) Even for a CVSSv3.1 of more than 5.0 we do not do a security
     release where the impact is only a Denial of Service (not a use
     after free) and the automated internal process restart will allow
     other clients to reconnect eventually.

     For clarity, the shared LDAP or KDC process in the AD DC will
     restart, so a simple NULL de-reference crash there would not
     trigger a release.  However a similar issue in the main smbd
     listener preventing new connections being established may require
     a release.

     These issues are real, important and should be backported to
     maintained releases, but do not justify the costs of coordinated
     disclosure or a seperate security release.

     This is similar to, but an extension of, our existing rule that
     crashing the smbd belonging to the connecting user is not a DoS.

     However, we do:
      - ask for a CVE (step 5.)
      - place the CVE on the bug (step 5b.)
      - leave or make the bug public (step 14. and 14a.)
      - mark the commits with the CVE (step 6a.)

5.) Ask for a CVE (usually Red Hat Product Security
    <secalert@redhat.com> does help out on this one).

To:      Red Hat Product Security <secalert@redhat.com>
Subject: Another Samba CVE (bug XXXX)

Red Hat Product Security,

Can I please get a CVE for what will be Samba Bugzilla:
https://bugzilla.samba.org/show_bug.cgi?id=14706

The Samba team has evaluated this issue and determined that it will
require a CVE per our process.
https://wiki.samba.org/index.php/Samba_Security_Process

Details are confidential for now, but will be clearly marked with that
bug (so you can connect the threads once vendors are notified or the
issue is made public).

Thanks!

    If the bug is already public, remove
     "are confidential for now, but "
    and feel free to describe the issue in cleartext.

    DO NOT attach the advisory from step 3.  This avoids two issues:
     - If Red Hat gets the advisory, they need to get GDPR permission for
       the reporter name and we don't want to block on the back and forth
       for that (see 3a).
     - It keeps all vendors on the same basis.

     See [1] for GPG key etc if the circumstances require it.

5b.) If for any reason Red Hat is unable to assist with obtaining a
     CVE number in time, the backup process is to fill in this form
     https://cveform.mitre.org/ (explain the situation in the
     submission)

5c.) After receiving the CVE number, please add it as an
     alias (this is a seperate bugzilla field) on the bug report
     and to the summary (title), eg:
     CVE-2038-12345 [EMBARGOED][SECURITY]...

6.) Write patches and tests and add them to the bug report.  Mark them
    WIP in the description until they are 'final'.
    (Even 'final' patches may change after being subject to review of
    course).

6a.) ALL commits in the patch should have a CVE prefix and a BUG tag eg:

  CVE-2038-12345 dsdb: time wrap at end of unix time

  At time_t rollover all AD security is lost due to integer wrap on
  32-bit systems

  BUG: https://bugzilla.samba.org/show_bug.cgi?id=999999

  Signed-off-by: Time Lord <time@samba.org>

6b.) Ask for early review of your WIP and final master patches ASAP

6c.) Prepare backports for all affected and supported versions

     (1 file per version, even if identical).

     Files should be named $CVE-$DESCRIPTION-$MAJOR-$VERSION.patch

     E.g.:
     CVE-2018-14629-timewrap-4.9-01.patch

6d.) Run *private* autobuild (see doc/autobuild.txt) or *private*
     Gitlab CI for each CVE and each maintained branch.  (This allows
     the release manager to defer some patches if problems appear
     later in the process).

6e.) Mark the patch that has passed with the ci-passed flag in the
     bugzilla attachment details.

6f.) Once each CVE patch and branch has passed, ask for review ASAP.

6g.) Get one explicit review flag in Bugzilla (yours, as a team member,
     is implicit and CI passed is now a distinct flag).

7.) Once all patches and the advisory are available and reviewed, ask
    the release manager for a release date.

7a.) Between now and the release, the release manager or their
     delegate will run a *private* autobuild of the exact combination
     of patches the be released.

7b.) If multiple issues are being released in a batch, create a
     tracking bug that is blocked by the CVEs to be addressed in this
     bundle.

8.) Finish the advisory and attach it to the bug report as
    advisory-$CVE.txt.  Ask for review.  (This must be after getting
    the release date so the correct version numbers can be included).

9.) ~10 days before the release date, confirm every patch and the CVE
    text still has the correct reviews (due to additional feedback for
    example).

9a.) add samba-vendor to the CC list in the bug report,

9b.) open the bug report by checking "Core developers, and Vendors
     shipping Samba as part of their products" and removing "Samba
     Core Developers".

9c.) Add the planned release date to the bug or the tracking bug if
     that has been created.  This will be the first useful e-mail seen
     by our vendors.

10.) 7 days before the release date, send an e-mail to
     samba@lists.samba.org, samba-technical@lists.samba.org and
     samba-announce@lists.samba.org indicating there will be a security
     release and the broad component it impacts.  This is to allow
     large installations time to prepare for security patching.

     For example:

To:	 samba-announce@lists.samba.org
Cc:	 Upstream Samba Technical Mailing list <samba-technical@lists.samba.org>, samba@lists.samba.org
Subject: Heads-up: Security Releases ahead!
Hi,

this is a heads-up that there will be Samba security updates on
Tuesday, XXXXX YYth. Please make sure that your Samba
servers will be updated soon after the release!

Impacted components:
 - AD DC (CVSS 7.5, High)
 - client (CVSS 5.9, Medium)
 - file server / classic DC (CVSS 6.8 Medium)

10a.) Note that this represents the final GO/NO-GO point.  In order to
      facilitate creation of tarballs etc, after this date the patches
      and CVE text *must not change* or else the release will need to
      be publicly rescheduled, patches dropped or other appropriate
      action taken at the absolute discretion of the release manager.

11.) The release manager or their delegate will prepare the tarballs
     in the *stable* branches:
    - git fetch
    - git rebase
    - git merge -ff-only the VERSION bump commit from the corresponding test
      branch
    - apply the security patchset
    - WHATSNEW.txt: add the release notes
    - VERSION: disable GIT_SNAPSHOT
    - add an empty announce.samba-$VERSION.quotation.txt file
    - GNUPGHOME=$PATH_TO_THE_RELEASE_KEY script/release.sh samba-stable create
    DO NOT PUBLISH ANYTHING BEFORE THE END OF EMBARGO!

    On the release day:
    Upload the files and publish the announcements as described in steps
    3.) and 4.) in team-info/doc/releases/howto_releases.txt 

12.) Additional steps for the release manager:
     - upload the signed security patch(es) to the ftp server:
       samba-bugs@samba.org:/home/ftp/pub/samba/patches/security/
     - push the advisory to the samba-web git repository:
       samba-web/security/
     - update samba-web/history/security.html

     Merge the tags to the test branches:
     - git fetch
     - git rebase
     - git merge $TAG
     - VERSION: bump version
     - push without autobuild:
       LC_SAMBA_AUTOBUILD_PUSH=1 git push-v4-X-test-skip-autobuild

13.) After shipping the releases, the responsible person must make
     sure that the patches find their way into the master branch and
     remove the [EMBARGOED] tag from the bug report.

14.) Mark as 'private' any sensitive comments or attachments

14a.) Then un-select the "Core developers, and Vendors shipping Samba
      as part of their products" restriction.

15.) Address any minor improvements that were suggested after the
     patches were frozen and incorporate those into commits in master.

16.) Close out bug report when patches have been pushed to *all* relevant
     branches.

17.) Now that any regressions etc will have been broadly noticed,
     remove samba-vendor from the CC list of the now public bug, ask
     that they subscribe individually if still interested.

[1] https://access.redhat.com/security/team/contact/
[2] https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator

Template security advisory

The template security advisory is here: File:Template security advisory.txt

In Video

There is a Video of a presentation by Jeremy Allison about this security process in practice.