Yesterday Microsoft confirmed that every 32-bit version of Windows over the past 17 years, from Windows 7 all the back to Windows NT 3.1 (extra credit to any readers remember that OS) is host to a vulnerability that could allow hackers to take over a system. If this tells us one thing, it's that it's time to drop all the legacy support baggage that's buried in Windows.
Many of the affected operating systems are now part of history and have no place on a web-facing PC, but the list of affected OSes still includes:
- Microsoft Windows 2000 Service Pack 4
- Windows XP Service Pack 2 and Windows XP Service Pack 3
- Windows Server 2003 Service Pack 2
- Windows Vista, Windows Vista Service Pack 1, and Windows Vista Service Pack 2
- Windows Server 2008 for 32-bit Systems and Windows Server 2008 for 32-bit Systems Service Pack 2
- Windows 7 for 32-bit Systems
The vulnerability lies in the Windows Virtual DOS Machine (VDM) subsystem, a mechanism added to Windows NT 3.1 back in 1993 to allow it to run DOS applications and 16-bit Windows software. And there it's been, for 17 years.
OK, vulnerabilities exist, they're a fact of life. But do we really want our 21st century OS riddled with legacy code, especially code that seems functionally unchanged for so long? Ridding OS of legacy (or at the very least, making the installing of such legacy support an option) reduced the attack surface that the OS presents to the bad guys. Reduce that attack surface by getting rid of stuff that's no longer needed, and you make the OS safer.
Another point worth noting is that Google engineer Tavis Ormandy only posted details of this vulnerability to the Full Disclosures security email list on the 19th of January after disclosing it to Microsoft over seven months ago. This disclosure also shows that Microsoft needs to be more responsive when it comes to fixing vulnerabilities disclosed to them. The world's largest software vendor shouldn't need to take so long to process and fix vulnerabilities.
While we wait for a patch, Microsoft has posted workarounds for this vulnerability, which involves disabling NTVDM support.