27 August 2006

Safety First

Personal computers have gone from geek hobby, to useful private tools, to ubiquitous globally-connected life repositories. Today, we're as likely to conduct finance and store memories on the PC as we are to cruise around the web - on the same PC.

That means "make it easy to use" should change to "make it easy to use safety". Yet the level of knowledge needed to use the PC is way lower than skills needed to use it safely, and IMO it borders on criminal negligence to deepen that trend. That's like making handguns lighter with less trigger pull required so that toddlers could use them "more easily".

To use a PC...

...you need to know how to press a button, click one of two mouse buttons, and familiarity with the alphabet so you can type. It's useful to know about "folders", but Vista seeks to remove even that semi-requirement. If you can click what you see, you can use the PC.

To use a PC safely...

...you need to know about file types and the levels of risk they represent, and that information is hidden from you by default. In fact, the UI that makes things "so easy" does nothing to help you assess risk, nor is it constrained to act within the risk indicators it displays.

You also need an unhealthy amount of de-spin and paranoia. Almost everything you see has to be reversed through the mirror of suspicion; "value" isn't, "free" can gouge you, "click to unsubscribe" means "don't click else you'll get more spam", and so on. The endless cynicism and lies can be damaging to the psyche, and I often wonder if usability studies into UI stress ever take this factor into account.

What we need to know

You wouldn't dream of wiring house so that it wasn't possible to know what sockets and wires were "live" or not, nor would you make firearms such that it was impossible to tell if they were loaded or not, had the safety catch on or not, or which way they were pointing.

So why do we accept computers that use the meaningless term "open" that hides what a file can do when used? Why do we use an interface that makes no distinction between what is on our PC and what is from some arbitrary system out on the 'net?

The basic things we need to know at all times are:
  • Whether a file is "code" or "data"
  • Whether something is on our PC or from outside the PC
  • Where we are in the file system
We also need to be able to rely on this information, i.e. it should not be possible for material to mis-represent itself and have the OS take risks larger than the UI implied.

As owners of our own PCs, we have the right to whatever we like with any file on our systems. We may not expect that right when we use our employer's PC at the workplace, but at home, there is no-one who should override our control.


In the old days of DOS, you had to know more to use a PC, but beyond that, all you needed to know was not to run files with names ending in .exe, .com or .bat or boot off strange disks. Hidden files weren't that hidden, and it was quite easy to manage risky files because they wouldn't be run unless triggered from one of two editable files. Only when viruses injected themselves into existing code files or boot code, did one need antivirus tools to clean up.

The first safety failure was loss of the data/code distinction, when Windows 95 hid file name extensions by default, and when MS Office applications started auto-running macros within "data" files. Windows 95 also hid hidden files, as well as where you were in the file system.

The second safety failure was when Internet Explorer 4 shell integration blurred the distinction between what was on your PC and what was not. Local material was often presented in a web-like way, while the local file browser could seamlessly display off-PC content. The new web standards also allowed web sites to spawn dialog boxes that looked as if they were part of the local system, as well as drop and run code on visitors' computers.

The third safety failure includes all mechanisms whereby code can run without user consent; from CDs that autorun when inserted, to code that gropes inside file content when all we wanted was to see a list of files, to "network services" that allow any entity on the Internet to silently initiate a machine dialog, as exploited by the Slammer, Lovesan and Sasser generations.

The fourth safety failure will be a loss of awareness as to where we are within the file system. As long as different files in different parts of the file system can present themselves as being "the same", we need to know the full and unambiguous path to a file to know which it is.


Vista tries to make computing easier by dumbing down "where things are", but makes "safe hex" as difficult as ever. File name extensions and paths are still hidden, as are hidden files and ADS. You still need to know an arcane list of file name extensions, you still need to bang the UI to actually show you these, and if anything the OS is more likely to ignore the extension when "opening" the file, acting on embedded information hidden within the file.

Just as the web enraptured Microsoft in the days of Internet Explorer 4, so "search" is enrapturing them now. Today's users may rarely type in a URL to reach a site; they are more likely to search for things via Google, and Vista brings the same "convenience" to your own PC. You're encouraged to ignore the namespace tree of locations and names, and simply type what you want so that the OS can guess what you want and "open" it for you.

The other growing risk in Vista, is that of automatic metadata processing. The converse of "any non-trivial code has bugs" is "if you want bugless code, keep it trivial". The traditional DOS directory entry is indeed trivial enough to be pretty safe, but I suspect the richer metadata embraced by NTFS is non-trivial enough to offer exploit opportunities - and that's before you factor in 3rd-party extensibility and malicious "metadata handlers".

Vista continues the trend of XP in that metadata and actual file content may be groped when you display a list of files, or when you do nothing at all (think thumbnailers, indexers etc.). If something manages to exploit these automatically-exposed surfaces, it allows loose malware files to run without any explicit integration you might detect and manage using tools such as HiJackThis or MSConfig. Removing such files may be impossible, if all possible OSs that can read the file system are also exploitable by the malicious content.


