User: Password:
Subscribe / Log in / New account


A white paper on comparative browser security

December 14, 2011

This article was contributed by Nathan Willis

A paper was released in early December comparing the security designs of recent versions of Microsoft Internet Explorer, Mozilla Firefox, and Google Chrome, and concluded that Google Chrome was the "most secured against attack" — and Firefox the least. But Google sponsored the paper (by Denver-based security firm Accuvant), a fact that many in the trade press immediately latched onto as evidence that its contents were untrustworthy. It is always wise to take such reports with a heap of salt, but Google's funding alone does not mean that there is no interesting information in the report. Still, many of the headlines in recent days have glossed over some important details in the paper and its conclusions.

A careful reading of the paper shows it to be not a quantitative analysis of the various browsers' vulnerabilities (or lack thereof) to real-world attacks, but more of a feature-by-feature review of their respective security architectures. In other words, when the paper's conclusion calls Chrome the most secured, instead of the most secure, the distinction is important. The paper's premise is that the browser with the most "modern" security features is the best prepared to repel likely attacks, and it examines the three browsers against a list of specific features, namely sandboxing, just-in-time (JIT) compiler hardening, protection against malicious add-ons (plug-ins, extensions, and themes), and various low-level exploit-prevention measures (such as address space randomization).

The browsers scored equally well on the low-level exploit prevention measures, but Chrome's sandbox, add-on security, and JIT hardening were deemed "industry standards" while the other browsers' were not. Interestingly enough, the paper also includes sections on URL blacklisting, and a look at browsers' vulnerability-report and patch statistics over an 18-month period — statistics which the authors take pains to insist should not be used to draw conclusions.

Approaches, blacklists, and statistics

The paper, dated December 6, 2011, is entitled Browser Security Comparison: A Quantitative Approach. A summary is posted on the Accuvant blog, and includes a link to a separate page on which the full, 140-page PDF is available, along with a ZIP archive of the raw data and supporting tools.

The paper begins by making a case for the approach used — comparing the security design of the browsers tested — and follows up with an overview of the browsers' architectures. For the security feature comparison, the paper considers Google Chrome versions 12 (12.0.724.122) and 13 (13.0.782.218), Internet Explorer 9 (9.0.8112.16421), and Firefox 5 (5.0.1), all of which were examined in July 2011, on Microsoft Windows 7 (32-bit).

Next is a survey of security vulnerability statistics, collected and collated between January 2009 and June 2011 (which includes versions of Firefox from 2.0 to 5.0, versions of IE from IE6 to IE9, and all stable releases of Chrome). The paper makes four arguments that such statistics are unreliable. First, that vendor-advisories do not correspond one-to-one with vulnerabilities (which includes rolling multiple vulnerabilities into one advisory and unreported vulnerabilities). Second, that timeline information gleaned from advisory and patch publication dates does not accurately reflect when a vulnerability is caught and/or fixed (which includes a number of factors, from bug duplication to vulnerabilities that are discovered internally by Microsoft and unpublished). Third, that there are no generally-agreed-upon criteria for classifying the severity of vulnerabilities. Finally, the varying development models of the browser vendors make correlating vulnerability data across vendors difficult if not impossible (which includes patches to Windows that affect IE, and idiosyncrasies in the bug trackers used by both Firefox and Chrome).

Nevertheless, the authors follow up by reporting statistics for update frequencies, public vulnerability reports, vulnerabilities sorted by severity, and the average time between a vulnerability report and a published fix. The section makes several comments dissuading readers from inferring browser quality based on the numbers, such as "none of these pieces of information can be used to draw a security related conclusion" and "any conclusion drawn from the data is speculation and the data does not aid in discovering which browser is most secure." However, each of these comments comes immediately after a set of conclusions spelled out by the authors — such as Chrome being the most frequently updated browser, and Firefox having the most "critical" vulnerabilities. It is a puzzling approach: writing a conclusion, and then immediately disavowing it, but since the entire topic is deemed unreliable, too, perhaps this is a moot point.

The next section is a look at URL blacklist services, namely Microsoft's URL Reporting Service (URS) and Google's Safe Browsing List (SBL). The authors harvested active malware URLs from four web security sites, and queried both services. Over an eight-day stretch, they sampled a total of 47,682 URLs. Out of the 24,686 malware URLs which were still live when requested, URS and SBL each managed to block a scant 10%, with the remainder successfully slipping by.

