Patches, mobile devices and network equipment
The recent ‘heartbleed’ vulnerability should teach us something, and that is to pay more attention to patch processes.
A recap: this vulnerability is due to a bug in certain versions of the open source OpenSSL library, where implementation of the ‘heartbeat’ part of the TLS protocol does not include proper bounds checking. Consequently, a malicious client can effectively ask a server to dump the contents of its memory space, or a malicious server can ask for a copy of a client’s memory.
The patch is trivial (likely 1 line of code). Most organizations have been pretty good about patching their web sites. So far so good.
The challenge is that OpenSSL seems to have been embedded, over the years, in many products. This includes hardware devices such as routers and phones. This has happened both because it is free and because OpenSSL is both useful well made. I know that, in general, I would rather trust the security of OpenSSL than RSA BSAFE, as the latter has been explicitly compromised by the NSA.
The problem is that while we, as an industry, have gotten pretty good at patching servers and PCs, we have absolutely no handle on the process for patching phones, tablets, network devices and even some apps. There is no clean, standard, autonomous process for patching firmware on corporate devices – it’s a one-device-at-a-time effort. Things get worse on consumer devices: home users won’t know that they should patch or how. Phones are a problem too, because – iOS and Google Nexus devices aside – telco’s control the patch process and they are very slow to push patches to consumer devices.
So think of ‘Heartbleed’ as a call to arms to vendors: patch your products quickly and automatically, please. This should include embedded software in hardware products, operating systems and apps on phones and tablets and applications. These segments of the market need to catch up with modern operating systems, which can download and apply patches automatically.