Security Bugs: Difference between revisions

Latest revision as of 22:55, 15 March 2023

In other languages: العربية (ar) English (en) [edit]

If you need to report a security vulnerability please read Reporting a Security Vulnerability.

Security bugs, in Fedora, generally come from one of two places: people finding them and opening a ticket in Red Hat's Bugzilla instance or Red Hat's Product Security group opening bugs in response to CVEs being made public. Security bugs are sometimes kept private due to an ongoing embargo but we generally do not want a security bug to remain out of the public's sight for too long and actively work to establish reasonable embargo times.

Reporting a Security Vulnerability

If you find a security issue (potential or verified) and need to report it against a package please follow the instructions for reporting bugs and feature requests. Security issues have an extra step or two that should be added as noted below.

Providing Proper Information

When entering a security bug in Bugzilla, it is important to ensure the information is accurate and clear. If the issue discovered is triggered by a bad file, please be sure to attach the file to the bug report. A testcase that can be reproduced is best so the security team can verify the issues exists, and to verify that the fix is complete. Additionally, if you know which bits of code are incorrect and are triggering the issue, this information will help speed the time needed to research the issue.

Marking your ticket as security-related

Once you have started your new ticket, but before you actually submit it, select Show Advanced Fields at the top of the page (just above Product). Now that all the possible fields are now shown scroll to the bottom and select Security Sensitive Bug (Check if this is a security related issue and should not be public). This does a couple of things including notifying Red Hat Product Security to the issue. With that setting selected you may now select Submit Bug. You'll be kept in the loop to any development of the issue you reported through this bug.

We are in support of the full public disclosure of security issues, but it should be done so in a responsible manner. This primarily applies to embargoed issues.

If you are unsure at any time during this process, email Red Hat Product Security at secalert AT redhat.com and you will get a timely response.

Resolving security bugs

The Fedora Security Team's mission, in this case, is to help steer security bugs that affect Fedora towards a successful resolution. That means, if necessary, taking control of the process and making sure that patches get shipped.

Working with upstream

Some security bugs will come with patches that do not come from upstream. If this is the case we should make contact with upstream, opening bugs a needed upstream, and work with them to confirm the vulnerability and if the patch fixes the issue.

Shipping the fix

If the patch comes from upstream we should test the patch with the current package and verify it builds. If so, we should work with the packager to ship the patch, closing the tracker bug using Bodhi. If the fix comes from upstream as a new version then shipping that version should go through the same process, closing the tracker bug with Bodhi.

If the packager does not respond in a timely manner then involving FESCo should be a priority.

Frequently asked questions about security bugs

Different types of security bugs

CVE Bugs

When Red Hat Product Security creates a CVE bug that affects Fedora a tracker bug should also be opened explicitly against the package where the vulnerability is found. There may be follow up on the tracker bug but if the package is only shipped in Fedora and/or EPEL and not RHEL there may not be any additional feedback from Red Hat.

CVEs are assigned one of four priorities depending on the severity and impact:

Critical
Important
Moderate
Low

Non-CVE Bugs

There may be times when someone within the community finds a potential security bug and submits a bug against the package. When this happens, and the bug is properly tagged as a security issue, Red Hat Product Security will likely follow up and evaluate the issue against current CVE criteria. Once this happens we'll likely see a process as explained with CVE bugs.

Embargoed Security Issues

An embargoed security issue is one which is not publicly known, and its existence is to be reported to responsible organizations. Often when a researcher discovers a security issue, they will contact an organization such as vendor sec or the project's upstream developers. If the issue is of great severity, it is wise to give the upstream project, various distribution vendors, and the researcher some time to produce patches and advisories for the issue. That means setting a date sometime in the future which all parties can agree upon.

When entering an embargoed issue in the Red Hat Bugzilla, please check the "Security Sensitive Bug" check-box to ensure that the information being entered is not publically viewable until the embargo date passes. These bugs will only be viewable by certain Red Hat employees, the reporter, and anyone in the CC field.

While a security bug is under embargo, you should not push your fixes to Fedora GIT repository (or upstream version control repositories) because that would disclose details about the bug prematurely. But you are welcome to prepare a patch fixing the issues, and attach it to the Bugzilla bug.

When in doubt, please contact Red Hat Product Security.

Security Issues Classification

So what counts a security issue in Fedora? Find answers in the Security Classifications page.

Security Features

Security features available in Fedora is explained on Security Features page.

Fedora Security Response

The Fedora Security Response Team handles security issues within Fedora. Red Hat Product Security can be reached by mailing secalert AT redhat DOT com.

Endemic Security Risks

Due to the Fedora Project's use of resources not directly under our control, such as mirrors, Fedora and its users have exposure to additional endemic risks, and takes as many steps as possible mitigate these risks.

