|
|
| |
|
| |
Security
By Jonathan Corbet
February 19, 2013
A security-oriented firm called Trustwave recently sent out a
preview of an upcoming report [PDF] that features some focused criticism of
how the Linux community handles security vulnerabilities. Indeed, it says:
" Software developers vary greatly in their ability to respond and
patch zero-day vulnerabilities. In this study, the Linux platform had the
worst response time, with almost three years on average from initial
vulnerability to patch." Whether or not one is happy with how
security updates work with Linux, three years sounds like a rather longer
response time than most of us normally expect. Your editor decided to
examine the situation by focusing on two vulnerabilities that are said to
be included in the Trustwave report and one that is not.
Three years?
As of this writing, Trustwave's full report is not available, so a detailed
look at its claims is not possible. But, according to this
ZDNet article, the average response time was calculated from these two
"zero-day" vulnerabilities:
- CVE-2009-4307: a divide-by-zero crash
in the ext4 filesystem code. Causing this oops requires convincing
the user to mount a specially-crafted ext4 filesystem image.
- CVE-2009-4020: a buffer overflow in
the HFS+ filesystem exploitable, once again, by convincing a user to
mount a specially-crafted filesystem image on the target system.
The ext4 problem was reported on
October 1, 2009 by R.N. Sastry, who had been doing some filesystem fuzz
testing. The report included the filesystem image that triggered the bug —
that is the "exploit code" that Trustwave used to call this bug a zero-day
vulnerability. Since the problem was limited to a kernel oops, and since
it required the victim's cooperation (in the form of mounting the
attacker's filesystem) to trigger, the ext4 developers did
not feel the need to drop everything and fix it immediately; Ted Ts'o
committed a
fix toward the end of November. SUSE was the first distributor to
issue an update containing the fix; that happened on January 17, 2010.
Red Hat did not put out an update until the end of March — nearly five
months after the problem was disclosed — and Mandriva waited until February
of 2011.
One might argue that things happened slowly, even for an extremely
low-priority bug, but where does "three years" come from? It turns out
that the fix did not work properly on the x86 architecture; Xi Wang
reported the problem's continued existence
on December 26,
2011, and sent a proper fix on
January 9, 2012. A new CVE number (CVE-2012-2100) was assigned for the problem
and the fix was promptly committed into the mainline. Distributors were a
bit slow to catch up, though; Debian issued an update in March, Ubuntu in
May, and Red Hat waited until mid-November — nearly eleven months after
disclosure — to ship the fix to its users. The elapsed time from the
initial disclosure until Red Hat's shipping an update that fixes the
problem properly is, indeed, just over three years.
The story for the HFS/HFS+ vulnerability is similar. An initial patch
fixing a buffer overflow in the HFS filesystem was posted by Amerigo Wang
at the beginning of December, 2009. The fix was committed by Linus on
December 15, and distributor updates began with Red Hat's on
January 19, 2010. Some distributors were rather slower, but it was
another hard-to-exploit bug that was deemed to have a low priority.
The problem is that the kernel supports another (newer) filesystem called
HFS+. It
is a separate filesystem implementation, but it contains a fair amount of
code that was cut-and-pasted from the original HFS implementation, much like ext4
started with a copy of the ext3 code. The danger of this type of code
duplication is well known: developers will fix a bug in one copy but not
realize that the same issue may be present in the other copy as well.
Naturally enough,
that was the case here; the HFS+ filesystem had the same buffer overflow
vulnerability, but nobody thought to do anything about it until Timo Warns
quietly told a few kernel developers about it at the end of April 2012.
Greg Kroah-Hartman committed
a fix on May 4, and the problem was publicly disclosed a few days
after that. Once again, a new CVE number (CVE-2012-2319) was assigned, and, once again,
distributors dawdled with the fixes; openSUSE sent an update in June, while
Red Hat waited until October, five months after the problem became known.
The time period from the initial disclosure of the HFS vulnerability until
Red Hat's update for the HFS+ problem was just short of three years.
One could look at this situation two ways. On one hand, Trustwave has clearly chosen
its vulnerabilities carefully, then applied an interpretation that yielded
the longest delay possible. Neither story above describes a zero-day
vulnerability knowingly left open for three years; for most of that time,
it was assumed that the problems had been fixed. That is doubly true for
the HFS+ filesystem, for which the vulnerability was not even disclosed
until May, 2012. Given the nature of the vulnerabilities, it is highly
unlikely that the black hats were jealously guarding them in the meantime;
the odds are good that no system has ever been compromised by exploiting
either one of them. Trustwave's claims, if they are indeed built on these
two vulnerabilities, are dubious and exaggerated at best.
On the other hand, even low-priority vulnerabilities requiring the victim's
cooperation should be fixed — and fixed properly — in a timely manner,
and it is not at all clear that happened with these problems. The
response to the ext4 problem was arguably fast enough given the nature of
the problem, but the fact that the problem persisted on the obscure x86
architecture suggests that the testing applied to that fix was, at best,
incomplete. In the HFS/HFS+ case, one could argue that somebody
should have thought to check for copies of the bug elsewhere. The fact
that the HFS and HFS+ filesystems are nearly unused and nearly unmaintained
did not
help in this case, but attackers do not restrict themselves to
well-maintained code. And, for both bugs, distributors took their time to get
the fixes out to their users. We can do better than that.
Meanwhile, in 2013
Perhaps the slowness observed above is the natural response to
vulnerabilities that nobody is actually all that worried about. Had they
been something more serious, it could be argued, the response would have
been better. As it happens, there is an open issue at the time of this
writing that can be examined to see how well we do respond; the answer
is a bit discouraging.
On January 20, a discussion on the private kernel security list went public
with this patch posting by Oleg Nesterov.
It seems that the Linux implementation of the ptrace() system call
contains a race condition: a traced process's registers can be changed in a
way that causes the
kernel to restore that process's stack contents to an arbitrary location.
The end result
is the ability to run arbitrary code in kernel mode. It is a local attack,
in that the attacker needs to be able to run an exploit program on the
target system. But, given the ability to run such a program, the attacker
can obtain full root privileges. That is the kind of vulnerability
that needs quick attention; it puts every system out there at the mercy of
any untrusted users that may have accounts there — or at the mercy of any
attacker that may be able to
compromise a network service to run an arbitrary program.
On February 15, the vulnerability was disclosed as such, complete with handy exploit
code for those who do not wish to write their own. Most victims are
unlikely to apply the kernel patch included with the exploit that makes the
race condition easier to
hit; the exploit also needs the ability to run a process with real-time
priority to win the race more reliably.
But, even without the patch or real-time scheduling, a sufficiently patient
attacker should be able to
time things right eventually. Solar Designer reacted to the disclosure this way:
I haven't looked into this closely yet, but at first glance it
looks like the worst Linux kernel vulnerability in a few years.
For distro vendor kernels (rather than mainline, which was patched
almost a month ago), this is a 0-day.
Arguably this should not be a zero-day vulnerability: the public discussion
of the fix is nearly one month old, and the private discussion had been
going on for some time before. But, as of this writing, no distributors
have issued updates for this problem. That leads to some obvious
questions; quoting Solar Designer again:
The mainline commits from January are by Oleg Nesterov of Red Hat.
Why wasn't(?) the issue handled with due severity within Red Hat,
then - such that Red Hat would at the very least have a statement
on whether and which of their kernels are affected by now.
One assumes that such a statement will be forthcoming in the near future. In the meantime,
users and system administrators worldwide need to be worried about whether
their systems are vulnerable and who might be exploiting the problem.
Once again, we can do better than that. This bug was known to be a serious
vulnerability from the outset; one of the developers who reported it
(Salman Qazi, of Google) also provided the exploit code to show how severe
the situation was. Distributors knew about the problem and had time to
respond to it — but that response did not happen in a timely manner. The
ptrace() problem will certainly be
straightened out in less than three years, but that still may not be a
reason for pride. Users should not be left wondering what the situation is
(at least) one month after distributors know about a serious vulnerability.
Comments (52 posted)
Brief items
I know some people don't "like" how the kernel team handles bug
reports and fixes, but seriously, this should have been pretty
obvious by anyone watching the stable kernel releases, which all
distros do. The fact that the distros didn't notify others is not
the kernel community's fault, sorry.
— Greg Kroah-Hartman
Comments (none posted)
James Bottomley describes
the process of taking control of a UEFI secure boot system.
" Even if you only ever plan to run Windows or stock distributions of
Linux that already have secure boot support, I’d encourage everybody who
has a new UEFI secure boot platform to take ownership of it. The way you
do this is by installing your own Platform Key. Once you have done this,
you can use key database maintenance tools like keytool to edit all the
keys on the Platform and move the platform programmatically from Setup Mode
to User Mode and back again. This blog post describes how you go about
doing this."
Comments (57 posted)
Over at Linux.com, Linux Foundation (LF) system administrator Konstantin Ryabitsev describes a joint effort by the LF and the Fedora project to support two-factor authentication in Linux. The article describes multi-factor authentication, some of the problems inherent with using hardware tokens, and notes that smartphones can provide much of the same functionality without requiring a dedicated device. " Nearly all of us carry a powerful computer in our pocket that is more than capable of calculating and displaying TOTP [Time-based One-Time Password] tokens. Google recognized this a while back and released a free mobile app called 'Google Authenticator,' available on most mobile platforms. Anyone can set up two-factor authentication for their Google Account using the Authenticator, but the best part is that it's not just limited to Google's services. Since TOTP is an open standard, any infrastructure can use Google Authenticator to provision their own software tokens and implement TOTP-based two-factor authentication for their services."
Comments (74 posted)
New vulnerabilities
blender: privilege escalation
| Package(s): | blender |
CVE #(s): | CVE-2010-5105
|
| Created: | February 15, 2013 |
Updated: | February 20, 2013 |
| Description: |
From the openSUSE bug tracker:
An insecure temporary file use flaw was found in the way
'undo save quit' routine of Blender kernel of Blender, a 3D
modeling, animation, rendering and post-production software
solution, performed management of 'quit.blend' temporary file,
used for session recovery purposes. A local attacker could use
this flaw to conduct symbolic link attacks, leading to ability
to overwrite arbitrary system file, accessible with the privileges
of the user running the blender executable.
|
| Alerts: |
|
Comments (none posted)
boost: input validation bypass
| Package(s): | boost1.49 |
CVE #(s): | CVE-2013-0252
|
| Created: | February 18, 2013 |
Updated: | February 25, 2013 |
| Description: |
From the Ubuntu advisory:
It was discovered that the Boost.Locale library incorrectly validated some
invalid UTF-8 sequences. An attacker could possibly use this issue to
bypass input validation in certain applications. |
| Alerts: |
|
Comments (none posted)
dbus-glib: privilege escalation
| Package(s): | dbus-glib |
CVE #(s): | CVE-2013-0292
|
| Created: | February 18, 2013 |
Updated: | March 11, 2013 |
| Description: |
From the Mageia advisory:
A privilege escalation flaw was found in the way dbus-glib, the D-Bus
add-on library to integrate the standard D-Bus library with the GLib
thread abstraction and main loop, performed filtering of the message
sender (message source subject), when the NameOwnerChanged signal was
received. A local attacker could use this flaw to escalate their
privileges. |
| Alerts: |
|
Comments (none posted)
gnome-online-accounts: information disclosure
| Package(s): | gnome-online-accounts |
CVE #(s): | CVE-2013-0240
|
| Created: | February 15, 2013 |
Updated: | March 25, 2013 |
| Description: |
From the openSUSE bug tracker:
It was found that Gnome Online Accounts (GOA)
did not perform SSL certificate validation, when
performing Windows Live and Facebook accounts creation.
A remote attacker could use this flaw to conduct
man-in-the-middle (MiTM) attacks, possibly leading
to their ability to obtain sensitive information. |
| Alerts: |
|
Comments (none posted)
java: sandbox restriction bypass
| Package(s): | java |
CVE #(s): | CVE-2013-1486
|
| Created: | February 20, 2013 |
Updated: | March 19, 2013 |
| Description: |
From the Red Hat advisory:
An improper permission check issue was discovered in the JMX component in
OpenJDK. An untrusted Java application or applet could use this flaw to
bypass Java sandbox restrictions. |
| Alerts: |
|
Comments (none posted)
java: sandbox restriction bypass
| Package(s): | java |
CVE #(s): | CVE-2013-1484
CVE-2013-1485
|
| Created: | February 20, 2013 |
Updated: | February 21, 2013 |
| Description: |
From the Red Hat advisory:
Improper permission check issues were discovered in the JMX and
Libraries components in OpenJDK. An untrusted Java application or applet
could use these flaws to bypass Java sandbox restrictions. (CVE-2013-1484)
An improper permission check issue was discovered in the Libraries
component in OpenJDK. An untrusted Java application or applet could use
this flaw to bypass certain Java sandbox restrictions. (CVE-2013-1485) |
| Alerts: |
|
Comments (none posted)
jquery: cross-site scripting
| Package(s): | jquery |
CVE #(s): | CVE-2011-4969
|
| Created: | February 14, 2013 |
Updated: | March 13, 2013 |
| Description: |
From the Ubuntu advisory:
It was discovered that jQuery incorrectly handled selecting elements using
location.hash, resulting in a possible cross-site scripting (XSS) issue.
With cross-site scripting vulnerabilities, if a user were tricked into
viewing a specially crafted page, a remote attacker could exploit this to
modify the contents, or steal confidential data, within the same domain.
|
| Alerts: |
|
Comments (none posted)
kernel: denial of service
| Package(s): | kernel |
CVE #(s): | CVE-2013-0290
|
| Created: | February 18, 2013 |
Updated: | March 22, 2013 |
| Description: |
From the Red Hat bugzilla:
A flaw was found in the way __skb_recv_datagram() processed skbs with no payload when MSG_PEEK was requested. An unprivileged local user could use this flaw to cause local denial of service. |
| Alerts: |
|
Comments (none posted)
mediawiki: session fixation flaw
| Package(s): | mediawiki |
CVE #(s): | CVE-2012-5391
|
| Created: | February 19, 2013 |
Updated: | March 22, 2013 |
| Description: |
From the Red Hat bugzilla:
A session fixation flaw was found in the way MediaWiki, a wiki engine, performed maintenance of user session ids after user login / logout. A remote attacker could provide a specially-crafted URL that, when visited by an authenticated MediaWiki user, could allow the attacker to impersonate the victim.
|
| Alerts: |
|
Comments (none posted)
mozilla: multiple vulnerabilities
| Package(s): | firefox thunderbird seamonkey |
CVE #(s): | CVE-2013-0784
CVE-2013-0772
CVE-2013-0765
CVE-2013-0773
CVE-2013-0774
CVE-2013-0777
CVE-2013-0778
CVE-2013-0779
CVE-2013-0781
|
| Created: | February 20, 2013 |
Updated: | March 11, 2013 |
| Description: |
From the CVE entries:
Multiple unspecified vulnerabilities in the browser engine in Mozilla Firefox before 19.0, Thunderbird before 17.0.3, and SeaMonkey before 2.16 allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via unknown vectors. (CVE-2013-0784)
The RasterImage::DrawFrameTo function in Mozilla Firefox before 19.0, Thunderbird before 17.0.3, and SeaMonkey before 2.16 allows remote attackers to obtain sensitive information from process memory or cause a denial of service (out-of-bounds read and application crash) via a crafted GIF image. (CVE-2013-0772)
Mozilla Firefox before 19.0, Thunderbird before 17.0.3, and SeaMonkey before 2.16 do not prevent multiple wrapping of WebIDL objects, which allows remote attackers to bypass intended access restrictions via unspecified vectors. (CVE-2013-0765)
The Chrome Object Wrapper (COW) and System Only Wrapper (SOW) implementations in Mozilla Firefox before 19.0, Firefox ESR 17.x before 17.0.3, Thunderbird before 17.0.3, Thunderbird ESR 17.x before 17.0.3, and SeaMonkey before 2.16 do not prevent modifications to a prototype, which allows remote attackers to obtain sensitive information from chrome objects or possibly execute arbitrary JavaScript code with chrome privileges via a crafted web site. (CVE-2013-0773)
Mozilla Firefox before 19.0, Firefox ESR 17.x before 17.0.3, Thunderbird before 17.0.3, Thunderbird ESR 17.x before 17.0.3, and SeaMonkey before 2.16 do not prevent JavaScript workers from reading the browser-profile directory name, which has unspecified impact and remote attack vectors. (CVE-2013-0774)
Use-after-free vulnerability in the nsDisplayBoxShadowOuter::Paint function in Mozilla Firefox before 19.0, Thunderbird before 17.0.3, and SeaMonkey before 2.16 allows remote attackers to execute arbitrary code or cause a denial of service (heap memory corruption) via unspecified vectors. (CVE-2013-0777)
The ClusterIterator::NextCluster function in Mozilla Firefox before 19.0, Thunderbird before 17.0.3, and SeaMonkey before 2.16 allows remote attackers to execute arbitrary code or cause a denial of service (out-of-bounds read) via unspecified vectors. (CVE-2013-0778)
The nsCodingStateMachine::NextState function in Mozilla Firefox before 19.0, Thunderbird before 17.0.3, and SeaMonkey before 2.16 allows remote attackers to execute arbitrary code or cause a denial of service (out-of-bounds read) via unspecified vectors. (CVE-2013-0779)
Use-after-free vulnerability in the nsPrintEngine::CommonPrint function in Mozilla Firefox before 19.0, Thunderbird before 17.0.3, and SeaMonkey before 2.16 allows remote attackers to execute arbitrary code or cause a denial of service (heap memory corruption) via unspecified vectors. (CVE-2013-0781)
|
| Alerts: |
|
Comments (none posted)
mozilla: multiple vulnerabilities
| Package(s): | firefox thunderbird seamonkey |
CVE #(s): | CVE-2013-0775
CVE-2013-0776
CVE-2013-0780
CVE-2013-0782
CVE-2013-0783
|
| Created: | February 20, 2013 |
Updated: | March 11, 2013 |
| Description: |
From the CVE entries:
Use-after-free vulnerability in the nsImageLoadingContent::OnStopContainer function in Mozilla Firefox before 19.0, Firefox ESR 17.x before 17.0.3, Thunderbird before 17.0.3, Thunderbird ESR 17.x before 17.0.3, and SeaMonkey before 2.16 allows remote attackers to execute arbitrary code via crafted web script. (CVE-2013-0775)
Mozilla Firefox before 19.0, Firefox ESR 17.x before 17.0.3, Thunderbird before 17.0.3, Thunderbird ESR 17.x before 17.0.3, and SeaMonkey before 2.16 allow man-in-the-middle attackers to spoof the address bar by operating a proxy server that provides a 407 HTTP status code accompanied by web script, as demonstrated by a phishing attack on an HTTPS site. (CVE-2013-0776)
Use-after-free vulnerability in the nsOverflowContinuationTracker::Finish function in Mozilla Firefox before 19.0, Firefox ESR 17.x before 17.0.3, Thunderbird before 17.0.3, Thunderbird ESR 17.x before 17.0.3, and SeaMonkey before 2.16 allows remote attackers to execute arbitrary code or cause a denial of service (heap memory corruption) via a crafted document that uses Cascading Style Sheets (CSS) -moz-column-* properties. (CVE-2013-0780)
Heap-based buffer overflow in the nsSaveAsCharset::DoCharsetConversion function in Mozilla Firefox before 19.0, Firefox ESR 17.x before 17.0.3, Thunderbird before 17.0.3, Thunderbird ESR 17.x before 17.0.3, and SeaMonkey before 2.16 allows remote attackers to execute arbitrary code via unspecified vectors. (CVE-2013-0782)
Multiple unspecified vulnerabilities in the browser engine in Mozilla Firefox before 19.0, Firefox ESR 17.x before 17.0.3, Thunderbird before 17.0.3, Thunderbird ESR 17.x before 17.0.3, and SeaMonkey before 2.16 allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via unknown vectors. (CVE-2013-0783)
|
| Alerts: |
|
Comments (none posted)
nss-pam-ldapd: code execution
| Package(s): | nss-pam-ldapd |
CVE #(s): | CVE-2013-0288
|
| Created: | February 18, 2013 |
Updated: | March 25, 2013 |
| Description: |
From the Debian advisory:
Garth Mollett discovered that a file descriptor overflow issue in the
use of FD_SET() in nss-pam-ldapd, which provides NSS and PAM modules for
using LDAP as a naming service, can lead to a stack-based buffer
overflow. An attacker could, under some circumstances, use this flaw to
cause a process that has the NSS or PAM module loaded to crash or
potentially execute arbitrary code. |
| Alerts: |
|
Comments (none posted)
openconnect: code execution
| Package(s): | openconnect |
CVE #(s): | CVE-2012-6128
|
| Created: | February 15, 2013 |
Updated: | February 25, 2013 |
| Description: |
From the Mageia advisory:
A stack-based buffer overflow flaw was found in the way OpenConnect, a
client for Cisco's "AnyConnect" VPN, performed processing of certain
host names, paths, or cookie lists, received from the VPN gateway.
A remote VPN gateway could provide a specially-crafted host name, path
or cookie list that, when processed by the openconnect client would lead
to openconnect executable crash. |
| Alerts: |
|
Comments (none posted)
pidgin: multiple vulnerabilities
| Package(s): | pidgin |
CVE #(s): | CVE-2013-0271
CVE-2013-0272
CVE-2013-0273
CVE-2013-0274
|
| Created: | February 14, 2013 |
Updated: | March 21, 2013 |
| Description: |
From the Pidgin advisories:
CVE-2013-0271: The MXit protocol plugin saves an image to local disk using a filename that could potentially be partially specified by the IM server or by a remote user.
CVE-2013-0272: The code did not respect the size of the buffer when parsing HTTP headers, and a malicious server or man-in-the-middle could send specially crafted data that could overflow the buffer. This could lead to a crash or remote code execution.
CVE-2013-0273: libpurple failed to null-terminate user IDs that were longer than 4096 bytes. It's plausible that a malicious server could send one of these to us, which would lead to a crash.
CVE-2013-0274: libpurple failed to null-terminate some strings when parsing the response from a UPnP router. This could lead to a crash if a malicious user on your network responds with a specially crafted message. |
| Alerts: |
|
Comments (none posted)
polarssl: multiple vulnerabilities
| Package(s): | polarssl |
CVE #(s): | CVE-2013-1621
CVE-2013-1622
|
| Created: | February 14, 2013 |
Updated: | February 20, 2013 |
| Description: |
From the Debian advisory:
CVE-2013-1621:
An array index error might allow remote attackers to cause a denial
of service via vectors involving a crafted padding-length value
during validation of CBC padding in a TLS session
CVE-2013-1622:
Malformed CBC data in a TLS session could allow remote attackers to
conduct distinguishing attacks via statistical analysis of timing
side-channel data for crafted packets.
These appear to be related to the "Lucky Thirteen" vulnerabilities. |
| Alerts: |
|
Comments (none posted)
roundcubemail: cross-site scripting
| Package(s): | roundcubemail |
CVE #(s): | CVE-2012-6121
|
| Created: | February 18, 2013 |
Updated: | February 20, 2013 |
| Description: |
From the Red Hat bugzilla:
A cross-site scripting (XSS) flaws were round in the way Round Cube Webmail, a browser-based multilingual IMAP client, performed sanitization of 'data' and 'vbscript' URLs. A remote attacker could provide a specially-crafted URL that, when opened would lead to arbitrary JavaScript, VisualBasic script or HTML code execution in the context of Round Cube Webmail's user session. |
| Alerts: |
|
Comments (none posted)
rubygem-rdoc: cross-site scripting
| Package(s): | rubygem-rdoc |
CVE #(s): | CVE-2013-0256
|
| Created: | February 15, 2013 |
Updated: | February 20, 2013 |
| Description: |
From the Ruby advisory:
RDoc documentation generated by rdoc bundled with ruby are vulnerable to an XSS exploit. All ruby users are recommended to update ruby to newer version which includes security-fixed RDoc. If you are publishing RDoc documentation generated by rdoc, you are recommended to apply a patch for the documentaion or re-generate it with security-fixed RDoc.
RDoc documentation generated by rdoc 2.3.0 through rdoc 3.12 and prereleases up to rdoc 4.0.0.preview2.1 are vulnerable to an XSS exploit. This exploit may lead to cookie disclosure to third parties. |
| Alerts: |
|
Comments (none posted)
xen: denial of service
| Package(s): | xen |
CVE #(s): | CVE-2013-0215
CVE-2013-0153
|
| Created: | February 18, 2013 |
Updated: | February 20, 2013 |
| Description: |
From the Red Hat bugzilla [1], [2]:
[1] The oxenstored daemon (the ocaml version of the xenstore daemon) does
not correctly handle unusual or malicious contents in the xenstore
ring. A malicious guest can exploit this to cause oxenstored to read
past the end of the ring (and very likely crash) or to allocate large
amounts of RAM.
A malicious guest administrator can mount a denial of service attack
affecting domain control and management functions.
[2] To avoid an erratum in early hardware, the Xen AMD IOMMU code by default chooses to use a single interrupt remapping table for the whole system. This sharing implies that any guest with a passed through PCI device that is bus mastering capable can inject interrupts into other guests, including domain 0.
Furthermore, regardless of whether a shared interrupt remapping table is in use, old entries are not always cleared, providing opportunities (which accumulate over time) for guests to inject interrupts into other guests, again including domain 0.
In a typical Xen system many devices are owned by domain 0 or driver domains, leaving them vulnerable to such an attack. Such a DoS is likely to have an impact on other guests running in the system.
A malicious domain which is given access to a physical PCI device can mount a denial of service attack affecting the whole system. |
| Alerts: |
|
Comments (none posted)
Page editor: Jake Edge
Next page: Kernel development>>
|
|
|