About "Backdoors" ...

Again, inspired by the PGP WDE Bypass Issue ...

I am not the only one in the world that uses the term "backdoor" in a generic, non-cryptographic, opposite of your-favorite-national-security-or-mafia-organization-is-going-to-get-you sort of way.

Here are several sources that are considered (at least somewhat) reputable:

Princeton's Wordnet:

"an undocumented way to get access to a computer system or the data it contains"

Wikipedia (supposedly the opinion of the general public, mind you)

"A backdoor in a computer system (or cryptosystem or algorithm) is a method of bypassing normal authentication, securing remote access to a computer, obtaining covert access to plaintext, and so on, while attempting to remain undetected. The backdoor may take the form of an installed program (e.g., Back Orifice), or could be a modification to an existing program and/or hardware device."

Search Security/Tech Target:

"A back door is a means of access to a computer program that bypasses security mechanisms."

F-Secure (in the context of malware):

"Backdoors are remote administration utilities that open infected machines to external control via the Internet or a local network."

Albany University's Information Security glossary:

"Normally installed by a virus or worm, a backdoor is a alternate method of accessing a system."

The Net Guy (whoever that is-- Google had his definition):

"A means of access to a computer system that bypasses security mechanisms, installed sometimes by an authorized person, sometimes by an attacker. Often installed by programs called Trojans horse programs."

And one of my favorite ones, in light of everything recently:

"Also called a trapdoor. An undocumented way of gaining access to a program, online service or an entire computer system. The backdoor is written by the programmer who creates the code for the program. It is often only known by the programmer. A backdoor is a potential security risk."

Search for yourself. While the use of the term may have prompted a media over-hype, I was not out of line in my word usage. [I removed the term from the parent post anyway, because I do not wish any harm to PGP as a company.] Rarely, if ever, is "backdoor" synonymous with paranoia surrounding an agency having access to your private keys, except ... perhaps ... maybe in a slashdot thread.


UPDATED: Adobe's PDF vulnerability is a current event that illustrates how other people in the "security community" use the word "backdoor" beyond just mathematical-cryptographic access control bypasses.

PGP's Publicized Documentation of WDE Bypass

John Dasher, Director of Product Management at PGP, commented with a link to PGP's documentation on the WDE Bypass Feature. I thought it pertinent to raise John's comment, especially with this at the end of that page:

"We appreciate and are thankful for open dialog between us, our customers, and even our critics. This discourse always helps us improve our process, our products, and the standards on which they’re based."

I cannot agree more with that comment from John.

More on the PGP issue

There have been several comments regarding the PGP whole disk encryption bypass issue and in the process a few people have brought up the question that my discussion of them is exactly what I have preached against with "insecurity researchers"; however, I want to clear a few things up.

Yes, I wrote:

"So, let's see if we can figure out the economic process ...
1. Find some vulnerability in some widely used product.
2. Create a proof-of-concept and publish it to the world (preferably before sharing it with the vendor).
3. Use FUD (Fear, Uncertainty, and Doubt) to sell the services of a security consultancy startup.
4. Profit!"

But this PGP issue is not insecurity research:

1. It is not a vulnerability; it's a problem in the design. It's not a coding bug; it's a "dangerous" approach to solving a problem. And if that doesn't convince you that this is not a vulnerability, even PGP thinks there's no problem.
2. There's no proof-of-concept. There's a threat model, sure, but that's not a POC. There's no exploit code, there's only paradigms of attack/defense. I think that will even pass the Ranum test.
3. If you think this is FUD, I apologize. I obviously do not. However, please note, there are no services being sold, no ads on the pages hosting this content, nor in the feeds, etc. There's zero royalty going to me. I'm not even using a real name to take credit. I just want to discuss paradigms of attack/defense and intricately examine and evaluate what some might call an academic-only exercise. Extended readership is nice, but not the intention here.
4. See #3 -- no profit here.

For the record ... I did discuss this (in the real world) with the vendor. They said the documentation level was fine, and even wanted to close my support ticket before actually adding the KB article that was available for current customers only, which is now accessible here. I asked for them to send a notice to current customers, but they decided there was no warrant for that. I even asked to escalate my support ticket more than once.

I still have respect for the vendor and I encourage others to evaluate all solutions thoroughly regardless of this or anything else. The bottom line is that customers (current and potential) have the right to know their risks ahead of time-- they should not have to buy consultants/professional services time to become aware of a feature like this. It should just be well known. Jon Callas has a thorough track record of proven expertise and his opinion is very valid, just like my (somewhat opposing) view is valid.

I do also wish everyone to understand that "backdoor" has controversy-- I never intended this to mean a backdoor that law enforcement, etc., could use. It's not a cryptographic backdoor; it's a backdoor in the historical sense-- as in there's a way to get unauthorized access.

Yes, the Trojan possibilities seem absurd because malware could do more. What isn't discussed, though, is that malware doing this in addition to the other things it does leaving workstations in a wholesale bypass state so that any less sophisticated smash/grab thief can have access is still a possibility. It would be more than a nuisance to an enterprise IT shop, whether you think somebody would take the time to do it or not.

And, of course, there's the timing attack: grabbing the machine when it shuts down, but before it comes back up. That's the risk that is barely documented--not discoverable by 99+% of current and potential customers. That's the point. If you read into anything else beyond, then you're missing the idea.

Response to Jon Callas - continued #2

This is the continuation of my response to Jon Callas regarding the PGP Whole Disk Encryption bypass.

I can appreciate the problems inherent in managing distributed computers while still protecting the confidentiality and integrity of the data contained within them. I understand there is often the need to do maintenance on machines in-mass.

However, what I do not understand is the classification of machines that would have both physical access control needs (hence the PGP Whole Disk Encryption) and the immediate availability without a human nearby. Here's the rough categories/scenarios I can come up with:

