Think Security

On 12 August, 2009, a Rocky Mountain Bank employee sent sensitive information to the wrong GMail address. The tale of how the problem was ultimately resolved is a bit long, sordid, and painful to read. A court order was issued to have Google shut down the recipient's email account long enough to delete the missent message from Google's servers, and Google was eventually allowed by the court to reactivate the unfortunate user's email account. The missent email itself, it turns out, was never actually viewed by anyone before being deleted.

CNET writer Elinor Mills asked:

• should the person who registered the e-mail address lose access to the account or have items deleted without his or her permission, particularly through no fault of their own?




• what recourse would the bank have if the data had been sent via regular mail to the wrong address?

These are important questions that lead to the very heart of the matter — the availability of privacy technologies, the implementation of good privacy protection policies, and the way most of the world is failing at both tasks. Given the easy availability of privacy technologies such as OpenPGP that can be used to prevent problems exactly like this, the only excuses that come to mind for such issues ever arising are laziness, ignorance, and incompetence.

Why do banks, utility companies, and other organizations that offer online services that deal in sensitive data not have adequate security policies in place to guard against these problems? Why do they not at least allow users to opt-in for secure messaging via standardized privacy technologies? Why does the Chase Online site for JP Morgan Chase Bank not allow its customers to limit communications containing sensitive information so that they will only occur over secure channels?

If your organization ever sends any sensitive information via plain text email (or, worse, unencrypted Webpage), it is not serious enough about privacy. Even if they are sent to the correct person, there is always the possibility that someone else eavesdropping on the network might be able to capture that sensitive data — and, conversely, even if you think you're safe because both ends of the communication are secure, your bank might have an employee who will send an email to the wrong address.

Banks and other institutions that regularly deal with sensitive financial data, or equivalently private information, should take a number of simple steps to ensure the privacy of their customers, all of which are solved by the capabilities of public key encryption protocols such as OpenPGP:

• They should stamp all emails with verifiable cryptographic signatures, so the legitimate emails can be differentiated from spam and phishing emails that spoof the source address or otherwise pretend to be something they are not.




• They should ensure that customers cannot set up access to sensitive data without either doing so in person or making use of some out-of-band, second factor authentication mechanism.




• They should ensure that customers never need to worry that any sensitive data will ever be sent — or requested — via unsecured channels such as unencrypted email.

I understand that many end users are not quite technically savvy enough to be able to make use of the cryptographic tools that already exist, but we have a chicken and egg problem here. Someone needs to start pushing things toward a better way of doing things so that others can follow. Part of the problem is that, for the majority of users, securing their communications is far from "second nature". Many of them do not even understand that plain text email is not entirely private or secure, especially when that email is stored on a third party's servers.

Still, some of us are fully aware of the implications of using plain text email, and a step in the right direction would be for organizations like our banks to offer at least an option to require all communications concerning sensitive data (anything but unpersonalized mass mailings, in other words) to be delivered only via secured channels. I should be able to click checkboxes at my bank's Website saying "Always Digitally Sign Emails" and "Always Encrypt Emails", ideally with an option I can check that says "Use OpenPGP Public Key Encryption". Go ahead and set it under an "Advanced" tab — I promise I won't be offended. Call that the opt-in advanced security option.

The default, opt-out basic security option should be that plain text emails will only tell me to go to my bank's encrypted Website and log in to receive a critically important message. The information would then still be encrypted, and while both verification and the security of the encryption might be slightly less certain, it would be a lot better than sending plain text emails with sensitive information in them for anyone with a packet sniffer to read. Make the "Use Unsecured Email" option opt-in, with plenty of disclaimers to let people know just how stupid it would be to turn off all the secure communications options.

To be fair to Chase, it does do some things correctly that many other banks do not. For instance, when signing up for a user ID at the Chase Online site, it gives you three options for out-of-band verification that you are who you say you are — an SMS text message sent to your cellphone if that is the number they have on file for you, a voice call to the telephone they have on file for you, or an email to the address they have on file for you, in each case to provide you with a one-time password to complete the sign-up process. None of these options encrypts the communication, but I suppose we should be happy with baby steps for now.

