SSL Protocol Vulnerability – and Confidentiality

There was an SSL vulnerability revealed last week – a design flaw in the protocol itself. There are two very notable things in this news: the vulnerability being in the protocol itself (like DNS and SNMP before it), and the way news of the vulnerability was broken.

The flaw in the protocol was discovered in August by researchers at PhoneFactor, and the vulnerability was released confidentially to those who could fix its problems and produce fixes for the vulnerability.

This flaw was then discovered by an independent researcher, who likewise released the vulnerability confidentially to an IETF security mailing list.

The problem was that a reader of that mailing list did an irresponsible thing and let the news of the SSL protocol vulnerability loose by sending a tweet message about it on Twitter to all of their friends – which meant that the news was set to be released to everyone. Mark Twain said: “Three people can keep a secret if two of them are dead.”. This problem of vulnerabilities and of when and how to release the news is not new; nor is the problem of the unknowing releasing confidential details.

The problem with security vulnerabilities and confidentiality is legend: it has become one of those arguments that never quits: do you release the details of a vulnerability as soon as they are known or do you wait for the fix to be released after confidentially notifying affected vendors? The uneasy answer most often reached is that a combination of both is necessary.

The problem of tweet messages releasing confidential information has happened before; one most notable incident was when Congressman Pete Hoekstra (R-Mich.) let slip news in Twitter about his trip to Baghdad. This news was then picked up by Wired, the New York Times, CNet, and – of course – the Congressional Quarterly.

In the security arena, confidentiality is much more critical – as is evidenced by the fact that Twitter itself was attacked with this vulnerability just in the last few days.

When you “speak” on the Internet, the world will hear: so be careful what you say.

Laissez-faire Security – A Good Thing

Bruce Schneier wrote today about a paper that describes something it calls laissez-faire security: the idea that tight role-based security (RBAC) will lead to situations where the security prevents people from doing what they need to do for their jobs, which subsequently leads to normal people finding ways to circumvent (and weaken) security.

The proposal presented in the paper Laissez-faire Security (by two researchers from Columbia University and two from Microsoft) suggests that rather than tightening things down, one should audit strongly instead. One of the authors, Steven M. Bellovin, is a luminary steeped in the history of the Internet, in the security arena, and one of the founders of Usenet.

The results of RBAC can be seen by every administrator sooner or later – many times, experienced personally. SELinux is a perfect example: despite its acknowledged security benefits, it is commonly disabled or left in an “advisory” state only because of the problems in implementing such a restrictive policy.

From a user perspective, there are numerous examples of people bypassing security in efforts to share data or to utilize tools to get work done.

Laissez-faire Security is about letting users select the appropriate security rules within a framework of policies – which they can ignore (after notification and auditing) – at their own peril. The policy violations can then be handled outside of the computing environment in other ways if needed.

The paper compares computer security to an economy and to the workings of the free-market economy in particular. This paper is very interesting reading and would be worth reading for any security-minded administrator.

SSH Key Conversions: ssh-keygen (OpenSSH)

I’ve discussed this before, but this time I’m focusing on another angle. When interacting with commercial SSH implementations (such as exists on OpenVMS and Tru64 implementations) it becomes useful to know how to convert your OpenSSH public keys to SSH2 format and vice versa.

These examples will assume that you are using OpenSSH and are on a UNIX system. Note that these are public keys, not private keys. All key types (DSA, RSA) should convert fine, but DSA is the stronger cryptographic algorithm.

One you have a public key in the appropriate format, you can add it to the authorized keys file (whatever that may be called). This is normally found in ~/.ssh or ~/.ssh2 depending on the SSH version.

The OpenSSH utility ssh-keygen is what makes this happen. This utility can do a lot more than just generate keys. It can be used to change passphrases of encrypted keys; convert keys; generate public keys from private OpenSSH keys; and read and write keys to smartcards.

Converting an SSH2 key to OpenSSH

