By now many of you have heard that Symantec released a
security advisory last Tuesday that reported its use of rootkit-like cloaking technology in its SystemWorks product. The Symantec use of rootkit-like cloaking raises the question of what exactly defines a “rootkit” and whether or not there is ever a justifiable reason to use cloaking. I’ll first describe Symantec’s cloaking and then I’ll move on to trying to answer these two questions.
SystemWorks includes a feature called Norton Protected Recycle Bin that serves as an extension of the standard Windows Recycle Bin, saving copies of deleted files that the standard Recycle Bin doesn’t capture such as those deleted by applications. The saved files store in a directory named NPROTECT that SystemWorks creates under the standard Windows Recycle Bin directory, RECYCLER, of each volume. Symantec was originally concerned that end-users might stumble across the directory, not realize its purpose, and inadvertently permanently delete the backups of their already deleted files. The cloaking therefore uses a file system filter driver to mask the presence the NPROTECT directories from Windows directory enumeration APIs.
I learned of the cloaking several months again when users of our
RootkitRevealer rootkit detection tool sent us log files asking whether their was evidence of malware (others have
posted logs in the Sysinternals forums). A little research showed that it was generally known that SystemWorks creates NPROTECT directories that show up as “false-positives” in RootkitRevealer scans.
After the Sony rootkit story died down I turned my attention to commercial use of rootkits, purchased a copy of SystemWorks and installed it. I deleted some files, ran RootkitRevealer, and verified that the NPROTECT directory was being cloaked:
On a whim I decided to see if the Symantec cloak had the same behavior as the Sony XCP rootkit. Sony’s rootkit only masked the directory from directory enumeration APIs, but allowed access to the directory if specified explicitly by name. To my amazement, Symantec’s cloak let me into the NPROTECT directory when I entered its full path into Explorer or a command prompt change-directory command. I confirmed that a security vulnerability similar to Sony’s exists in the cloaking by copying files into the directory and noting that they did not appear in the SystemWorks interface that displays the contents of the NPROTECT directories. I contacted Symantec and they quickly agreed to remove the cloaking altogether.
So does Symantec’s cloaking classify it as a rootkit? I arrived at my working definition for the word rootkit several years ago as:
Software that hides itself or other objects, such as files, processes, and Registry keys, from view of standard diagnostic, administrative, and security software. My definition is based largely on the way I’ve seen the term used by developers of cloaking technologies, including those that frequent
www.rootkit.com, the central gathering place of both cloaking and anti-cloaking developers. The only text on the subject, Hogland (founder of Rootkit.com) and Butler’s “Rootkits: Subverting the Windows Kernel”, has a definition similar to mine:
A rootkit is a set of programs and code that allows a permanent or consistent, undetectable presence on a computer.Symantec disagrees with my definition, and presumably Hogland and Butler’s, because they feel that malicious intent has been attributed with the word through general use in the media and that aspect is missing from the definition. But if we turn to the Rootkit.com community for guidance intent is also absent from their usage: Hoglund has even recently argued in
an article he posted on Rootkit.com that Sony was justified in its use of the XCP rootkit.
Despite the evidence I see to back my definition I’m willing to concede, especially after the Sony debacle, that malicious intent has been associated with the term. The security industry is just now debating a formal definition for the word so in the meantime I’ve agreed to use “rootkit-like” when discussing cloaking that’s intended to benefit the consumer rather than the software publisher (or music publisher, in the case of the Sony rootkit).
Symantec’s use of a rootkit technique is a great place to start examining the question as to whether there’s ever justifiable use of rootkit technology. I strongly believe that there is never a case for its use, and I’ve had several discussions with Dave Cutler, Senior Technical Fellow at Microsoft and the original architect of Windows NT, and he agrees unequivocally with my view.
The obvious risk rootkits present, which has been demonstrated by both Sony’s and Symantec’s implementation, is malware being able to hide beneath the cloak. Even if a vendor has ensured with certainty that that’s not possible, the cloak makes it impossible for a security administrator to ensure that the cloaked objects have correctly configured security, and if they consist of executable code, are updated with the latest security patches.
Another detrimental effect of cloaking is that it changes the way Windows operates, making it difficult or impossible for users and systems administrators to understand the behavior of modified systems and to diagnose issues that arise as a result of altered behavior. Cloaking can make it impossible to account for resource usage like disk space, memory, or CPU, to perform a complete inventory of a system, to understand incompatibilities between Windows or other software and the cloaked objects, and even to make a functional backup. As I said when originally discussing the Sony case, a cloaked driver that crashes a computer can cause a misdiagnosis of the problem and can be extremely difficult to remove or update.
If a software developer ever believes a rootkit is a necessary part of their architecture they should go back and re-architect their solution. Microsoft was faced with a predicament very similar to Symantec’s when they implemented Windows XP System Restore. Instead of cloaking the directory that stores restore points they create a directory in the root of each volume named System Volume Information and set permissions on it so that only the Local System account has access. Even power users that check the “Show hidden files and folders” and deselect “Hide protected operating system files” settings in Explorer cannot enter the directory and inadvertently delete their backup files. There are any number of non-cloaking approaches that Symantec could have chosen.
I hope that the publicity generated by the Sony and Symantec examples have sent a strong message to the software and music industries and that they follow Symantec’s lead by removing the use of rootkit techniques from their applications and avoiding them in the future.