One of the more important concepts of computer security that is a function of operating system design is the concept of privilege separation.

Real privilege separation is a design decision baked into an operating system at the architectural level, as an intrinsic part of the OS rather than a feature added on later. It is that state of system behavior where the OS recognizes differences between user accounts — and between what actions they are able to perform — and is designed in such a way as to make it effectively impossible for one account to directly perform actions prohibited to it but potentially allowed for other accounts.

There are often work-arounds for privilege separation, allowing a given user account to achieve much the same effects as violating privilege separation. Examples include the (in some circles, notorious) setuid and setgid file permissions on Unix systems. These are work-arounds, however, and not true violations of privilege separation, because setting a file's setuid or setgid permission is essentially an act of delegation, where an account that already has a given privilege can delegate that privilege to other accounts under limited circumstances. This can be a very dangerous thing to do, because a process with too much flexibility in terms of what it can do on the system, when it has a setuid permission and is executable by other accounts, might end up essentially granting other privileges than those intended the user intended to grant. It is not a violation of the principle of privilege separation in the system's design because, among a given account's privileges on a standard Unix system, it has the power of delegating certain privileges to others.

Another such Unix delegation work-around is sudo, a tool developed for the purpose of granting the ability to perform specific administrative tasks to generally non-administrative user accounts. Just as with setuid and setgid permissions, sudo must be used with care to avoid accidentally granting much more power to a non-administrative user account than intended.

By contrast with Unix systems, which have intrinsic privilege separation protections designed into their architectures and provide work-arounds that can be used to allow special cases of crossing the privilege barrier when needed, there is the example of Microsoft Windows. This is an operating system originally built on a single-user model, where privilege separation was not even a meaningful concept because there was only one user account to have any privileges. Further development of the OS began to accomodate the concept of multiple user accounts over the years, with increasing ability to maintain separate user environment settings and files.

Because the core architecture of the system was not reworked to include privilege separation as a foundational assumption of the entire OS, privilege separation became a matter of superficial features that attempt to intercept any actions a given account attempts to perform that the MS Windows developers in Redmond, Washington have decided it should not be allowed to complete. Rather than starting from a basis of denial of permission, where everything has its realm of privilege and user accounts are limited within those realms, MS Windows starts from a basis of allowance of permission, where every user account can do everything. It then addresses privilege separation matters as the developers realize they need addressing. The primary problem with this approach is that there are, in effect, infinite possibilities for specific cases of privilege escalation, where one user account achieves the ability to accomplish something that should be reserved to a different account, without that other account's delegation of the privilege in question.

Failures of privilege separation are to blame for many of the ills of computer security today. Many viruses and worms would be stopped in their tracks if they were prevented by architectural privilege separation from infecting any files that the user account that executed the malware should not be able to touch, or from propagating itself by taking control of networking and filesystem access capabilities that the user account should not be able to control. Privilege escalation vulnerabilities allow malicious security crackers to gain administrative control of systems, so they can install rootkits and essentially do whatever they like to the software running on these systems, after having first gotten a foot in the door via what should be an unimportant network application executed by what should be an unprivileged user account.

Applications, as well as operating systems, can avail themselves of privilege separation for security purposes. For instance, an application that forks itself into several separate processes that each manage separate tasks the application must accomplish, and only allows the separate processes to communicate through controlled vectors such as network sockets, can ensure that a compromise of one part of the application will not be able to easily affect the other parts.

Many applications are designed to take advantage of an operating system's privilege separation architecture to ensure they do not pose a significant security threat to the rest of the system even if they are compromised, too. For instance, many server daemons on Unix systems need to be started by the root account to gain access to network ports and other capabilities that are typically prohibited to unprivileged user accounts. Once started, however, such daemons may "drop root", assuming the permissions of a new user account further down the privileges chain. Once it has assumed those permissions, it can only access what it delegated to itself before dropping root, and no longer has sufficient permissions to change what user account controls the process, thus ensuring it cannot escalate its own permissions up to those of the root account.