Clearly, neither of the blacklist services performed well, but the data in this section of the paper is presented in a confusing manner. For example, in the pie chart which purports to show the portion of malware URLs blocked by the blacklist services (a graph reproduced in several news reports about the paper), the "unmatched URLs" pie-piece that takes up roughly 75% of the circle is labeled with the number from the total row of the chart. The pie-pieces showing URS and SBL's respective numbers of blocked URLs are also separate from each other, which implies that they had no URL-matches in common — a highly unlikely, albeit not impossible, event. Essentially, the pie pieces seem to come from two or three separate pies.


The next section defines the security features examined in each browser. The approach taken to assess the quality of each feature varied. First are the low-level exploit-prevention measures. This list includes Address Space Layout Randomization (ASLR), Data Execution Prevention (DEP), Stack Cookies (a buffer overflow prevention technique), and Structured Exception Handling (SEH; techniques to prevent exception handlers from executing hidden payloads of malware). The authors examined all of binaries loaded by the three browsers (including .EXEs and .DLLs of the browser itself as well as all of the Windows system .DLLs called by the browser) and checked for ASLR, DEP, Stack Cookie, and SEH compatibility.

Sandboxing receives the most attention. On Windows, Chrome and IE both take advantage of the OS's sandboxing functionality to limit each process's access to the filesystem, the network, Windows Registry data, other processes and threads, and various other system resources. Chrome and IE are both multi-process, providing separate processes for the UI, the rendering engine, and most individual tabs. Chrome and Firefox also run plug-ins in separate processes (though IE does not). Firefox, though, uses one process for the rest of the browser, and does not take advantage of Window's sandboxing features. It therefore receives the default "Medium" level security token from Windows.

That distinction is responsible for the bulk of the paper's criticism of Firefox; the analysis section examines each of the system components that are accessible to an un-sandboxed Firefox process and walled off from a sandboxed Chrome process in turn. The authors used the sandbox testing tool from the Chrome project to perform tests on each browser. Chrome does not hit every bullet point, however, allowing access to some system parameters and "Windows Hooks" on the authors' checklist. Firefox does not miss on every point, either, rather it receives mixed marks on many of the checklist items. IE falls somewhere in between.

JIT hardening is the next topic examined. The authors enumerate eight techniques for securing the JIT engine against malware: codebase alignment randomization, instruction alignment randomization, constant blinding, constant folding, memory page protection, resource constraints, executable memory allocation randomization, and memory guard pages. On this topic, the authors examined the source code, disassembled binaries, and ran test scripts against the JIT engines to check for each technique. IE received the most positive marks, with complete implementations of all the techniques except for additional randomization and guard pages, for which it was scored "technique was not necessary."

Chrome scored in the middle of the pack, without implementations for three of the eight techniques (codebase alignment randomization, instruction alignment randomization, and memory page protection). On the guard pages technique, though, Chrome received a check-mark with a footnote noting that the feature was implemented in Chrome 14 — which was not the version reported earlier as having been tested. Firefox did not receive any check-marks in this section, with the authors observing succinctly "Firefox does not implement any JIT hardening techniques."

The final section of the paper addresses the security measures protecting each browser against malicious add-ons. The authors identify a list of 19 possible security measures — including whether add-ons are subject to many of the sandboxing protections measured for the browsers themselves. It also includes user-facing techniques, such as displaying pre-install warnings, allowing automatic updates, and providing a user-controlled permission set for each add-on. The authors examined each browser with a mix of manual inspection (for user-visible techniques such as installation warnings) and repetition of the earlier sandbox tests.

Here the results are surprising considering what has come before; all of the browsers scored virtually the same, with mediocre add-on security. Chrome picked up one more checkbox than Firefox for its add-on permission model and a "partially-functioning" mark for its incomplete sandboxing. Both browsers received failing marks on eleven of the other criteria, including many sandboxing techniques that Chrome passed when examining the browser itself. IE, as always, scored in the middle, but it, too, failed to enforce many of sandboxing rules for add-ons that it enforced for browser processes itself. Nevertheless, in the paper's Executive Summary section, Chrome is given an "industry standard" check-mark, IE is given an "implemented" dot, and Firefox an "unimplemented or ineffective" X.

