Lucene search

K
nessusThis script is Copyright (C) 2014-2021 and is owned by Tenable, Inc. or an Affiliate thereof.ORACLEVM_OVMSA-2013-0042.NASL
HistoryNov 26, 2014 - 12:00 a.m.

OracleVM 3.2 : xen (OVMSA-2013-0042)

2014-11-2600:00:00
This script is Copyright (C) 2014-2021 and is owned by Tenable, Inc. or an Affiliate thereof.
www.tenable.com
15

The remote OracleVM system is missing necessary patches to address critical security updates :

  • Other than the HVM emulation path, the PV case so far failed to check that YMM state requires SSE state to be enabled, allowing for a #GP to occur upon passing the inputs to XSETBV inside the hypervisor. This is CVE-2013-2078 / XSA-54. (CVE-2013-2078)

  • x86/xsave: recover from faults on XRSTOR Just like FXRSTOR, XRSTOR can raise #GP if bad content is being passed to it in the memory block (i.e. aspects not under the control of the hypervisor, other than e.g. proper alignment of the block). Also correct the comment explaining why FXRSTOR needs exception recovery code to not wrongly state that this can only be a result of the control tools passing a bad image. This is CVE-2013-2077 / XSA-53. (CVE-2013-2077)

  • x86/xsave: fix information leak on AMD CPUs Just like for FXSAVE/FXRSTOR, XSAVE/XRSTOR also don’t save/restore the last instruction and operand pointers as well as the last opcode if there’s no pending unmasked exception (see CVE-2006-1056 and commit 9747:4d667a139318). While the FXSR solution sits in the save path, I prefer to have this in the restore path because there the handling is simpler (namely in the context of the pending changes to properly save the selector values for 32-bit guest code). Also this is using FFREE instead of EMMS, as it doesn’t seem unlikely that in the future we may see CPUs with x87 and SSE/AVX but no MMX support. The goal here anyway is just to avoid an FPU stack overflow. I would have preferred to use FFREEP instead of FFREE (freeing two stack slots at once), but AMD doesn’t document that instruction. This is CVE-2013-2076 / XSA-52.
    (CVE-2013-2076)

#%NASL_MIN_LEVEL 70300
#
# (C) Tenable Network Security, Inc.
#
# The package checks in this plugin were extracted from OracleVM
# Security Advisory OVMSA-2013-0042.
#

include('deprecated_nasl_level.inc');
include('compat.inc');