Designing software that separates privileges at an architectural level, so that a failure of some superficial feature cannot circumvent that privilege separation, and selecting software (such as OSes like FreeBSD) that implements privilege separation at an architectural level when choosing what software to use instead of selecting something that offers little or no architectural privilege separation support at all (such as OSes like MS Windows), are among the key concerns any security conscious computer user should consider. It is fundamental to not just mitigating, but often entirely preventing, much of the damage malicious security crackers currently do in the world.

The first Tuesday of November 2009 saw Sophos security community liaison Chester Wisniewski commenting in Windows 7 vulnerable to 8 out of 10 viruses on Microsoft Windows 7's UAC behavior.

It started with an ad-hoc test at SophosLabs on 22 October.

We grabbed the next 10 unique samples that arrived in the SophosLabs feed to see how well the newer, more secure version of Windows and UAC held up. Unfortunately, despite Microsoft's claims, Windows 7 disappointed just like earlier versions of Windows. The good news is that, of the freshest 10 samples that arrived, 2 would not operate correctly under Windows 7.

This should not be terribly surprising, of course. As he explained at the beginning of his report on the test, UAC was essentially the only defense on the system against the malware the researchers loaded onto the system. In addition to the two malware samples that simply were not compatible with Win7, one of them was effectively blocked by UAC.

Some of the key take-aways from Wisniewski's report are:

1. "UAC's default configuration is not effective at protecting a PC from modern malware."

   In particular, Wisniewski is picking on the fact that UAC behavior on Win7 is less draconian than on MS Windows Vista, and less prone to intruding on a smooth user experience. In Wisniewski's view, the strictness of UAC should never have been scaled back, as indicated by a quote in Computerworld US's Microsoft left Windows 7 open to hackers, says Sophos, "UAC was neutered too much by Microsoft."

   Of course, he has ignored the reasons that cutting back on the intrusiveness of UAC in Win7 may have been a good decision, even if it is slightly less likely to catch malware infections before they do harm:

   • Users who are bothered too often by nags from the OS that, in most cases, do not actually protect anyone from anything, may train the users to just hit "OK" all the time without even checking to see what they are approving.
   • Perhaps even worse than uncritically clicking "OK" on everything is the tendency many people have to just turn off UAC, because a computer whose security features make it almost unusable is little better than one that is prone to infection.
   • If UAC provided the level of security it seems to provide at first glance — akin to what you might expect from the sudo utility on Unix — "neutering" the capabilities of UAC for all users might be an unforgivable sin, regardless of the previous two points. The fact remains, though, that UAC is a superficial feature that tries to layer some user approval based security over a system whose architecture is oriented toward letting most software do whatever the heck it wants to, without a decent, foundational privilege separation scheme in sight.

2. "Lesson learned? You still need to run anti-virus on Windows 7."

   I wonder whether anyone with a lick of sense thought otherwise. It is good, of course, that the people at Sophos chose to make this demonstration of principle and share it with the world so that any security unsavvy users who read about it would hopefully be enlightened. As long as Microsoft fails to properly address the matter of actually patching any and all virus and worm exploitable vulnerabilities in a timely manner, rather than just leaving the vast majority of them to be covered over by band-aids like antivirus software and UAC, the assumption should be that MS Windows will always need antivirus software. Period.

   This is not exactly "news" to those of us who know anything about principles of security.