1. Mobile Computers (i.e. laptops)
2. Less-Mobile Desktops/Workstations
3. Servers

It is very obvious why an enterprise IT shop would turn to a product like PGP WDE for laptops. We have all seen the stolen laptop cases in the news. What I do not understand is where the applicability of a maintenance bypass of the PGP WDE encryption would come into play here. Laptops, being the very nature of something that can grow legs and walk away, should ALWAYS have maintenance reboots send the machines into the pre-boot authentication state. PERIOD. Because if you don't, the device is very likely to end up in the wrong hands. And like I predicted before, we will likely see a case in the news of a stolen laptop that had encryption software deployed on it-- yet it still resulted in a data leakage. Having a feature like this bypass turned on for this category of systems is a sure-fire way to make headlines.

I will temporarily skip over #2 (workstations) for #3 servers.

I understand the reasoning behind protecting servers' drives from data leakage via whole disk encryption software. I also understand that large enterprises have farms of servers and rarely manage individual servers, preferring to manage multiple servers at once through a single admin interface. However, a smart enterprise is going to use layers of security, starting at physical security controls (the data center: locked doors, raised floors, controlled environmentals, etc.), moving through network layers (firewalls, IDS), up to the system and application layers. Besides going through the performance trade-offs, and enterprise has to decide if the complexity of WDE is worth the trade-off of the confidentiality/integrity it might provide.

In this situation, I personally prefer the way TPMs (Trusted Platform Modules) have been used in WDE-like implementations (NOTE: PGP Corp does not currently support the use of TPMs with its WDE product). TPMs, in theory (but perhaps not in all implementations), have the ability to create a Trusted Path for the boot process, roughly in these steps:

1. TPM takes a cryptographic hash of the software used in the boot process (BIOS, bootstrap, kernel, etc.).
2. TPM compares hash output of components to known good hash output of the same components [remember that the TPM is tamper resistant-- any attempts to modify the hash outputs will render the device unusable].
1. If the hash outputs match, boot process continues.
2. If the hash outputs do not match, the boot process halts.
3. The boot strap (i.e. boot guard) can then rely upon the TPM to store the Master Volume Key, releasing it to the known-good (and therefore trustworthy) volume encryption/decryption driver either automatically or after additional authentication processes are completed successfully.

The caveat is that a stolen device can still boot the OS, but at that point the confidentiality/integrity of the system is no longer the responsibility of a full disk encryption product, but rather on the OS/Applications/Listening Services. However, on the plus side, there are no passphrases going around in the clear-- in plaintext scripts pushed down by administrative tools to implement a one-time reboot with a pre-boot authentication bypass. If the system's Trusted Path along the initial hardware and software phases can be established, it will reboot without interaction.

A major plus with TPMs over PGP's implemented bypass is that its use truly is a customer opt-in choice. Whereas the PGP Boot Guard (today) always checks for the existence of the bypass user access key and supplies it a generic/static x01 passphrase whether a customer knows or wants this feature to work on their systems or not, the TPM is clearly designed and documented to perform that function. There's no hidden trick; it's a deliberate act on behalf of the customer. Another huge plus is that there is no API or command line tool with which to interact in order to establish the automated boot, so there are less opportunities to accidentally disclose a critical boot volume passphrase (i.e. no plaintext scripts).

Now, to return to the issue of workstations ...

I have seen enterprise IT organizations treat workstations as servers, by installing production-dependent servers upon desktop-class hardware and expecting SLAs a server in a well-protected data center (or at least a locked closet) could provide. Those people are making mistakes--not just security mistakes-- but IT management mistakes. If something is that critical, it should be well-supported and funded, being provided the layers of control it should have. And if those are PGP's customers, I would still contend they should pursue the TPM route as described above for servers.

For workstations that are sitting (semi-) permanently on employees' desks, what are the real objections to having users come into work some morning only to see the PGP Boot Guard authentication dialog box waiting for them? If the objection is that the users are not trusted to have a User Access Key of their own (think: kiosks), then again, the TPM route is probably best, so there is less of a key management issue. If the objection is that it simply isn't convenient ... well ... anyone who understands security truly understands how dangerous playing into that line of thinking can be. Most organizations that would use the PGPwde.exe --add-bypass command in-mass will be using a shared administrative account (some call these "service accounts"), which means yet-another-default-password that has to be managed, reset when staff leave, etc. For most organizations, that is a nightmare. To top that off, remote-management tools like Microsoft's SMS often place scripts and installers in temp space, which is rife with problems cleaning up after-the-fact. Sure, if a file is deleted by the OS (using the "tombstoning" technique, not over-writing) on a fully-encrypted volume there is no access to the file when the OS is not running, but online recovery of deleted files within a file system can occur, even if the subsystem is reading/writing blocks of encrypted data from the disk. It's still semi-visible to the OS, which means a passphrase in a script could leak.

So to recap: use PGP WDE with pre-boot authentication under the expectation that users will always have a pre-boot authentication experience, even after maintenance reboots. Where that is not feasible, select a WDE solution that uses TPMs for integrity checking and secure storage of keys.

...

I would bet that some *magic* with TPMs would be possible to create some hybrid best-of-both-worlds scenario. Since TPMs can securely store hashes for matching online hash output with a known good historical state, it may be feasible to create a scenario where the default action is to salt+hash the user's passphrase and compare to hashes known only be the TPM, but follow-up with a one-time-bypass scenario where the TPM is told to check another source for the hash output comparison (i.e. the environmentals of the system, the BIOS, the serial number, the boot loader, etc., all hashed together, similar to some current TPM-WDE implementations today do always). That might make it possible to have pre-boot authentication as the default with a truly trustworthy one-time-bypass in the case of remote/automated maintenance.

And, because I could not leave this important point out, like I said previously:

"Please keep in mind that encrypted data is just data protected under time-lock; either the time required to crack the encryption key starting today on current hardware, or the time it takes to wait until current computing hardware can trivially crack the encryption key. And of course, keep in mind that most end-users of a disk encryption software will be setting a password that they can remember and type readily with little slow-down at boot. Even the strongest passwords could be shoulder-surfed and if the motivation is the data, encryption software likely won't be victorious in the end ... but it does make for a good security blanket (sensation of comfort). Instead try to remember that a wonderful and viable alternative is to not carry sensitive data on a mobile device at all! There are layers of security that exist to protect data that is centrally stored on servers in a data center. Those layers tend to not travel well with mobile devices."

PGP Bypass on Slashdot

Thanks, Slashdot. Some of your comments are on target, some ... well, I anticipated the knee-jerk response you gave. Many people (even technical people) make the mistake of thinking the use of crypto automatically equals secure. Yes, I realize it requires cryptographic (as in authorized already) access to the drive, but that's the point. The bypass feature creates an opportunity for authorized users to accidentally allow access to unauthorized users.

The positive aspects of the bypass ...

1. Yes, it does require an authorized person to enable it (not necessarily an administrator, but at least a user).
2. Yes, it does make remote, automated management possible. Although, at an expense.
3. OK. It's not a true cryptographic backdoor, but it is a dangerous access control bypass. Either way, it's unfriendly to discover after installation.

There are really a couple issues at hand here ...

1. There is no central audit trail. Any user could set this feature up without the knowledge of the "remote" admins. In fact, a smart user could create a script (or use someone else's) to disable the boot passphrase after each boot, which leads into the next point ...
2. There is no way to disable this feature. Jon Callas' (of PGP Corp) response that the bypass is "disabled" by default is more accurately stated as the bypass feature is "unused" by default. Anyone can use it at any time. In fact, the PGP Boot Guard (as best as one can tell without public documentation) checks for the existence of the bypass at each boot.
3. There are no integrity checking controls on the Boot Guard. Admins must trust that the boot guard is not accidentally or intentionally modified to stop the bypass reset/removal function.
4. The biggest threat is a timing attack. Capturing a system that hasn't reset the bypass grants full access to the data. If an adversary (or semi-trusted insider) can know when the automated reboots are scheduled, the device can be captured and misused.
5. The feature wasn't PUBLICLY documented. There simply is no excuse for this feature not be disclosed to current and potential customers. That is the #1 motivation for my discussion of this problem.

The bottom line is that if the bypass was properly documented for potential customers to review before bestowing trust in the product, OR, if the bypass could be truly disabled (guaranteed by integrity checks), then this would not be an issue at all.

Some comments bring up the issue of open source vs. closed source for security. Personally, I view that as an irrelevant side-detail; the question I am concerned with is who has access to review the source code. But yes, despite PGP having some sort of an open source code review
process, this feature was still not publicly documented.

UPDATED: Since there are objections to my claim that "The feature wasn't documented" (besides my details about how the feature came to become documented as it is now), I have changed the wording to "The feature wasn't PUBLICLY documented". Because if the documentation isn't in the hands of someone who would find it useful ... then what's the point?

Are Security Model's Bankrupt: Microsoft's Stride Chart

Over on the Microsoft SDL (Security Development Lifecycle) blog, there's a post about a security tool Microsoft uses in their threat modeling process called the "Stride Chart". Why is it that Microsoft's Stride Chart appears to be such a weird derivation of Donn Parker's Hexad? Here are the components Microsoft uses to estimate security threats:

• Authentication
• Integrity
• Non-Repudiation
• Confidentiality
• Availability
• Authorization

And, of course, the Hexad is a derivation from the CIA Triad:


First of all, there is some controversy surrounding Parker's Hexad, roughly because it does appear to just be a more detailed model of its parent, the CIA Triad. But looking at the Stride Chart, I have to wonder why Microsoft has chosen six main "threat categories" (not three: CIA), but not the exact same six as the Hexad: Confidentiality, Integrity, and Availability, buffeted by Possession/Control, Authenticity, and Utility. Why Authorization and Non-Repudiation and not Utility and Possession as well? Isn't Non-Repudiation and Authenticity a hair-splitting, English-has-too-many-synonyms type of oversight?

Are security models bankrupt? Has Microsoft (and others, because this Stride Chart is getting head nods) reduced to adding every last security buzzword to their lists? Can the basic security models we use be simplified any further? And, very importantly, where are the logic proofs that formally establish these principles as the foundation upon which all security solutions should be built?

Or, is the security industry so busy building money-making solutions that fundamentals are ignored?

Response to Jon Callas - PGP Encryption Bypass

As I can only assume the real Jon Callas placed this comment (and, Jon, I am grateful for your time and thoughts if it is you), here are my responses....

"You bring up an interesting issue with the automated reboot feature, but you don't have the details right. I can't fault you for that, as we haven't documented on the web site. Full product documentation should be coming in the next release."

I am curious, Jon, if you could be forthcoming with details as to why this feature was not documented. I would hate to pull out the overused "security by obscurity" banner. Was it intentional (and if so, why?) or was it simply oversight?

"The major inaccuracy you have is that the passphrase bypass operates only once. After the system boots, the bypass is reset and has to be enabled again. Note that to enable it, you must have cryptographic access to the volume. You cannot enable it on a bare running disk."

Of course you are correct on that detail. I was aware of the one time use parameter, but did unintentionally neglect its inclusion.

But we are both working under the assumption that we are using the PGP issued boot guard binary to unlock and boot the drive. If (and please correct me if I am wrong, Jon), however, a third party were to reverse engineer the process the PGP boot guard works to build their own (say to boot from media such as a CD or DVD), this bypass, which is simply another key (protected by a passphrase of hexadecimal value x01) to decrypt the Volume Master Key could remain on disk. The users (and administrators) have to trust that the PGP binary will leave the function calls (the ones that remove the bypass from disk) intact.

Essentially, this is an example of a trusted client, which (without going too off subject here) is not that much different from why client-based NAC implementations fail [Because if you cannot trust a machine trying to connect to your network, how can you trust the output of some software running on that machine as an attempt to interrogate its trustworthiness?]. There is no trusted path to validate that the binary image that is called to both add the bypass and to boot the device, removing the bypass, is unchanged from its distribution from its maker, PGP Corp. Administrators who use this feature are putting their trust (or perhaps their faith) in the hope that: 1) the binary as identified by file path has not (and will not be) changed, and 2) there is no interest in the "insecurity research" community to create a method to maliciously alter those binaries.

