Snippets: Mavibot, Brackets and Tessel


  • 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.
  • Tessel.js: Latest in the “tiny boards that can” is Tessel, an 180MHz Cortex-M3 device with 32MB of RAM and 32MB of Flash, Wi-Fi, 16 pins of GPIO and running off micro-USB or battery power. It’s claim to fame is it’s programmed using JavaScript; we assume a fairly close to the hardware interpreter with minimal OS as it also supports “1000’s of Node.js modules from NPM”. There’s Tessel modules to extend it and it can be connected to Arduino shields too. No price or dates yet but one to keep an eye on as they say they are launching soon.

Meteor framework burns brighter


Meteor is a very clever Node/JavaScript framework which I will admit to have been using in the recent past. It allows developers to create live updating, multiple screen apps without having to delve too much into the required magic of how the data gets from A to B,C and D – check out the screencasts and examples for a better idea. Now the developers have announced the latest update, version 0.6.5, which has added some very useful features that will make building larger, more complex applications easier. First new feature is a namespacing system which gives each module or package its own namespace and automagically wraps them to stop them clashing. This works in the server or browser and makes life easier of package writers who don’t need to worry about butting heads with other package writers.

Second highlight feature is the components of standard apps are now visible in the packaging systems as “standard-app-packages” and developers can remove them as needed. One example would be removing the web server so you can write lean command-line tools or daemons. Third up, full support for source maps which means that when there’s an error with say CoffeeScript code (which is turned into JavaScript and goes through various manipulations before it hits the browser or server), then the error will, using the source map, point to where it went wrong in the CoffeeScript source, not to the JavaScript code it became. Fourth feature on the list is simple support for server-side data files. Full details of these and the many other changes in the release notes. Meteor is open sourced under an MIT licence.

Android SecureRandom: It gets worse


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 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.

Riak CS 1.4 plugs into OpenStack

riak-cs-logo2Basho 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.

Snippets: Firefox tools, Ping’o’death and Cloud Fuel


  • Firefox sharpens tools: Mozilla just detailed the new developer features for Firefox 25, just going into alpha/aurora. The ability to “black box” common libraries so that they are no longer in the stack trace, an option to edit and resend network requests in the network monitor, CSS autocompletion in the inspector (hussah!), in-frame Javascript execution and profile data import and export. Set your timers, in 12 weeks these will be in stable Firefox.
  • 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.

Proxies from Proxies: Did Apache really lose 5% web server share?

ApacheFeather150Yes, 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.

Money for null things – Google hits $2million in security rewards

Google logo 120

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.