3. "Microsoft seems to be saying that Vista is the least ugly baby in its family."

   Unfortunately, I am not sure Microsoft is even correct in that claim. While it is true that Vista tends to be compromised and infected less often in general usage, and some of that may even be attributable to changes in the way Vista works, the statistics only show that it is less prone to infection in the general case. The general case, of course, is someone going down to Best Buy and getting some off-the-shelf laptop or desktop system, taking it home, plugging it in, and forgetting about it.

   As Wisniewski pointed out, new computers running Vista tend to have antivirus software preloaded with a free year of AV update subscription protecting them. while XP systems that have been running since 2003 or 2004 are well beyond their freshness dates for antivirus protection, and many home users never ensure continuing updates after that first year. This one fact alone could potentially account for Vista's reduction in the rate of infection as compared with XP's.

   Meanwhile, many users disagree that Vista is a less ugly baby than XP. I find that XP is more responsive and easier to configure to meet my security needs than Vista, for instance, and I am not the sort to just use the default AV software and firewall, then let protection lapse after a year. At least until Microsoft stops supporting XP with security updates, I am more confident of my MS Windows XP test system's security than I would be with an equivalent Vista system, at least for my purposes.

4. "Windows 7 users need not feel left out. They can still participate in the ZBot botnet with a side of fake anti-virus. Windows 7 is no cure for the virus blues, so be sure to bring your protection when you boot up."

   I have to wonder if, in this wrap-up to his report on the Sophos Win7 malware test, Wisniewski means to equate UAC with antivirus software. That is what it appears he means. It is not antivirus software. Unless I missed something important, even Microsoft has not made any claim that UAC is intended to be antivirus software. It is a superficial attempt to implement usable privilege separation, and to provide protection against automatically executing malware. It attempts to do this over the top of an operating system without effective privilege separation at the architectural level, and with Windows Autorun exposing its users to substantial risk from malware that takes advantage of uncritical automatic execution of foreign code.

   If you think of UAC as virus protection, you're doing it wrong. Wisniewski is right: you need separate antivirus software on MS Windows 7, just as on previous MS Windows OS releases. UAC does not in any way make your computer invulnerable, just as sudo does not make Ubuntu invulnerable. In fact, the major privilege separation benefit on Ubuntu Linux comes from the core of the Linux system itself, and sudo just opens a hopefully well-defended hole in that to make life easier for users. If Microsoft wants its Windows operating systems to have real privilege separation security, it could do worse than to learn from Ubuntu's example.

Ultimately, UAC is just a superficial, pseudo-heuristic security "feature", as currently implemented. As long as the underlying design of Microsoft Windows eschews true architectural privilege separation, it will never be more than a band-aid on a gushing wound in OS security.

It is in large part because of this fact that I find Wisniewski's criticism of Microsoft for "neutering" UAC in Win7 so ill-conceived. The security of Vista is not significantly better than that of Win7 because of any changes in UAC. To the extent it is achievable, real security with either version of MS Windows depends far more heavily on other factors, such as user behavior, firewall configuration, and good, solid update policy for the OS itself, the applications that run on it, and a lineup of hopefully high quality security software.

To the extent that making UAC's intrusions into the lives of MS Windows 7 users more gentle and less annoyingly common encourages its average home computing customers to use the feature properly, it is my opinion that Microsoft did the right thing. Those of us with a better than average understanding of security principles know that much more than UAC needs to be employed in the fight against malware infections in any case, and the change in User Account Control behavior is quite unlikely to affect us negatively anyway.

In Microsoft Windows thwarts police efforts to cut child porn author Anna Caldwell discusses Microsoft Windows 7's filesystem encryption capabilities. The teaser for the article reads:

THE much lauded latest Microsoft Windows operating system could make it harder for police to prosecute child pornography suspects, experts warn.

The experts to whom she refers in the teaser, who warn us about the evils of MS Windows 7 and how it can help child pornographers escape prosecution, include:

• Adrian McCullagh, a Queensland University of Technology "cyber-law expert"
• Hetty Johnson, a "child safety advocate"
• . . .

There are only two such experts. One of them is apparently an expert in "child safety" advocacy, which essentially translates as expertise in saying "Think of the children!" at the right volume, in the right places, and at the right times, to induce panic. Note that she is not identified as an expert in child safety in the sense of any rigorous social, psychological, biological, or technological discipline; she is an expert in advocacy and, apparently, nothing else relevant.

