Cybersecurity
Microsoft fell victim (sort of) to yet another controversy when they patched up a bug in Internet Explorer, which affected all versions of Windows since – hold on to your hats – Windows 95.
Really old and undetected
Why is this surprising? The bug wasn’t discovered until earlier this year, neither by hackers nor by security experts. IBM researchers reported the bug in May, right after it had been patched. The vulnerability had been sitting in plain sight, even though many other flaws affecting the same library – Microsoft Windows Object Linking and Embedding (OLE) – had been found and patched before.
A legacy bug in a legacy code is a problem for today #protectmybiz
Tweet
Now, more attention is being paid to OLE from both sides of the cybersecurity front. In late October, iSight Partners reported the Sandworm APT group had used yet another OLE zeroday flaw (CVE2014-6352) to attack their targets. Sandworm used malicious tools codenamed BlackEnergy, which had been recently reported by Kaspersky Lab experts. Read their research here.
Technical details on two latest OLE critical flaws – CVE2014-6332 and CVE2014-6352 – are available here.
While many other OLE vulnerabilities had been exploited in the wild, including the Sandworm-associated bug, this particular 19-year-old bug was not.
You never know
What’s the take away? We may never know where new vulnerabilities will be discovered, including “potentially disastrous” ones allowing for a remote code execution.
Current users of Windows XP, which has not been supported by Microsoft since this April, remain at risk. So far there are no known exploits for it, but since the problem has only recently been publicized, they are expected shortly.
A lot of legacy code is still in use, not often reviewed #enterprisesec
Tweet
Earlier this year, two significant and old bugs had been discovered in open source software – Heartbleed and Shellshock. They were both undetected for years. Widely publicized and much discussed, they led to an increased scrutiny of the code in open source software, which revealed a few lesser publicized bugs.
Here we have a two-decades old bug in Windows, the most popular PC operating system. It was sitting in a plain sight, it was critical, and it was missed for 19 years. Amazing.
Legacy code
All together, these bugs reveal a serious problem that deserves attention: the legacy code. “Don’t touch it if it works fine,” people say, and keep using antique code for decades. Sometimes to ensure the backward compatibility, which is a sort of Gordian knot problem for the operating systems’ developers. They have to “drag along” the legacy code for old devices and software that may be still around, even though this leads to “bloating” of the OS itself. One day, they’ll do what Microsoft has done: eliminate support for older versions of software (Windows XP and earlier). But if the software is still popular, this leads to discontent from the users and the potential for large-scale security issues. It is a solution, but not necessarily a good one.
In custom business software there are loads of legacy codes. How often does it get reviewed? Custom business software was one of the primary reasons for Windows XP’s longevity in the corporate segment. You have custom software that runs in the Windows XP environment using some of its peculiarities; it may not be fully compatible or executable in Windows Vista, Windows 7 and 8, and writing a new one costs a lot. The solution for businesses? Sticking to Windows XP for as long as possible is an option. But is that really a solution or just postponing the inevitable?
At the very least, “legacy” systems such as Windows XP have to be properly protected. This is one of the reasons why we’ll still support XP in our corporate and consumer products until 2016. Hopefully it won’t be necessary afterwards.
Tips