Tag Archives: Core Infrastructure Initiative

Google offers financial and technical support to open source projects

Early last week Google shared their results after beginning a project to fuzz (defined) test open source software (defined). Their project is currently processing 10 trillion test cases per day. Open source projects involved in this initiative include GNUTLS, BoringSSL, FFMpeg, JSON, Libpng, LibreOffice, LibSSH, OpenSSL and Wireshark (among many well-known others).

What is the purpose of their project?
The purpose of fuzzing is to repeatedly and thoroughly test how robust/secure the code of the enrolled open source projects is. More than 1000 bugs have found so far (approximately 264 of which were potential security vulnerabilities).

As Google points out, this also helps to increase the reliability of the software being created since regressions (defined) are fixed within hours before they ever affect a user. Another aspect of this is other software bugs e.g. logic errors can be detected and corrected sooner.

In return for a project signing up to this initiative, Google have pledged to provide extra funding:

  1. $1,000 USD for initial integration of the OSS-Fuzz tests into their development process
  2. Up to $20,000 USD for ideal integration (an itemised list of how this figure is obtained is detailed here).

How this project become to be developed?
I have mentioned the Core Infrastructure Initiative (CII) on this blog before. This fuzzing project was created with assistance from the CII to benefit projects critical to the global IT infrastructure. This project is in progress alongside Project Wycheproof (with its objective to strengthen cryptographic implementations by having new implementations pass a series of tests to verify they are not affected by these particular implementation issues being checked for).

How does this project help the wider industry/community?
With projects such as those mentioned above used by large corporations, small business and consumers alike; the regular feature/security updates we all receive make these projects more stable and secure than they otherwise would be. The outcomes will be very similar to that of Pwn2Own.

With these benefits for the projects as well as all of their users, I hope projects such as this continue and expand in scope as time progresses.

Thank you.

OpenSSL Releases Security Updates

Yesterday the OpenSSL project made available updates for version 1.0.2c and 1.0.1o of its OpenSSL cryptographic library. The updates bring the version numbers up to 1.0.2d and 1.0.1p respectively. These updates resolve a critical issue that was introduced inadvertently in the June 2015 security updates for the above mentioned OpenSSL branches.

The security issue CVE-2015-1793 (definition of the term CVE) involves a check by the OpenSSL library to verify the authenticity of TLS certificates. If the first attempt to locate a certificate validation chain is not successful the code will look elsewhere to verify authenticity and it is a bug in how this alternative certificate validation chain is verified where this security issue could occur.

If an attacker could convince you to visit a malicious website, this website could be signed using a fake certificate but due to this bug in OpenSSL this fake certificate would appear to be legitimate and thus would not cause any suspicion (namely that the green padlock icon would still appear in your web browser). This malicious website could be used in a phishing attack to make a fake site appear like the real site it’s impersonating and thus you may be inclined to enter your login credentials for the legitimate site but actually be providing these details to a person with malicious intent. For this attack to occur, the attacker must already be on the network path between the client and the server i.e. a man in the middle attack (MITM, MITM defined) thus reducing this attacks feasibility.

How can I protect myself from this issue?
If you don’t manage a web server/website that uses the OpenSSL library you are not affected by this issue. Web browsers such as Mozilla Firefox, Google Chrome, Apple Safari and Internet Explorer are not affected by this issue since they don’t use OpenSSL. In addition, where 2 servers running OpenSSL communicate with each other they are not affected by this issue (this issue occurs only in a client and server interaction and not server to server).

Google Chrome since version 38 actually uses a custom code fork of OpenSSL known as BoringSSL. The OpenSSL project attributed the discovery of the security updates being discussed in this post to the BoringSSL team. Further information on BoringSSL is available in this blog post.

For any server that you manage that uses OpenSSL, please update your OpenSSL installations to 1.0.1p or 1.0.2d (as appropriate). FTP mirrors to obtain the necessary downloads are available from here. Downloadable Tarballs (compressed/packaged code made for distribution) are available from here. It should also be possible to use the package manager of a Linux/Unix operating system to update your OpenSSL installation.

OpenSSL also took the opportunity to re-iterate that versions 1.0.0 and 0.9.8 will cease to receive security updates from the 31st of December 2015. Users of these versions should upgrade before this deadline.

We can expect many more of these updates from OpenSSL as the year progresses. This is good news since everyone that uses OpenSSL (either on their web server or within their software) benefits from the fixes that are released. The frequency of updates has increased since the OpenSSL project received funding last year from the Core Infrastructure Initiative which supports critical open source projects upon which the internet and the global information infrastructure relies on. In addition, an audit and code clean up of the OpenSSL project is taking place which should also improve the projects security and long term stability/maintainability.

Thank you.