Basically, (and I apologize, Jon, if this is a simplistic diagram) the image below is a disk that is protected by PGP Whole Disk. The User Access Keys, Boot Guard (software that unlocks the disk), and Volume Master Key may be out of order (probably are-- after I quickly made the diagram I realize the Boot Guard is likely to be first), but the ideas are the same regardless. User Access Keys unlock the Volume Master Key, and users unlock their corresponding access key by their passphrase (or various physical token). If a bypass exists, it is added to the User Access Keys. The Boot Guard has a function call for using the bypass (by attempting to decrypt the bypass user01 access key with a passphrase of value x01) and a function call to remove the bypass from the user access keys on disk.


What if the PGP Boot Guard's function for removing the keys was removed (e.g. by a Trojan/malicious boot guard or boot media)? What controls would then obligate that the bypass key would be removed? If the PGPwde.exe --add-bypass command checks the integrity of the Boot Guard to ensure the RemoveBypass() (or equivalent) function call is intact, it certainly isn't documented that it does so. Regardless of whether it checks at the instant it creates the bypass, there still is no guarantee from that point in time that the Boot Guard won't be manipulated or that alternative boot media won't leave the bypass intact.

Jon went on to say:

"We are not the only manufacturer to have such a feature -- all the major people do, because our customers require it of us. A number of other disk encryption vendors call this a "wake on lan" feature, which we believe to be misleading. We call it a passphrase bypass because that is what it is. It is a dangerous, but needed feature. If you run a business where you remotely manage computers, you need to remotely reboot them.

"The scenario you describe is more or less the intended one, and you identify the risk inherent in the feature. If someone enables the bypass and the volume is immediately stolen, then the volume is open. However, this window is usually very small. The people who use it understand the risk."

Exactly. This is the theme of which I would like to take hold, more so than the hype of a problem in a widely-adopted product. The question at hand may be: "Is whole disk encryption an example of bolt-on security that doesn't truly solve the problem of confidentiality and integrity of data at distributed locations?"

What also surprises me about the customers that would require PGP WDE to have such a feature is the way they would have to use the feature. Since this is command line driven, this is obviously designed for use in scripting. I have a hard time fathoming an enterprise organization that would, on one hand, require the use of full disk encryption of computers and then, on the other hand, distribute a script with a hardcoded passphrase in it, presumably using a software distribution tool like Microsoft's Systems Management Server (SMS), or similar. The risk of this feature of PGP WDE notwithstanding, we are talking about admins using shared/generic/static passphrases for all or many computers stored in plaintext scripts, set to execute in mass. If the complexity doesn't accidentally disclose the default administrative passphrase, then the fact that fallible humans keeping human readable scripts in N locations used every time Microsoft releases a patch certainly will. An average security conscious IT shop running Windows products (because PGP WDE is a product for Windows) will have at least 12 opportunities per year for devices to get stolen when they are in this vulnerable "bypass" state. Does the use of this PGP WDE (or any full disk encryption vendor as Jon claims competitors have similar functionality) feature increase the risk that laptops will be stolen on the eve of the second Tuesday of every month?

"You do not note, however, that the existence of this feature does not affect anyone who does not use it. It is not a back door, in the sense that cryptographers normally use the word.

"You cannot enable the feature without cryptographic access to the volume. If you do not have it enabled, you are not affected, either. I think this is an important thing to remember. Anyone who can enable the feature can mount the volume. It is a feature for manageability, and that's often as important as security, because without manageability, you can't use a security feature."

True. It's not a "backdoor" in the sense of 3 letter agencies' wiretapping via a mathematical-cryptographic hole in the algorithm used for either session key generation or actual data encryption, but how can a PGP WDE customer truly disable this "bypass" feature? As long as the function call to attempt the bypass exists in the boot guard's code, then the feature is "enabled", from my point of view. It may go unused, but it may also be maliciously used in the context of a sophisticated attack to steal a device with higher valued data contained within it:

1. Trojan Horse prompts user for passphrase (remember, PGP WDE synchronizes with Windows passwords for users, so there are plenty of opportunities to make a semi-realistic user authentication dialog).
2. Trojan Horse adds bypass by unlocking the master volume key with the user's passphrase.
3. [Optional] Trojan Horse maliciously alters boot guard to disable the RemBypass() feature. [NOTE: If this were to happen, it would be a permanent bypass, not a one-time-use bypass. Will PGP WDE customers have to rely on their users to notice that their installation of Windows boots without the Boot Guard prompting them? Previous experience should tell us that users will either: A) not notice, or B) not complain.]
4. Laptop is stolen.

OR just this:

1. Enterprise IT shop sends notification to users regarding upcoming maintenance (OS/Application patch) which will include a mandatory/automated reboot.
2. Malicious insider powers off computer when BIOS screen appears, keeping disk in "bypass" state.
3. Malicious insider images the drive or steals the device entirely.

Jon continued:

"You say, 'There has to be a better solution for this problem.' Please let me know when you have it. I can come up with alternate solutions, but they all boil down to an authorized user granting a credential to the boot driver allowing the boot driver to get to the volume key. We believe that our solution, which only allows a single reboot to be a good compromise. It doesn't endanger people who don't use the feature, but it allows people to remotely administer their own systems."

