Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

EGI CSIRT:Alerts/AdvisoryTemplate

From EGIWiki
Revision as of 14:46, 22 November 2010 by Tdussa (talk | contribs) (Initial revision.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
!!! Choose proper TLP color
** WHITE information - Unlimited distribution allowed                       **
** GREEN information - Community-wide distribution allowed                  **
** AMBER information - Limited distribution allowed                         **
** RED information - Personal for Named Recipients Only                     **
** see https://wiki.egi.eu/wiki/EGI_CSIRT:TLP for distribution restrictions **

!!! Fill in advisory number, title, date, and URL
!!! Title should be prepended by the criticality rating (e. g., CRITICAL, HIGH, ...)
!!! If applicable, a CVE number or the like should be included
!!! The title should be used as mail subject as well
EGI CSIRT ADVISORY [EGI-ADV-YYYYMMDD]

Title:       CRITICAL Local Root Vulnerability in the Linux Kernel (CVE-YYYY-NNNN) [EGI-ADV-YYYYMMDD]
Date:        Month DD, YYYY
Last update: Month DD, YYYY
URL:         https://wiki.egi.eu/wiki/EGI_CSIRT:Alerts/EGI-ADV-YYYYMMDD


Introduction
============

!!! Give a brief (one paragraph, three to five sentences) description
!!! of the vulnerability, containing at least
!!!  + general nature of the vulnerability
!!!  + affected systems (broadly)
!!!  + whether PoC/live exploits exist
!!!  + mitigation status (broadly)
!!!  + patch status (broadly)
!!!  + deadlines, if any
!!! Technical details go in the next section
!!! Fictive example below:
On 2010-11-22, a linux kernel vulnerability (CVE-2010-9999) was disclosed.
The vulnerability allows local users to gain root privileges; affected
distributions include RHEL 5, SL 5, SLC 5.  No live exploit is known to
exist; however, proof-of-concept code is public.  Vendor patches are
not available yet, mitigation is theoretically possible but of little
practical value.

EGI CSIRT considers this to be a CRITICAL vulnerability; either
workarounds or patches MUST be in place on running resources by
2010-11-29T21:00+01:00 (Monday, November 29, 21:00 CET).


Details
=======

!!! Technical details
!!!  + vulnerability details
!!!  + PoC/exploit details
!!! Fictive example below:
In kernel version 2.6.20, a buffer overflow in the VFS stack was
introduced, allowing an attacker with local access to execute
arbitrary code by creating a file with a carefully chosen name.
In principle, the vulnerability is independent of the underlying
file system used; however, to actually exploit the vulnerability,
a file name with a length of at least 36 characters must be used.

Proof-of-concept code is public but does not run any malicious
code.  An attacker can easily build a working exploit based on
this code, though.


Mitigation
==========

!!! Details and instructions on how to mitigate, if available
!!! If possible and sensible, include command lines to be used
!!! Fictive example below:
Theoretically, it is possible to work around this vulnerability
by preventing regular users from writing to a file system, for
example by mounting all file systems read-only.  

Another possibility is to use only filesystems that do not support
file names longer than 35 characters, for instance FAT (not VFAT).

Finally, it is possible to set the set_vulnerable parameter of the
virtual filesystem to 0; however, this slows down file system
accesses by a factor of 100.  The parameter may be set with the
following command as root:
---
  echo 0 > /proc/vfs/set_vulnerable
---

The current state can be queried with this command:
---
  cat /proc/vfs/set_vulnerable
---


Recommendations
===============

!!! EGI CSIRT recommendations
!!! Again repeat the deadline, if any
!!! Fictive example below:
Immediately apply vendor patches as they become available.  All
running resources MUST be either patched or otherwise have a
work-around in place by 2010-11-29T21:00+01:00.

Vendor patches are already announced for these distributions:
* Ubuntu
* RHEL5
* SL5
* SLC5
* CentOS5


References
==========

!!! Any references to the vulnerability
!!! Include links to vendor pages with patches as they become available
!!! Fictive example below:
Ubuntu kernel update:
https://lists.ubuntu.com/archives/ubuntu-security-announce/2010-November/999999.html

RHEL5 update:
https://rhn.redhat.com/errata/RHSA-2010-9999.html