| Issue Number | 810 |
|---|---|
| Summary | Uninstall Comment module |
| Created | 2024-01-17 14:50:03 |
| Issue Type | Improvement |
| Submitted By | Kline, Bob (NIH/NCI) [C] |
| Assigned To | Kline, Bob (NIH/NCI) [C] |
| Status | Closed |
| Resolved | 2024-02-16 06:36:27 |
| Resolution | Won't Fix |
| Path | /home/bkline/backups/jira/oceebms/issue.386817 |
A security bulletin was released this afternoon, reporting a Denial-of-Service (DoS) vulnerability in the core Comment module. The announcement says "Sites that do not use the Comment module are not affected." So strictly speaking, the EBMS is not affected, because although the module is enabled, we don't make any use of it. We have no Article content nodes (the only type in the system which allows Comment fields supported by this module). (The comment fields in our content use custom fields which I implemented myself, in order to avoid the footprint of the core Comment module, as well as—as it turned out— this vulnerability.)
We have four options.
Remove the unused Article content type and disable the Comment module now.
Remove the Comment field from the Article content type and disable the Comment module now.
Remove the unused Article content type and disable the Comment module as part of Harpers Ferry.
Remove the Comment field from the Article content type and disable the Comment module as part of Harpers Ferry.
My own preference would be #3 or #4, because that would avoid having to do any additional testing beyond what we'll need to do anyway for the Harpers Ferry release. Which of those two options we prefer would depend on whether the users think they'd ever want to use the EBMS to create blog-like articles for the site (seems unlikely).
If we get any grief from CBIIT or CIT and we can't convince them that we're not really at risk since we don't have any comments in the system (and it's not really a public-facing system), then it's possible we'd need to choose option #1 or #2. In the worst-case scenario, if CBIIT or CIT insisted that even disabling the module was insufficient, we'd need to upgrade Drupal to the latest version between releases.
Adding ~vshields, ~juther, and ~duganal for visibility.
~vshields and ~juther - do you want to weigh in on whether you think it's possible we'll ever want to create article pages (referring to the blog-like content type native to Drupal, not the pages for imported PubMed articles) for the EBMS? There's actually a fifth option if you do, which is to do nothing beyond the Drupal upgrade taken care of by OCEEBMS-795, which eliminates the security hole. And to re-iterate: we're not vulnerable to it in the meantime, because we don't currently have any content which accepts Drupal core comments in the system.
We've decided to go with option #5, which is to do nothing.
Elapsed: 0:00:00.000556