Security
Android Verified Boot
Verified (or secure) boot has been a hot topic over the last few years, so it is not surprising to see that Android has gotten this capability. Andrew Boie gave a presentation at the Android Builders Summit (ABS) on the Verified Boot feature that originally appeared in the Android 4.4 ("KitKat") release. Boie is part of the team at Intel that implemented this boot security mechanism for x86 devices. His presentation (slides [PDF]) is based on the Android 5.0 ("Lollipop") version of Verified Boot.
The idea behind Verified Boot is to establish a chain of trust from the bootloader up to the Android system image; the bootloader itself must be protected with some other mechanism. Prior to this feature, malware could tamper with the system or boot image on an Android device, which was difficult to defend against. Under Verified Boot, the boot and recovery images are protected with a signature that covers all of the elements in those images: kernel, ramdisk, and an optional second-stage loader. The feature is not intended to be an anti-jailbreak measure, he said, as users can enroll their own keys and build their own images using those keys to get a verified boot of their code.
The system image is protected by the dm-verity device mapper module, as is the optional vendor image, if it is present. The root key used by dm-verity is stored in the boot image ramdisk. As a consequence of using dm-verity, the system image can no longer be mounted read-write, since doing so will write to the superblock, thus invalidating the block-level hashes maintained by dm-verity.
In fact, even the update process can't mount the system image read-write. Instead, the over-the-air (OTA) updates do a block-level, incremental update. He pointed those interested in the OTA process to the slides [PDF] (and, eventually, video) of another talk he gave at this year's ABS on Android OTA updates.
For Verified Boot, the integrity of the bootloader is out of scope, he said. Intel's bootloader, which is called Kernelflinger, uses UEFI Secure Boot to ensure bootloader integrity, but other vendors will have different solutions.
Boot images and signatures
The boot image format (which is also used for recovery images) is unchanged since the "Cupcake" (1.5) release. It is essentially just a series of blobs concatenated together, so the signature block is just another blob. To do OTA updates, the old and new images are compared and a kind of a "diff" is computed. Changing the format would complicate that process.
![[Andrew Boie]](https://static.lwn.net/images/2015/abs-boie-sm.jpg "Andrew Boie")
As part of the build process, Android images are always signed using the test keys that come from the build tree. The boot_signer program is run by the build system immediately after mkbootimg to do so. There is a separate program (sign_target_files_apks) to re-sign images using the production keys (which tend to be more closely guarded) once the final image has been built. Those images are written as raw data to the appropriate (i.e. "boot" or "recovery") partitions on an Android device.
The signature block is formatted with ASN.1 (which is encoded using DER) that contains the signature along with some other useful pieces of information. There is a version field (set to one for Lollipop) and an X.509 certificate field. The latter is not used in the verification at boot time, but the keys in it can be used by various testing tools to ensure that the signature is being calculated correctly. There is an algorithm identifier (which can either be SHA-1/RSA or SHA-256/RSA) as well.
The signature itself is calculated by hashing the boot image and the authenticated attributes in the signature block (which include the image type, boot or recovery, and the image length) then signing that hash with a private key. The signature is added into the block and the block is appended onto the boot image. There is no way to tell whether a given boot image is signed, so Kernelflinger reads an additional 4KB beyond the "end" of the boot image and feeds it to OpenSSL. That will either return an error for garbage or zeroes, or it will return the ASN.1 object if it is present.
The bootloader manages the public keys for the device in one or more keystores, which are signed collections of RSA key objects. There is a keystore_signer tool in the Android build tools that uses the Java BouncyCastle APIs to create keystore binaries. Devices will ship with an "OEM keystore" that is built into the system and signed by a key that is managed by the OEM.
For devices that Intel is shipping, at least, users will be able to enroll their own keystore binary by using a Fastboot command. That keystore will not be signed by the OEM (obviously), so the user will get an unverified keystore warning that they must "click" through before booting. After that, the user's keystore will be used to verify the boot and recovery images. The OEM keystore will always be tried first, though, so putting factory images back onto the device is supported.
In answer to audience questions, Boie noted that OEMs are not prevented from removing the ability of users to add their own keystores, though that may depend on the OEM's business relationship with Google. For Intel devices, users must press the volume-up button to boot when they get the warning; they can also hit the volume-down button to go into Fastboot mode to remove the user keystore. That warning could become annoying for those who boot frequently or who have phones that crash and reboot at times when they are not handling the phone.
Despite its name, Fastboot is not a way to optimize the boot time of an Android system, it is simply a protocol for communicating with the device over USB, he said. It allows issuing commands for performing operations like flashing images or changing the lock state of the device. It does not provide any facility to get data off of the device (other than simple strings). Fastboot is implemented by the bootloader, but there is no real reference implementation for it. Kernelflinger has a Fastboot implementation and source code for that should be appearing soon on Intel's 01.org open-source portal, Boie said.
Lock states
Intel has implemented its version of Verified Boot to have three different security states: locked, verified, and unlocked. Any transition between these states requires a Fastboot command. Intel is concerned about the possibility of an "evil butler" (or "evil maid") attack against devices, so any change of the security state is accompanied by a wipe of the /data partition (i.e. the user data). It simply zeroes out the partition; when the device boots, it will recognize that state and put a new filesystem on /data.
Beyond that, security-state transitions require users to physically confirm that the change is desired using the device's buttons. That will help defend against malware that might surreptitiously issue Fastboot commands. In addition, transitioning to the unlocked state requires changing an option in the developer settings of the device, which requires getting past the lock screen.
Devices will be shipped in the locked state, which will prevent users from flashing or erasing any images using Fastboot. The boot and recovery images will be verified using the enrolled keystores (which will simply be the OEM keystore to start). The only Fastboot command available is to unlock the device, but in order to do so, the checkbox in the developer settings must be ticked (it is off by default).
The verified state allows flashing and erasing a subset of the partitions using Fastboot. It will not allow enrolling keystores or tampering with the persistent data block (PDB, which Boie covers later). It is a good state to choose for running user or third-party (e.g. Cyanogenmod) images, especially for developers frequently flashing images to the device. But devices in the verified state may still have to deal with the boot warning if they are using a keystore that is not OEM-signed.
In the unlocked state, "all bets are off". All Fastboot commands are available; user keystores may be enrolled or erased. While in the unlocked state, there is no verification of the boot or recovery images. At boot time, users will be warned that the device is unlocked and must press volume-up to continue the boot process.
In order to run their own signed images, users will need to change the developer setting to allow unlocking, then unlock the device. They can then enroll their own keystore and flash their own boot, recovery, and system images. After that, they can either switch to the locked or verified states depending on the desired security capabilities. Developers will likely want to stay in verified mode (so they can flash images), while users will probably want locked mode.
A device's security level can be expressed as one of four colors to signify the verification state of its images. Green means the device is locked or verified, the keystore is verified with an OEM key, and that the boot image was verified by the keystore. Yellow means that an alternate keystore was used to verify the boot image, while orange indicates that the device is unlocked, so no verification was done. The red state means that a device in the locked or verified state had a boot image that did not verify. These colors impact the boot policy in Kernelflinger; yellow or orange results in a warning that the user must acknowledge with a button press, while red means that the boot cannot continue at all. These colors are reported in the Fastboot user interface and are made available to the Android system by Kernelflinger.
The PDB is a new persistent partition that is listed in the fstab file. For Intel devices, it is 1MB in size. The last byte in that partition stores the value of the developer setting that governs whether the device can be unlocked. The "master clear" command from the settings app will clear the PDB, while Fastboot or the recovery console in the verified state will not. Accessing the settings app requires getting past the lock screen, so it is treated differently.
Devices that have Google's mobile services will store additional information in the PDB. Those devices will require a user to sign into an account that has already been used on the phone before allowing an untrusted reset to occur. That is meant to discourage theft by making it difficult to simply reset and reuse the device.
As noted, Android uses dm-verity to protect the integrity of the system partition. Dm-verity uses a tree of SHA-256 hashes of the contents of each 4KB block in the partition. Intermediate nodes in the tree contain hashes of the nodes below them (which could be block nodes or other, lower intermediate nodes), on up to the root node which has a hash that represents the entire disk. That hash is signed with a key from the boot image's ramdisk.
The dm-verity checking is all done in software, Boie said, though hardware support may speed it up. It is only available for ext4 in Android, though. The verification of the hashes is "extremely quick" and, if any of the data in the system partition is tampered with, the Android system will be unable to read it. Google has done most of the work needed to handle dm-verity in Android systems; it is mostly a matter of enabling it in the build and adding "verify" to the fstab entry for the partition.
Bootloader considerations
There are a number of things to consider when implementing a bootloader for Verified Boot, he said. The Kernelflinger source might be a useful reference for anyone planning to develop their own. To start with, some kind of user-confirmation interface is likely to be needed to get the user's permission for proceeding when verification fails, for example.
A bootloader will also need cryptographic code that can parse DER ASN.1 messages and X.509 certificates, do SHA-256 hashing, and perform RSA verification. Boie reiterated the advice of crypto experts everywhere: "Don't write your own crypto code". Intel used OpenSSL for Kernelflinger. There needs to be a non-volatile place to store Fastboot state information, including the security state and user keystore. That area should not be accessible in the running operating system, so Intel used EFI variables that can only be accessed by the bootloader.
Another thing to consider is having a different bootloader for developers to use that relaxes some of the constraints of the normal bootloader. Someone asked about whether replacing the bootloader on unlocked devices was an option. Boie said that it was up to the OEM, but that he expected most devices would not allow replacing the bootloader. Finally, the procedure for returned devices needs to be thought out; there will need to be some way to circumvent all of the protections when restoring a phone for reuse.
Boie said that actually writing the bootloader was the "fun part" of the whole process. He spent most of last (northern hemisphere) summer in doing just that.
[I would like to thank the Linux Foundation for travel support to San Jose for Android Builders Summit.]
Brief items
Security quotes of the week
New vulnerabilities
docuwiki: cross-site scripting
| Package(s): | dokuwiki | CVE #(s): | |||||
| Created: | March 29, 2015 | Updated: | April 1, 2015 | ||||
| Description: | From the Mageia advisory: "DokuWiki before 20140929d is vulnerable to a cross-site scripting (XSS) issue in the user manager. The user's details were not properly escaped in the user manager's edit form. This allows a registered user to edit her own name (using the change profile option) to include malicious JavaScript code. The code is executed when a super user tries to edit the user via the user manager." | ||||||
| Alerts: |
| ||||||
drupal7: multiple vulnerabilities
| Package(s): | drupal7 | CVE #(s): | CVE-2015-2749 CVE-2015-2750 | ||||||||||||
| Created: | March 27, 2015 | Updated: | April 1, 2015 | ||||||||||||
| Description: | From the Drupal advisory: Open redirect (Several vectors including the "destination" URL parameter - Drupal 6 and 7) Drupal core and contributed modules frequently use a "destination" query string parameter in URLs to redirect users to a new destination after completing an action on the current page. Under certain circumstances, malicious users can use this parameter to construct a URL that will trick users into being redirected to a 3rd party website, thereby exposing the users to potential social engineering attacks. In addition, several URL-related API functions in Drupal 6 and 7 can be tricked into passing through external URLs when not intending to, potentially leading to additional open redirect vulnerabilities. This vulnerability is mitigated by the fact that many common uses of the "destination" parameter are not susceptible to the attack. However, all confirmation forms built using Drupal 7's form API are vulnerable via the Cancel action that appears at the bottom of the form, and some Drupal 6 confirmation forms are vulnerable too. Open redirect via the "destination" URL parameter: CVE-2015-2749 Open redirect via URL-related API functions: CVE-2015-2750 | ||||||||||||||
| Alerts: |
| ||||||||||||||
drupal7-entity: cross-site scripting
| Package(s): | drupal7-entity | CVE #(s): | |||||||||
| Created: | April 1, 2015 | Updated: | April 1, 2015 | ||||||||
| Description: | From the Drupal advisory:
The Entity API module extends the entity API of Drupal core in order to provide a unified way to deal with entities and their properties. The module doesn't sufficiently sanitize field labels when exposing them through the Token API thereby exposing a Cross Site Scripting (XSS) vulnerability. This vulnerability is mitigated by the fact that an attacker must have a role with the permission to administer fields such as "administer taxonomy". | ||||||||||
| Alerts: |
| ||||||||||
drupal7-views: multiple vulnerabilities
| Package(s): | drupal7-views | CVE #(s): | |||||||||
| Created: | March 27, 2015 | Updated: | April 1, 2015 | ||||||||
| Description: | From the Drupal advisory: Open redirect vulnerability: The module does not sanitize user provided URLs when processing the page to break the lock on Views being edited, thereby exposing an open redirect attack vector. This vulnerability is mitigated by the fact that the Views UI submodule must be enabled. Access bypass vulnerability: The module does not protect the default Views configurations that ship with the module sufficiently, thereby exposing possibly protected information to unprivileged users. This vulnerability is mitigated by the fact that it only affects sites that have not granted the common "access content" or "access comments" permission to untrusted users. Furthermore, these default views configurations are disabled by default and must be enabled by an administrator. | ||||||||||
| Alerts: |
| ||||||||||
dulwich: code execution
| Package(s): | dulwich | CVE #(s): | CVE-2014-9706 CVE-2015-0838 | ||||||||||||||||||||
| Created: | March 29, 2015 | Updated: | May 28, 2015 | ||||||||||||||||||||
| Description: | The dulwich library (used to access Git files and protocols) suffers from two code execution vulnerabilities when used with a hostile Git repository. | ||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||
freexl: code execution
| Package(s): | freexl | CVE #(s): | CVE-2015-2753 CVE-2015-2754 CVE-2015-2776 | ||||||||||||
| Created: | March 30, 2015 | Updated: | June 27, 2016 | ||||||||||||
| Description: | From the Debian advisory:
Jodie Cunningham discovered multiple vulnerabilities in freexl, a library to read Microsoft Excel spreadsheets, which might result in denial of service or the execution of arbitrary code if a malformed Excel file is opened. | ||||||||||||||
| Alerts: |
| ||||||||||||||
gd: denial of service
| Package(s): | gd | CVE #(s): | CVE-2014-9709 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | March 31, 2015 | Updated: | April 1, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the CVE entry:
The GetCode_ function in gd_gif_in.c in GD 2.1.1 and earlier, as used in PHP before 5.5.21 and 5.6.x before 5.6.5, allows remote attackers to cause a denial of service (buffer over-read and application crash) via a crafted GIF image that is improperly handled by the gdImageCreateFromGif function. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
gnupg: code execution
| Package(s): | gnupg, gnupg2 | CVE #(s): | CVE-2015-1607 | ||||||||||||||||
| Created: | April 1, 2015 | Updated: | April 1, 2015 | ||||||||||||||||
| Description: | From the Ubuntu advisory:
Hanno Böck discovered that GnuPG incorrectly handled certain malformed keyrings. If a user or automated system were tricked into opening a malformed keyring, a remote attacker could use this issue to cause GnuPG to crash, resulting in a denial of service, or possibly execute arbitrary code. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
ipa, slapi-nis: multiple vulnerabilities
| Package(s): | ipa, slapi-nis | CVE #(s): | CVE-2015-0283 CVE-2015-1827 | ||||||||||||||||||||||||||||
| Created: | March 27, 2015 | Updated: | April 6, 2015 | ||||||||||||||||||||||||||||
| Description: | From the Red Hat advisory: It was discovered that the IPA extdom Directory Server plug-in did not correctly perform memory reallocation when handling user account information. A request for a list of groups for a user that belongs to a large number of groups would cause a Directory Server to crash. (CVE-2015-1827) It was discovered that the slapi-nis Directory Server plug-in did not correctly perform memory reallocation when handling user account information. A request for information about a group with many members, or a request for a user that belongs to a large number of groups, would cause a Directory Server to enter an infinite loop and consume an excessive amount of CPU time. (CVE-2015-0283) | ||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||
jakarta-taglibs-standard: code execution
| Package(s): | jakarta-taglibs-standard | CVE #(s): | CVE-2015-0254 | ||||||||||||||||||||||||||||||||||||
| Created: | March 31, 2015 | Updated: | October 15, 2015 | ||||||||||||||||||||||||||||||||||||
| Description: | From the Ubuntu advisory:
David Jorm discovered that the Apache Standard Taglibs incorrectly handled external XML entities. A remote attacker could possibly use this issue to execute arbitrary code or perform other external XML entity attacks. | ||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||
kernel: code execution
| Package(s): | kernel | CVE #(s): | CVE-2015-2666 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | March 29, 2015 | Updated: | April 7, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | The kernel's Intel early microcode loader has a stack overflow vulnerability. It could be exploited by a local root user to execute arbitrary code in kernel mode, bypassing UEFI secure boot lockdown. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
mercurial: command injection
| Package(s): | mercurial | CVE #(s): | CVE-2014-9462 | ||||||||||||||||||||
| Created: | March 29, 2015 | Updated: | June 4, 2015 | ||||||||||||||||||||
| Description: | The mercurial source code management system suffers from a code-injection flaw; see this blog entry for details. | ||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||
mongodb: denial of service
| Package(s): | mongodb | CVE #(s): | CVE-2015-1609 | ||||||||||||
| Created: | March 29, 2015 | Updated: | November 21, 2016 | ||||||||||||
| Description: | A remote attacker can crash a mongodb server via a malformed BSON request. | ||||||||||||||
| Alerts: |
| ||||||||||||||
mozilla: multiple vulnerabilities
| Package(s): | firefox thunderbird seamonkey | CVE #(s): | CVE-2015-0802 CVE-2015-0803 CVE-2015-0804 CVE-2015-0805 CVE-2015-0806 CVE-2015-0808 CVE-2015-0811 CVE-2015-0812 CVE-2015-0814 | ||||||||||||||||||||||||||||||||||||||||||||
| Created: | April 1, 2015 | Updated: | September 4, 2015 | ||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Arch Linux advisory:
- CVE-2015-0802 (privilege boundary violation): Mozilla developer Bobby Holley reported that windows created to hold privileged UI content retained access to privileged internal methods if later navigated to unprivileged content. If a separate flaw was found that allowed for web content to reference these privileged windows, an attacker could use this reference to navigate them to their own content allowing for an escalation of privilege and arbitrary code execution. On its own, this flaw does not allow for privilege escalation by web content. - CVE-2015-0803 (use-after-free): Security researcher Nils used the Address Sanitizer tool to discover two type confusion flaws. The first of these occurs while setting specific attributes of a source element resulting in incorrect object casting. The second flaw occurs when binding a source to a tree when the function fails to validate the namespace. These flaws lead to use-after-free errors, resulting in potentially exploitable crashes. - CVE-2015-0804 (use-after-free): Security researcher Nils used the Address Sanitizer tool to discover two type confusion flaws. The first of these occurs while setting specific attributes of a source element resulting in incorrect object casting. The second flaw occurs when binding a source to a tree when the function fails to validate the namespace. These flaws lead to use-after-free errors, resulting in potentially exploitable crashes. - CVE-2015-0805 (memory corruption): Security researcher Abhishek Arya (Inferno) of the Google Chrome Security Team used the Address Sanitizer tool to discover two memory corruption crashes during 2D graphics rendering due to problems in Off Main Thread Compositing. These crashes are potentially exploitable. - CVE-2015-0806 (memory corruption): Security researcher Abhishek Arya (Inferno) of the Google Chrome Security Team used the Address Sanitizer tool to discover two memory corruption crashes during 2D graphics rendering due to problems in Off Main Thread Compositing. These crashes are potentially exploitable. - CVE-2015-0808 (mismatched free): Security researcher Mitchell Harper used Valgrind to discover incorrect memory management for simple-type arrays in WebRTC. This was undefined behavior which is theoretically dangerous but was determined to be safe in this instance. - CVE-2015-0811 (information disclosure): Security researcher Felix Gröbert of Google used the Address Sanitizer tool to discover an out of bounds read in the QCMS color management library while transforming images with certain parameters. This could lead to information disclosure. - CVE-2015-0812 (approval bypass): Security researcher Armin Razmdjou discovered that a man-in-the-middle (MITM) attacker spoofing a Mozilla sub-domain could bypass user approval messages to install a Firefox lightweight theme. This was possible because add-on installations of the lightweight themes do not require the use of HTTP over SSL. Firefox extensions were not directly affected and still required user approval for installation. - CVE-2015-0814 (arbitrary code execution): Mozilla developers and community identified and fixed several memory safety bugs in the browser engine used in Firefox and other Mozilla-based products. Some of these bugs showed evidence of memory corruption under certain circumstances, and we presume that with enough effort at least some of these could be exploited to run arbitrary code. | ||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||
mozilla: multiple vulnerabilities
| Package(s): | firefox thunderbird seamonkey | CVE #(s): | CVE-2015-0801 CVE-2015-0807 CVE-2015-0813 CVE-2015-0815 CVE-2015-0816 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | April 1, 2015 | Updated: | September 4, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat advisory:
Several flaws were found in the processing of malformed web content. A web page containing malicious content could cause Firefox to crash or, potentially, execute arbitrary code with the privileges of the user running Firefox. (CVE-2015-0813, CVE-2015-0815, CVE-2015-0801) A flaw was found in the way documents were loaded via resource URLs in, for example, Mozilla's PDF.js PDF file viewer. An attacker could use this flaw to bypass certain restrictions and under certain conditions even execute arbitrary code with the privileges of the user running Firefox. (CVE-2015-0816) A flaw was found in the Beacon interface implementation in Firefox. A web page containing malicious content could allow a remote attacker to conduct a Cross-Site Request Forgery (CSRF) attack. (CVE-2015-0807) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
musl: code execution
| Package(s): | musl | CVE #(s): | CVE-2015-1817 | ||||
| Created: | March 31, 2015 | Updated: | April 1, 2015 | ||||
| Description: | From the Arch advisory:
A stack-based buffer overflow has been found in musl libc's ipv6 address literal parsing code. Programs which call the inet_pton or getaddrinfo function with AF_INET6 or AF_UNSPEC and untrusted address strings are affected. Successful exploitation yields control of the return address. Having enabled stack protector at the application level does not mitigate the issue. An attacker can execute arbitrary code by submitting a carefully crafted IPv6 address to a program linked with musl calling inet_pton() or getaddrinfo() with AF_INET6 or AF_UNSPEC. | ||||||
| Alerts: |
| ||||||
openldap: denial of service
| Package(s): | openldap | CVE #(s): | CVE-2015-1545 CVE-2015-1546 | ||||||||||||||||||||||||||||||||
| Created: | March 29, 2015 | Updated: | April 13, 2015 | ||||||||||||||||||||||||||||||||
| Description: | The openldap server has two remotely-exploitable denial-of-service vulnerabilities. | ||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||
openldap: unauthorized access to resources
| Package(s): | openldap | CVE #(s): | CVE-2014-9713 | ||||||||||||
| Created: | March 31, 2015 | Updated: | April 1, 2015 | ||||||||||||
| Description: | The default Debian configuration of the directory database allows
every users to edit their own attributes. When LDAP directories are
used for access control, and this is done using user attributes, an
authenticated user can leverage this to gain access to unauthorized
resources.
Please note this is a Debian specific vulnerability. The new package won't use the unsafe access control rule for new databases, but existing configurations won't be automatically modified. Administrators are incited to look at the README.Debian file provided by the updated package if they need to fix the access control rule. | ||||||||||||||
| Alerts: |
| ||||||||||||||
owncloud: unspecified vulnerabilities
| Package(s): | owncloud | CVE #(s): | |
| Created: | April 1, 2015 | Updated: | April 1, 2015 |
| Description: | From the Mageia advisory:
Owncloud version 6.0.7 fixes several unspecified security vulnerabilities, as well as many other bugs. See the ownCloud changelog for details. | ||
| Alerts: | (No alerts in the database for this vulnerability) | ||
python-django: cross-site scripting
| Package(s): | python2-django python-django | CVE #(s): | CVE-2015-2241 | ||||||||||||
| Created: | March 29, 2015 | Updated: | April 1, 2015 | ||||||||||||
| Description: | From the Django advisory: "The ModelAdmin.readonly_fields attribute in the Django admin allows displaying model fields and model attributes. While the former were correctly escaped, the latter were not. Thus untrusted content could be injected into the admin, presenting an exploitation vector for XSS attacks." | ||||||||||||||
| Alerts: |
| ||||||||||||||
setroubleshoot: privilege escalation
| Package(s): | setroubleshoot | CVE #(s): | CVE-2015-1815 | ||||||||||||||||||||||||||||||||||||||||
| Created: | March 27, 2015 | Updated: | April 8, 2015 | ||||||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat advisory: It was found that setroubleshoot did not sanitize file names supplied in a shell command look-up for RPMs associated with access violation reports. An attacker could use this flaw to escalate their privileges on the system by supplying a specially crafted file to the underlying shell command. | ||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||
setup: information disclosure
| Package(s): | setup | CVE #(s): | |||||||||||||||||
| Created: | March 30, 2015 | Updated: | April 27, 2015 | ||||||||||||||||
| Description: | From the Mageia advisory:
An issue has been identified in Mageia 4's setup package where the /etc/shadow and /etc/gshadow files containing password hashes were created with incorrect permissions, making them world-readable (mga#14516). This update fixes this issue by enforcing that those files are owned by the root user and shadow group, and are only readable by those two entities. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
shibboleth: denial of service
| Package(s): | shibboleth-sp2 | CVE #(s): | CVE-2015-2684 | ||||||||||||
| Created: | March 29, 2015 | Updated: | June 30, 2015 | ||||||||||||
| Description: | The Shibboleth identity service provider can crash when presented with a malformed SAML message. | ||||||||||||||
| Alerts: |
| ||||||||||||||
tiff: denial of service
| Package(s): | tiff | CVE #(s): | CVE-2014-9330 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | April 1, 2015 | Updated: | April 2, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the CVE entry:
Integer overflow in tif_packbits.c in bmp2tif in libtiff 4.0.3 allows remote attackers to cause a denial of service (crash) via crafted BMP image, related to dimensions, which triggers an out-of-bounds read. | ||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
webkitgtk: information disclosure
| Package(s): | webkitgtk | CVE #(s): | CVE-2015-2330 | ||||||||||||||||
| Created: | March 29, 2015 | Updated: | May 26, 2015 | ||||||||||||||||
| Description: | WebKitGTK+ prior to 2.7.92 performed TLS certificate verification too late; the result is that it can send an HTTP request prior to ensuring that the server's certificate is valid. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
Page editor: Jake Edge
Next page:
Kernel development>>