The Case of the Insecure Security Software
A little over a year ago I set out to determine exactly why, prior to Window Vista, the Power Users security group was considered by most to be the equivalent of the Administrators group. I knew the answer lay in the fact that default Windows permissions allow the group to modify specific Registry keys and files that enable members of the group to elevate their privileges to that of the Local System or Administrators group, but I didn’t know of any concrete examples. I could have manually investigated the security on every file, directory and Registry key, but instead decided to write a utility, AccessChk, that would answer questions like this automatically. AccessChk quickly showed me directories, files, keys, and even Windows services written by third parties, that Power Users could modify to cause an elevation of privilege. I posted my findings in my blog post The Power in Power Users.
Since the posting, AccessChk has grown in popularity as a system security auditing tool that helps identify weak permissions problems. I’ve recently received requests from groups within Microsoft and elsewhere to extend its coverage of securable objects analyzed to include the Object Manager namespace (which stores named mutexes, semaphores and memory-mapped files), the Service Control Manager, and named pipes.
When I revisited the tool to add this support, I reran some of the same queries I had performed when I wrote the blog post, like seeing what system-global objects the Everyone and Users groups can modify. The ability to change those objects almost always indicates the ability for unprivileged users to compromise other accounts, elevate to system or administrative privilege, or prevent services or programs run by the system or other users from functioning. For example, if an unprivileged user can change an executable in the %programfiles% directory they might be able to cause another user to execute their code. Some applications include Windows services, so if a user could change the service executable they could obtain system privileges.
These local elevation-of-privilege and denial-of-service holes are unimportant on single-user systems where the user is an administrator, but on systems where a user expects to be secure when running as a standard user (like Windows Vista), and on shared computers like a family PCs that have unprivileged accounts, Terminal Server systems, and kiosk computers, they break down the security boundaries that Windows provides to separate unprivileged users from each other and from the system.
In my testing I executed AccessChk commands to look for potential security issues in each of the namespaces it supports. In the commands below, the -s option has AccessChk recurse a namespace, -w has it list only the objects for which the specified group – Everyone in the examples – has write access, and -u directs AccessChk to not report errors when it can’t query objects for which your account lacks permissions. The other switches indicate what namespace to examine, where the default is the file system.
File system: accesschk everyone -wsu “%programfiles%”
File system: accesschk everyone -wsu “%systemroot%”
Registry: accesschk everyone -kwsu hklm
Processes: accesschk everyone -pwu *
Named Objects: accesschk everyone -owu basenamedobjects
Services: accesschk everyone -cwu *
I ran similar commands looking for write access from the Authenticated Users and Users groups. An output line, which looks like “RW C:Program FilesVendor”, reveals a probable security flaw.
To my surprise and dismay, I found security holes in several namespaces. The security settings on one application’s global synchronization and memory mapping objects, as well as on its installation directory, allow unprivileged users to effectively shut off the application, corrupt its configuration files, and replace its executables to elevate to Local System privileges. What application has such grossly insecure permissions? Ironically, that of a top-tier security vendor.
For instance, AccessChk showed output that indicated the Users group has write access to the application’s configuration directory (note that names have been changed):
RW C:Program FilesSecurityVendorConfig
RW C:Program Files SecurityVendorConfigscanmaster.db
RW C:Program Files SecurityVendorConfigrealtimemaster.db
…
Because Malware would run in the Users group, it could modify the configuration data or create its own version and prevent the security software from changing it. It could also watch for dynamic updates to the files and reset their contents.
For the object namespace, it reported output lines like this:
RW [Section] basenamedobjects12345678-abcd-1234-cdef-123456789abc
RW [Mutant] basenamedobjects87654321-cdab-3124-efcd-6789abc12345
…
I executed handle searches in Process Explorer to determine which processes had these objects open and it reported those of the security software. Sections represent shared memory so it was likely that the security agent, running in user login sessions, was using it to communicate data to the security software’s service process that was running in the Local System account. Malware could therefore modify the contents of the memory, possibly triggering a bug in the service to that might allow the malware to obtain administrative rights. At the minimum it could manipulate the data to foil the communication.
“Mutant” is the internal name for Windows mutexes, and the security software’s service was using the mutex for synchronization. That means that malware could acquire the mutex and block forward progress by the service. There were more than few of these objects with wide-open security that could potentially be used to compromise or disable the security software.
In the wake of my discovery, I analyzed the rest of my systems, as well as trial versions of other popular security, game, ISP and consumer applications. A number of the most popular in each category had problems similar to those of the security software installed on my development system. I felt like I was shining a flashlight under a house and finding rotten beams where I had assumed there was a sturdy foundation. The security research community has focused its efforts uncovering local elevations via buffer overflows and unverified parameters, but has completely overlooked these obvious problems – problems often caused by the software of security ISVs, or in some cases, their own.
Why are these holes created? I can only speculate, but because allowing unprivileged groups write-access to global objects requires explicit override of secure defaults, my guess is that they are common in software that was originally written for Windows 9x or assumed a single administrative user. When faced with permissions issues that crop up when migrating to a version of Windows with security, or that occur when their software is run by standard user accounts, the software developers have taken the easy way out and essentially turned off security.
Regardless of the reason, it’s time for software vendors – especially those of security applications - to secure their software. If you discover insecure software on your system please file a bug with the publisher, and if you are a software developer please follow the guidance in "Writing Secure Code,” by Michael Howard and David LeBlanc.
Comments
Anonymous
January 01, 2003
PingBack from http://www.bufferoverflow.it/2007/06/20/trovare-punti-deboli-in-windows-con-accesschk/Anonymous
January 01, 2003
> I get lots of output for Objects on 32-bit XP, but 0 for 64-bit XP, no matter what user or group I try. Objects not working on 64-bit? That's a bug that shows up only on 64-bit XP. I'll be posting an update in the next few days that addresses it.Anonymous
January 01, 2003
Thanks for the feedback, Jody!Anonymous
January 01, 2003
PingBack from http://blog.binaryparadox.net/?p=35Anonymous
June 19, 2007
Did you only find flawed security models in third party applications or was there numerous findings in the baseline OS? I work in infrastructure for a software developer, so I'll be passing this along for consideration. Thanks as alwaysAnonymous
June 20, 2007
Thanks for the tool. I found a potential problem in a couple of minutes. I get lots of output for Objects on 32-bit XP, but 0 for 64-bit XP, no matter what user or group I try. Objects not working on 64-bit?Anonymous
June 21, 2007
D'Oh, this is about how much news? Some year-old examples: Security software from G-Data gives Everyone-FullAccess on its install directory and some registry keys. WebDrive, FTPDrive and Novell NetDrive set NULL DACLs on their service and driver. The NVidia ForceWare Driver gives Everyone-FullAccess on some keys in HKLMSYSTEM which allows a user to DoS the system by writing garbage there. Additionally, the control panel uses a shared section for no good reason. DeviceLock, at least until version 5.76.1, gave Everyone-FullAccess on DeviceHarddiskX objects if the access list contained as least one allow entry (and other totally removed any access, even to administrators). Hurray for "dd if=.C:"! I could list many more examples... @rivet: Of course in the baseline OS there are only miniscule violations, f.e. some Full and Create access in some HKCRCLSID{CLSID}, but nothing serious. Microsoft isn't dumb.Anonymous
July 03, 2007
I think that third party software not cause most of Windows crashes, but also creates very many security flaws. For example a driver creating device object (for example meant for interface with service) accessible to everyone can be very dangerous.Anonymous
July 03, 2007
The comment has been removedAnonymous
July 06, 2007
The comment has been removedAnonymous
July 09, 2007
The comment has been removedAnonymous
July 09, 2007
I love these articles, even though I have little interest in Windows; it's the technical, investigative techniques that makes for compelling reading. Thank you!Anonymous
July 12, 2007
The comment has been removedAnonymous
August 07, 2007
A common reason for lowering security on the Program Files folder for an app is that the app creates data files in that location, and limited users can't create files there so.... The reason often seems to be sheer laziness. It's too easy to use files ("myfile.txt") without any folder name, instead of a proper location with a CSIDL and too much trouble to change the app.Anonymous
February 20, 2008
The comment has been removedAnonymous
March 03, 2008
@confused_by_ms_security_model Absolutely agree!Anonymous
April 08, 2008
"simply that the security model is too complex" - anyone who can not deal with security INHERENT complexity (not so far really, in the case YOU used Visual Studio) might not be in development BUSINESS. "People cut and paste code and then go from there" - laziness was never compatible with quality and professional attitude. Let the market to pros, not hobbysts. Anyone who accepts to work in "piggest" conditions for not having another option to get a salary might be in other market but IT. Those people are the peskies who assolate the users, at all, when comes to them use their cheap stuff. Further, write a SECURE app for low price is UNREASONABLE, even foolness. Valet parking makes same money, no mental pain.