ISVs Avoid Windows Security Measures

In June, security research firm Secunia released a report entitled “DEP/ASLR Implementation Progress In Popular Third-party Windows Applications,” examining adoption rates among third-party application developers of the exploit avoidance technologies built into Windows. Not surprisingly, adoption was fairly low given the stated ease of their implementation.  

The report (PDF) looked at 16 popular third-party Windows applications (including application frameworks such as Adobe Flash and Java, browsers such as Firefox, Opera and Google Chrome, and standalone programs such as Adobe Reader or Apple iTunes), examining their adoption of Microsoft’s advanced security measures over the course of 26 months (from May 2008 to June 2010). In the end, the report found developer adoption of both DEP (Data Execution Prevention) and ASLR (Address Space Layout Randomization)—in both Windows XP SP3 and Windows 7/Vista—was slowly increasing over time but was hardly pervasive. 

Secunia’s findings come as no surprise, as I’ve complained about the lack of developer adoption of Microsoft’s newer security strictures in the past, albeit focused more on user rights and UAC (User Account Control). For my most rancorous quote in that post, I wrote, “It’s bad code, written by lazy, hurried or unconcerned developers adhering to development standards 10 years in the rear view mirror.” However, in hindsight I regret using the word “lazy,” as I’ve found myself in the time since mightily impressed with the lengths some ISVs have gone to not only ensure their applications work with limited rights but that actually circumvent or subvert Microsoft’s controls altogether. 

Since Microsoft released Windows 7 RTM almost a year ago, I’ve been operating my primary system with limited user rights, supplemented with an AppLocker rule set that only allows me to run programs stored within the Windows or Program Files directories. This habit has proven most effective at providing insight into programs running from non-typical locations of the file system, places where the applications can be written and updated regardless of the user’s local rights under normal operating conditions.

For instance, Google Chrome bypasses UAC entirely by installing itself within the AppData folder within the user’s profile—allowing Google to advertise the app for those without local admin rights. This workaround means Chrome needs to be installed separately for each user on a shared system, of course. Administrators who wish to add Chrome to their corporate build instead need to install Chrome using the Google Pack to extend the program to all local users by installing it in the Windows Program Files directory.

Likewise, WebEx runs from a non-standard location, the C:\ProgramData\ directory. A throwback to a simpler time, the ProgramData directory is a rare bastion of open write permissions in the base of the Windows 7 system drive, allowing non-admin users to write temp data—or programs—to disk. WebEx developers freely acknowledge they use that location because most of their users don’t have permission to write to the Program Files directory.

My award for the trickiest UAC workaround, however, goes to Lenovo for their ThinkVantage System Update tool for Thinkpad laptops. When first installed, System Update creates an always-on service that auto-starts at system boot.  When the System Update application is subsequently started by a limited rights user, the service dynamically generates a new user account on the local system with administrative rights (with random names like wostbqwyajHCZJEKNDQ), and the application’s tvsukernel.exe process runs as that user.  

Lenovo representatives inform me that this account’s “only purpose is to avoid multiple UAC prompts during installation and is cleaned up afterwards.” Although the account apparently has no password, I was not able to log in to the system interactively with it. 

ISVs commonly focus on their application’s features and functions, with system security often taking a backseat priority. Mostly, ISVs just want it to work, by hook or by crook. If and when security problems come to light due to their freewheeling approach—well, it can be fixed at that time.