By now, we know that any code can be found to be exploitable, so that actual outcome of contact with material may bear no resemblence to what the code was supposed to do with it. Some have suggested this means we should abandon any pretence at a data/code distinction, and treat all material as if it posed the high risk of code.

IMO, that's a fatuous approach. Use of the Internet involves interaction with strangers, where identity is not only unprovable, but meaningless. That requires us to safely deal with content from arbitrary sources; only when we initiate a trust relationship (e.g. by logging in to a specific site) does identity start to mean something.

Instead, the message I take home from this is that any subsystem may need to be amputated at any time - including particular file types, irrespective of how safe they are supposed to be. For example, if .RTF files are found to be exploitable, I'd want to elevate expected risk of .RTF to that of code files until I know the risk is patched.

A pervasive awareness of exploitability dictates the following:
  • No system-initiated handling of arbitrary material
  • Strict file type discipline, i.e. abort rather than "open" any mis-labeled content
The first may be a bitter pill to swallow, as we may have come to enjoy the convenience of metahandling. However, some contexts should default to full safety rigor; mOS, "Safe Mode", content that can be expected to be hi-risk such as new drives or incoming material, and whenever the user selects "safe view" from the shell's UI.

Making safety easier

Vista tries hard in the wrong places (user rights), though that approach is becoming more appropriately tuned - but that's another subject! What we need is:

Run vs. View or Edit

Let's see the death of "open"; it means nothing, in a context where we need meaning.

First, we need to re-create a simple data vs. code distinction, and force the OS to respect this so that we as users can trust what is shown to us.

Every time material is shown to use in a context that allows us to interact with it, we should be shown whether it is code or data. It's no use hiding this as a pop-up toolbar, extra column in detail view, some peripheral text in a status bar, or requiring a right-click and Properties.

Then we need to use terms such as Run or Launch to imply code behavior, as opposed to View or Edit to imply data behavior. You could View or Edit code material too, but doing so would not run it!

It would also help to show the file type as well, so that if a type that should be "data" becomes "code" due to code exploitability, we could avoid that risk. It's important that the system derives this type information in a trivial way (i.e. no deep metadata digging) and respects it (i.e. material is always handled as the type shown).

Safe handling and context awareness

Microsoft has juggled with various "My..." concepts for a while now, but there's no safety aspect to this as yet. Indeed, Microsoft encourages you to mix arbitrary downloads and incoming attachments with your own data files, as well as recommending the storage of infectable code fiels within "My Documents" as a way of hiding them from System Restore.

What we need is a new clue; that incoming material and infectable files are not safe to treat as if they were data files, nor should they be mixed with your data files that would be restored in the case of some system melt-down. I've applied this clue for many years now, and it does make system management a lot easier.

Once you herd all incoming and risky material into one subtree, you can add safer behaviors for that subtree - such as always showing file name extensions and paths, and never digging into metadata even to display imbedded icons.

These safer behaviours can be wrapped up as a "Safe View" mode, which can then be automatically applied to other hi-risk contexts, such as when new drives are discovered, or the system is operated in Safe Mode, or when one is running the maintenance OS from DVD boot.

Change the mindset

Currently, we encourage newbies to jump in and use everything. Then we suggest to interested survivors that they learn and apply some safety tips.

Newbies may see a suggestion to turn on the firewall, install and update an antivirus scanner, and swallow patches automatically - but we don't talk about file type risks, and we encourage them to send attachments without suggesting they should avoid doing so.

IMO, the first mention of sending email to more than one recipient should explain and recommend the use of BCC:, and users who know nothing about file types or the need for meaningful descriptive message text should not be shown how to send attachments.

In other words, safety should be learned at the same time as how to do things, rather than offered as an afterthought, and it should be as easy to operate a PC safely as it is to operate it at all.

19 August 2006

The Trust Stack

Some readers will be familiar with the OSI network stack model, which helps clarify issues when troubleshooting network or connectivity problems. I propose a similar 7-layer stack for evaluating trustworthiness within Information Technology contexts.

Each layer rests on the layer below it, and cannot be effective if a lower layer fails. Conversely, if the top layer is rotten, then all they layers below are no longer relevant.


Are the goals of your vendor compatible with your own, or are they contrary to these? The adage "he who pays the piper, calls the tune" applies here; if it is not you who provide the vendor's income stream, then it's not likely to be your needs that are uppermost in the vendor's mind. Even if the vendor derives income from you, the vendor may afford to ignore your needs if you are perceived to have no choice other than to buy their product.


What is the intention of the specific thing you are evaluating? If it is intended to do something that is contrary to your interests, then at best it can be trusted only to work against your interests in the way intended.


The vendor may commit itself to policies (e.g. a privacy policy) or may be compelled to act within policies laid down by law. For example, a privacy policy may defines what the vendor would do with your data, were they to be the sole agent with access to it.


