Penguin's Security Level Penguin is designed to implement a layer of security around applications. However, a language can't do everything, and Penguin relies on several key assumptions which might be used to mount attacks on Penguin-aware services. If you're planning on using Penguin for secure work, you should be aware of the risks and what you can do to ensure your security. The short story is that without privileged access to one of the two machines involved in the transaction, an intruder has no known way to cause a drastic failure in Penguin. Further, without privileged access to your machine, an intruder has no way of forcing you to run dangerous code. And, in all cases, Penguin does not add appreciably to the danger of running a machine connected to an insecure network. However, please don't take my word for it. Read the following document carefully, mull the issues, read the source code, examine the algorithms involved (they're all published and non-proprietary), and decide for yourself the risk factor. After all, Penguin is offered freely, with no warranty, and by using it you agree that I am not liable for any damages caused by the software, so I've got nothing to lose by lying. :) THE KNOWN ATTACKS 1. Alice is sending a Penguin application to Bob. Maeve, listening in on the network, is able to determine a) that Alice is sending an application to Bob, b) that Alice and Bob have Perl 5.002 or greater installed, c) that Alice and Bob have Penguin installed on their machines, d) the text of the source code being sent, e) Alice's public PGP key (if Alice is using the PGP Wrapper) f) that Alice has PGP installed (" " " ") g) the time. attacks that can be mounted with this information: 1. Maeve can use the fact that Alice is communicating with Bob to mount attacks through other channels (perhaps by calling up Bob on the phone, pretending that she's Alice, adding verisimilitude to her story by talking about the Penguin application) What to do: make sure that the fact of your communication does not convey information you're not willing to convey (i.e. don't send Penguin applications to illicit lovers over an insecure network). 2. Maeve can use yet-unknown security problems in Perl to completely infiltrate both machines. What to do: don't worry; trust that Perl's been seen by enough people that it doesn't have time bombs that throw open the gates to intruders. The probability of this attack is vanishingly small compared to others. 3. Maeve can use yet-unknown security problems in Penguin to completely infiltrate both machines. What to do: examine the source code. Communicate with strong Perl coders who have examined the source code and get their opinions. Write code that attempts to overcome the (small, relatively straightforward) Safe module, which is the linchpin of Penguin's security. Do not trust Penguin just because this ASCII document suggests that it's a good idea. 4. Maeve can examine the text of the code being sent and exploit bugs in it to cause security breaches. What to do: write good source code. In the future, you may have the option of encrypting your source code at the same time that you sign it. However, that will only be security through obscurity. This attack is easily foiled by not trusting anyone with operations that could conceivably cause security holes; however, I personally feel one can relax enough to trust good coders with most of those operations. Another thing to do is to wait for encrypted IP. 5. Maeve can, knowing Alice's public PGP key, attack it and compromise her secret key. Maeve can then pretend to be Alice, and can send Bob a Penguin application that uses Alice's rights. What to do: feel relatively safe from this attack. If Alice chooses a large (1536-bit-modulus or greater) PGP key, then it's conjectured that breaking it using known methods is mathematically impossible before the universe collapses. Read Bruce Schneier's _Applied Cryptography_ for details in this area. 6. Maeve can use the fact that Alice uses PGP against her. What to do: worry if, and only if, the fact that you use PGP can be used to harm you in some way. For example, worry if you're the offspring of a U.S. Senator who hates the fact that cryptography is in the hands of the public; your exposure could be embarrassing. Everyone else should examine his or her own country's laws on encryption and PGP to determine if it's legal. Commercial users should examine the RSA patents and the PGP copyright to determine legal liability. 7. Maeve can discover the time according to Alice's machine. What to do: don't worry, unless the time on your machine can be used to breach security through other methods. As an example, the Kerberos security system relies on all machines across the network having virtually the same time. An intruder might be able to mount an attack against Kerberos if they know that your machine is sufficiently out of synchronization with another Kerberos machine on the network. 2. Alice is sending a program to Bob. Maeve is actively on the network, and can intercept programs and place fraudulent programs on the net. 1. Maeve can make sure the program never gets to Bob, but can forge a return data packet that looks like the code got there. Or, she can change the data packet that Bob does send. What to do: only believe in code that is signed by a known signing authority. Currently, Data packets are not signed, but Code packets can be. Use other channels to verify sending and receipt of critical messages. 2. Maeve can intercept Alice's program and send her own bogus program. What to do: don't worry. Maeve cannot pretend to be Alice, because Maeve cannot replicate Alice's digital signature or extract it from the program. Maeve cannot alter the signed code without destroying the digital signature. Consult the PGP documentation for further discussion. 3. Maeve can run a denial-of-service attack against Alice's or Bob's machine by flooding either machine with an onslaught of Penguin traffic. What to do: make sure that your machine is properly firewalled against networks accessible to malicious third parties. This problem is endemic to insecure networks, and cannot be dealt with properly in software; future releases of Penguin daemons which communicate with insecure networks will take whatever measures can be taken to eliminate these. 3. Alice is sending a Penguin application to Bob. Maeve has non-privileged access to Alice's or Bob's machine. There are no known Penguin-related attacks that a user without access to Bob's or Alice's files or processes can mount. In addition, I personally believe that they have a vanishingly small chance of existing. 4. Alice is sending a Penguin application to Bob (have you noticed that she does this a lot?). Maeve has privileged access to Alice's or Bob's machine. 1. Maeve can perfectly pretend to be the person whose machine she has compromised. What to do: don't give people whose machines might be compromised the ability to perform powerful or possibly insecure operations on your machine using Penguin. 2. Maeve can perfectly pretend to be everyone else, to the person whose machine she has compromised (by altering the perl binary, the pgp binary, etc.) What to do: don't let your machine get compromised. Set up defenses (such as Tripwire, Cops, MD5 checksums, hardware read-only binary/script directories) in proportion to your perceived loss in the event that such a compromise occurs. 5. Either Alice or Bob is Maeve. What to do: trust people only so far. Don't give powerful rights to people who might be malicious, corrupt, subversive, or merely hideously erroneous (i.e. human), and all other things being equal, you'll only get damaged in proportion to the degree to which you leave yourself open. 6. Felix Gallo, Malcolm Beattie, Tim Bunce and/or Larry Wall are malicious hackers out to get you. What to do: read the source code carefully to ensure that in the event that one of us is malicious, evil, or stupid and has reflected that in the code, that your security is not compromised. If you're not a perl hacker, then ask someone who is to verify the code and warrant its probability of tameness. If you've read this far, then good for you! You've possibly gained some understanding of the issues involved in using and implementing a language and protocol designed to work across insecure networks with untrusted endpoints. If you don't trust the Penguin author -- and with the relatively low amount of public scrutiny my code has received as of this writing, you probably have no good reason to do so -- then I urge you to read the code, examine the algorithms, understand the motivations, and attempt to break it yourself. Only when enough of that sort of behavior has happened to Penguin will it truly be "safe to use". Felix Gallo Thu Apr 11 17:53:31 CDT 1996 updated Wed Apr 17 14:04:42 CDT 1996 rechecked Tue May 13 14:53:17 EDT 1997