A bit of searching on Google will tell you what other areas of expertise line Ms. Johnson's CV. For instance, Machine Gun Keyboard reports in Censorship, self-censorship, and the chilling effect [NSFW photograph in article] that Hetty Johnson is going after photographic artist Bill Henson, trying to get his photographic art essentially banned throughout Australia. Among her tactics were strident support for both Henson and the Ros Oxley gallery that displayed his work being charged with child pornography crimes, despite the fact that Section 91H of the New South Wales Crimes Act is explicit in its definition of child pornography such that Henson's work is exempt.

If Henson were to be found in violation of the law in this case, Anne Gedde's Sleeping Angels images would be just as susceptible to criminal charges — if not more so. Think about that for a moment. Once you have finished thinking about that, think about what this says about her actual expertise in legal and technical matters relating to criminal prosecution.

You have probably already figured out that she has zero expertise in such matters. "Think of the children!" advocacy is one of those rare industries where absolutely zero understanding of the subject matter is no barrier to being called an "expert".

Dr. Adrian McCullagh of the Queensland University of Technology, on the other hand, appears to have some actual credentials. He has degrees in both computer security and legal fields. Unfortunately, his major contribution to this article about how much Microsoft "thwarts" efforts to eliminate child pornography was to call for "replication of UK laws that made it a crime to refuse to decrypt data requested by police."

Different people may have different opinions on the matter of whether or not law enforcement agencies should have unfettered access to our private data. A discussion in any depth of whether such a thing is a good idea is well beyond the scope of this article. It seems incredibly short-sighted, however, to declare what is perhaps Microsoft's only completely positive contribution to computer security in recent memory — the inclusion of strong encryption for protecting sensitive data on a filesystem — a danger to public safety.

You will find no apologies for Microsoft's failings here, but credit should be given where it is due. If Microsoft Windows 7 provides filesystem encryption capable of keeping the police from accessing it without the help of the person who wishes to keep the data secret, that means that Microsoft has finally done something right in terms of offering true security to the users of its operating systems. Sensational headlines suggesting Microsoft is intentionally aiding and abetting those who violate the safety of children are irresponsible and display a shockingly amoral disregard for security.

There is not much controversy about the importance of keeping the software on your computer up to date. If you have a computer connected to the Internet, you need to keep things updated to ensure that any vulnerabilities that have been discovered will get patched in a timely manner. You do not want to be the only person on the Internet still dealing with an image handling library vulnerability from 2007, after all.

Where things get controversial is in the area of how you handle software updates. The security experts from large corporate software vendors such as Apple and Microsoft are fairly close to unanimous in their insistence that the best way to keep security vulnerabilities patched is to turn on the automatic software updating mechanism particular to the operating system and let the vendor decide when things should be updated.

Of course, there have been many instances this decade where uncritically accepting any and all software updates could lead to rather severe problems. One of the best remembered examples of this was the deployment of Microsoft Windows XP's first Service Pack. Many system administrators remember the initial deployment of SP1 with a chill up the spine, because it caused software and hardware compatibility problems akin to those one might expect from using an MS Windows upgrade CD to move from Win98 to Win2k or ME.

In fact, I was personally bitten by this problem — not because I installed SP1, but because one of the clients for the consultancy where I worked at the time did so, in direct defiance of the advice we gave that client. The consultancy made close to a thousand dollars in billable hours off that affair, and I got paid my usual rate for the work I did, but the aggravation of solving the problem caused by a client who did not take our advice was for me at least not fully offset by the money.

We told the client "Do not install SP1 until we have had a chance to research the problems people are having with it and determine what, if any, workarounds are necessary to ensure a smooth upgrade." Within a couple of days, the client got a notification from Windows Update informing him that installing Service Pack 1 was very important, and that he should do so right away. He panicked, of course, and did so across his entire network. The effects were smooth except for one computer. He gave us a call and said "I installed SP1 on everything, and one of the computers is broken now."