To use an SSH2 public key in OpenSSH, it needs to be converted. Use the ssh-keygen utility in this manner:

ssh-keygen -e -f ~/.ssh/id_dsa_ssh2.pub > ~.ssh/id_dsa.pub

Converting an OpenSSH key to SSH2

Using an OpenSSH public key in SSH2 requires a conversion; ssh-keygen can do this:

ssh-keygen -i -f ~/.ssh/id_dsa.pub > ~/.ssh/id_dsa_ssh2.pub

Getting Passwords from Random Data (portably!)

Over at Mark Kolich’s blog, he wrote several months ago about using a source of randomness (/dev/urandom) to generate passwords. The idea is simple enough: take the random data, strip out only the printable characters, and then print the desired length of characters for a password.

Shortly thereafter, he described how to use a simple shell script to generate many passwords – such as for setting up many different accounts.

Working with HP-UX and OpenVMS as I do, I immediately thought: how could I do this in Perl, making the idea portable and making a program that will work on both UNIX and OpenVMS? It was easy – and easy to make it flexible as well. Here is the program that I came up with:

#!/usr/bin/perl

# code released by David Douthitt into the public domain

use Getopt::Long;

Getopt::Long::Configure('bundling');
GetOptions( 'l=i' => \$opt_l,
            'p=s' => \$opt_p,
            'm=i' => \$opt_m );

$pat{"ext"} = "[[:alnum:][:punct:]]";
$pat{"alnum"} = "[[:alnum:]]";
$pat{"alpha"} = "[[:alpha:]]";
$pat{"simple"} = "[a-km-z2-9]";
$pat{"normal"} = "[a-km-z2-9A-HJ-NPR-Z]";

if (defined($opt_p)) {
   if (defined($pat{$opt_p})) {
      $pat = $pat{$opt_p};
   } else {
      print "undefined pattern!\n";
      exit(1);
   }
} else {
   $pat = $pat{"normal"};
}

$max = (defined($opt_m) ? $opt_m : 1000);
$len = (defined($opt_l) ? $opt_l : 6);

$x = $len;

for $i (0..$max) {
   $c = chr(int(rand(255)));
   if ($c =~ /$pat/o) {
      $s .= $c;
      if (--$x == 0) {
         print "$s\n";
         $x = $len;
         $s = "";
      }
   }
}

Note that since OpenVMS does not use the “#!” notation, that this line will be ignored as a comment and the program needs to be invoked via direct invocation of perl itself.

As an aside, Mark says how he prefers random passwords. Me, I prefer “pronouncable” passwords – still random, but using phoenemes which makes the generation process just that more complicated – and complicates internationalization. Apple’s MacOS X comes with a password generator that can generate random and pronouncable passwords.

However, with the proper password storage system a fully randomized password is good – or is it? A completely random password of eight characters could be zzzzzzzz as much as anything else. Perhaps a password with a random distribution of characters (rather than a random selection of characters) would be better. I’m not aware of any password generators that guarantee a random distribution instead of a random collection.

Powered by ScribeFire.

Wheel Group on HP-UX 11i

On HP-UX 11i, it appears that setting up the wheel group has been made easier than ever through the use of PAM and the pam_hpsec module.

To enable the wheel group, make sure that the wheel group does, in fact, exist – you’ll probably have to add it. After adding the wheel group, make yourself a member of it (no sense in getting locked out, right?).

Edit the file /etc/default/security and look for the entry:

# SU_ROOT_GROUP=wheel

Uncomment this line (by removing the first two characters) and save:

SU_ROOT_GROUP=wheel

You’re done! Easy, wasn’t it?

Powered by ScribeFire.

sudo – bane or benefit?

The commonly requested tool sudo is often maligned by younger administrators and venerated by older administrators.

But how much security does sudo actually provide? How useful is it really?

Running sudo gives you some benefits – so one hears:

• Using sudo records everything someone does as root.
• Using sudo prevents a user from running continually as root, preventing errors.
• Using sudo prevents a user from having to know the root password.
• Using sudo prevents a user from executing anything they are not permitted to.

The problem is that sudo does none of these things very well.

Sudo does indeed record everything one does as root. How does this increase our security? How does this prevent a hacker from compromising a system?

The answer is it doesn’t; recording what someone is doing through this method provides no security at all. A hacker will not use sudo; a regular admin who is using sudo can just use sudo ksh to get a shell that will do what they want. In this way, sudo is merely security through obscurity: if you don’t know how to bypass it, you’ll be recorded. Sudo is like a security camera, watching what you are doing.

Certainly, if you are using sudo, you are not continually running as root – and this is indeed a benefit – and perhaps the primary one. However, there are many things that must be done that cannot be done with sudo. Changing into a restricted directory is just one of them.

It is also true that a user using sudo does not have to know the root password; this also can be a benefit. However, ssh should already be in use and can serve this purpose even better: using an individual’s key, that individual can be granted rights to the root account without knowing the root password – and revoked at will.

The last item is the most dangerous: that using sudo, users can be completely limited in what they can do. The best example of how this can be abused is the attempt of some to prevent the running of a shell by a sudo user. No matter what the sudo file says, one can always do this:

$ cd /bin
$ cp ksh ~/bugbear
$ chmod 700 ~/bugbear
$ sudo ~/bugbear

Instant root shell for anyone with sudo access, regardless of the restrictions in the sudo file. This can be done for any program, as long as the user can read the file it can be changed to a different name and run elsewhere – and if the file can’t be read it can’t be run.

So what are the answers? There are several that, when taken together, will do what sudo wants to do but better:

• Use SSH. Using ssh one can limit a user to a specific command, and prevent the user from knowing the root password.
• Use rksh. This may be too restrictive, but can permit users to execute only certain commands appointed by the administrator.
• Use a chroot jail (or better yet, a BSD jail). Again, this may be too restrictive for most, but will permit a user to only do what is allowed – on a much more restrictive basis than rksh.
• Use an auditing shell. Ksh93 provides this capability – though there may be a reason that this specific capability is not in the standard ksh supported on today’s system. Using an auditing shell, every command from every user, including system administrators, is logged and retained – possibly to another system on the network. Here is a good article on ksh93 auditing. I would posit, however, that if you can’t trust your system administrators then they shouldn’t be your system administrators: often auditing like this merely provides “a throat to choke.”

In particular, if you utilize the ssh public key encryption capabilities to their fullest with a logging ksh93 shell – and with a “captive” menu perhaps – you can provide the capabilities of sudo without the drawbacks. If you do use sudo, realize how serious its shortcomings are and be aware of them to increase your security elsewhere.

The real benefit of a password vault: security!

Using a password vault or a password safe can provide some ease and can simplify our lives nicely. However, what is the point of saving all these passwords when we can just type it in – or use Firefox or Opera to do it for us?

Let’s look at several and consider what they offer – and the hidden surprise that makes them most valuable. There are several that are worth considering depending on your environment – Apple’s Keychain, GNOME’s Keyring, KDE’s Kwallet, KeePass and KeePassX, and Passpack. The first three belong to that set of tools that provide for password vaults that are unlocked when you log into your computer. As long as you are logged in – and perhaps only until the screen saver kicks in or you log out – these tools will be active and your passwords automatically available.

KeePassX is part of a small set of tools that provide this capability, though in a cross-platform way.

Lastly, PassPack is an online password vault which is easy to use and provides for exports to other systems like KeePassX and its ilk.

What is it that provides a surprisingly high level of security with the use of these vaults? Simply this:

You can generate random passwords of arbitrary length that you need not even try to remember.

This is very powerful. Passwords no longer need to be memorized: so why try? The passwords can be generated by the associated password generator, and then copied or otherwise placed into the password field of whatever process is requesting authorization.

