Direkt zum Hauptbereich

Save Your Cloud: DoS on VMs in OpenNebula 4.6.1

This is a post about an old vulnerability that I finally found the time to blog about. It dates back to 2014, but from a technical point of view it is nevertheless interesting: An XML parser that tries to fix structural errors in a document caused a DoS problem.

All previous posts of this series focused on XSS. This time, we present a vulnerability which is connected another Cloud Management Platform: OpenNebula. This Infrastructure-as-a-Service platform started as a research project in 2005. It is used by information technology companies like IBM, Dell and Akamai as well as academic institutions and the European Space Administrations (ESA). By relying on standard Linux tools as far as possible, OpenNebula reaches a high level of customizability and flexibility in hypervisors, storage systems, and network infrastructures. OpenNebula is distributed using the Apache-2 license.


OpenNebula offers a broad variety of interfaces to control a cloud. This post focuses on Sunstone, OpenNebula's web interface (see Figure 1).

Figure 1: OpenNebula's Sunstone Interface displaying a VM's control interface

Before OpenNebula 4.6.2, Sunstone had no Cross-Site Request Forgery (CSRF) protection. This is a severe problem. Consider an attacker who lures a victim into clicking on a malicious link while being logged in at a private cloud. This enables the attacker to send arbitrary requests to the private cloud through the victims browser. However, we could find other bugs in OpenNebula that allowed us to perform much more sophisticated attacks.

Denial-of-Service on OpenNebula-VM

At its backend, OpenNebula manages VMs with XML documents. A sample for such an XML document looks like this:
<VM>
   <ID>0</ID>
   <NAME>My VM</NAME>
   <PERMISSIONS>...</PERMISSIONS>
   <MEMORY>512</MEMORY>
   <CPU>1</CPU>
   ...
</VM>
OpenNebula 4.6.1 contains a bug in the sanitization of input for these XML documents: Whenever a VM's name contains an opening XML tag (but no corresponding closing one), an XML generator at the backend automatically inserts the corresponding closing tag to ensure well-formedness of the resulting document. However, the generator outputs an XML document that does not comply with the XML schema OpenNebula expects. The listing below shows the structure that is created after renaming the VM to 'My <x> VM':
<VM>
   <ID>0</ID>
   <NAME>My <x> VM</x>
      <PERMISSIONS>...</PERMISSIONS>
      <MEMORY>512</MEMORY>
      <CPU>1</CPU>
      ...
   </NAME>
</VM>
The generator closes the <x> tag, but not the <NAME> tag. At the end of the document, the generator closes all opened tags including <NAME>.

OpenNebula saves the incorrectly generated XML document in a database. The next time the OpenNebula core retrieves information about that particular VM from the database the XML parser is mixed up and runs into an error because it only expects a string as name, not an XML tree. As a result, Sunstone cannot be used to control the VM anymore. The Denial-of-Service attack can only be reverted from the command line interface of OpenNebula.

This bug can be triggered by a CSRF-attack, which means that it is a valid attack against a private cloud: By luring a victim onto a maliciously crafted website while logged in into Sunstone, an attacker can make all the victim's VMs uncontrollable via Sunstone. A video of the attack can be seen here:


This bug has been fixed in OpenNebula 4.6.2.

This result is a collaborative work together with Mario Heiderich. It has been published at ACM CCSW 2015. The paper can be found here.

Beliebte Posts aus diesem Blog

CORS misconfigurations on a large scale

Inspired by James Kettle's great OWASP AppSec Europe talk on CORS misconfigurations, we decided to fiddle around with CORS security issues a bit. We were curious how many websites out there are actually vulnerable because of dynamically generated or misconfigured CORS headers. The issue: CORS misconfiguration Cross-Origin Resource Sharing (CORS) is a technique to punch holes into the Same-Origin Policy (SOP) – on purpose. It enables web servers to explicitly allow cross-site access to a certain resource by returning an Access-Control-Allow-Origin (ACAO) header. Sometimes, the value is even dynamically generated based on user-input such as the Origin header send by the browser. If misconfigured, an unintended website can access the resource. Furthermore, if the Access-Control-Allow-Credentials (ACAC) server header is set, an attacker can potentially leak sensitive information from a logged in user – which is almost as bad as XSS on the actual website. Below is a list of CORS misc…

Printer Security

Printers belong arguably to the most common devices we use. They are available in every household, office, company, governmental, medical, or education institution.
From a security point of view, these machines are quite interesting since they are located in internal networks and have direct access to sensitive information like confidential reports, contracts or patient recipes.

TL;DR: In this blog post we give an overview of attack scenarios based on network printers, and show the possibilities of an attacker who has access to a vulnerable printer. We present our evaluation of 20 different printer models and show that each of these is vulnerable to multiple attacks. We release an open-source tool that supported our analysis: PRinter Exploitation Toolkit (PRET) https://github.com/RUB-NDS/PRET Full results are available in the master thesis of Jens Müller and our paper. Furthermore, we have set up a wiki (http://hacking-printers.net/) to share knowledge on printer (in)security.
The hi…