Fedora Security Advisories

Fedora Security Errata

Fedora Security Tracking Bugs

To track security vulnerabilities in packages, tracking bugs are used.

List of Embedded Software

We are maintaining a list of embedded software within various packages. This will help us to quickly identify if a problem in library X can be corrected with updating library X, or if it also requires updating other packages that may contain their own private copies of library X. The embedded software list is used for this purpose.

List of SUID / SGID executables

We are maintaining a list of SUID / SGID bit equipped executables within various packages. This will help us to quickly identify privileged binaries. This list is preliminary planned to be prepared for Fedora release of 14 and it will be enhanced later to include list of privileged binaries in also in newer versions of Fedora. The list of SUID SGID executables is used for this purpose.

@@ Line 1: / Line 1: @@
+{{autolang|base=yes}}
-= Reporting Security Issues =
+{{Admon/important | If you need to report a security vulnerability please read [[Security_Bugs#Reporting_a_Security_Vulnerability|Reporting a Security Vulnerability]].}}
-Fedora includes a large number of [[Security/Features|  security features]]  to mitigate and prevent potential security issues. However new security flaws are continously found in thousands of software packages we include in the Fedora repository. Reporting these security issues and exploits will help the project fix these issues and release updates that resolve the problem. Read on to understand how to deal with these problems effectively.
+Security bugs, in Fedora, generally come from one of two places: people finding them and [[Security_Bugs#Reporting_a_Security_Vulnerability | opening a ticket]] in [https://bugzilla.redhat.com Red Hat's Bugzilla instance] or Red Hat's Product Security group opening bugs in response to CVEs being made public.  Security bugs are sometimes kept private due to an ongoing [[Security_Bugs#Embargoed_Security_Issues | embargo]] but we generally do not want a security bug to remain out of the public's sight for too long and actively work to establish reasonable embargo times.
-== Understanding Security Issues  ==
+== Reporting a Security Vulnerability ==
+If you find a security issue (potential or verified) and need to report it against a package please follow the instructions for reporting [[bugs and feature requests]].  Security issues have an extra step or two that should be added as noted below.
-When filing security bugs, care may need to be taken regarding the information being placed in public view.  We are in support of the full public disclosure of security issues, but it should be done so in a responsible manner.  This primarily applies to embargoed issues.
+=== Providing Proper Information ===
-{{Admon/tip | Please see the [[Security/Classifications|  Security Classifications]]  page for more information regarding what qualifies as a security issue, and how to file a bug.  You can find more general information on filing bugs from [[BugsAndFeatureRequests]] page.}}
+When entering a security bug in Bugzilla, it is important to ensure the information is accurate and clear.  If the issue discovered is triggered by a bad file, please be sure to attach the file to the bug report.  A testcase that can be reproduced is best so the security team can verify the issues exists, and to verify that the fix is complete.  Additionally, if you know which bits of code are incorrect and are triggering the issue, this information will help speed the time needed to research the issue.
+=== Marking your ticket as security-related ===
+Once you have started your new ticket, but before you actually submit it, select ''Show Advanced Fields'' at the top of the page (just above ''Product'').  Now that all the possible fields are now shown scroll to the bottom and select ''Security Sensitive Bug (Check if this is a security related issue and should not be public)''.  This does a couple of things including notifying Red Hat Product Security to the issue.  With that setting selected you may now select ''Submit Bug''.  You'll be kept in the loop to any development of the issue you reported through this bug.
-== Embargoed Security Issues ==
+We are in support of the full public disclosure of security issues, but it should be done so in a responsible manner.  This primarily applies to [[Security_Bugs#Embargoed Security Issues|embargoed]] issues.
-An embargoed security issue is one which is not publically known, and its existence is to be reported to responsible organizations.  Often when a researcher discovers a security issue, they will contact an organization such as vendor sec or the project's upstream developers.  If the issue is of great severity, it is wise to give the upstream project, various distribution vendors, and the researcher some time to produce patches and advisories for the issue.  That means setting a date sometime in the future which all parties can agree upon.
+If you are unsure at any time during this process, email [https://access.redhat.com/security/overview Red Hat Product Security] at secalert AT redhat.com and you will get a timely response.
-When entering an embargoed issue in the Red Hat Bugzilla, please check the "Security Sensitive Bug" checkbox to ensure that the information being entered is not publically viewable until the embargo date passes.  These bugs will only be viewable by certain Red Hat employees, the reporter, and anyone in the CC field.
+== Resolving security bugs ==
+The Fedora Security Team's mission, in this case, is to help steer security bugs that affect Fedora towards a successful resolution.  That means, if necessary, taking control of the process and making sure that patches get shipped.
+=== Working with upstream ===
+Some security bugs will come with patches that do not come from upstream.  If this is the case we should make contact with upstream, opening bugs a needed upstream, and work with them to confirm the vulnerability and if the patch fixes the issue.
+=== Shipping the fix ===
+If the patch comes from upstream we should test the patch with the current package and verify it builds.  If so, we should work with the packager to ship the patch, closing the tracker bug using Bodhi.  If the fix comes from upstream as a new version then shipping that version should go through the same process, closing the tracker bug with Bodhi.
+If the packager does not respond in a timely manner then involving FESCo should be a priority.
+== Frequently asked questions about security bugs ==
+=== Different types of security bugs ===
+==== CVE Bugs ====
+When Red Hat Product Security creates a CVE bug that affects Fedora a tracker bug should also be opened explicitly against the package where the vulnerability is found.  There may be follow up on the tracker bug but if the package is only shipped in Fedora and/or EPEL and not RHEL there may not be any additional feedback from Red Hat.
+CVEs are assigned one of four priorities depending on the severity and impact:
+* Critical
+* Important
+* Moderate
+* Low
+==== Non-CVE Bugs ====
+There may be times when someone within the community finds a potential security bug and submits a bug against the package.  When this happens, and the bug is properly tagged as a security issue, Red Hat Product Security will likely follow up and evaluate the issue against current CVE criteria.  Once this happens we'll likely see a process as explained with CVE bugs.
+=== Embargoed Security Issues ===
+An embargoed security issue is one which is not publicly known, and its existence is to be reported to responsible organizations.  Often when a researcher discovers a security issue, they will contact an organization such as vendor sec or the project's upstream developers.  If the issue is of great severity, it is wise to give the upstream project, various distribution vendors, and the researcher some time to produce patches and advisories for the issue.  That means setting a date sometime in the future which all parties can agree upon.
+When entering an embargoed issue in the Red Hat Bugzilla, please check the "Security Sensitive Bug" check-box to ensure that the information being entered is not publically viewable until the embargo date passes.  These bugs will only be viewable by certain Red Hat employees, the reporter, and anyone in the CC field.
 {{Admon/important |
 While a security bug is under embargo, you should not push your fixes to Fedora GIT repository (or upstream version control repositories) because that would disclose details about the bug prematurely.  But you are welcome to prepare a patch fixing the issues, and attach it to the Bugzilla bug.
-When in doubt, please contact the [mailto:secalert@redhat.com Red Hat Security Response Team].}}
+When in doubt, please contact [mailto:secalert@redhat.com Red Hat Product Security].}}
-== Setting Keywords ==
+=== Security Issues Classification ===
-Make sure you set the bug keywords to "security". These bugs receive special attention compared to other normal bug reports.
+So what counts a security issue in Fedora? Find answers in the [[Security Classifications]] page.
-== Providing Proper Information ==
+=== Security Features ===
-When entering a security bug in Bugzilla, it is important to ensure the information is accurate and clear.  If the issue discovered is triggered by a bad file, please be sure to attach the file to the bug report.  A testcase that can be reproduced is best so the security team can verify the issues exists, and to verify that the fix is complete.  Additionally, if you know which bits of code are incorrect and are triggering the issue, this information will help speed the time needed to research the issue.
+Security features available in Fedora is explained on [[Security Features]] page.
+=== Fedora Security Response ===
+The Fedora [[Security/ResponseTeam|Security Response Team]] handles security issues within Fedora. Red Hat Product Security can be reached by mailing secalert AT redhat DOT com.
+=== Endemic Security Risks  ===
+Due to the Fedora Project's use of resources not directly under our control, such as mirrors, Fedora and its users have exposure to [[Mirror_manager_security_risks|additional endemic risks]], and takes as many steps as possible mitigate these risks.
+=== Fedora Security Advisories ===
+* [https://bodhi.fedoraproject.org/updates/?type=security Fedora Security Errata]
+=== Fedora Security Tracking Bugs ===
+* To track security vulnerabilities in packages, [[Security/TrackingBugs|tracking bugs]] are used.
+=== List of Embedded Software ===
+* We are maintaining a list of embedded software within various packages.  This will help us to quickly identify if a problem in library X can be corrected with updating library X, or if it also requires updating other packages that may contain their own private copies of library X.  The [[Security_of_Embedded_Software|embedded software list]] is used for this purpose.
+=== List of SUID / SGID executables ===
+* We are maintaining a list of SUID / SGID bit equipped executables within various packages. This will help us to quickly identify privileged binaries. This list is preliminary planned to be prepared for Fedora release of 14 and it will be enhanced later to include list of privileged binaries in also in newer versions of Fedora. The [[Set_User_Group_ID_Executables| list of SUID SGID executables]] is used for this purpose.
 [[Category:Security]]

Search