Security
The security of git.centos.org
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 CentOS.org. 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:
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
git.centos.org 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:
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:
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:
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 git.centos.org 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
git.centos.org 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 git.centos.org. 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.
Brief items
Security quotes of the week
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.
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 "
Update: This issue has been fixed in LibreSSL 2.0.2.
an initial release to allow the
community to start using and providing feedback;" it is tagged
as version 2.0.0.
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.
"
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.
New vulnerabilities
ansible: unspecified vulnerability
| Package(s): | ansible | CVE #(s): | |||||||||
| Created: | July 11, 2014 | Updated: | July 16, 2014 | ||||||||
| Description: | 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 | ||||||||||
| Alerts: |
| ||||||||||
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. | ||||||||||
| Alerts: |
| ||||||||||
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. | ||||||||||
| Alerts: |
| ||||||||||
eglibc: privilege escalation
| Package(s): | eglibc | CVE #(s): | CVE-2014-0475 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | July 11, 2014 | Updated: | October 20, 2014 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | 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. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
kernel: multiple vulnerabilities
| Package(s): | kernel | CVE #(s): | CVE-2014-4715 CVE-2014-4699 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | July 11, 2014 | Updated: | July 25, 2014 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | 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) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
libav: code execution
| Package(s): | libav | CVE #(s): | CVE-2014-4609 | ||||||||||||
| Created: | July 11, 2014 | Updated: | February 9, 2015 | ||||||||||||
| Description: | 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. | ||||||||||||||
| Alerts: |
| ||||||||||||||
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. | ||||||||||||||
| Alerts: |
| ||||||||||||||
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. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
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. | ||||||||||||||
| Alerts: |
| ||||||||||||||
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. | ||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||
Page editor: Jake Edge
Next page:
Kernel development>>