Two appendices follow; the first is an exploration of Chrome Frame, a plug-in for IE that uses Chrome as the page rendering and JavaScript engine. The authors examine how Chrome Frame operates and assess its potential security impact, concluding that it increases the attack surface of IE just like any other browser add-on. The second appendix is a lengthy (22-page) table of the low-level exploit-prevention measure test results for the browsers. Detailed test results for the other features examined are not included, although they are included in the downloadable data archive at the Accuvant site.

Is the perspective of the paper slanted?

Skeptics and Mozilla fans have every right to doubt the results of any Google-funded "research" that shows Chrome superior to other browsers — just as any skeptic should with vendor-funded research. After all, such research could be designed from the start to ensure a victory for Chrome, by examining only those features where Chrome outscores the competition. In that case, there is no need to fudge any numbers; the victor emerges naturally. Such a set-up was alleged by several Slashdot commenters (and hinted at by the story submitter) in the site's December 10 discussion of the paper.

Certainly the sandbox analysis could have been chosen to showcase one of Chrome's flagship features, but I would not conclude the same thing about the JIT hardening or add-on analysis sections, which did not show Chrome in nearly as favorable of a light. On the other hand, I simply do not think that I buy the paper's premise that running a checklist examination of the browsers results in what the authors call "a more accurate window into the vulnerabilities of each browser." Under the "Methodology Delta" section, the authors say:

Accuvant LABS' analysis is based on the premise that all software of sufficient complexity and an evolving code base will always have vulnerabilities. Anti-exploitation technology can reduce or eliminate the severity of a single vulnerability or an entire class of exploits. Thus, the software with the best anti-exploitation technologies is likely to be the most resistant to attack and is the most crucial consideration in browser security.

Perhaps that is a defensible position in theory, but what the paper examines is essentially the existence of these anti-exploitation features in the code base — it is hardly a "quantitative" approach as the title suggests. After all, the paper spends several pages asserting that real-world quantitative data on vulnerability reporting and patching can be "misleading" and "misappropriated." One could argue that a bug in the sandboxing code could single-handedly undermine a dozen of the check-marks that Chrome or IE received for implementing the features examined. A test performed in the lab may or may not catch such a bug, while real-world vulnerability reports — or attacks — are more likely to.

Regardless of how one feels about the approach taken by the paper, it is worth taking a look at because it has a different approach to measuring application security than do the bulk of other analyses. We can all agree that vulnerability statistics are often open to interpretation, so relying on them to measure the security of different applications is suspect — but many similarly targeted white papers do so. Accuvant has made an effort to analyze the security of these browsers in a different way, which is useful in its own right.

What a browser-maker might learn

Of course, weaknesses in the paper do not mean that Firefox should not consider a sandbox and multi-process design on all of its desktop platforms. It would clearly be more secure if it migrated to a model that included both, and if it implemented JIT hardening techniques, but those are hardly overnight changes.

At least the paper provides a survey of the attack surface addressed by Windows sandboxing and JIT hardening, which is valuable — both to browser vendors and to other developers. It is also interesting to note how many Windows system libraries are touched by each of the browsers, how ineffective URL blacklists are in practice, as well as how-and-where the security provided by the main browser breaks down when an add-on is installed. Skeptics may turn up their noses at Google's financing of the work, or at the methodology employed, but a detailed discussion of application security always makes for valuable reading.

Firefox's Johnathan Nightingale told Informationweek that Mozilla regards sandboxing as just one tool among many used to reduce security threats, "from platform-level features like address space randomization to internal systems like our layout frame poisoning system." He added that the browser-maker emphasizes security in the development process as well as in the code itself, highlighting code reviews, testing and analysis, and rapid responses to security issues.

As for the specifics touched on in the paper's comparison to Chrome's security architecture, Mozilla has been exploring a multi-process design for some time — but primarily out of an interest in speeding up Firefox's responsiveness. That work appears to have been back-burnered in favor of a set of smaller changes, including optimizations to the Places database and garbage collector. There are also Bugzilla issues tracking JIT hardening work, which does not include substantial architectural changes to Firefox.

The paper is a puzzling affair — parts of it contradict other parts, the URL blacklisting discussion is a tangent, and the conclusion seems to weigh some of the tests significantly more than others. But whatever else they may show, the public reaction to the paper since its release indicates that many Firefox users are interested in seeing that project push forward in these unaddressed areas.