The natural reaction from the boss, who handled the call, was probably not the best reaction possible. He said "This is why we told you to wait on installing SP1. I'll have my guy go over there and give it a look." The client's reaction was even worse: he panicked again, and tried to uninstall SP1 from his own computer. Being far from the most technically adept person on the planet, what he ended up doing was completely hosing up the computer on his own desk.

As a result, when he called back breathless and fearful to tell us that he tried to remove SP1 in some bizarre, really awful and bad way of doing so that I do not even recall any longer, he broke his computer. The boss sighed and told him we would be there in a few minutes, and we drove out to the client's site together. He worked on the client's computer, and I worked on the receptionist's. Luckily, there weren't any other computers negatively affected by this mess.

The problem with the receptionist's was an interesting one. The hard drive on which WinXP was installed was an SATA drive, which used an SATA controller plugged into a PCI slot. When SP1 was installed, it came with Microsoft's new driver certification checking. The next time the computer was restarted, it got as far as the initial hardware certification check, then noticed that the driver for the SATA controller was not Microsoft certified. MS Windows then unloaded the SATA controller's driver, tried to finish booting, and could no longer read the hard drive because there was no driver for the SATA controller.

Several hours later, the two computers affected by the client's inability to take good advice when it is offered were running smoothly again, at a cost of hundreds of dollars and much frustration on the parts of everyone involved (except, perhaps, the receptionist herself, who got to go home early while we worked).

Other problems for which SP1 was famous included a lot of networking software simply ceasing to work because SP1 deemed it "insecure" and many drivers and applications failing because APIs and ABIs had changed, breaking the software. This was especially common among corporate enterprise networks where a lot of custom software was used to serve specialized business needs.

While SP1 is probably the instance of uncritical application of software updates causing severe problems that is most widely remembered, it is far from the most spectacular. That prize must go to the problems surrounding the SQL Slammer worm.

About four months after people started running afoul of SP1's gotchas, the SQL Slammer worm hit the Internet hard. Nearly 75,000 computers were infected within ten minutes on 25 January 2003, and the only reason it did not spread further than it did is that its denial of service effects were so severe that it took down large networks before the worm could spread through them. The tech world was in a panic and huge chunks of the Internet went "dark", and talk of Internet-killing malware started making the rounds.

Over the ensuing months, there was a constant battle to get as many vulnerable machines as possible updated to eliminate the vulnerability SQL Slammer used to spread. It was revealed that a pair of updates issued by Microsoft months earlier actually addressed this vulnerability, and soon Microsoft and many users of Microsoft software were blaming "lazy" system administrators for failing to keep their systems updated. People surely lost jobs over this. Ironically, Microsoft itself was affected by SQL Slammer, as some of its systems were infected.

It turns out that many of those system administrators who insisted they had kept machines up to date were probably entirely innocent of any wrongdoing or laziness in this case. Certain updates from 2002, if installed in the "wrong" order, would actually result in a security patch important to eliminating the vulnerability SQL Slammer exploited being effectively neutralized. This news came out months after the initial SQL Slammer panic, to relatively little fanfare, but it was an enlightening moment for many system administrators who had previously believed that installing every Microsoft software update right away was the best way to keep security patches up to date.

The lesson to be taken from these examples of disaster caused by vendor-issued software updates is one of caution and testing. Most corporate enterprise networks have some kind of testing policy in place for Microsoft software update deployments these days, sometimes even going so far as to have entire test networks and "beta testers" within the organization whose job it is to suffer any potential ill effects of a software update before it is deployed to the rest of the network. I, for one, never recommend that anyone use Windows Automatic Updates, because you should always know what is getting installed on your computer. The much more recent incident where Microsoft made Firefox vulnerable to .NET vulnerabilities is an excellent example of what happens when you do not know what is being installed on your computer.

No other software vendor has, to my knowledge, achieved quite the scope and impact of these two software update management disasters. Still, any critical software on your computer or within your organization should be patched by software updates with care, and only after at least minimal research into the nature and effects of the update. If it is reasonable to do so, such updates should be tested before deployment to "live" systems, as well — and backups should be kept so that any changes can be undone as needed.