Jon, I would be more content with this feature in your product, if:

1. The feature was documented clearly, including a security warning covering the risks of its use/presence in such a way that administrators must see it.
2. The feature could be permanently disabled-- not just ignored or left seemingly unused.
3. The intended use of the feature did not require the creation of a passphrase with cryptographic access to the Volume Master Key.
4. The intended use of the feature did not require the distribution of plain text scripts with an embedded passphrase to N clients each and every time that feature is needed.

As for "there must be a better solution", I will follow this post up with potential "better solutions". Some of them may be attainable with your product line, but I'll warn you, Jon, that some of them are not possible today and would require extensive implementation efforts-- potentially rethinking distributed computing entirely. I will likely present a possible solution that will be beyond what your company is positioned to implement.

PGP Whole Disk Encryption - Barely Acknowledged Intentional Bypass

Popular whole disk encryption vendor, PGP Corporation, has a remote support “feature” which allows unattended reboots, fully-bypassing the decryption boot process. The feature, which until recently was not documented (customer accessible only) in most support manuals, allows a user who knows a boot passphrase to add a static password (hexadecimal x01) that the boot software knows. If this flag is set, the boot process does not interrogate a user. It simply starts the operating system. The feature can be accessed via the command line (ignore line wrap):

"%programfiles%\PGP Corporation\PGP Desktop\PGPwde.exe" --add-bypass --passphrase [passphrase here]

How trivial would it be for a Trojan to pretend to be an authentication dialog box and apply the user-supplied password as the drive unlocking passphrase!

This illustrates that, while encryption of hard drives can reduce the exposure of a lost or stolen hard drive to a time-complexity problem, there can also be a false sense of security here, too. My personal anticipation is that the lost laptop parade in the media will eventually include a breach of an encrypted laptop. This feature of PGP notwithstanding, there is the age-old problem of shoulder surfing for the boot passphrase. PGP’s feature now allows a lost machine with the by-pass flag to be easily compromised. Granted, without that feature, a Trojan could capture the boot passphrase anyway. The real solution is to not have critical data on mobile devices. Our banks do not issue us mobile bank vaults—we keep our valuables in nice, safe, centralized bank vaults where layers of security protect them.

Imagine this scenario:

1. Enterprise IT ships out a maintenance patch requiring a reboot.
2. Scripted installation also uses PGP WDE bypass to setup unattended reboot.
3. Script preps the system for shutdown, but the laptop is stolen.

All it would take at that point is for somebody to use a simple disk imaging tool to get repeated attempts at access to the drive.

PGP Corporation should also be in the doghouse for keeping this "feature" so quiet. For example, there is nothing in the current release that documents this feature. Even the pgpwde.exe help option delivers nothing to indicate its existence:

C:\"%programfiles%\PGP Corporation\PGP Desktop\PGPwde.exe" --help
PGP WDE command line tool.
Commands:

Generic:
-h --help this help message
--version show version information
Disk enumeration:
--enum enumerate all fixed and removable disks
--disk-info display information about a specified disk
User management:
--add-user add a user to specified disk
--remove-user remove a user from specified disk
--list-user list all users from specified disk or user file
--verify-user verify a user on disk with specified passphrase
Disk management:
--disk-status display encryption status of specified disk
--instrument instrument a disk with Bootguard
--uninstrument remove Bootguard instrumentation from specified disk
Disk operation:
--decrypt remove whole disk encryption from specified disk
--stop stop an active encryption or encryption removal process
--wipe-disk wipe the content of specified disk
--recover try to recover specified damaged disk

Options:

Boolean:
--fast enable fast mode encryption
--safe enable safe mode encryption

Integer:
--disk specify physical disk by number
--block-size optional specify encryption block size

Strings:
--public-keyring public keyring file
--private-keyring private keyring file
-i --input input file name
-o --output output file name
--passphrase passphrase for disk user or private PGP key
--ap --admin-passphrase admin symmetric passphrase
--rp --recovery-token recovery passphrase
--asc armored key file in .asc format
--admin-asc armored admin key file
-u --user user name

There has to be a better solution for this problem.

UPDATED: You can remove any bypass passwords using the "--remove-bypass" switch and you can check to see if bypass are setup using the "--check-bypass" switch. For example:

C:\>"%programfiles%\PGP Corporation\PGP Desktop\PGPwde.exe" --remove-bypass
Failed to locate user: ☺user

UPDATE 2: Jon Callas, CTO/CSO of PGP Corp, allegedly (because there is no non-repudiation in the comment) left a comment regarding this post. My response is here.

UPDATE 3: Here is some feedback for the slashdot thread. Here is a continuation of my response to Jon Callas.

UPDATE 4: If you're coming here from Jon Callas' CTO Corner article, then take a quick trip here to see my response.

Thomas Ptacek on DMA, Virtualization, and Nate Lawson

Thomas Ptacek makes an important comparison between network security and memory/hardware resource allocation, especially in terms of virtualization. This is an excellent follow-up to Nate Lawson's posts that I mentioned early today. From Thomas' post:

"In 5 years, nobody will deploy new servers for applications. Every application will run on a virtual machine. Inevitably. And as we approach this end-state, more and more of our applications are virtualized, and performance becomes a bigger concern....

[There] is a hole in the X86 VMM security strategy. Today, if you want your guest VMs not to have to trust each other, and one of them needs direct access to NIC, you have to trust that the NIC can’t be coerced into copying network packets with executable code directly into the kernel memory of the other machines....

You only need to read Nate’s posts if you (a) believe virtualization will be ubiquitous within the next 5 years, (b) work in security, and (c) believe you need to sound like you know what you’re talking about. Otherwise, Nate’s posts are entirely optional."

So, now you know why you need to read Nate’s posts, right?

Code Review vs. Application Layer Firewall

