Mavibot: A new project to create a replacement for JDBM in the Apache Directory Server, Mavibot, just released the first milestone code for its MVCC BTree implementation. They aim to offer a faster alternative with concurrent reads and writes, transactions, bulk loads, multi-version support and in-memory BTree.
Brackets: Adobe’s web-centric open source editor Brackets is now available to preview on Linux. The editor depends on the Chromium Embedded Framework and has required work to make that deliverable on Ubuntu and Debian. Well, thats done now and preview builds – albeit missing live preview highlights, file rename and delete and extension management – are now shipping. The developers are looking for Linux/C++ hands to help round out the development.
As we previously mentioned, there have been problems with Bitcoin wallets on Android due to implementation problems with SecureRandom on Android not having enough entropy to be cryptographically useful and this has lead to Bitcoin theft. But, the problem has got worse. It was assumed by many, us included, that this was traceable to Android’s use of the broken Apache Harmony code for Secure Random.
Now though, a posting on the Android Developers blog lightly titled “Some SecureRandom Thoughts” shows that Google did pick up on the problem with the Apache Harmony code and replaced it in 4.2 with an implementation that used the system-level OpenSSL PRNG (Pseudo Random Number Generator). The only problem is that the OpenSSL PRNG wasn’t being properly initialised so was more predictable. And its not like the problem was unknown; HttpClient and java.net classes also use the OpenSSL PRNG and made sure it was seeded with values from /dev/urandom.
The posting includes an all-versions SecureRandom patch which developers can include in their code, which not only replaces the Harmony derived code on older versions but also correctly seeds the OpenSSL PRNG. Google are suggesting that anyone who uses the Java Crypto API for key or random number generation or signing update their code and “evaluate whether to regenerate” previously generated keys.
There are patches available which have been provided to Open Handset Alliance partners, so with any luck we’ll see those widely deployed by the end of the … well at some point in time at least. OHA partners time to ship patches is a PRNG all of its own.
Apparently, at least according to the code, all these bugs have been fixed in Android 4.3. That was released on July 24 before the BitCoin thefts started. Did the 4.3 changes give an attacker a clue to vulnerabilities?
Edit: Misread the code. The bugs are in 4.3 too and the patching applies to that too.
Unfortunately, Google’s ostensible public handling of the problem as a bug rather than a security vulnerability probably means we’ll never know the full story behind this problem and why Google, when changing PRNG, didn’t extensively test the consumers of that PRNG.
Basho have announced that the freshly available Riak CS 1.4’s highlight feature is better OpenStack integration. If you’ve heard of Riak but not Riak CS, CS stands for cloud storage and it basically builds on top of Riak’s capabilities to offer a highly available storage system with an S3 compatible API. Great if you want to get into the storage business or replace AWS S3 with your own systems.
With the latest release, you can now point Riak CS at the OpenStack Keystone authentication service where it can validate users and roles. The support for OpenStack, tagged as preliminary in the release notes, also includes an support for the Swift API so Riak CS can take the place of OpenStack Swift storage.
There’s also some performance improvements that exploit changes made in Riak 1.4. Riak CS was open sourced earlier this year under an Apache 2 licence. Source code is available on Github, binaries and documentation on the Riak website.
Retro-vulnerabilities: Remember to do your Windows updates, because one cracker in the latest Patch Tuesday is a modern version of an old classic, the Ping of Death. MS13-065 notes pretty much all versions of Windows are affected by a denial of service when hit by an specially crafted ICMPv6 packet. Some folks are suggesting disabling IPv6 if not in use to reduce exposure to this find of flaw. Details of three critical fixes and other patches are in the Microsoft monthly advisory.
Cloud Fuel: Mirantis just updated their Fuel deployment tool for OpenStack. Fuel 3.1 now has both its web based UI and command line tools in the one package, works with Red Hat’s OpenStack Platform and is able to run a health check on deployments. The Red Hat support was expected, what with Red Hat investing in Mirantis.
Yes, but no. GoDaddy didn’t swap Apache Web Server out for IIS resulting in the 5% drop observed by Netcraft and reported as a blow for the Apache Web Server elsewhere. As Netcraft say, the switch was from Apache Traffic Server (ATS), acting as a proxy, over to proxying with Microsoft IIS 7.5. When GoDaddy turned the Apache Traffic Server proxy on in May, after apparently testing it with content delivery networks in the previous months, 28.3 million sites appeared to be using ATS, numbers that were added to the Apache total, despite it not being Apache Web Server. This also made GoDaddy the operator of 99% of the ATS served sites out there. GoDaddy have yet to comment on why they switched to IIS 7.5.
The Apache Web Server numbers do appear to be trending down, but in 2009 it was at the same 47% share in raw hostname counting before rocketing back up. The raw hostname count and share is an interesting figure, but it’s counting a lot of dead ended sites managed by registration companies like GoDaddy and other services which use a proxy server to help front-end millions of sites behind them. This is why the graph flip-flops around like it does; one change in configuration at a major user of their proxy and boom, there’s a couple of million hosts just changed server. So deriving a proxy market share while counting these proxies is going to have a margin of error of “oodles”.
Back over in the working would though, Apache still holds 54% of active sites in the survey (number 2 is Microsoft with 15%) and 57% share in the top million (number 2 there is nginx at 15%). These numbers are better indicators, as they exclude the dead zones of the web, but they still count proxies. When reading these number, keep that in mind.
Google has announced that it has past the $2 million mark in the total number of security rewards it has paid out. Thats a million for its Chrome/Chromium/Pwnium bug hunt and a million for its lower profile web application security programme. The former programme has been, predominantly, the headline grabber with headlines galore when the various cracking competitions kick off, but its the money paid out to the web application security programme which is more interesting as it demonstrates that a web surface is a rich seam of vulnerabilities waiting to be mined.
That should provide a wake up call for web application developers outside Google – if Google’s seams are that rich, how many vulnerabilities do you have in your own code. Don’t panic over it though, start engineering in better processes to check and test, and this about rewarding responsibly disclosed vulnerabilities yourself, if you can afford it. In the comments, Google’s Eric Grosse says that $2M is “very reasonable compared to the security value received” but does note that anyone planning reward programmes will need a well-staffed internal security team to triage and act. He also suggests that top reporters on such programmes would make top candidates for such a team.
But also remember, just because these programmes exist, like a gun amnesty only some of the guns get handed in. There are companies who will happily stockpile vulnerabilities for sale to government agencies, for example, and for the really good holes, they do pay well. That Google are upping their rewards again, by up to 5 times for Chrome/Chromium bugs, vividly indicates there is a market at work.