By Jake Edge
June 26, 2013
Ensuring that the binary installed on a system corresponds to the source code for a project can be a tricky task. For those who build their own
packages (e.g. Gentoo users), it is in principle a lot easier, but most
Linux users probably delegate that job to their distribution's build
system. That does turn the distribution into a single point of failure,
however—any
compromise of its infrastructure could lead to the release of malicious
packages. Recognizing when that kind of compromise has happened, so that
alarms can be sounded, is not particularly easy to do, though it may become
fairly important over the coming years.
So how do security-conscious users determine that the published source code
(from the project or the distribution) is being reliably built into the
binaries that get installed on their systems? And how do regular users
feel confident that they are not getting binaries compromised by an
attacker (or government)? It is a difficult problem to
solve, but it also important to do so.
Last week, we quoted Mike Perry in our "quotes of the week", but he had
more to say in that liberationtech
mailing list post: "I don't believe that software development
models based on single party trust can actually be secure against
serious adversaries anymore, given the current trends in computer
security and 'cyberwar'". His argument is that the playing field
has changed; we are no longer just defending against attackers with limited
budgets who are mostly interested in monetary rewards from their efforts.
He continued:
This means that software development has to evolve beyond the simple
models of "Trust my gpg-signed apt archive from my trusted build
machine", or even projects like Debian going to end up distributing
state-sponsored malware in short order.
There are plenty of barriers in the way.
Even building from source will not result in a bit-for-bit
copy of the binary in question—things like the link time stamp or build
path strings within the binary
may be different. But differences in the toolchains used, the contents
of the system's or dependencies' include files, or other differences that
don't affect the
operation of the program may also lead to differences in the resulting
binary.
The only reliable way to reproduce a binary is to build it in the
exact same environment (including time stamps) that it was
originally built in. For binaries
shipped by distributions, that may be difficult to do as all of the
build environment information needed may not (yet?) be available. But, two
people can pull
the code from a repository, build it in the same environment with the same
build scripts, and each bit in the resulting binaries should be the same.
That is the idea behind Gitian, which
uses virtualization or containers that can be used to create identical build
environments in
multiple locations. Using Gitian, two (or more) entities can build from
source and compare the hashes of the binaries, which should be the same.
In addition, those people, projects, or organizations can sign the hash
with their GPG key, providing a "web of trust" for a specific binary.
Gitian is being used by projects like Bitcoin and the Tor browser (work on the latter was done by
Perry), both of which are particularly
security-sensitive. In both cases, Gitian is used to set up an
Ubuntu container or virtual machine (VM) to build the binaries (for Linux,
anyway), so support for other distributions (or even different versions of
Ubuntu)
would require a different setup.
That points to a potential problem with Gitian: scalability. For a few
different sensitive projects, creating the scripts and information needed
to build the containers or VMs of interest may not be a huge hurdle. But
for a distribution to set things up so that all of its packages can
be independently verified may well be. In addition, there is a question of
finding people to actually build all the packages so that the hashes can be
compared. Each time a distribution updates its toolchain or the package
dependencies,
those changes would need to be reflected in the Gitian (or some similar
system) configuration, packages would need to be built by both the
distribution and at least one (more is better, of course) other "trusted"
entity before consumers (users) could fully trust the binaries. Given the
number of packages, Linux distributions, and toolchain versions, it would
result in
a combinatorial explosion of builds required.
Beyond that, though, there is still an element of trust inherent in that
verification method. The compiler and other parts of the toolchain are
being trusted to produce correct code for the source in question. The
kernel's KVM and container implementation is also being trusted. To
subvert a binary using the compiler would require a "Trusting Trust" type
of attack, while some kind of nefarious (and undetected) code in the kernel
could potentially subvert the binary.
The diversity of the underlying
kernels (i.e. the host kernel for the container or VM) may help alleviate
most of the concern with that problem—though it can never really eliminate
it. Going deeper, the hardware itself could be malicious. That may sound
overly paranoid (and may in fact be), but when lives are possibly on the
line, as with the Tor browser, it's important to at least think about the
possibility. Money, too, causes paranoia levels to rise, thus Bitcoin's
interest in verification.
In addition to those worries, there is yet another: source code auditing.
Even if the compiler is reproducibly creating "correct" binaries from the
input source code, vigilance is needed to ensure that nothing untoward
slips into the source. In something as complex as a browser, even
run-of-the-mill bugs could be dangerous to the user, but some kind of
targeted malicious code injection would be far worse. In the free software
world, we tend to be sanguine about the dangers of malicious source code
because it is all "out in the open". But if people aren't actually
scrutinizing the source code, malicious code can sneak in, and we have seen
some instances of that in the past. Source availability is no panacea for
avoiding either intentional or accidental security holes.
By and large, the distributions do an excellent job of safeguarding their
repositories and build systems, but there have been lapses there as well
along the way. For now, trusting the distributions or building from source
and trusting the compiler—or some intermediate compiler—is all that's
available. For certain packages, that may change somewhat using Gitian or
similar schemes.
The compiler issue may be alleviated with David A. Wheeler's Diverse Double-Compiling
technique, provided there is an already-trusted compiler at
hand.
As Wheeler has said, one can write a new
compiler to use in the diverse double-compilation, though that compiler
needs to be compiled itself, of course. It may be hard to imagine a
"Trusting Trust" style attack on a completely unknown compiler, but it
isn't impossible to imagine.
As mentioned above, source-binary verification is a hard problem.
Something has to be trusted: the
hardware, the kernel, the compiler, Gitian, or, perhaps, the distribution.
It's a
little hard to see how Gitian could be applied to entire distribution
repositories, so looking into other techniques may prove fruitful. Simply
recording the entire build environment, including versions of all the tools
and dependencies, would make it easier to verify the correspondence of
source and binaries, but even simple tools (e.g. tar as reported
by Jos van den Oever) may have unexplained differences. For now, focusing
the effort
on the most security-critical projects may be the best we can do.
Comments (20 posted)
Brief items
In the long run, I suspect they will result in more deeply buried and impenetrable surveillance empires -- both in the U.S. and around the world -- and a determined sense by their proponents that in the future, the relative transparency we had this time around would be banished forever.
In the short run, we may see some small victories -- like Web firms being permitted by the government to more effectively defend themselves against false accusations, and perhaps a bit more transparency related to the court actions that enable and (at least in theory) monitor these programs.
But beyond that, while hope springs eternal, logic suggests that prospects for the masters of surveillance around the world have not been significantly dimmed, and in fact may have actually obtained a longer-term boost.
—
Lauren Weinstein
Conspiracy theorists may be unsurprised that:
- Microsoft's support for PFS is conspicuous by its absence across Internet Explorer, IIS, and some of its own web sites. Apple's support for PFS in Safari is only slightly better.
- Russia, long-time target of US spies, is the home of the developer of nginx, the web server which uses PFS most often.
- Almost all of the websites run by companies involved in the PRISM programme do not use PFS.
—
Netcraft
looks into
perfect forward
secrecy (PFS)
All of this mapping of vulnerabilities and keeping them secret for offensive use makes the Internet less secure, and these pretargeted, ready-to-unleash cyberweapons are destabilizing forces on international relationships. Rooting around other countries' networks, analyzing vulnerabilities, creating back doors, and leaving logic bombs could easily be construed as acts of war. And all it takes is one overachieving national leader for this all to tumble into actual war.
It's time to stop the madness. Yes, our military needs to invest in cyberwar capabilities, but we also need international rules of cyberwar, more transparency from our own government on what we are and are not doing, international cooperation between governments, and viable cyberweapons treaties. Yes, these are difficult. Yes, it's a long, slow process. Yes, there won't be international consensus, certainly not in the beginning. But even with all of those problems, it's a better path to go down than the one we're on now.
—
Bruce
Schneier
Just as important was what the Japanese government and people did not
do. They didn't panic. They didn't make sweeping changes to their way of
life. They didn't implement a vast system of domestic surveillance. They
didn't suspend basic civil rights. They didn't begin to capture, torture,
and kill without due process. They didn't, in other words, allow themselves
to be terrorized. Instead, they addressed the threat. They investigated and
arrested the cult's leadership. They tried them in civilian courts and
earned convictions through due process. They buried their dead. They
mourned. And they moved on. In every sense, it was a rational, adult,
mature response to a terrible terrorist act, one that remained largely in
keeping with liberal democratic ideals.
—
Freddie
on the Japanese reaction to the Aum Shinrikyo terrorism (from the
L'Hôte blog)
Comments (9 posted)
At his blog, Jos van den Oever
looks into recreating binaries from their published source code to verify that the executable contains what it says it does.
"
A license that promises access to the source code is one thing, but an interesting question is: is the published source code the same source code that was used to create the executable? The straightforward way to find this out is to compile the code and check that the result is the same. Unfortunately, the result of compiling the source code depends on many things besides the source code and build scripts such as which compiler was used. No free software license requires that this information is made available and so it would seem that it is a challenge to confirm if the given source code corresponds to the executable."
Comments (59 posted)
New vulnerabilities
curl: heap corruption
| Package(s): | curl |
CVE #(s): | CVE-2013-2174
|
| Created: | June 24, 2013 |
Updated: | July 23, 2013 |
| Description: |
From the cURL advisory:
libcurl is vulnerable to a case of bad checking of the input data which may
lead to heap corruption.
The function curl_easy_unescape() decodes URL encoded strings to raw binary data. URL encoded octets are represented with %HH combinations where HH is a two-digit hexadecimal number. The decoded string is written to an allocated memory area that the function returns to the caller.
The function takes a source string and a length parameter, and if the length provided is 0 the function will instead use strlen() to figure out how much data to parse.
The "%HH" parser wrongly only considered the case where a zero byte would
terminate the input. If a length-limited buffer was passed in which ended
with a '%' character which was followed by two hexadecimal digits outside of the buffer libcurl was allowed to parse alas without a terminating zero, libcurl would still parse that sequence as well. The counter for remaining data to handle would then be decreased too much and wrap to become a very large integer and the copying would go on too long and the destination buffer that is allocated on the heap would get overwritten.
We consider it unlikely that programs allow user-provided strings unfiltered
into this function. Also, only the not zero-terminated input string use case
is affected by this flaw. Exploiting this flaw for gain is probably possible
for specific circumstances but we consider the general risk for this to be
low.
The curl command line tool is not affected by this problem as it doesn't use
this function. |
| Alerts: |
|
Comments (none posted)
haproxy: denial of service
| Package(s): | haproxy |
CVE #(s): | CVE-2013-2175
|
| Created: | June 20, 2013 |
Updated: | September 5, 2013 |
| Description: |
From the Debian advisory:
CVE-2013-2175:
Denial of service in parsing HTTP headers. |
| Alerts: |
|
Comments (none posted)
java-1.7.0-openjdk: multiple vulnerabilities
| Package(s): | java-1.7.0-openjdk |
CVE #(s): | CVE-2013-1500
CVE-2013-1571
CVE-2013-2407
CVE-2013-2412
CVE-2013-2443
CVE-2013-2444
CVE-2013-2445
CVE-2013-2446
CVE-2013-2447
CVE-2013-2448
CVE-2013-2449
CVE-2013-2450
CVE-2013-2452
CVE-2013-2453
CVE-2013-2454
CVE-2013-2455
CVE-2013-2456
CVE-2013-2457
CVE-2013-2458
CVE-2013-2459
CVE-2013-2460
CVE-2013-2461
CVE-2013-2463
CVE-2013-2465
CVE-2013-2469
CVE-2013-2470
CVE-2013-2471
CVE-2013-2472
CVE-2013-2473
|
| Created: | June 20, 2013 |
Updated: | July 31, 2013 |
| Description: |
From the Red Hat advisory:
Multiple flaws were discovered in the ImagingLib and the image attribute,
channel, layout and raster processing in the 2D component. An untrusted
Java application or applet could possibly use these flaws to trigger Java
Virtual Machine memory corruption. (CVE-2013-2470, CVE-2013-2471,
CVE-2013-2472, CVE-2013-2473, CVE-2013-2463, CVE-2013-2465, CVE-2013-2469)
Integer overflow flaws were found in the way AWT processed certain input.
An attacker could use these flaws to execute arbitrary code with the
privileges of the user running an untrusted Java applet or application.
(CVE-2013-2459)
Multiple improper permission check issues were discovered in the Sound,
JDBC, Libraries, JMX, and Serviceability components in OpenJDK. An
untrusted Java application or applet could use these flaws to bypass Java
sandbox restrictions. (CVE-2013-2448, CVE-2013-2454, CVE-2013-2458,
CVE-2013-2457, CVE-2013-2453, CVE-2013-2460)
Multiple flaws in the Serialization, Networking, Libraries and CORBA
components can be exploited by an untrusted Java application or applet to
gain access to potentially sensitive information. (CVE-2013-2456,
CVE-2013-2447, CVE-2013-2455, CVE-2013-2452, CVE-2013-2443, CVE-2013-2446)
It was discovered that the Hotspot component did not properly handle
out-of-memory errors. An untrusted Java application or applet could
possibly use these flaws to terminate the Java Virtual Machine.
(CVE-2013-2445)
It was discovered that the AWT component did not properly manage certain
resources and that the ObjectStreamClass of the Serialization component
did not properly handle circular references. An untrusted Java application
or applet could possibly use these flaws to cause a denial of service.
(CVE-2013-2444, CVE-2013-2450)
It was discovered that the Libraries component contained certain errors
related to XML security and the class loader. A remote attacker could
possibly exploit these flaws to bypass intended security mechanisms or
disclose potentially sensitive information and cause a denial of service.
(CVE-2013-2407, CVE-2013-2461)
It was discovered that JConsole did not properly inform the user when
establishing an SSL connection failed. An attacker could exploit this flaw
to gain access to potentially sensitive information. (CVE-2013-2412)
It was discovered that GnomeFileTypeDetector did not check for read
permissions when accessing files. An untrusted Java application or applet
could possibly use this flaw to disclose potentially sensitive information.
(CVE-2013-2449)
It was found that documentation generated by Javadoc was vulnerable to a
frame injection attack. If such documentation was accessible over a
network, and a remote attacker could trick a user into visiting a
specially-crafted URL, it would lead to arbitrary web content being
displayed next to the documentation. This could be used to perform a
phishing attack by providing frame content that spoofed a login form on
the site hosting the vulnerable documentation. (CVE-2013-1571)
It was discovered that the 2D component created shared memory segments with
insecure permissions. A local attacker could use this flaw to read or write
to the shared memory segment. (CVE-2013-1500) |
| Alerts: |
|
Comments (none posted)
java-1.7.0-oracle: multiple unspecified vulnerabilities
| Package(s): | java-1.7.0-oracle |
CVE #(s): | CVE-2013-2400
CVE-2013-2437
CVE-2013-2442
CVE-2013-2451
CVE-2013-2462
CVE-2013-2464
CVE-2013-2466
CVE-2013-2468
CVE-2013-3744
|
| Created: | June 20, 2013 |
Updated: | July 31, 2013 |
| Description: |
From the Red Hat advisory:
975757 - CVE-2013-2464 Oracle JDK: unspecified vulnerability fixed in 7u25 (2D)
975761 - CVE-2013-2468 Oracle JDK: unspecified vulnerability fixed in 7u25 (Deployment)
975764 - CVE-2013-2466 Oracle JDK: unspecified vulnerability fixed in 7u25 (Deployment)
975769 - CVE-2013-2462 Oracle JDK: unspecified vulnerability fixed in 7u25 (Deployment)
975770 - CVE-2013-2442 Oracle JDK: unspecified vulnerability fixed in 7u25 (Deployment)
975773 - CVE-2013-2437 Oracle JDK: unspecified vulnerability fixed in 7u25 (Deployment)
975774 - CVE-2013-2400 Oracle JDK: unspecified vulnerability fixed in 7u25 (Deployment)
975775 - CVE-2013-3744 Oracle JDK: unspecified vulnerability fixed in 7u25 (Deployment)
|
| Alerts: |
|
Comments (none posted)
kfreebsd-9: privilege escalation
| Package(s): | kfreebsd-9 |
CVE #(s): | CVE-2013-2171
|
| Created: | June 26, 2013 |
Updated: | June 26, 2013 |
| Description: |
From the Debian advisory:
Konstantin Belousov and Alan Cox discovered that insufficient permission
checks in the memory management of the FreeBSD kernel could lead to
privilege escalation. |
| Alerts: |
|
Comments (none posted)
mozilla: multiple vulnerabilities
| Package(s): | firefox thunderbird seamonkey |
CVE #(s): | CVE-2013-1682
CVE-2013-1684
CVE-2013-1685
CVE-2013-1686
CVE-2013-1687
CVE-2013-1690
CVE-2013-1692
CVE-2013-1693
CVE-2013-1694
CVE-2013-1697
|
| Created: | June 26, 2013 |
Updated: | July 23, 2013 |
| Description: |
From the CVE entries:
Multiple unspecified vulnerabilities in the browser engine in Mozilla Firefox before 22.0, Firefox ESR 17.x before 17.0.7, Thunderbird before 17.0.7, and Thunderbird ESR 17.x before 17.0.7 allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via unknown vectors. (CVE-2013-1682)
Use-after-free vulnerability in the mozilla::dom::HTMLMediaElement::LookupMediaElementURITable function in Mozilla Firefox before 22.0, Firefox ESR 17.x before 17.0.7, Thunderbird before 17.0.7, and Thunderbird ESR 17.x before 17.0.7 allows remote attackers to execute arbitrary code or cause a denial of service (heap memory corruption) via a crafted web site. (CVE-2013-1684)
Use-after-free vulnerability in the nsIDocument::GetRootElement function in Mozilla Firefox before 22.0, Firefox ESR 17.x before 17.0.7, Thunderbird before 17.0.7, and Thunderbird ESR 17.x before 17.0.7 allows remote attackers to execute arbitrary code or cause a denial of service (heap memory corruption) via a crafted web site. (CVE-2013-1685)
Use-after-free vulnerability in the mozilla::ResetDir function in Mozilla Firefox before 22.0, Firefox ESR 17.x before 17.0.7, Thunderbird before 17.0.7, and Thunderbird ESR 17.x before 17.0.7 allows remote attackers to execute arbitrary code or cause a denial of service (heap memory corruption) via unspecified vectors. (CVE-2013-1686)
The System Only Wrapper (SOW) and Chrome Object Wrapper (COW) implementations in Mozilla Firefox before 22.0, Firefox ESR 17.x before 17.0.7, Thunderbird before 17.0.7, and Thunderbird ESR 17.x before 17.0.7 do not properly restrict XBL user-defined functions, which allows remote attackers to execute arbitrary JavaScript code with chrome privileges, or conduct cross-site scripting (XSS) attacks, via a crafted web site. (CVE-2013-1687)
Mozilla Firefox before 22.0, Firefox ESR 17.x before 17.0.7, Thunderbird before 17.0.7, and Thunderbird ESR 17.x before 17.0.7 do not properly handle onreadystatechange events in conjunction with page reloading, which allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via a crafted web site that triggers an attempt to execute data at an unmapped memory location. (CVE-2013-1690)
Mozilla Firefox before 22.0, Firefox ESR 17.x before 17.0.7, Thunderbird before 17.0.7, and Thunderbird ESR 17.x before 17.0.7 do not prevent the inclusion of body data in an XMLHttpRequest HEAD request, which makes it easier for remote attackers to conduct cross-site request forgery (CSRF) attacks via a crafted web site. (CVE-2013-1692)
The SVG filter implementation in Mozilla Firefox before 22.0, Firefox ESR 17.x before 17.0.7, Thunderbird before 17.0.7, and Thunderbird ESR 17.x before 17.0.7 allows remote attackers to read pixel values, and possibly bypass the Same Origin Policy and read text from a different domain, by observing timing differences in execution of filter code. (CVE-2013-1693)
The PreserveWrapper implementation in Mozilla Firefox before 22.0, Firefox ESR 17.x before 17.0.7, Thunderbird before 17.0.7, and Thunderbird ESR 17.x before 17.0.7 does not properly handle the lack of a wrapper, which allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code by leveraging unintended clearing of the wrapper cache's preserved-wrapper flag. (CVE-2013-1694)
The XrayWrapper implementation in Mozilla Firefox before 22.0, Firefox ESR 17.x before 17.0.7, Thunderbird before 17.0.7, and Thunderbird ESR 17.x before 17.0.7 does not properly restrict use of DefaultValue for method calls, which allows remote attackers to execute arbitrary JavaScript code with chrome privileges via a crafted web site that triggers use of a user-defined (1) toString or (2) valueOf method. (CVE-2013-1697) |
| Alerts: |
|
Comments (none posted)
mozilla: multiple vulnerabilities
| Package(s): | firefox |
CVE #(s): | CVE-2013-1683
CVE-2013-1688
CVE-2013-1695
CVE-2013-1696
CVE-2013-1698
CVE-2013-1699
|
| Created: | June 26, 2013 |
Updated: | July 3, 2013 |
| Description: |
From the CVE entries:
Multiple unspecified vulnerabilities in the browser engine in Mozilla Firefox before 22.0 allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via unknown vectors. (CVE-2013-1683)
The Profiler implementation in Mozilla Firefox before 22.0 parses untrusted data during UI rendering, which allows user-assisted remote attackers to execute arbitrary JavaScript code via a crafted web site. (CVE-2013-1688)
Mozilla Firefox before 22.0 does not properly implement certain DocShell inheritance behavior for the sandbox attribute of an IFRAME element, which allows remote attackers to bypass intended access restrictions via a FRAME element within an IFRAME element. (CVE-2013-1695)
Mozilla Firefox before 22.0 does not properly enforce the X-Frame-Options protection mechanism, which allows remote attackers to conduct clickjacking attacks via a crafted web site that uses the HTTP server push feature with multipart responses. (CVE-2013-1696)
The getUserMedia permission implementation in Mozilla Firefox before 22.0 references the URL of a top-level document instead of the URL of a specific page, which makes it easier for remote attackers to trick users into permitting camera or microphone access via a crafted web site that uses IFRAME elements. (CVE-2013-1698)
The Internationalized Domain Name (IDN) display algorithm in Mozilla Firefox before 22.0 does not properly handle the .com, .name, and .net top-level domains, which allows remote attackers to spoof the address bar via unspecified homograph characters. (CVE-2013-1699) |
| Alerts: |
|
Comments (none posted)
nagios: should be built with PIE flags
| Package(s): | nagios |
CVE #(s): | |
| Created: | June 25, 2013 |
Updated: | June 26, 2013 |
| Description: |
From the Red Hat bugzilla:
http://fedoraproject.org/wiki/Packaging:Guidelines#PIE says that "you MUST
enable the PIE compiler flags if your package has suid binaries...".
However, currently nagios is not being built with PIE flags. This is a
clear violation of the packaging guidelines.
|
| Alerts: |
|
Comments (none posted)
otrs2: privilege escalation
| Package(s): | otrs2 |
CVE #(s): | CVE-2013-4088
|
| Created: | June 20, 2013 |
Updated: | June 26, 2013 |
| Description: |
From the Debian advisory:
It was discovered that users with a valid agent login could use
crafted URLs to bypass access control restrictions and read tickets to
which they should not have access. |
| Alerts: |
|
Comments (none posted)
python-swift: code execution
| Package(s): | swift |
CVE #(s): | CVE-2013-2161
|
| Created: | June 20, 2013 |
Updated: | August 13, 2013 |
| Description: |
From the Ubuntu advisory:
Alex Gaynor discovered that Swift did not safely generate XML. An
attacker could potentially craft an account name to generate arbitrary XML
responses to trigger vulnerabilties in software parsing Swift's XML.
(CVE-2013-2161) |
| Alerts: |
|
Comments (none posted)
xen: multiple vulnerabilities
| Package(s): | xen |
CVE #(s): | CVE-2013-2194
CVE-2013-2195
CVE-2013-2196
|
| Created: | June 24, 2013 |
Updated: | June 26, 2013 |
| Description: |
From the Xen advisory:
The ELF parser used by the Xen tools to read domains' kernels and
construct domains has multiple integer overflows, pointer dereferences
based on calculations from unchecked input values, and other problems.
A malicious PV domain administrator who can specify their own kernel
can escalate their privilege to that of the domain construction tools
(i.e., normally, to control of the host).
Additionally a malicious HVM domain administrator who is able to
supply their own firmware ("hvmloader") can do likewise; however we
think this would be very unusual and it is unlikely that such
configurations exist in production systems. |
| Alerts: |
|
Comments (none posted)
Page editor: Jake Edge
Next page: Kernel development>>