Comments (none posted)

Brief items

Security quotes of the week

I thought would try to behave for at least a few days while the heat is on, but they're already back to distributing malware. The trojan installer now tries to install something called Drop Down Deals on your computer (screen shot). This handy application spies on all of your web traffic in order to pop up ads when you visit certain sites.
-- Fyodor of Nmap fame is still unhappy with

Merely restricting a printer to installing or running software signed by the manufacturer deprives the owner of both security and freedom. It might end one specific threat, but only at the much greater cost of leaving the printer's security policies under the manufacturer's control. The way to give printer owners real security—security from rogue print jobs and manufacturer antifeatures alike—is for them to have the freedom to study, modify, and replace the software the printer runs.
-- Brett Smith on the Free Software Foundation blog

Comments (4 posted) "apologises" for bundling (The H)

The H reports that has apologized for bundling the Nmap scanner with an installer that does a lot more than just install Nmap (it changes the default search to Bing, installs toolbars, ...). "'The bundling of this software was a mistake on our part and we apologize to the user and developer communities for the unrest it caused' said ['s Sean] Murphy, adding that the company had 'reviewed all open source files in our catalog to ensure none are being bundled'. Nmap has been removed from the download manager on, according to Murphy, and attempts to download it from the site will now send the user what appears to be an unmodified setup file for the network scanner." Nmap's Fyodor is maintaining a web page covering the "unrest".

Comments (10 posted)

New vulnerabilities

acpid: multiple vulnerabilities

Package(s):acpid CVE #(s):CVE-2011-2777 CVE-2011-4578
Created:December 9, 2011 Updated:October 29, 2013

From the Ubuntu advisory:

Oliver-Tobias Ripka discovered that an ACPI script incorrectly handled power button events. A local attacker could use this to execute arbitrary code, and possibly escalate privileges. (CVE-2011-2777)

Helmut Grohne and Michael Biebl discovered that ACPI scripts were executed with a permissive file mode creation mask (umask). A local attacker could read files and modify directories created by ACPI scripts that did not set a strict umask. (CVE-2011-4578)

Gentoo 201310-20 acpid 2013-10-28
Mandriva MDVSA-2012:137 acpid 2012-08-17
Mageia MGASA-2012-0215 acpid 2012-08-12
Mandriva MDVSA-2012:138 acpid 2012-08-17
Mageia MGASA-2012-0216 acpid 2012-08-12
Debian DSA-2362-1 acpid 2011-12-10
Ubuntu USN-1296-1 acpid 2011-12-08

Comments (none posted)

arora: certificate spoof

Package(s):arora CVE #(s):CVE-2011-3367
Created:December 13, 2011 Updated:August 20, 2012
Description: From the CVE entry:

Arora, possibly 0.11 and other versions, does not use a certain font when rendering certificate fields in a security dialog, which allows remote attackers to spoof the common name (CN) of a certificate via rich text.

Gentoo 201412-09 racer-bin, fmod, PEAR-Mail, lvm2, gnucash, xine-lib, lastfmplayer, webkit-gtk, shadow, PEAR-PEAR, unixODBC, resource-agents, mrouted, rsync, xmlsec, xrdb, vino, oprofile, syslog-ng, sflowtool, gdm, libsoup, ca-certificates, gitolite, qt-creator 2014-12-11
Mageia MGASA-2012-0220 arora 2012-08-18
Fedora FEDORA-2011-14756 arora 2011-10-22
Fedora FEDORA-2011-14719 arora 2011-10-22

Comments (none posted)

chasen: code execution

Package(s):chasen CVE #(s):CVE-2011-4000
Created:December 8, 2011 Updated:July 10, 2012

From the Debian advisory:

It was discovered that ChaSen, a Japanese morphological analysis system, contains a buffer overflow, potentially leading to arbitrary code execution in programs using the library.

Gentoo 201207-03 chasen 2012-07-09
openSUSE openSUSE-SU-2012:0026-1 chasen 2012-01-05
Debian DSA-2361-1 chasen 2011-12-07

Comments (none posted)

dhcp: denial of service

Package(s):dhcp CVE #(s):CVE-2011-4539
Created:December 8, 2011 Updated:January 3, 2012

From the Mandriva advisory:

dhcpd in ISC DHCP 4.x before 4.2.3-P1 and 4.1-ESV before 4.1-ESV-R4 does not properly handle regular expressions in dhcpd.conf, which allows remote attackers to cause a denial of service (daemon crash) via a crafted request packet (CVE-2011-4539).

Gentoo 201301-06 dhcp 2013-01-09
Slackware SSA:2012-237-01 dhcp 2012-08-24
Debian DSA-2519-2 isc-dhcp 2012-08-04
Fedora FEDORA-2011-16976 dhcp 2011-12-11
CentOS CESA-2011:1819 dhcp 2011-12-22
Oracle ELSA-2011-1819 dhcp 2011-12-17
Scientific Linux SL-dhcp-20111214 dhcp 2011-12-14
Ubuntu USN-1309-1 isc-dhcp 2011-12-15
Fedora FEDORA-2011-16981 dhcp 2011-12-11
Red Hat RHSA-2011:1819-01 dhcp 2011-12-14
openSUSE openSUSE-SU-2011:1318-1 dhcp 2011-12-13
Mandriva MDVSA-2011:182 dhcp 2011-12-08

Comments (none posted)

dovecot: certificate validation flaw

Package(s):dovecot CVE #(s):CVE-2011-4318
Created:December 9, 2011 Updated:February 21, 2013

From the Ubuntu advisory:

It was discovered that Dovecot incorrectly validated certificate hostnames when being used as a POP3 and IMAP proxy. If a remote attacker were able to perform a man-in-the-middle attack, this flaw could be exploited to view sensitive information.

CentOS CESA-2013:0520 dovecot 2013-03-09
Scientific Linux SL-dove-20130304 dovecot 2013-03-04
Oracle ELSA-2013-0520 dovecot 2013-02-25
Red Hat RHSA-2013:0520-02 dovecot 2013-02-21
openSUSE openSUSE-SU-2012:0219-1 dovecot20 2012-02-09
Fedora FEDORA-2011-16234 dovecot 2011-11-23
Fedora FEDORA-2011-16272 dovecot 2011-11-23
Ubuntu USN-1295-1 dovecot 2011-12-08

Comments (none posted)

icu: code execution

Package(s):icu CVE #(s):CVE-2011-4599
Created:December 14, 2011 Updated:September 25, 2012
Description: ICU has a vulnerability wherein the opening of a crafted locale representation can cause a crash or code execution.
Gentoo 201209-07 icu 2012-09-24
Debian DSA-2397-1 icu 2012-01-29
Ubuntu USN-1348-1 icu 2012-01-26
openSUSE openSUSE-SU-2012:0100-1 icu 2012-01-19
Mandriva MDVSA-2011:194 icu 2011-12-27
CentOS CESA-2011:1815 icu 2011-12-22
Oracle ELSA-2011-1815 icu 2011-12-17
Scientific Linux SL-icu-20111213 icu 2011-12-13
CentOS CESA-2011:1815 icu 2011-12-14
Oracle ELSA-2011-1815 icu 2011-12-14
Red Hat RHSA-2011:1815-01 icu 2011-12-13
Fedora FEDORA-2011-17101 icu 2011-12-14
Fedora FEDORA-2011-17119 icu 2011-12-14

Comments (none posted)

ipmitool: denial of service

Package(s):ipmitool CVE #(s):CVE-2011-4339
Created:December 14, 2011 Updated:January 3, 2012
Description: The PID file used by ipmitool is world-writable, allowing a local attacker to kill arbitrary processes on the system.
Fedora FEDORA-2011-17071 ipmitool 2011-12-13
Fedora FEDORA-2011-17065 ipmitool 2011-12-13
Debian DSA-2376-2 ipmitool 2011-12-31
Debian DSA-2376-1 ipmitool 2011-12-30
Mandriva MDVSA-2011:196 ipmitool 2011-12-28
CentOS CESA-2011:1814 ipmitool 2011-12-22
Oracle ELSA-2011-1814 ipmitool 2011-12-17
Scientific Linux SL-ipmi-20111213 ipmitool 2011-12-13
Red Hat RHSA-2011:1814-01 ipmitool 2011-12-13

Comments (none posted)

jasper: two code execution flaws

Package(s):jasper CVE #(s):CVE-2011-4516 CVE-2011-4517
Created:December 9, 2011 Updated:January 24, 2012

From the Red Hat advisory:

Two heap-based buffer overflow flaws were found in the way JasPer decoded JPEG 2000 compressed image files. An attacker could create a malicious JPEG 2000 compressed image file that, when opened, would cause applications that use JasPer (such as Nautilus) to crash or, potentially, execute arbitrary code. (CVE-2011-4516, CVE-2011-4517)

Slackware SSA:2015-302-02 jasper 2015-10-29
Fedora FEDORA-2014-17032 mingw-jasper 2014-12-17
Fedora FEDORA-2014-17027 mingw-jasper 2014-12-17
Fedora FEDORA-2014-16961 mingw-jasper 2014-12-17
Gentoo 201201-10 jasper 2012-01-23
Ubuntu USN-1317-1 ghostscript 2012-01-04
Fedora FEDORA-2011-16955 jasper 2011-12-11
Fedora FEDORA-2011-16966 jasper 2011-12-11
CentOS CESA-2011:1807 jasper 2011-12-22
Ubuntu USN-1315-1 jasper 2011-12-20
Oracle ELSA-2011-1807 jasper 2011-12-17
Scientific Linux SL-jasp-20111209 jasper 2011-12-09
openSUSE openSUSE-SU-2011:1328-1 jasper 2011-12-16
Mandriva MDVSA-2011:189 jasper 2011-12-16
Oracle ELSA-2011-1811 netpbm 2011-12-13
Oracle ELSA-2011-1811 netpbm 2011-12-13
SUSE SUSE-SU-2011:1317-2 jasper 2011-12-14
Scientific Linux SL-netp-20111212 netpbm 2011-12-12
Debian DSA-2371-1 jasper 2011-12-24
CentOS CESA-2011:1811 netpbm 2011-12-12
CentOS CESA-2011:1811 netpbm 2011-12-12
Red Hat RHSA-2011:1811-01 netpbm 2011-12-12
SUSE SUSE-SU-2011:1317-1 jasper 2011-12-12
Red Hat RHSA-2011:1807-01 jasper 2011-12-09
openSUSE openSUSE-SU-2016:2737-1 jasper 2016-11-05

Comments (none posted)

nova: file overwrite

Package(s):nova CVE #(s):CVE-2011-4596
Created:December 13, 2011 Updated:December 14, 2011
Description: From the Ubuntu advisory:

David Black discovered that Nova did not properly perform input validation during image registration. An attacker could exploit this by registering a crafted image using the EC2 API or S3/RegisterImage method and overwrite files as the nova user.

Ubuntu USN-1305-1 nova 2011-12-13

Comments (none posted)

opera: multiple vulnerabilities

Package(s):opera CVE #(s):CVE-2011-4681 CVE-2011-4682 CVE-2011-4683 CVE-2011-4684 CVE-2011-4685 CVE-2011-4686 CVE-2011-4687
Created:December 9, 2011 Updated:December 14, 2011
Description: Evidently there are 7 flaws of one kind or another that were fixed in Opera. See the openSUSE advisory for more information.
Gentoo 201206-03 opera 2012-06-15
openSUSE openSUSE-SU-2011:1314-1 opera 2011-12-09

Comments (none posted)

php: denial of service and information disclosure

Package(s):php5 php CVE #(s):CVE-2011-4566
Created:December 14, 2011 Updated:April 13, 2012
Description: PHP incorrectly handles EXIF headers in JPEG files; an attacker could exploit this vulnerability to crash the PHP server or view (unspecified) sensitive information.
SUSE SUSE-SU-2013:1351-1 PHP5 2013-08-16
Gentoo 201209-03 php 2012-09-23
Oracle ELSA-2012-1046 php 2012-06-30
Mandriva MDVSA-2012:071 php 2012-05-10
SUSE SUSE-SU-2012:0496-1 PHP5 2012-04-12
openSUSE openSUSE-SU-2012:0426-1 php5 2012-03-29
Scientific Linux SL-php-20120130 php 2012-01-30
Oracle ELSA-2012-0071 php 2012-01-31
Debian DSA-2399-1 php5 2012-01-31
CentOS CESA-2012:0071 php 2012-01-30
Red Hat RHSA-2012:0071-01 php 2012-01-30
Fedora FEDORA-2012-0420 maniadrive 2012-01-26
Fedora FEDORA-2012-0420 php-eaccelerator 2012-01-26
Fedora FEDORA-2012-0420 php 2012-01-26
Fedora FEDORA-2012-0504 maniadrive 2012-01-19
Fedora FEDORA-2012-0504 php-eaccelerator 2012-01-19
Fedora FEDORA-2012-0504 php 2012-01-19
Scientific Linux SL-php-20120119 php 2012-01-19
Oracle ELSA-2012-0033 php 2012-01-18
CentOS CESA-2012:0033 php 2012-01-18
Red Hat RHSA-2012:0033-01 php 2012-01-18
Oracle ELSA-2012-0019 php53 2012-01-13
Scientific Linux SL-NotF-20120112 php/php53 2012-01-12
Oracle ELSA-2012-0019 php 2012-01-12
CentOS CESA-2012:0019 php 2012-01-11
CentOS CESA-2012:0019 php53 2012-01-11
Red Hat RHSA-2012:0019-01 php/php53 2012-01-11
Ubuntu USN-1307-1 php5 2011-12-14
Mandriva MDVSA-2011:197 php 2011-12-30