In a recent sales attempt, I received a whitepaper (warning: PDF) from Web Application Layer Firewall vendor Imperva entitled: "The New PCI Requirement: Application Firewall vs. Code Review".

For those not familiar with the Payment Card Industry (PCI) compliance regulations, visit the PCI DSS (Data Security Standard) website.

From my perspective, PCI is an excellent set of security compliance regulations, perhaps the best that exist in the U.S. Items are clear, concise, and specific (sometimes too specific), which is in stark contrast to other regulations, such as SOX, HIPAA, GLBA, etc.

Here's the specific PCI requirement in question:

6.6 Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:
• Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security
• Installing an application layer firewall in front of web-facing applications.
Note: This method is considered a best practice until June 30, 2008, after which it becomes a requirement.

If you're bored already, you can sum up this problem as a typical 'business case for better engineering' problem.

We (the IT and Security field) know how to achieve higher security assurance in critical applications: thorough source code analysis coupled with simple design. However, we know that for many (if not most) organizations to adopt this mindset, it will require an overhaul for their existing software lifecycles. To put it bluntly: few people are truly analyzing their design and their code.

So in to our rescue is a typical information security vendor, ready to offer a hybridized second-rate solution to the problem. [To be fair, I think it is a well engineered solution, but for the wrong problem-- the problem of managing an application without truly understanding its code.]

Now to jump in and dissect their whitepaper ...

"What is an “Application Layer Firewall”?
An application layer firewall, also known as a “Web Application Firewall” or “WAF” is a network device that is placed in front of the Web applications in an organization’s data center to protect against attacks. A WAF is able to view and understand the full spectrum of application traffic so that it can protect the applications and the sensitive data from illegitimate access and usage." [Italics are mine]

This is stopping point #1. How is it possible that a vendor-- who has NEVER seen your organization's application-- can create a drop-in box that can "understand the full spectrum" of your application's traffic??? Again, to be blunt: they cannot. They can make guesses about commonalities among applications they have seen in the past (e.g. like customers whose applications were extensively analyzed for the purpose of product development). They may be even able to code in some inference engines that can make educated guesses at runtime, but they cannot ever truly "understand the full spectrum".

"Because of SecureSphere’s unique Dynamic Profiling capabilities, it automatically builds a complete baseline profile of your applications and network traffic in a matter of days. Using the application profile, SecureSphere can distinguish between legitimate user behavior and illegitimate behavior as well as protect from attacks... No manual intervention or tuning is necessary, keeping your on-going administrative costs far lower than other WAF products." [Italics are mine]

So, yes, it is an inference engine; note the italicized portions of the quote above. What is striking is the claim that this behavioral analysis tool does not require human intelligence for tuning, which means either: 1) the engine is tuned to avoid false positives at the expense of neglecting true positives, or 2) the Marketing department is (ahem) over-estimating their product's ability. Any behavioral analysis tool requires extensive tuning.

"While code review is a good idea, and is consistent with coding best practices, hiring consultants entails extra cost, loss of flexibility, resource allocation issues, scheduling headaches, and ultimately a lower grade of security than you would achieve through the deployment of a Web Application Firewall." [Italics are mine]

What amazes me in the world of marketing is that it's an acceptable practice to both claim a universal truth and debunk it in the same sentence. The whitepaper notes that code review is a "best practice", yet before a breath is taken attempts to claim that code review is a lower security assurance process when compared to using an application layer firewall, which simply doesn't make sense. Drop-in products work blind-- they do not know your organization's applications and they can only make inferences regarding them. Human Intelligence (this assumes training and expertise, hence the word "intelligence") will certainly trump; understanding the application is inherent to the process of good coding review and implementation.

If the assurance of externally facing applications is of utmost importance, then design/implementation time controls (e.g. static analysis) should be explored, not runtime controls (i.e. application layer firewalls).

...
UPDATED 12/10/2007: Here's a follow-up ...

Nate Lawson on DMA/IOMMU

In the past few days, Nate Lawson has a couple interesting articles on PC Memory Architecture and Protecting Memory from DMA using IOMMU. Nate's got some good stuff in there, including comments around ring 0 code and virtualization ... many ideas that play well with the notion of separating code from data.

More comments on the PDF vulnerability

Matasano has some comments on the recent PDF vulnerability:

"Modern PDF Readers do crazy things. Like embed remote web pages. That means they talk to the internet. That means more network attack surface!"

From the overview (page 33) of Adobe's PDF Reference Manual:

"In addition to describing the static appearance of pages, a PDF document can contain interactive elements that are possible only in an electronic representation. PDF supports annotations of many kinds for such things as text notes, hypertext links, markup, file attachments, sounds, and movies. A document can define its own user interface; keyboard and mouse input can trigger actions that are specified by PDF objects. The document can contain interactive form fields to be filled in by the user, and can export the values of these fields to or import them from other applications." [italics are mine]

The spec sounds almost like a general purpose Operating System, not a document data format. And since the data and the code are not well separated, Dave at Matasano is right:

"These conditions create the perfect storm for the modern attacker. This is going to get worse not better."

I'm afraid there will be more holes found in PDFs, perhaps even to the point of businesses questioning the viability to remove PDF support from their systems.

Still more separation of code and data

Separating code from data is a HUGE problem (possibly a root of all remote code execution evil). Here's more info, some of it new, some of it very old ...

There's a variety of vulnerabilities discovered recently that all involve document file types that either: A) allow executable code or script (which should be treated as code, not text data) to be embedded within the document, or B) to have buffer overruns because of the complexity of the file types. [Special thanks to the blog post at Hackademix.net for the summary of recent events and for his contribution of NoScript.]
Schneier's blog also pointed readers to a paper from 2002 regarding Multics, an "an operating system from the 1960s, and had better security than a lot of operating systems today" (Schneier).

From the paper on Multics:

"Multics also avoided many of the current buffer overflow problems through the use of three hardware features. First and most important, Multics used the hardware execute permission bits to ensure that data could not be directly executed. Since most buffer overflow attacks involve branching to data, denying execute permission to data is a very effective countermeasure. Unfortunately, many contemporary operating systems have not used the execute permission features of the x86 segmentation architecture until quite recently [17].

Second, Multics virtual addresses are segmented, and the layout of the ITS pointers is such that an overflow off the end of a segment does not carry into the segment number portion. The net result is that addressing off the end of a segment will always result in a fault, rather than referencing into some other segment. By contrast, other machines that have only paging (such as the VAX, SPARC, or MIPS processors) or that allow carries from the page offset into the segment number (such as the IBM System/370) do not protect as well against overflows. With only paging, a system has to use no-access guard pages that can catch some, but not all references off the end of the data structure. In the case of the x86 processors, although the necessary segmentation features are present, they are almost never used, except for operating systems specifically designed for security, such as GEMSOS [32].

Third, stacks on the Multics processors grew in the positive direction, rather than the negative direction. This meant that if you actually accomplished a buffer overflow, you would be overwriting unused stack frames, rather than your own return pointer, making exploitation much more difficult." [Boldface and italics are mine]

Amazing. Three features that most modern OSes still do not have. Note that the "first and most important" feature is that executable code is tagged with the execute bit. While that is not pure separation of code and data, it is an excellent start because it does at least distinguish between with memory objects are code and which are just data. Hence, a char/string based buffer overflow could not result in a remote code execution scenario because the object would not have the execute bit flipped.

To be fair, some OSes have limited support for NX (No Execute) bits (which if you're smart you'll catch that to be "black lists" not "white lists" like Multics uses), but the implementation's quality and thoroughness is typically limited to support from the CPU architecture employed. From the list, though, it looks like a fair number of the 64 bit CPUs are well supported.

Windows Vista will support NX (along with ASLR), but there may be some caveats, such as the typical requirement of vendors to opt-in to use the feature. From AMD:

"For NX to be applied to a given executable, three conditions must be met. First, the processor has to support NX. As mentioned, any AMD64 processor will fill the bill here. Second, EVP support has to be on globally, which will be true for all 64-bit Vista builds and all 32-bit Vista builds unless NX support is explicitly switched off with a boot configuration option. And finally, Vista has to mark all of the program's non-code pages with the NX flag, which is determined by the operating environment (32-bit or 64-bit Vista), boot configuration options, and the program itself."

Overall, that may make a compelling argument to switch to 64 bit architecture.


So, what's today's lesson? Either separate code from data or pay for it eternally as you penetrate and patch.

Symantec Considers White Lists

After years of attempting to convince every Symantec SE I met to drop the Sisyphean virus signature database model, it appears that Symantec is finally seriously considering to use white lists.

Virus signatures, or lists of all the bad software that your AV vendor thinks you wouldn't want to run on your computer, are "black lists" (or "bad lists" for those of you, who like me, aren't in favor of even a nuance of color discrimination in language). For many people, security practitioners included, the thought of the converse model of "white lists" (or, again, "good lists") has not even entered their minds. In AV speaking terms, this would mean building an anti-malware (yes "malware" to encompass any of the garbage that you don't want to get CPU or memory resident on your systems) solution that allows only known good code to execute. "Why would anyone want to do that?" you might ask ... Well, because keeping up with all the bad things is Sisyphean (as in rolling a large boulder uphill only to have it fall back down on you several times).

Here's a quick graph to depict the rate of virus variant increases over the past couple decades, taken from F-Secure's blog:

At first glance, there are portions of that curve that look to be increasing quadratically. [Disclaimer: this chart is not meant to be thoroughly scientific, but more of a generalization to paint a picture in a quick blog post.] Ask your average enterprise IT administrator if the number of good, trustworthy applications is increasing on a scale similar to that. The answer should be not just "no" but "heck, no". If it was, there would be all other sorts of management issues, such as change/release/version control, and redundancy of similar applications. So, to put it simply, "white lists" in AV allow an organization to approach their malware problem at the same pace as they approach their "bonware" (beneware? goodware? niceware?).

Marcus Ranum has been saying this for years, too. Review his "6 Dumbest Ideas in Computer Security", starting with #1 (Default Permit) and #2 (Enumerating Badness) which are exactly this issue.

Trust at the foundational levels: IOMMU & DMA

IOMMU, or Input Output Memory Management Unit, will likely play a large role in the security of future operating systems. If IOMMU does not play a large role, it will hopefully be because there is something better (that is to say, hopefully IOMMU is not neglected from future computer architectures). In a nutshell, IOMMU is like a mini-firewall for RAM (yes, there are problems with this over-simplification, but bear with me), controlling hardware's access to critical memory locations to prevent ignorance or malice from, say, using a DMA-connected device to patch a kernel at runtime.


DMA, or Direct Memory Access, was designed to rid computer architectures of the performance problems associated with sending all memory IO requests through the CPU. It's yet another instance of the convenience versus security trade-off.

Most OSes in use today are monolithic kernels, which when juxtaposed to their evolved cousins, microkernels, it becomes apparent the differences of trust models used within each. Monolithic kernels are like DMA, they make a convenience over security trade-off; system drivers and services run in kernel mode for convenient access to each other's data (which is scary if one of those is corrupted and taken over by an adversary, or adversary's malicious code). Microkernels, on the other hand, do not make that trade-off; all IPC (inter process communication) is routed the long way around while all drivers and services run in userland-- not privileged memory space. One example is MINIX, an academic OS with a microkernel design.


Microkernels and IOMMU go hand in hand, as both are attempting to address trust at the foundational levels, IOMMU at the hardware layer and Microkernels at the OS (control/allocation of hardware) layer.

Joanna Rutkowska is a security researcher who focuses on security issues closer to the hardware than most attacks, such as kernel fundamentals that may or may not lead to rootkits. What Joanna has pointed out, is not unpredictable to Operating System researchers. From Joanna's Blog:

I must say really like the design of MINIX3, which keeps all the drivers (and other system components) in usermode, in separated address spaces. This is, however, still problematic today, as without IOMMU we can’t really fully protect kernel from usermode drivers, because of the potential DMA attacks – i.e. a driver can setup a DMA write-transaction to overwrite some part of the micro kernel memory, thus owning the system completely. But I guess we will all have processors supporting IOMMU within the next 1-2 years.

The important thing to note here, is not necessarily that the OS an enterprise chooses for critical computing should change to MINIX3 (although maybe it should), but rather: until there are proficient controls to ensure the trustworthiness of the foundational levels of computing, worrying about the trustworthiness of everything that runs on top of the foundation is pointless. To quote Schneier: "security is a chain; it's only as strong as its weakest link."

Se Cura: Free of Care or Worry

"Secure" derives from the Latin words se, meaning "without", and cura, meaning "care" or "worry". In simplest terms, being secure means not having to worry about security. Threats to well-being are just not of concern.

This is important to note as most people use the term "secure" to mean a variety of different things. There's some people who use "secure" interchangeably with the elements from the CIA Triad. There are some who mean that an asset is important and adequately protected. And there are those who even use "secure" to mean "comfortable", as in "I am secure with who I am". What's surprising is how close the last use really is to its etymological roots. There are even those who use "secure" to mean physically fastened to another object. Personally, I am most frustrated with people who use the word "secure" or "security" interchangeably with, say, Confidentiality, because it shows a flagrant ignorance into the bigger picture of what it takes for, say, users of a system to be comfortable that their information assets are truly safe. Clearly, more is needed than just Confidentiality, hence all of these models like the CIA Triad and Parker's Hexad. [For the record, I think both of those models are inaccurate, but that's for another time.]

The Woes of TOR

I predicted this a year or so ago (when I first heard of TOR), but as predictions go, they don't have value if they aren't published. Now there are issues in the news about how TOR doesn't provide the security that users expected.


The following is a picture from the EFF's website depicting how TOR supposedly provides anonymity for users' web browsing:


Just like perpetual motion is impossible, so is this idea of anonymity. In simplest terms, it comes down to understanding how trust works. A TOR user trusts (an action) the TOR client on her computer which trusts the TOR nodes to properly route her data without breaching confidentiality. The important little detail that is so often overlooked is that these TOR nodes are operated by ... that's right ... people. And people will ruin a security model every time, either deliberately (malice) or accidentally (ignorance). [Hanlon's Razor comes to mind: "Never attribute to malice that which can be adequately explained by stupidity."]

In the case of the embassy's pitfalls with TOR, users assumed (watch that!) that their traffic was not being monitored by the TOR network nodes, when in fact it was. This is not a pitfall of TOR's implementation, but of TOR's design. Since this is an anonymous network of nodes operated by people such that Adam does not know Eve, how can any user ever expect a trustworthy (not an action, but a state of assurance) network? Compare this to the "real world" ... would Jane expect that if she were to go to some special coffee shop and share her secrets with a total stranger that the secrets would stay safe with her? Regardless of whether Jane has that expectation, it would be prudent for you not to have that expectation yourself.

So, extrapolating upon this situation ... how long will it be until we have law enforcement regularly participating in TOR networks? The logical next step is either an arms race inside the TOR network or a total breakdown of the network altogether. Either we will see law enforcement participate and "security researchers" (terms used loosely) evaluating methods to evade untrustworthy--yet totally anonymous--TOR nodes, OR, we will see law enforcement agencies lobbying their respective governments to make TOR illegal. From where I sit, this looks like the former is the better option. And why not? After all, there are millions of ignorant people out there who will assume that total anonymity is actually possible-- actually achievable. But it's not. That's dictated by the physical laws of information security. And while they're out there using TOR, law enforcement has a new "beat to walk": the TOR networks.



Another perpetual motion attempt in InfoSec today is DRM which will be discussed in the future.

Separation of Code and Data

One of the most surprising things for a savvy information security practitioner is the continued prevalence of intermingling of code and data in modern information systems. It is as if some mandate dictates that these items must be desegregated. This is the root cause of every buffer overrun/overflow exploit, every XSS or SQL Injection attack, even Microsoft's infamous run of bugs in office documents and images (think GDI). Yet, today, there are simply too many systems that do not properly (if at all) segregate data objects from executable code objects in memory.

Buffer overruns
The gist is that a program allocates memory for a data object (as in "information" of some type), but because of some implementation bug, executable code can be passed to the function instead of data (because the program does not distinguish the two). And eventually for one reason or another, but mainly because the system does not require executable code to be stored in a location with better access control separate from data elements, the data object is unintentionally executed, frequently containing malicious payloads.

Cross Site Scripting
Most cases of XSS are no different. Essentially, data elements (usually expected to be in the form of plain, rich, or html text) are uploaded containing client-side executable scripts with malicious payloads.

SQL Injection
Again, same song, second verse, only this time the "data" is really malicious SQL commands uploaded as text.


Why, if the top technical causes of malware all share the commonality of not properly segregating code and data, do we not yet have systems that build this property in?


Excellent question, of course. The current-generation attempts to solve this include Address Space Layout Randomization (ASLR), and, more formidably, No Execute (NX). Windows Vista's downfall, of course (all debate on licensing aside) is that for backwards-compliance's sake old applications cannot be forced to segregate their memory objects. And the patterns of lazy or ignorant developers yet again plague both the consumer and the enterprise.


Perhaps one day we'll get this right.

About this blog...

As it says above (and below for posterity), the intention of this blog is to look at the scientific aspects of security, namely "information" security (security of information or digital assets in the modern world).

(noun) securology. Latin: se cura logia
the science or study of security: the state of being without care or worry