[Security-news] Announcement: Drupal core issues with some risk levels may be treated as bugs in the public issue queue, not as private security issues - PSA-2023-07-12

[security-news at drupal.org]

View online: https://www.drupal.org/psa-2023-07-12

Date: 2023-July-11
Description: 
Beginning today, Drupal core issues reported to the Security Team with risk
levels [1] that are "Not Critical", "Less Critical", or "Moderately Critical"
may be treated as bugs in the public issue queue, not as private security
issues requiring a security advisory and CVE.

.... Policy Change

The Security Team will use its discretion to handle some issues in public
depending on the risk score, the severity of the impact, the difficulty to
exploit, and any other mitigating factors.

We still encourage all security researchers to start by filing a private
issue [2] that can then be moved public later. Members of the Security Team
also will sometimes unpublish a public issue and move it private as needed.

Drupal core issues with risk levels [3] of "Critical" or "Highly Critical"
will continue to be private security issues. Some issues with lower risk
scores will also be handled privately at Security Team discretion, depending
on their impact.

.... What are some examples?

Exactly which issues are moved into the public queue will be at the
discretion of the Security Team members triaging the issue. Some examples of
common categories follow.

.. Information disclosure

Information disclosure is when information that should be private can be seen
outside of the intended private context.

A key difference between this and other kinds of security issues is that the
circumstances in which it is a security risk often greatly reduce the risk of
information being disclosed publicly.

Sometimes, the information being disclosed is already public on the internet
without any explicit action from users. For example, if unpublished article
teasers accidentally show in a listing accessible to anonymous users, these
will be visible to anyone visiting the page including search engines and
other crawlers. Keeping the information disclosure /bug/ private does not
keep the information itself private in these cases; it is already public.

Other times, metadata about an article like its title or URL is leaked only
to users who already have content editing or similar permissions on a site,
and via their normal workflows. The potential audience for the leaked
information is very small, they may already be seeing it, the impact of
learning that secret is likely low.

These issues often require significant active effort against an individual
site to exploit. The amount of effort and individual-site nature make them
less likely to be exploited.

Scenarios that would make the issue a security vulnerability are extremely
uncommon. For example, a vulnerability might expose the content of a field
under very specific circumstances. The contents of that field might only be
considered important in rare circumstances. In those situations we would tend
toward fixing the bug in public.

In scenarios when the information disclosure would represent a great risk to
many sites we will not disclose publicly. For example, if you could get
access to the passwords of users, or secret keys as an anonymous user, those
issues would be handled privately with a security advisory.

.. Content injection

Content injection vulnerabilities exist when information from a URL ends up
reflected in the HTML page, which can result in unwanted content being
accessible from a domain. While these bugs are embarrassing, they do not
allow other kinds of access unless paired with a cross-site scripting (XSS)
or similar vulnerability.

.. Denial of service

Denial of service is an attack intended to render a site unusable, usually by
saturating it with traffic. Certain categories of bugs sometimes make these
attacks easier (for example, triggering code that takes a long time to run).
However, they are often symptoms of scalability issues or type checking
errors, which are routinely fixed in public.

.... What if sites I manage are concerned about these kinds of issues?

You should monitor the Drupal core issue queue for the 'Security' and
'Security improvements' [4] tags and dedicate resources to helping fix those
issues.

.... What should I do if I find a security issue that might fall under the
       above?

You should still report the issue privately to the Security Team so that they
can verify it is not a symptom of a different security issue (such as access
bypass or privilege escalation) and that it meets the guidelines above that
allow it to be handled in public. The Security Team may then  have you open a
public issue and close the private report.

.... What will happen to  issues meeting these criteria that are already open
       in the private issue tracker?

These will be transferred to the public issue queues for their respective
projects over time.

Coordinated By: 
The following people contributed to this public service announcement.

   * xjm [5] of the Drupal Security Team
   * Michael Hess [6] of the Drupal Security Team
   * Nathaniel Catchpole [7] of the Drupal Security Team
   * Greg Knaddison [8] of the Drupal Security Team
   * Lee Rowlands [9] of the Drupal Security Team
   * cilefen [10] of the Drupal Security Team
   * Cathy Theys [11] of the Drupal Security Team


[1] https://www.drupal.org/drupal-security-team/security-risk-levels-defined
[2]
https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquette/reporting-a-security-issue
[3] https://www.drupal.org/drupal-security-team/security-risk-levels-defined
[4]
https://www.drupal.org/project/issues/search/drupal?project_issue_followers=&status%5B%5D=Open&version%5B%5D=any_11.&version%5B%5D=any_10.&issue_tags_op=%3D&issue_tags=security%2C+Security+improvements
[5] https://www.drupal.org/user/65776
[6] https://www.drupal.org/user/102818
[7] https://www.drupal.org/user/35733
[8] https://www.drupal.org/user/36762
[9] https://www.drupal.org/user/395439
[10] https://www.drupal.org/user/1850070
[11] https://www.drupal.org/user/258568