if (description)
{
  script_id(79510);
  script_version("1.4");
  script_set_attribute(attribute:"plugin_modification_date", value:"2021/01/04");

  script_cve_id("CVE-2006-1056", "CVE-2013-2076", "CVE-2013-2077", "CVE-2013-2078");
  script_bugtraq_id(17600, 60277, 60278, 60282);

  script_name(english:"OracleVM 3.2 : xen (OVMSA-2013-0042)");
  script_summary(english:"Checks the RPM output for the updated packages.");

  script_set_attribute(
    attribute:"synopsis", 
    value:"The remote OracleVM host is missing one or more security updates."
  );
  script_set_attribute(
    attribute:"description", 
    value:
"The remote OracleVM system is missing necessary patches to address
critical security updates :

  - Other than the HVM emulation path, the PV case so far
    failed to check that YMM state requires SSE state to be
    enabled, allowing for a #GP to occur upon passing the
    inputs to XSETBV inside the hypervisor. This is
    CVE-2013-2078 / XSA-54. (CVE-2013-2078)

  - x86/xsave: recover from faults on XRSTOR Just like
    FXRSTOR, XRSTOR can raise #GP if bad content is being
    passed to it in the memory block (i.e. aspects not under
    the control of the hypervisor, other than e.g. proper
    alignment of the block). Also correct the comment
    explaining why FXRSTOR needs exception recovery code to
    not wrongly state that this can only be a result of the
    control tools passing a bad image. This is CVE-2013-2077
    / XSA-53. (CVE-2013-2077)

  - x86/xsave: fix information leak on AMD CPUs Just like
    for FXSAVE/FXRSTOR, XSAVE/XRSTOR also don't save/restore
    the last instruction and operand pointers as well as the
    last opcode if there's no pending unmasked exception
    (see CVE-2006-1056 and commit 9747:4d667a139318). While
    the FXSR solution sits in the save path, I prefer to
    have this in the restore path because there the handling
    is simpler (namely in the context of the pending changes
    to properly save the selector values for 32-bit guest
    code). Also this is using FFREE instead of EMMS, as it
    doesn't seem unlikely that in the future we may see CPUs
    with x87 and SSE/AVX but no MMX support. The goal here
    anyway is just to avoid an FPU stack overflow. I would
    have preferred to use FFREEP instead of FFREE (freeing
    two stack slots at once), but AMD doesn't document that
    instruction. This is CVE-2013-2076 / XSA-52.
    (CVE-2013-2076)"
  );
  script_set_attribute(
    attribute:"see_also",
    value:"https://oss.oracle.com/pipermail/oraclevm-errata/2013-June/000155.html"
  );
  script_set_attribute(
    attribute:"solution", 
    value:"Update the affected xen / xen-devel / xen-tools packages."
  );
  script_set_cvss_base_vector("CVSS2#AV:A/AC:M/Au:S/C:N/I:N/A:C");
  script_set_cvss_temporal_vector("CVSS2#E:ND/RL:OF/RC:C");
  script_set_attribute(attribute:"exploitability_ease", value:"No known exploits are available");
  script_set_attribute(attribute:"exploit_available", value:"false");

  script_set_attribute(attribute:"plugin_type", value:"local");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:oracle:vm:xen");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:oracle:vm:xen-devel");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:oracle:vm:xen-tools");
  script_set_attribute(attribute:"cpe", value:"cpe:/o:oracle:vm_server:3.2");

  script_set_attribute(attribute:"vuln_publication_date", value:"2006/04/20");
  script_set_attribute(attribute:"patch_publication_date", value:"2013/06/04");
  script_set_attribute(attribute:"plugin_publication_date", value:"2014/11/26");
  script_set_attribute(attribute:"generated_plugin", value:"current");
  script_end_attributes();

  script_category(ACT_GATHER_INFO);
  script_copyright(english:"This script is Copyright (C) 2014-2021 and is owned by Tenable, Inc. or an Affiliate thereof.");
  script_family(english:"OracleVM Local Security Checks");

  script_dependencies("ssh_get_info.nasl");
  script_require_keys("Host/local_checks_enabled", "Host/OracleVM/release", "Host/OracleVM/rpm-list");

  exit(0);
}


include("audit.inc");
include("global_settings.inc");
include("rpm.inc");

if (!get_kb_item("Host/local_checks_enabled")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);
release = get_kb_item("Host/OracleVM/release");
if (isnull(release) || "OVS" >!< release) audit(AUDIT_OS_NOT, "OracleVM");
if (! preg(pattern:"^OVS" + "3\.2" + "(\.[0-9]|$)", string:release)) audit(AUDIT_OS_NOT, "OracleVM 3.2", "OracleVM " + release);
if (!get_kb_item("Host/OracleVM/rpm-list")) audit(AUDIT_PACKAGE_LIST_MISSING);

cpu = get_kb_item("Host/cpu");
if (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);
if ("x86_64" >!< cpu && cpu !~ "^i[3-6]86$") audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, "OracleVM", cpu);
if ("x86_64" >!< cpu) audit(AUDIT_ARCH_NOT, "x86_64", cpu);

flag = 0;
if (rpm_check(release:"OVS3.2", reference:"xen-4.1.3-25.el5.6.13")) flag++;
if (rpm_check(release:"OVS3.2", reference:"xen-devel-4.1.3-25.el5.6.13")) flag++;
if (rpm_check(release:"OVS3.2", reference:"xen-tools-4.1.3-25.el5.6.13")) flag++;

if (flag)
{
  if (report_verbosity > 0) security_warning(port:0, extra:rpm_report_get());
  else security_warning(0);
  exit(0);
}
else
{
  tested = pkg_tests_get();
  if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);
  else audit(AUDIT_PACKAGE_NOT_INSTALLED, "xen / xen-devel / xen-tools");
}
VendorProductVersionCPE
oraclevmxenp-cpe:/a:oracle:vm:xen
oraclevmxen-develp-cpe:/a:oracle:vm:xen-devel
oraclevmxen-toolsp-cpe:/a:oracle:vm:xen-tools
oraclevm_server3.2cpe:/o:oracle:vm_server:3.2