20 October 2010

Related:

clsid-list-06.htm     CLSID Shit List 6                                October 15, 2010

CLSID Shitlist Series Beyond

A sends:

I've been looking at your CLSID shitlist series. It doesn't go far enough. There are lots of other places in a Windows system to look for bad action or clandestine stuff. Someone who's trying to keep a normal Windows system secure and non-invasive has to watch a lot more than just CLSIDs.

This is just a short note to say how I deal with controlling what software gets onto my system and how it behaves. To keep it short I'll omit all the usual advice about where to download software, what to download, what to permit in your browser, how to do a software installation under Windows, etc., and just say how I keep watch.

I audit software installations and behavior with software I wrote that tracks file system changes and registry changes. (My software doesn't detect rootkits, but I do check for them from time to time.)

For instance, I audit what file system and registry changes an installation makes; and also what changes the operational package makes. My software filters out things that definitely don't need my attention. (Who cares what's the last thing DirectX looked at?) What remains are things of interest.

Bad software often leaps out at me from these audits: anything that makes 30,000 registry changes and adds 8,000 files on C: is shit. I can see what's being added to run automatically, and where programs are keeping their parameters. I can often see a package's methods of surveillance over the user, and sometimes thwart them. It's clear how file associations are being created, or stolen from other software. It's visible how software is, possibly clandestinely, integrating itself into other software like browsers or mail agents.

I get an initial idea of whether a software package is "trustworthy" in a simple sense: are its use of the registry and the file system well considered? Does it install a lot of unused stuff? Does it rely heavily on proprietary underpinnings? Does it install elements with no apparent relation to what it claims to do? Does it provide access to its operational parameters? Are there signs in how it uses the file system and the registry that it was sloppily designed or carelessly coded? (A good user interface can hide many gross sins of design and execution.) Is it spying on me and my system? Does it, finally, represent a threat to the system's wellbeing?

My software tells me what, from installation and operation, a package leaves behind when it's deinstalled. (But see below.) This can then give me an idea of what the company has to hide. What footprint does the deinstallation leave behind? License files or files with nonsense names you're not supposed to recognize? Registry entries that a reinstallation can detect later? Or just crap that the designers were too ignorant, too careless, or too incompetent to remove? Those are significant signs.

And so on. There's software I'd honestly like to use if only it could be trusted; but from auditing its installation, operation, and deinstallation I can see that it can't be trusted. Too bad, but I'll live without it.

Obviously most people aren't willing to go to these lengths. I am, and that makes my system more reliable, leaner, more secure, and faster than similar hardware in most other people's hands. In my opinion, of course -- but in my work I've had my hands on a hell of a lot of systems. What I do is (also in my opinion) just good practice, even if it isn't much practiced. There are probably others doing the same kind of thing, but they sure don't talk or write about it much.

Here's the "see below" part. It's an essential part of my practices.

When my system is in an operative, stable, clean, infection-free state, I make an image snapshot. There are obvious benefits to having a trustworthy backup of the system in a useful condition, but here's one more: with that snapshot on hand I can experiment -- install software, check the audit logs, and decide if I want to proceed with it. If so, I work with it a while. If not, I may deinstall it just to audit the deinstallation, but in any case I can restore the system from the snapshot knowing that it contains no trace of the software I just tried. Making and checking my audit logs takes some time and attention, but restoring a system from an image snapshot is usually faster, and always cleaner and more reliable, than deinstalling software.

And knowing that I can restore the system to a reliable state gives me enormous peace of mind. I can't recommend too highly the cycle of

* establish a clean, stable, operative system

* make an image snapshot of it

* experiment to your heart's content, and when done ...

* restore the system from the snapshot

You're also permitted to restore the system from the snapshot if it becomes inoperative because -- just for instance, something many have seen -- a Windows update kills it stone cold dead. Or some software shows new and undesirable behavior.

One final note here, in case some noob thinks you can accomplish the same ends using Windows "System Restore": you can't. Someone who disagrees with me on this has my best wishes. He's going to need them.