App security wall of shame

A few columns ago I mentioned that 70 to 90 percent of all current malware threats would fail to work if the end-user executing them did not belong to the local administrators group (or, in Linux/Unix, were not running the application or process in the root context).

With some expected exceptions, such as running a network protocol sniffer in promiscuous mode, Linux/Unix doesn’t require root permissions to install or run most programs. The problem is definitely much worse in Microsoft Windows.

And the problem has deep roots: Early on, Microsoft didn’t emphasize enough the importance of end-users not being logged in as administrators all the time. In fact, while installing Windows XP in a nondomain mode, all user accounts made will be administrators by default. For at least the past five years, however, Microsoft has tried to communicate to end-users that they should be logged in as administrators only when administrative tasks need to be performed. The average network administrator still spends 50 percent of the time answering e-mail and surfing the Web -- tasks that normally do not require admin permissions.

Windows 2000 introduced the RunAs feature, which allows all users to be logged in with lower privileged accounts, and then allows them to run programs on-the-fly with admin privileges, if needed. Running these programs can be accomplished at the command line by right-clicking an executable or by modifying the program shortcut.

Unfortunately, the RunAs command isn’t a panacea. It only works about 90 percent of the time. Getting Windows Explorer to run within RunAs, as might be needed to modify NTFS permissions, is especially difficult.

Microsoft plans to make amends with Windows Vista. Vista contains many features that will make the process of running most programs in a lower privilege context easier and, even better, will make this the default choice.

For one, Vista will run most applications with limited permissions, even if the user is currently logged in with admin privileges. When users attempt to perform administrative tasks, Vista will ask the end-user to confirm their intentions and provide administrative credentials. Of course, this feature can be controlled by group policy. Vista requires that vendors create new configuration files to take full advantage of the new feature and minimize customer involvement.

And therein lies the rub. Thousands of vendors use incredibly poor programming practices today, and there is no reason to believe that they will suddenly change. Despite tons of documentation and a half-decade of enlightenment, too many vendors still require that end-users be administrators to run their programs. With few exceptions, no program needs administrator access to run -- the coders are just lazy or haven’t been trained in secure coding techniques. These vendors obviously don’t care enough about their customers.

Any Windows administrator who has tried to force all users to be logged in as nonadministrators can quickly rattle off all the programs in his or her environment that must be run in administrative context. It’s deplorable. It’s a shame.

In fact, I want to out on a wall of shame any vendor with a program that requires administrative access to run. Last week, I asked readers to send me their lists of abysmal apps, and I received dozens of tips.