There is no pattern which makes it easier to crack – no combinations of words, numbers, etc – just pure randomness (or as close as one can get on a non-random entity like a computer).

Once you have a tool like a password manger in place, you can use a different password – a random password – for every site and every location that a password is needed.

A vulnerability walk-through

The FreeBSD kernel recently had a issue in the kenv(2) kernel call, and this article describes very well what it is – and why it is bad. The vulnerability itself is not terribly bad, but the problem exposed is a common one and shows how all user data must be vetted before it is used: a programmer must treat all user data as suspect.

In fact, there have been studies done by Professor Barton Miller at the University of Wisconsin showing that both commercial and open source programs (in a variety of operating systems) are vulnerable (to differing extents) to a constant barrage of random data.

If your code is to be secure, you absolutely must treat user data as hostile and unknown: any trust placed in the user will be abused by someone, either accidentally or purposefully. If by accident, the user will think your software broken and unreliable; if by purpose, your system (or someone else’s!) could be compromised.

Two excellent books on this topic (from two different angles) are these: Hacking: the Art of Exploitation (by Jon Erickson) and Secure Coding Principles (by Mark Graff and Kenneth van Wyk). The first will show you how broken code can be taken advantage of; the second will show you how not to write broken code.

Pwn2Own 2009: Browsers Fall

With the Pwn2Own contest at CanSecWest nearly over, nearly all of the major browsers have quickly fallen – which is unfortunate. In fact, Safari on the Macintosh MacBook fell in less than 10 seconds.

This year’s contest strongly brings the security of current browsers under scrutiny: Internet Explorer, Firefox, and Safari all quickly fell, allowing compromise of the machine they were running on. Google’s Chrome browser will come under fire on Friday.

ComputerWorld had a nice writeup.

The Dark Side of Cloud Computing

If you have information in “the cloud” instead of on your personal computer, there is a dark side that you should be aware of.

The information that you save to the cloud resides on servers elsewhere, such as California or Korea or Canada. Wherever those servers reside, there are laws that govern them and the corporation that controls them. These laws may permit access to that information that is much looser than where you are.

Even within the United States, there is a big difference between the data stored on your personal computer or laptop and the information stored on external servers. The United States government must get a warrant signed by a judge before searching your home (and home computer); however, a warrant is not necessary to get a corporation such as an Internet Service Provider (ISP) or others to give the police your data. Companies such as Google and others can be forced to give the police data without notifying you.

This data is not just on the servers, but can also be found on backup tapes as well. Some services – either by their nature or by design – will keep multiple versions of your data, so all past versions can be scanned.

Cloud computing can be brought in-house to some extent, most notably by using open source projects such as eyeOS (which provides a remote desktop). If you are truly concerned by leaving your data open, do not use unsecured network protocols, and do not set up a server with a hosting service: you must run your own server internally.

Other services will provide a key which encrypts the data on their servers – such that the hosting service cannot read any of your data. These are the best services to use, although they may be harder to find. The most likely cloud computing services to do this are backup services as well as those specializing in privacy.

For example, SpiderOak keeps all data on their servers encrypted – so even they can’t read it. Mozy appears to offer the same capability.

Password storage sites also have security built-in; both Clipperz and PassPack have encrypted all of the data on their servers, preventing anyone from reading your data.

However, Google Docs, Zoho, and Thinkfree Office all appear to keep data on their servers readable by anybody – thus, your data could be subponeaed by a court of law if necessary.

It’s unlikely that any of the “micro” services would offer encryption of your data – services like del.icio.us or Joe’s Goals or Zotero.

There is also the possibility of losing all of your data due to a site shutting down. Some sites, polished though they may be, are run by individuals or tiny companies; thus one should not rely on cloud computing alone. Backups should be replicated internally – including backups of all data stored externally.

One good example of this would be the service Magnolia – the service suffered a total data loss stemming from a disaster that took place in February.

Thus, like RAID, cloud computing alone is not a backup!