This goes about limiting who has what abilities within the system. For example, a privacy policy is meaningless if entities other than the vendor also have access to data held by their system.


This goes about the level of risk (or range of possible consequences) within the system, and whether this is constrained to user's expectations. It's no use securing access so that only trusted employees can operate the system, if the system takes greater risks than the trusted employees expect when they operate it.


This goes about whether the system acts as it was designed to do, or whether defects create opportunities for it to act completely differently. For example, a defective JPG handler can escalate the risk of handling "graphic data" to running raw code; something that bears no resemblance to what the handler was created to do.


The above six layers are top-down, though some contexts may make more sense if Policy is considered to run above Intention. The seventh layer is different; it rides next to everything else, and each instance encompases all of the other six layers.

That's because the vendor can open the system out to additional players at every level. There may be co-owners (or successive owners, e.g. after a buy-out) with different goals; different coding teams may have different intentions, different departments or legislation may stipulate different policies, and the actual code may re-use modules developed by different vendors.

In addition to problems within each of these players, problems can arise at the interface between them. In an earlier blog post, I mentioned the rule that "users know less than you think", i.e. no matter how little you expect users to understand about your product, they will understand (or care) even less. This applies not only between end-user and product, but between each coding level and the objects re-used by those coders.

Trusted Computing

Now apply these tests to the concept of "Trusted Computing". The vendor who coined the phrase derives income from us who pay for Windows, but is the monopoly provider of the OS required to run applications written for it. The stated goals and intentions of the OS are to leverage interests of certain business partners over ours via DRM; in fact, "Trusted Computing" initially meant that media corporations could "trust" user's systems to be constrained from violating corporate interests.

So already, we have problems at the top of the trust stack, especially when we look at the track record of previous behavior. We also have a top-level granularity problem; the OS vendor empowers a class of "media providers" to leverage their rights over ours.

How is this class of "media providers" bounded? Free speech requires anyone to be accepted as a provider of content, which means we're expected to trust anyone to have rights that trump our own on our own systems. Or you could constrain these powers to a small cartel of well-resourced corporations, trading freedom of expression for putative trustworthiness of computing. Given that one of the largest media corporations has already been caught dropping rootkits onto PCs from "audio" CDs, I don't have much faith there.

If you look at the problem from the bottom up, it doesn't get better - the raw materials out of which "trusted computing" is to be built, are already so failure-prone as to require regular repairs that are limited to monthly patching for convenience.

Bottom line

We already trust computing, even though evidence proves it's unworthy of trust.

When we allow software to download and apply patches without explicitly reviewing or testing these, we break the best practice of allowing no unauthorised changes to be made to the system. Why would we give blanket authorization to any patches the vendor chooses to push?

It isn't because we trust the vendor's goals and intentions, given the vendor has already been caught pushing through user-hostile code (Genuine Windows Notification) as a "critical update".

And it isn't because we trust the quality of the code, given the patches are to fix defects in the same vendor's existing production code.

It's because the code fails so often that it has become impossible to keep up with all the repairs required to fix it. In other words, we trust the system because it is so untrustworthy that we can no longer evaluate its trustworthiness, and have to trust the untrustworthy vendor instead.

Why I Avoid Norton AV

What's the most important thing about an antivirus scanner?

That it detects 97% rather than "only" 95% of malware in a test?
Nope, not even close.

That you can keep it updated?
Closer, but that isn't it either.

No; the most important thing is that it works.

Norton Antivirus, on the other hand, is deliberately designed to not work - if it "thinks" it's being used in breach of its license conditions.

A while back, I added a new step in the process of disinfecting systems; right at the end of the Bart CDR boot phase, after doing the scans and checking integration points, I rename away all Temp and "Temporary Internet Files" locations so that any missed malware running from there will be unreachable when I boot Windows for the first time.

Over the last few weeks, I noticed several PCs would start Windows with an "Activate Norton Antivirus" nag, usually as "Your trial period has expired". Norton AV would not only not run, but would also not provide access to its quarantine or logs of previous scans.

Generally, I just shrug, uninstall it as the useless PoS it has proven to be, and replace it with a decent free scanner that works. I'm not going to phone clients to query license status, ask for product keys, etc. and as I neither sell nor recommend Norton, I wouldn't bother to troubleshoot it further unless paid clock time to do so.

However, I did do a Google( Norton Activation ) and that was verrry interesting...




...as well as plenty of forum shrieks:





As usual, it's doesn't fully meet the vandor's needs even as it screws the users:


Symantec offers the following hoops to jump through...





...but why should you accept this mission? Why pay scumbags who embed commercial malware within a product ostensibly designed to help you counter malware? Tackling malware is tough enough without having to worry about whether each hidden file or hook is part of Norton's self-serving un-documented user-hostile code, or some other malware.