Comments (none posted)

pidgin: denial of service

Package(s):pidgin CVE #(s):CVE-2011-4601
Created:December 12, 2011 Updated:January 9, 2012
Description: From the Mandriva advisory:

When receiving various messages related to requesting or receiving authorization for adding a buddy to a buddy list, the oscar protocol plugin failed to validate that a piece of text was UTF-8. In some cases invalid UTF-8 data would lead to a crash.

Ubuntu USN-1500-1 pidgin 2012-07-09
openSUSE openSUSE-SU-2012:0066-1 pidgin 2012-01-09
Fedora FEDORA-2011-17546 pidgin 2011-12-30
Fedora FEDORA-2011-17558 pidgin 2011-12-30
CentOS CESA-2011:1821 pidgin 2011-12-22
Oracle ELSA-2011-1821 pidgin 2011-12-17
Scientific Linux SL-pidg-20111214 pidgin 2011-12-14
Scientific Linux SL-pidg-20111214 pidgin 2011-12-14
Oracle ELSA-2011-1820 pidgin 2011-12-14
CentOS CESA-2011:1820 pidgin 2011-12-14
CentOS CESA-2011:1820 pidgin 2011-12-14
Red Hat RHSA-2011:1821-01 pidgin 2011-12-14
Red Hat RHSA-2011:1820-01 pidgin 2011-12-14
Mandriva MDVSA-2011:183 pidgin 2011-12-10

Comments (none posted)

python-celery: privilege escalation

Package(s):python-celery CVE #(s):CVE-2011-4356
Created:December 12, 2011 Updated:December 14, 2011
Description: From the CVE entry:

Celery 2.1 and 2.2 before 2.2.8, 2.3 before 2.3.4, and 2.4 before 2.4.4 changes the effective id but not the real id during processing of the --uid and --gid arguments to celerybeat, celeryd_detach, celeryd-multi, and celeryev, which allows local users to gain privileges via vectors involving crafted code that is executed by the worker process.

Fedora FEDORA-2011-16549 python-celery 2011-11-28
Fedora FEDORA-2011-16539 python-celery 2011-11-28

Comments (none posted)

ykclient: Authentication bypass via NULL password

Package(s):ykclient CVE #(s):CVE-2011-4120
Created:December 13, 2011 Updated:December 14, 2011
Description: Pressing Ctrl-D when the Yubico PAM Module prompts for password will allow the user to log in without a password. See the Red Hat bugzilla for details.
Fedora FEDORA-2011-15580 yubikey-val 2011-11-10
Fedora FEDORA-2011-15580 pam_yubico 2011-11-10
Fedora FEDORA-2011-15580 ykclient 2011-11-10

Comments (none posted)

zabbix: remote SQL command execution

Package(s):zabbix CVE #(s):CVE-2011-4674
Created:December 12, 2011 Updated:December 14, 2011
Description: From the CVE entry:

SQL injection vulnerability in popup.php in Zabbix 1.8.3 and 1.8.4, and possibly other versions before 1.8.9, allows remote attackers to execute arbitrary SQL commands via the only_hostid parameter.

Gentoo 201311-15 zabbix 2013-11-25
Fedora FEDORA-2011-16712 zabbix 2011-12-04
Fedora FEDORA-2011-16745 zabbix 2011-12-04

Comments (none posted)

Page editor: Jake Edge
Next page: Kernel development>>

Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds