User: Password:
Subscribe / Log in / New account


The security of

By Jake Edge
July 16, 2014

Two weeks ago, we looked at the new location for the Red Hat Enterprise Linux (RHEL) source code, which now (as of RHEL 7) resides in a Git repository at Switching away from a directory full of signed source RPMs (SRPMs), as Red Hat used to release, to Git caused some consternation about the ability for RHEL-rebuilds to ensure the provenance of the code. While much of that concern was dampened by explanations and tooling, there are still some who would like to see Red Hat sign Git commits and/or tags in the repository to eliminate some (fairly to wildly unlikely, depending on whom you listen to) possible avenues of source code corruption. As is often the case, it partly comes down to a question of threat models.

Nico Kadel-Garcia initiated the discussion with a request for signed tags on the import of SRPM contents into the RHEL source Git repositories. His concern is about man-in-the-middle (MITM) attacks against developers who are cloning or updating from the CentOS repositories, as he outlined in a later message:

It's man-in-the-middle attacks for remote software downloaders. [They're] vulnerable to trojaned repositories. placed *in between* their local client and And SSL itself is vulnerable to forged keys using stolen signature authorities, whether local to a remote environment or such as the stolen "GlobalSign" keys. But there are even environments that put proxies in front of *incoming* traffic, locally, to slap a new internal and internally signed SSL key on it, and *deliberately* do man-in-the-middle monitoring at the proxy.

Using GPG (aka OpenPGP) signatures on tags (or other commits) would provide a separate check that could help detect the kind of problems that a MITM can cause, he said. But CentOS project lead Karanbir Singh was not convinced that signatures provided anything more than the current TLS/SSL encryption does. He argued that the key exchange would likely happen via TLS/SSL anyway: "So the only way to get the originating gpg key ( that you'd verify against ) is over ssl on the internet, which also implies that having behind the same [level of] trust puts us no worse off." There are some major differences between TLS/SSL encryption of the data transfer and GPG signature verification of the data received, as Mark Mielke pointed out:

With SSL/SSH you are, at least in theory, authenticating the origin host. This makes no promise about the origin content.

A PGP-signed tag makes a promise about the content but does *not* make a promise about the origin host.

However, getting CentOS to sign objects in the Git repository doesn't really address the problem, Chris St. Pierre said. CentOS is simply a downstream consumer of those repositories, just like any other RHEL-rebuild distribution (or any other user of the repositories). To ensure that the code committed is the proper code, Red Hat would need to sign the tags or commits. St. Pierre ended his strongly worded message with an amusing (or, perhaps, almost amusing) warning:

I'll warn you, though, since the specter of the all-powerful NSA was raised: they already have Red Hat's signing keys. And yours, too.

Others argued that signed CentOS tags would add value, in much the same way that the signed SRPMs that CentOS produces are useful. But St. Pierre was having none of that: "If I, the end user, am concerned about the sources having been illicitly tampered with, all this tells me is that I've got the same (untrusted, possibly trojaned) sources as CentOS. Big whoop." If Red Hat had signed the content it pushed into those repositories, he said, then there is a chain of trust that can be established. But even the signed SRPMs from CentOS are not able to complete a chain:

A signed RPM tells me that CentOS did, in fact, build that RPM. It eliminates one possible point of contamination, but it does not ensure an unbroken chain of trust. Back in the olden days, it would have told me that CentOS built it using opaque processes from a signed upstream source -- the SRPMs at -- so there was still a break in the chain of trust, since CentOS's processes were insufficiently public. They're now increasingly public, so a signed RPM tells me that CentOS built the RPM, using well-known processes, from which point I could follow back the build logs and discover the unsigned, untrusted sources it was built from. Whereupon the chain of trust again disappears.

The only real argument against signatures came from Singh, who saw some procedural problems, and was also worried about the proliferation of distribution keys: "putting distro keys on developer laptops and circulating them around town [isn't] a nice thing, expand that with increasing contributor base who are able to branch and build their own content into SIG's [Special Interest Groups] etc, and you dramatically expand that problem base". He is looking at it from a CentOS perspective, as is only reasonable. So far, no one from the RHEL team has commented one way or the other about signing tags, though it is hard to believe the team is unaware of the issue. Given that Red Hat no longer distributes the signed SRPMs, it would seem that a conscious decision was made not to sign the source provided for RHEL 7.

There's no reason to believe that the source on has been tampered with. The CentOS developers are confident that the "the authenticity of the code is not in question", as project member Johnny Hughes put it. For his part, Kadel-Garcia does not seem to question the security of itself, he is more concerned with downstream users of the repositories getting code that has been tampered with.

It is clear that GPG-signed commits could help in a number of different scenarios. But some have been more directly concerned with the security of LWN commenter "jcpunk" noted that if a bad commit were to get into the CentOS repositories (somehow), it might not be discovered for quite some time. Mike Gerwitz's Git Horror Story was referenced by jcpunk; it covers some of the situations where even signed commits don't completely alleviate those kinds of problems.

The lack of a signed foundation on which to rebuild RHEL for CentOS, Scientific Linux, and others does seem a little strange upon further reflection. It may have no practical effect, which is essentially what many (including the CentOS developers) have been arguing, but it does require at least a small leap of faith. But, then, signed SRPMs from Red Hat require a (different) leap. In the final analysis, even signatures are based on trust.

Comments (2 posted)

Brief items

Security quotes of the week

It's actually a very hard problem to solve. The adversary can have unrestricted access to the computer, especially hotel business center computers that are often tucked away where no one else is looking. I assume that if someone has physical access to my computer, he can own it. This is doubly true if he has hardware access.
Bruce Schneier on this report about keyloggers at hotel business centers

Crafting a smart, snappy password that engages the reader right from the first character is tricky, especially if you’re unfamiliar with the form. And make no mistake: The best way to start writing truly great passwords is through years of diligent practice. You’re not going to sit down at a keyboard and just produce an all-time classic password like “let$g3titstart3d” on your first day.
— "Tips For Crafting A Strong Password That Really Pops"

Armed with knowledge of the encryption algorithm, key, initialization vector and an understanding of the mesh network protocol we could then inject packets into the mesh network, capture the WiFi details and decrypt the credentials, all without any prior authentication or alerting of our presence. Success!
Alex Chapman attacks an internet-connected light bulb

Comments (3 posted)

2014 Linux Security Summit schedule published

James Morris has a blog post announcing that the schedule for this year's Linux Security Summit (LSS) is now available. It starts with a keynote from James Bottomley of Parallels, then there are seven refereed talks, as well as other sessions: "Discussion session topics include Trusted Kernel Lock-down Patch Series, led by Kees Cook; and EXT4 Encryption, led by Michael Halcrow & Ted Ts’o. There’ll be kernel security subsystem updates from the SELinux, AppArmor, Smack, and Integrity maintainers. The break-out sessions are open format and a good opportunity to collaborate face-to-face on outstanding or emerging issues." LSS will be held August 18-19 in Chicago, overlapping the first two days of the Kernel Summit and it is followed by LinuxCon North America; all are being held in the same location.

Comments (none posted)

First Release of LibreSSL Portable Available

OpenBSD Journal is reporting that the first release of LibreSSL Portable is available for download from OpenBSD project servers. LibreSSL is the OpenSSL fork started in April by members of the OpenBSD development community after the "Heartbleed" vulnerability; the "Portable" version is designed to run on operating systems other than OpenBSD itself, including Linux. The announcement calls this release "an initial release to allow the community to start using and providing feedback;" it is tagged as version 2.0.0.

Comments (74 posted)

OpenSSL fork LibreSSL is declared “unsafe for Linux” (Ars Technica)

Ars Technica reports that a security researcher has found what he calls a "catastrophic failure" in the Linux version of LibreSSL. "The failure results in cases where the same 16-bit PID is used to designate two or more processes. Linux ensures that a process can never have the same ID as the child process it spawned, but it remains possible for a process to have the same PID as its grandparent process. The condition appears to be an edge case, but it's one that may be possible if the Linux fork_rand program forks enough times to produce identical PIDs. OpenSSL, the open-source program LibreSSL aims to replace, has ways to recover from such cases. LibreSSL does not, at least not on Linux."

Update: This issue has been fixed in LibreSSL 2.0.2.

Comments (55 posted)

Google's "Project Zero"

Google's newly announced Project Zero is focused on making the net as a whole safer from attackers. "We're not placing any particular bounds on this project and will work to improve the security of any software depended upon by large numbers of people, paying careful attention to the techniques, targets and motivations of attackers. We'll use standard approaches such as locating and reporting large numbers of vulnerabilities. In addition, we'll be conducting new research into mitigations, exploitation, program analysis—and anything else that our researchers decide is a worthwhile investment." Their policy of only reporting bugs to the vendor looks like it could result in the burying of inconvenient vulnerabilities, but presumably they have thought about that.

Comments (9 posted)

New vulnerabilities

ansible: unspecified vulnerability

Package(s):ansible CVE #(s):
Created:July 11, 2014 Updated:July 16, 2014

From the Fedora advisory:

Update to 1.6.6 with more security tweaks

Update to 1.6.5. Further fixes on security issue.

Update to 1.6.4 with a security fix

Fedora FEDORA-2014-8032 ansible 2014-07-11
Fedora FEDORA-2014-7997 ansible 2014-07-11

Comments (none posted)

claws-mail: code execution

Package(s):claws-mail CVE #(s):
Created:July 14, 2014 Updated:July 16, 2014
Description: From the Red Hat bugzilla:

There's a stack-based off-by-one in Claws Mail's HTML parsing.

NOTE: I've not investigated this properly and currently have no plans to do so. Depending on our stack layout and whether or not stack corruption mitigation is in place, this could be anything from no issue at all to possible code execution. My guess is that this is not really an issue for us, but then again it looks suspicious enough to get this fixed.

It looks like this got introduced with 3.10.0 and was fixed in 3.10.1. F20 ships 3.10.0, for F19 3.10.0 is only in updates-testing.

Fedora FEDORA-2014-7577 claws-mail-plugins 2014-07-13
Fedora FEDORA-2014-7577 claws-mail 2014-07-13

Comments (none posted)

docker-io: privilege escalation

Package(s):docker-io CVE #(s):CVE-2014-3499
Created:July 14, 2014 Updated:July 16, 2014
Description: From the Red Hat bugzilla:

It was found that the socket used to manage the Docker service was world readable and writable. A local user could use this flaw to escalate their privileges to root.

Fedora FEDORA-2014-8034 docker-io 2014-07-14
Fedora FEDORA-2014-8021 docker-io 2014-07-14

Comments (none posted)

eglibc: privilege escalation

Package(s):eglibc CVE #(s):CVE-2014-0475
Created:July 11, 2014 Updated:October 20, 2014

From the Debian advisory:

Stephane Chazelas discovered that the GNU C library, glibc, processed ".." path segments in locale-related environment variables, possibly allowing attackers to circumvent intended restrictions, such as ForceCommand in OpenSSH, assuming that they can supply crafted locale settings.

Mandriva MDVSA-2015:168 glibc 2015-03-30
Oracle ELSA-2015-0327 glibc 2015-03-09
Oracle ELSA-2015-0092 glibc 2015-01-27
Oracle ELSA-2014-2023 glibc 2014-12-18
Oracle ELSA-2014-1391 glibc 2014-10-16
openSUSE openSUSE-SU-2014:1115-1 glibc 2014-09-11
Ubuntu USN-2306-3 eglibc 2014-09-08
Scientific Linux SLSA-2014:1110-1 glibc 2014-08-29
Oracle ELSA-2014-1110 glibc 2014-08-29
Oracle ELSA-2014-1110 glibc 2014-08-29
Oracle ELSA-2014-1110 glibc 2014-08-29
CentOS CESA-2014:1110 glibc 2014-08-29
CentOS CESA-2014:1110 glibc 2014-08-29
CentOS CESA-2014:1110 glibc 2014-08-29
Red Hat RHSA-2014:1110-01 glibc 2014-08-29
Ubuntu USN-2328-1 eglibc 2014-08-28
Fedora FEDORA-2014-9824 glibc 2014-08-28
Fedora FEDORA-2014-9830 glibc 2014-10-19
Mageia MGASA-2014-0314 glibc 2014-08-05
Mandriva MDVSA-2014:152 glibc 2014-08-06
Ubuntu USN-2306-2 eglibc 2014-08-05
Ubuntu USN-2306-1 eglibc 2014-08-04
Debian DSA-2976-1 eglibc 2014-07-10
Gentoo 201602-02 glibc 2016-02-17

Comments (none posted)

java-1.7.0-openjdk: multiple vulnerabilities

Package(s):java-1.7.0-openjdk CVE #(s):CVE-2014-2483 CVE-2014-2490 CVE-2014-4209 CVE-2014-4216 CVE-2014-4218 CVE-2014-4219 CVE-2014-4221 CVE-2014-4223 CVE-2014-4244 CVE-2014-4252 CVE-2014-4262 CVE-2014-4263 CVE-2014-4266
Created:July 16, 2014 Updated:September 2, 2014
Description: From the Red Hat advisory:

It was discovered that the Hotspot component in OpenJDK did not properly verify bytecode from the class files. An untrusted Java application or applet could possibly use these flaws to bypass Java sandbox restrictions. (CVE-2014-4216, CVE-2014-4219)

A format string flaw was discovered in the Hotspot component event logger in OpenJDK. An untrusted Java application or applet could use this flaw to crash the Java Virtual Machine or, potentially, execute arbitrary code with the privileges of the Java Virtual Machine. (CVE-2014-2490)

Multiple improper permission check issues were discovered in the Libraries component in OpenJDK. An untrusted Java application or applet could use these flaws to bypass Java sandbox restrictions. (CVE-2014-4223, CVE-2014-4262, CVE-2014-2483)

Multiple flaws were discovered in the JMX, Libraries, Security, and Serviceability components in OpenJDK. An untrusted Java application or applet could use these flaws to bypass certain Java sandbox restrictions. (CVE-2014-4209, CVE-2014-4218, CVE-2014-4221, CVE-2014-4252, CVE-2014-4266)

It was discovered that the RSA algorithm in the Security component in OpenJDK did not sufficiently perform blinding while performing operations that were using private keys. An attacker able to measure timing differences of those operations could possibly leak information about the used keys. (CVE-2014-4244)

The Diffie-Hellman (DH) key exchange algorithm implementation in the Security component in OpenJDK failed to validate public DH parameters properly. This could cause OpenJDK to accept and use weak parameters, allowing an attacker to recover the negotiated key. (CVE-2014-4263)

SUSE SUSE-SU-2015:0376-1 java-1_5_0-ibm 2015-02-25
Gentoo 201502-12 oracle-jre-bin 2015-02-15
SUSE SUSE-SU-2015:0392-1 java-1_6_0-ibm 2015-02-27
openSUSE openSUSE-SU-2014:1645-1 java-1_7_0-openjdk 2014-12-15
openSUSE openSUSE-SU-2014:1638-1 java-1_7_0-openjdk 2014-12-15
Ubuntu USN-2319-3 OpenJDK 7 2014-09-16
Debian DSA-2987-2 openjdk-7 2014-08-31
Ubuntu USN-2319-2 openjdk-7 2014-08-25
Ubuntu USN-2319-1 openjdk-7 2014-08-19
Ubuntu USN-2312-1 openjdk-6 2014-08-12
Red Hat RHSA-2014:1042-01 java-1.7.1-ibm 2014-08-11
Red Hat RHSA-2014:1041-01 java-1.7.0-ibm 2014-08-11
Red Hat RHSA-2014:1036-01 java-1.5.0-ibm 2014-08-07
Mandriva MDVSA-2014:141 java-1.7.0-openjdk 2014-07-29
Red Hat RHSA-2014:1033-01 java-1.6.0-ibm 2014-08-07
Mageia MGASA-2014-0292 java-1.7.0-openjdk 2014-07-26
Fedora FEDORA-2014-8441 java-1.8.0-openjdk 2014-07-25
Fedora FEDORA-2014-8407 java-1.8.0-openjdk 2014-07-25
Fedora FEDORA-2014-8395 java-1.7.0-openjdk 2014-07-25
Oracle ELSA-2014-0889 java-1.7.0-openjdk 2014-07-23
Oracle ELSA-2014-0907 java-1.6.0-openjdk 2014-07-23
Debian DSA-2987-1 openjdk-7 2014-07-23
Scientific Linux SLSA-2014:0907-1 java-1.6.0-openjdk 2014-07-21
Oracle ELSA-2014-0907 java-1.6.0-openjdk 2014-07-21
Oracle ELSA-2014-0907 java-1.6.0-openjdk 2014-07-21
CentOS CESA-2014:0907 java-1.6.0-openjdk 2014-07-21
CentOS CESA-2014:0907 java-1.6.0-openjdk 2014-07-21
CentOS CESA-2014:0907 java-1.6.0-openjdk 2014-07-21
Red Hat RHSA-2014:0908-01 java-1.6.0-sun 2014-07-21
Red Hat RHSA-2014:0907-01 java-1.6.0-openjdk 2014-07-21
Fedora FEDORA-2014-8417 java-1.7.0-openjdk 2014-07-19
Red Hat RHSA-2014:0902-01 java-1.7.0-oracle 2014-07-18
Debian DSA-2980-1 openjdk-6 2014-07-17
Oracle ELSA-2014-0889 java-1.7.0-openjdk 2014-07-16
Oracle ELSA-2014-0890 java-1.7.0-openjdk 2014-07-16
Scientific Linux SLSA-2014:0890-1 java-1.7.0-openjdk 2014-07-16
Scientific Linux SLSA-2014:0889-1 java-1.7.0-openjdk 2014-07-16
CentOS CESA-2014:0890 java-1.7.0-openjdk 2014-07-16
CentOS CESA-2014:0889 java-1.7.0-openjdk 2014-07-16
CentOS CESA-2014:0889 java-1.7.0-openjdk 2014-07-16
Red Hat RHSA-2014:0890-01 java-1.7.0-openjdk 2014-07-16
Red Hat RHSA-2014:0889-01 java-1.7.0-openjdk 2014-07-16
SUSE SUSE-SU-2014:0961-1 openjdk 2014-08-04

Comments (none posted)

kernel: multiple vulnerabilities

Package(s):kernel CVE #(s):CVE-2014-4715 CVE-2014-4699
Created:July 11, 2014 Updated:July 25, 2014

From the CVE entry:

Yann Collet LZ4 before r119, when used on certain 32-bit platforms that allocate memory beyond 0x80000000, does not properly detect integer overflows, which allows context-dependent attackers to cause a denial of service (memory corruption) or possibly have unspecified other impact via a crafted Literal Run, a different vulnerability than CVE-2014-4611. (CVE-2014-4715)

From the Red hat bug report:

On Intel CPUs sysret to non-canonical address causes a fault on the sysret instruction itself after the stack pointer is set to user mode value but before the CPL is changed. Systems running on AMD CPUs are not vulnerable to this issue as sysret on AMD CPUs does not generate a fault before the CPL change.

It was found that certain Linux kernel's ptrace subsystem code paths allow the tracer to set tracee's instruction pointer to non-canonical address which is later used on tracee's return to user mode via the sysret instruction, effectively bypassing the hardening introduced via the fixes for CVE-2005-1764 (introduced guard page between the end of the user-mode accessible virtual address space and the beginning of the non-canonical) and CVE-2006-0744 (system call handler hardening).

An unprivileged local user could use this flaw to increase their privileges on the system. (CVE-2014-4699)

Oracle ELSA-2015-0290 kernel 2015-03-12
openSUSE openSUSE-SU-2014:1677-1 kernel 2014-12-21
openSUSE openSUSE-SU-2014:1246-1 kernel 2014-09-28
SUSE SUSE-SU-2014:1138-1 kernel 2014-09-16
Oracle ELSA-2014-1167 kernel 2014-09-09
Oracle ELSA-2014-1392 kernel 2014-10-21
openSUSE openSUSE-SU-2014:0957-1 kernel 2014-08-01
Oracle ELSA-2014-0981 kernel 2014-07-29
Mandriva MDVSA-2014:155 kernel 2014-08-07
Fedora FEDORA-2014-8487 kernel 2014-07-25
SUSE SUSE-SU-2014:0908-1 Linux kernel 2014-07-17
SUSE SUSE-SU-2014:0909-1 Linux kernel 2014-07-17
SUSE SUSE-SU-2014:0910-1 Linux kernel 2014-07-17
SUSE SUSE-SU-2014:0911-1 Linux kernel 2014-07-17
SUSE SUSE-SU-2014:0912-1 Linux kernel 2014-07-17
Fedora FEDORA-2014-8171 kernel 2014-07-11

Comments (none posted)

libav: code execution

Package(s):libav CVE #(s):CVE-2014-4609
Created:July 11, 2014 Updated:February 9, 2015

From the Debian advisory:

Don A. Baley discovered an integer overflow in the lzo compression handler which could result in the execution of arbitrary code.

Gentoo 201502-08 libav 2015-02-07
Ubuntu USN-2277-1 libav 2014-07-15
Debian DSA-2977-1 libav 2014-07-11

Comments (none posted)

pnp4nagios: cross-site scripting

Package(s):pnp4nagios CVE #(s):CVE-2014-4908 CVE-2014-4907
Created:July 14, 2014 Updated:May 12, 2015
Description: From the Red Hat bugzilla:

CVE-2014-4908: Two vulnerabilities have been reported in PNP4Nagios, which can be exploited by malicious people to conduct cross-site scripting attacks.

1) Input appended to the URL is not properly sanitised in "views/kohana_error_page.php" before being returned to the user. This can be exploited to execute arbitrary HTML and script code in a user's browser session in context of an affected site.

2) Input appended to the URL is not properly sanitised in "views/template.php" before being returned to the user. This can be exploited to execute arbitrary HTML and script code in a user's browser session in context of an affected site.

CVE-2014-4907: The 0.6.22 release of PNP4Nagios fixes a cross-site scripting flaw in an error page. An attacker could use this flaw to perform cross-site scripting attacks.

Mageia MGASA-2015-0203 pnp4nagios 2015-05-11
Fedora FEDORA-2014-8107 pnp4nagios 2014-07-14
Fedora FEDORA-2014-8098 pnp4nagios 2014-07-14

Comments (none posted)

ror40-rubygem-activerecord: SQL injection

Package(s):ror40-rubygem-activerecord CVE #(s):CVE-2014-3483
Created:July 15, 2014 Updated:August 25, 2014
Description: From the CVE entry:

SQL injection vulnerability in activerecord/lib/active_record/connection_adapters/postgresql/quoting.rb in the PostgreSQL adapter for Active Record in Ruby on Rails 4.x before 4.0.7 and 4.1.x before 4.1.3 allows remote attackers to execute arbitrary SQL commands by leveraging improper range quoting.

Fedora FEDORA-2014-8065 rubygem-activerecord 2014-08-23
Mageia MGASA-2014-0303 ruby-actionpack 2014-07-26
Debian DSA-2982-1 ruby-activerecord-3.2 2014-07-19
Red Hat RHSA-2014:0877-01 ror40-rubygem-activerecord 2014-07-14

Comments (none posted)

ruby193-rubygem-activerecord: SQL injection

Package(s):ruby193-rubygem-activerecord CVE #(s):CVE-2014-3482
Created:July 15, 2014 Updated:August 25, 2014
Description: From the CVE entry:

SQL injection vulnerability in activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb in the PostgreSQL adapter for Active Record in Ruby on Rails 2.x and 3.x before 3.2.19 allows remote attackers to execute arbitrary SQL commands by leveraging improper bitstring quoting.

Fedora FEDORA-2014-8089 rubygem-activerecord 2014-08-23
Debian DSA-2982-1 ruby-activerecord-3.2 2014-07-19
Red Hat RHSA-2014:0876-01 ruby193-rubygem-activerecord 2014-07-14

Comments (none posted)

transmission: code execution

Package(s):transmission CVE #(s):CVE-2014-4909
Created:July 16, 2014 Updated:August 15, 2014
Description: From the Ubuntu advisory:

Ben Hawkes discovered that Transmission incorrectly handled certain peer messages. A remote attacker could use this issue to cause a denial of service, or possibly execute arbitrary code.

Fedora FEDORA-2014-8332 transmission 2014-08-15
openSUSE openSUSE-SU-2014:0980-1 transmission 2014-08-11
Mageia MGASA-2014-0298 transmission 2014-07-26
Debian DSA-2988-1 transmission 2014-07-24
Fedora FEDORA-2014-8331 transmission 2014-07-19
Ubuntu USN-2279-1 transmission 2014-07-16

Comments (none posted)

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

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