Email Security by Procmail 1.16

Ahir vaig estar llegint a fons el funcionament d’aquest filtre de correu per
procmail i esta molt bé, avui ha sortit una nova versió a
cotinuació enganxo la pàgina on indica el funcionament generic
del programa.

La url és
ftp://ftp.rubyriver.com/pub/jhardin/antispam/procmail-security.html

Enhancing E-Mail Security With Procmail

Latest News

Email-based Attacks

There are four types of attacks on system security that can be carried out
via electronic mail:

• Active Content attacks, which take
  advantage of various active HTML and scripting features and bugs.
• Buffer Overflow attacks, where the
  attacker sends something that is too large to fit into a fixed-size memory
  buffer in the email client, in the hopes that the part that doesn’t fit will
  overwrite critical information rather than being safely discarded.
• Trojan Horse attacks, where an
  executable program or macro-language script that grants access, causes damage,
  or does other unwelcome things is mailed to the victim as a file attachment
  labeled as something innocuous, such as a greeting card or screen saver, or
  hidden in something the victim is expecting, such as a spreadsheet or important
  document.
• Shell Script attacks, where a
  fragment of a Unix shell script is included in the message headers in the hopes
  that an improperly-configured Unix mail client will execute the commands.

---

Active Content Attacks, a.k.a. Browser Attacks, Active HTML Attacks or
Scripting Attacks

These attacks are aimed at people who use a web browser or HTML-enabled
email client to read their email, which these days is a very large portion of
the computing community. Typically these attacks attempt to use the scripting
features of HTML or of the email client to retrieve private information from
the victim’s computer or to execute code on the victim’s computer without the
victim’s consent (and possibly without the victim’s knowledge).

Less dangerous forms of these attacks can automatically cause the
recipient’s computer to display some content the attacker wishes, such as
automatically opening an advertising or pornography web page when the message
is opened, or perform a Denial-of-Service attack on the recipient’s computer
through code that freezes or crashes the browser or the entire computer.

The simplest way to completely avoid such attacks is to not use a web
browser or HTML-enabled email client to read your email. Since many of these
attacks do not depend on bugs in the email client software, they cannot be
prevented through patches to the email client. If you use a web browser or
HTML-aware email client, you will be vulnerable to these kinds of
attacks.

Also, as some of these attack depend on the email client being able to
execute scripted HTML rather than depending on the weaknesses of any particular
operating system, these attacks can be cross-platform. An HTML-enabled email
client on a Macintosh is just as vulnerable to active-HTML email attacks as an
HTML-enabled email client on Windows or Unix. The vulnerabilty will vary from
system to system based on the email client rather than the operating
system.

Switching to a non-HTML-aware email client is not a realistic option for
many people. An alternative is to filter out or alter the offending HTML or
script code before the email client gets a chance to execute it. It may also be
possible to configure your email client to turn off the interpretation of
script code. See your program documentation for details. Turning off scripting
in your email client is strongly recommended. There is
very little reason to support scripted email messages.

Microsoft Outlook users should visit this page that describes tightening
down Outlook’s security settings.

The recently-announced Outlook email worms are an example of this attack.

See the Bugtraq Vulnerability database for more details.

---

Buffer Overflow Attacks

These attacks can be used as Denial-of-Service attacks, because when a
program’s memory gets randomly overwritten the program will generally crash.
However, by carefully crafting the exact contents of what overflows the buffer,
it is in some cases possible to supply program instructions for the victim’s
computer to execute. The attacker is mailing a program to the victim, and it
will be executed by the victim’s computer.

Note that this is the result of a bug in the program under attack. A
properly written email client will not allow random strangers to run
programs on your computer without your consent. Programs subject to buffer
overflows are incorrectly written and must be patched to permanently correct
the problem.

Buffer overflows in mail programs occur in handling the message headers and
attachment headers, which is information the email client needs to process in
order to know details about the message and what to do with it. The text in the
body of the message, which is simply displayed on the screen and which is
expected to be a large amount of text, is not used as the vehicle for buffer
overflow attacks.

The recently-announced overflow bugs in Outlook, Outlook Express and
Netscape Mail are examples of this. Patches for Outlook are available via
the Microsoft security
site.

The message headers and attachment headers can be preprocessed by the mail
server to limit their lengths to safe values. Doing this will prevent them
being used to attack the email client.

---

Trojan Horse Attacks

These attacks are usually used to breach security by getting a trusted user
to run a program that grants access to an untrusted user, or to cause damage
such as attempting to erase all of the files on the victim’s hard disk. Trojan
Horses can also act to steal information or resources or implement a
distributed attack, such as by distributing a program that attempts to steal
passwords or other security information, or a program that mails itself around
(a “worm”) and also mailbombs a target (a worm with an attitude :).

For this attack to succeed the victim must take action to run the program
that they’ve received. The attacker can use various “social engineering”
methods to convince the victim to run the program; for example, the program may
be disguised as a love letter or joke list, with the filename specially
constructed to take advantage of Windows’ propensity for hiding important
information from the user.

This attack can be avoided simply by not running programs that have been
received in email until they have been checked over, even if the program seems
to be harmless and especially if it comes from someone you don’t know
well and trust.

Except…

Bugs in the email client or poor design may allow the attack message to
automatically execute the Trojan Horse attachment without user intervention,
through either the use of active HTML, scripting or buffer overflow exploits.
This is an extremely dangerous scenario and HAS BEEN
DEMONSTRATED in a public computer security forum.

In an attempt to prevent this, the names of executable file attachments can
be changed in such a way that the operating system no longer thinks they are
executable (for example, by changing “EXPLOIT.EXE” to
“EXPLOIT.DEFANGED-EXE“). This will force the user to save and rename
the file before it can be executed (giving them a chance to think about whether
it should be executed), and it reduces the possibility that other
exploits in the same message will be able to find and execute the Trojan Horse
program automatically (since the name has changed).

In addition, for known Trojan Horse programs the attachment format itself
can be mangled in such a way that the email client no longer sees the
attachment as an attachment. This will force the user to contact technical
support to retrieve the attachment, and gives the system administrator a chance
to examine it.

Unmangling a mangled attachment is fairly straightforward for the
administrator. In mangling the attachment the original MIME attachment header
is shifted down and an attack warning attachment header is inserted. No
information is deleted or altered. To reattach the attachment simply edit the
mailbox file with a text editor and delete the attack warning header, returning
the original attachment header to its original location.

Here is a list of recent Trojan Horse executables and documents, gleaned
from bugtraq and Usenet newsgroup warnings and antivirus vendor advisories:

*.chm
*.hlp
*.hta
*.js
*.shb
*.shs
*.vb
*.vbe
*.vbs
*.wsf
*.wsh
*.[a-z0-9][a-z0-9][a-z0-9].[a-z0-9]+ (to catch “double-extension”
attachments)
IBMls.exe
aol4free.com
babylonia.exe
badass.exe
buhh.exe
chocolate.exe
compu_ma.exe
happy99.exe
i-watch-u.exe
ie0199.exe
jesus.exe
list.doc
path.xls
photos17.exe
picture.exe
pretty park.exe
prettypark.exe
serialz.hlp
setup.exe
story.doc
suppl.doc
surprise!.exe
x-mas.exe
y2kcount.exe
yahoo.exe
zipped_files.exe

Another channel for Trojan Horse attacks is via a data file for a program
that provides a macro (programming) language, for example, modern high-powered
word processors, spreadsheets, and user database tools.

If you cannot simply discard attachments that may put you at risk, it is
recommended that you install anti-virus software (which detects and disables
macro-language Trojan Horses) and that you always open data file
attachments in the program’s “do not automatically execute macros” mode (for
example, by holding down the [SHIFT] key when double-clicking the
attachment).

Also: if your system administrator (or someone claiming to be your system
administrator) emails you a program and asks you to run it, immediately become
very suspicious and verify the origin of the email by contacting your
administrator directly.

---

Shell Script Attacks

Many programs running under Unix and similar operating systems support the
ability to embed short shell scripts (sequences of commands similar to batch
files under DOS) in their configuration files. This is a common way to allow
the flexible extension of their capabilities.

Some mail-processing programs improperly extend this support for embedded
shell commands to the messages they are processing. Generally this capability
is included by mistake, by calling a shell script taken from the configuration
file to process the text of some headers. If the header is specially-formatted
and contains shell commands, it is possible that those shell commands will get
executed as well. This can be prevented by the program scanning the header text
for the special formatting and changing that formatting before it gets passed
to the shell for further processing.

Since the formatting needed to embed a shell script in an email header is
fairly special, it’s fairly easy to detect and alter.

---

Filtering Email for Security

(Finally! The meat!)

Procmail is a
program that processes email messages looking for particular information in the
headers or body of each message, and takes actions based on what it finds. If
you’re familiar with the concept of “rules” as provided in many major user mail
clients (such as the cc:Mail client), then you are already familiar with the
concept of automatically
processing email messages based on their content.

This page provides you with a procmail ruleset specifically designed to
“sanitize” your email against these attacks.

Personal safety

Please see my Procmail Kit page for details
about how to use procmail, and a kit of rules that includes the sanitizing
ruleset as well as anti-spam filters. If you just want to sanitize your email
and don’t care about spam, then you can download and install just the
sanitizing ruleset. Note that the full kit has an older version of the
sanitizing filter, and is not currently being maintained.

The ruleset

The email security procmail ruleset is available at:
[ FTP
Mirror 1 (USA: UT) | FTP Mirror 2 (Europe:
NL) | HTTP
Mirror 1 (USA: WA) ]

A tarball of the ruleset and some other files is available at:
[ FTP
Mirror 1 (USA: UT) | FTP Mirror 2
(Europe: NL) | HTTP Mirror 1
(USA: WA) ]

If you are downloading this on a Windows system for use on a Unix or Linux
system, make sure that you take care of text-file conversion – the
script will not run properly with DOS end-of-line characters in it. One way to
do this is to open the sanitizer script in vi and type:

:textmode on
:textmode off
:wq

---

Site Safety

If you’re an administrator and you wish to sanitize all of your users’ email
automatically, here’s how to do it:

Requirements

• Your email must be received by a system that runs or can run procmail. See
  the procmail link above for information about obtaining and installing procmail
  for your platform.
• If you are running sendmail then it
  must be set up to use procmail as the local delivery agent. Look for the
  following line in your /etc/sendmail.cf file:
  

    Mlocal,    P=/usr/bin/procmail, F=lsDFMAw5:/|@qSPfhn9, S=10/30, R=20/40,
               A=procmail -Y -a $h -d $u
  

  
  
• If you want to install the sanitizer on a sendmail relay (for example, to
  protect a Microsoft Exchange system that is not directly connected to the
  Internet), follow these directions:
  [ FTP
  Mirror 1 (USA: UT) | FTP Mirror 2
  (Europe: NL) | HTTP Mirror 1
  (USA: WA) ]
• You must have perl installed.
• If you wish to scan attachments, you must have mimencode
  (which is a part of the metamail package) and mktemp
  installed. I have decided that Mime::Base64 from CPAN is better for
  this, so sometime soon the sanitizer will use that instead of mimencode.

Installation under *nix and workalikes (Linux, *BSD, etc.)

1. Create a directory /etc/procmail owner and group root,
   permissions rwxr-xr-x.
2. Download the sanitizing ruleset and save it in that directory, owner and
   group root, permissions rw-r--r--. If you are using Lynx,
   highlight the above link and press “D” to download the file – don’t view it and
   save it, it’ll be corrupted.
3. Create /etc/procmailrc owner and group root, permissions
   rw-r--r-- and put the following into it:
   

   DROPPRIVS=YES
   LOGFILE=$HOME/procmail.log
   PATH="/usr/bin:$PATH"
   SHELL=/bin/sh
   POISONED_EXECUTABLES=/etc/procmail/poisoned
   SECURITY_NOTIFY="postmaster, security-dude"
   SECURITY_NOTIFY_VERBOSE="virus-checker"
   SECURITY_NOTIFY_SENDER=""
   SECURITY_NOTIFY_SENDER=/etc/procmail/local-email-security-policy.txt
   SECURITY_QUARANTINE=/var/spool/mail/security
   POISONED_SCORE=25
   SCORE_HISTORY=/var/log/macro-scanner-scores
   SECRET="CHANGE THIS"
   INCLUDERC=/etc/procmail/html-trap.procmail
   POISONED_EXECUTABLES=
   SECURITY_NOTIFY=
   SECURITY_NOTIFY_VERBOSE=
   SECURITY_NOTIFY_SENDER=
   SECURITY_QUARANTINE=
   SECRET=
   

   
   

Of course, if you’ve already got an /etc/procmailrc file
you’ll have to incorporate the
INCLUDERC=/etc/procmail/html-trap.procmail call into what’s already
there.

Notes about local policy:

This will create a file named procmail.log in the home directory of
any user who receives mail. Your users should be instructed to periodically
review and delete this file, or an administrative daemon (e.g. logrotate)
should be set up to periodically collect statistics and delete the files or
warn the user to do so. If you don’t care to log the sanitizing messages and
possible exploit warnings, then change the logfile line to:

LOGFILE=/dev/null

Note that the DROPPRIVS at the beginning means the log file
must be writable by the recipient.

You may override the default list of executable extensions by setting
MANGLE_EXTENSIONS. The default list is:

MANGLE_EXTENSIONS='html?|exe|com|cmd|bat|pif|sc[rt]|lnk|do[ct]|xl[sw]|p[po]t|rtf|vb[se]?|hta|p[lm]|sh[bs]|hlp|chm|eml|ws[cfh]|ad[ep]|jse?|md[be]|ms[ip]|reg|asd'

Note that what you specify completely replaces the default list, so,
for example, if you don’t want to mangle .EXE files for some reason,
you’d specify:

MANGLE_EXTENSIONS='html?|com|cmd|bat|pif|sc[rt]|lnk|do[ct]|xl[sw]|p[po]t|rtf|vb[se]?|hta|p[lm]|sh[bs]|hlp|chm|eml|ws[cfh]|ad[ep]|jse?|md[be]|ms[ip]|reg|asd'

This can also be used to customize the sanitizer on a by-sender or by-recipient
basis. For example, if has a legitimate reason to send you .EXE
attachments, you might do something like this before calling the sanitizer:

:0
* ^From:.*
{
MANGLE_EXTENSIONS='html?|com|cmd|bat|pif|sc[rt]|lnk|do[ct]|xl[sw]|p[po]t|rtf|vb[se]?|hta|p[lm]|sh[bs]|hlp|chm|eml|ws[cfh]|ad[ep]|jse?|md[be]|ms[ip]|reg|asd'

}

This sort of thing can become arbitratrily complex.
If you don’t want to mangle document filenames, try this:

MANGLE_EXTENSIONS='html?|exe|com|cmd|bat|pif|sc[rt]|lnk|vb[se]?|hta|p[lm]|sh[bs]|hlp|chm|eml|ws[cfh]|ad[ep]|jse?|md[be]|ms[ip]|reg|asd'

They will still be scanned for poisonous macros and quarantined if appropriate,
but they will not be checked against the poisoned executables list
(see below).

Note that the MANGLE_EXTENSIONS settings you enter must
all be on one line.

If you wish to block specific executable and document attachments, create a
text file containing one filename or filespec per line, with no comments or
leading spaces, permissions rw-r--r--, and set the variable
POISONED_EXECUTABLES to point at that file before calling
html-trap.procmail. See above for a recommended list of filenames of
known trojans. The names in this list are not case-sensitive
and wildcards may be used. For example:

*.hta
*.vbs
*.chm
happy??.exe
happy[0-9]+.exe

Note that only extensions in the MANGLE_EXTENSIONS list are compared
against the poisoned executables file. Omitting .EXE from
MANGLE_EXTENSIONS means you will not be able to poison any
.EXE attachments. This is a design weakness in the current sanitizer.

If you wish to be notified when the filter traps poisoned attachments, set
SECURITY_NOTIFY and/or SECURITY_NOTIFY_VERBOSE to a
comma-delimited list of email addresses to notify. The
SECURITY_NOTIFY_VERBOSE recipients will receive a full copy of the
message, the SECURITY_NOTIFY recipents will only receive the
headers.

If SECURITY_NOTIFY or SECURITY_NOTIFY_VERBOSE are set,
then the message sender may also be notified of the message being trapped. To
do this, set SECURITY_NOTIFY_SENDER to any value. If you wish to
override the simple default message, set SECURITY_NOTIFY_SENDER to
point at a text file and that text file will be included as the body of the
message – I recommend you explain site policy there if you are blocking
attachments by wildcard. If SECURITY_NOTIFY_SENDER is set but not
pointing at a file, a simple default message will be sent. NOTE: Be
careful that you set it to something that is NOT a file if you don’t want to
override the default message. “SECURITY_NOTIFY_SENDER=/etc/passwd“,
for example, would be bad. “SECURITY_NOTIFY_SENDER=YES” is probably
safe. If you do not want to send a notification reply, you may want to set it
explicitly to empty (“”) to avoid any inherited value.

If you wish to quarantine poisoned messages, set
SECURITY_QUARANTINE to the file you wish to save the message in. This
will prevent delivery to the original addressees. It is suggested that
you set SECURITY_NOTIFY if you set SECURITY_QUARANTINE as
this will remind you to check the quarantine file. If for any reason the
message cannot be quarantined it will be bounced and the
SECURITY_NOTIFY list will be notified. If you want the (mangled)
message to be delivered instead of bounced, set
SECURITY_QUARANTINE_OPTIONAL to any value. The
SECURITY_QUARANTINE file must already exist – the sanitizer cannot
reliably create it on-the-fly.

Note that the DROPPRIVS at the beginning means that the security
quarantine file must be writable by users: access permissions on the
quarantine file must be -rw--w--w-. If this is a problem, you may want
to try setting the quarantine filename to /dev/null and rely on
SECURITY_NOTIFY_VERBOSE to keep a copy of the original message.

The sanitizer implements a scanner which checks Microsoft document and
worksheet attachments for macros that appear to be trying to do dangerous
things. Depending on what the macros in a document or worksheet try to do, you
may see false positives (safe documents being marked as dangerous). The score
at which an attachment is considered “poisoned” may be set via
POISONED_SCORE. If not given, it defaults to 25. The minimum
POISONED_SCORE is 5.

It appears that many virus scanners do not actually delete evil macros;
instead, they are mangled enough to disable them and are left in place. The
sanitizer will very likely detect enough of these fragments to consider the
document as still infected. If this happens, suggest to the sender of the
document that they save the document in a format that does not support macros
at all, such as Rich Text (RTF).

If you wish to completely disable macro scanning, set
DISABLE_MACRO_CHECK to any value. If you wish to scan and save the
scores to do profiling but not mark any attachments as “poisoned”, you can
either set SCORE_ONLY to any value (not recommended), or set
POISONED_SCORE to a very high value (100-200 is recommended – this
will trap currently known exploits while giving you a chance to profile). Set
SCORE_HISTORY to the name of the file to save scores in (with the same
DROPPRIVS caveats as the other log files).

All of these site policy customizations must be made in the procmail script
that calls the sanitizer, before the sanitizer is called, or they will have no
effect on the sanitizer’s behavior.

Suggestions for what to consider dangerous in a macro are welcome, as are
samples of infected documents.

---

News & Notes

The current version of the html-trap.procmail ruleset is: 1.116 It is recommended you update your copy if your version is older, as bugfixes and filtering for newer exploits will have been added. An announce list for email security issues has been set up. It will primarily carry information on new exploits and updates of the sanitizer. To subscribe, send a message with the subject “subscribe” to esa-l-request@spconnect.com. This page is now being tracked by the Daily Diffs service.	Click below to receive email when this page changes * Powered by NetMind *	Click below to receive email when this page changes		* Powered by NetMind *
Click below to receive email when this page changes
* Powered by NetMind *

08/04/00 Okay, don’t trigger the Excessively Long Header trap until the
header exceeds 250 characters. Added asd to the default
MANGLE_EXTENSIONS. If you are overriding the default list you should add it to
your custom list. Fixed a problem where it was possible for the sanitizer to
overlook every other attachment in a series of document attachments. Added
clearing of the MIME content type if the attachment filename gets mangled, to
prevent the mail program from figuring out what program to run even though the
filename is mangled. For the same reason, drop x-mac-* clauses that Eudora uses
to indicate the file type and restore the filename extension.

07/26/00 Bugfix in NOTIFY SENDER.

07/23/00 Added checks for certain excessively long standard headers, to
address the MS Outlook header buffer-overflow bug; previously only MIME-related
headers were length-limited, and only in MIME messages. Disabled sanitizing of
encrypted/signed messages; changing the body of such a message breaks the
signature, so there’s no good way to sanitize it. Moved DROPPRIVS=YES
into the sanitizer itself to avoid configuration errors – this may break
gateway use, watch it closely. Enabled scanning of PowerPoint files, which
weren’t being scanned due to an oversight (D’oh!). Improved handling of RFC822
comments embedded in unquoted attachment filenames. Improved handling of
filenames containing international characters. Added a debugging mode – if you
want to see the poisoned filespecs it is comparing attachment names to, define
$DEBUG to be anything. Improved loop-prevention in notification messages; if
you want to secure your system against someone forging the X-Loop: headers in
an attempt to suppress attack notification messages, define $SECRET to be a
short string of random text.
Given the severity of the Outlook BO bug, you probably want to install the
updated sanitizer right away.

05/18/00 (Announcement here delayed, sorry) Okay, it’s happened. A
working demonstration attack that uses a combination of active-scripted HTML
and a scriptable attachment (in the form of a Microsoft Compiled Help file) to
automatically save and execute an arbitrary program remotely via email
without the user having to double-click on an
attachment has been posted to Bugtraq. This means that, for
example, someone could email you a copy of Back Orifice that would install
itself on your computer the moment you simply previewed the message in your
mail client.
Make sure that chm appears in your MANGLE_EXTENSIONS
list and that *.chm is in your poisoned executables list. You should
also visit this page
that describes tightening down Outlook’s security settings.

05/22/00 Added some new executable extensions to MANGLE_EXTENSIONS. See
above for the new default. Fixed a bug that prevented macro scanning if
document attachments were in MANGLE_EXTENSIONS. Dynamically set LINEBUF so that
we’re no longer vulnerable to extremely long To: headers.

05/14/00 Fixed a bug in notification. Added error logging on failure to open
poisoned spec file.

05/13/00 Made sender notification optional. Added ability to specify
executable extensions list in configuration file. No more script updates for
new executables! Site-customized executable mangling!

05/12/00 Improved sender notification. Added quarantine reliability
assurance (i.e. bounce if quarantine fails).

05/10/00 Added “.vbe” to the executable extensions list. You should add
“*.vbe” to your poisoned executables list. Fixed a problem where a message that
was *only* a poisoned executable (e.g. no text body at all) wouldn’t be
quarantined.

05/06/00 Added “.wsf” and “.wsh” to the executable extensions list. Fixed
another DoS bug in header fixups. Fixed a missing executable extension in the
UUE checker. Added notification of the message sender on hits.

03/26/00 Added “.eml” to the executable extensions list. Dynamic
configuration of this soon…

02/01/00 Improved handling of quotes in tag arguments.

01/22/00 Sanitizer now deals with attempted obscuration of tag options with
and % escapes.

01/14/00 Fixed another DoS bug in certain quoted strings, and generally
improved quoted string and wrapped-header handling.

---

Troubleshooting

If you get “Word too long” errors, try adding
“SHELL=/bin/sh” or “SHELL=/bin/ksh” to
/etc/procmailrc just before the call to html-trap.procmail –
csh can’t handle a
command-line argument the size of the Perl script that’s in the filter.

Do not put html-trap.procmail into
/etc/procmailrcs/ as implied by the procmail
man page. You’ll get security errors from Perl about -e and setuid scripts if
you do this. You may also have problems with filtering mail sent to root for
this reason.

It looks like this perl script can be a bit of a memory hog on some systems.
If you start getting “Out of memory” errors in your procmail log file, try
adding

ulimit -d 15000;

just before the perl -p -e in the MIME-sanitizing rule:

:0 fw
| ulimit -d 15000; perl -p -e ' #

You might also have to increase the hard memory limit originally set for
sendmail.

---

I can be contacted at – you could
also visit my home page.

---

Best viewed with Any
Browser

$Id: procmail-security.html,v 1.101 2000-08-04 17:33:36-07 jhardin Exp
jhardin $

Carnivore – FBI Sniffer

Últimament tothom parla d’aquest sniffer q l’FBI usa per espiar als
delinqüents com q no tinc temps de mirar com funciona, enganxo un escrit q
he trobat d’un tio q diu q l’ha vist/usat.

Statement of Tom Perrine

Computer Security Office, San Diego Supercomputer Center

Subcommittee on the Constitution

Monday, July 24, 2000

Mr. Chairman, and Members of the Subcommittee. Thank you for inviting me to
testify
on this important subject.

From the beginning of my career in computer security, I have always been an
advocate of
personal privacy, unrestricted personal access to strong encryption, and less
government
oversight and intervention in the lives of law-abiding citizens. In the course
of my career I
have also designed and developed computer systems to protect classified
government
information, deployed nation-wide security systems to protect privacy and
intellectual
property and consulted on computer security to educational institutions, the
Department
of Defense and public and private organizations. Due to my work in detecting
and
analyzing computer intrusions, I also understand and support legitimate law
enforcement
access to Internet traffic.

Introduction

I believe that this current debate over the FBI’s new digital wiretap tool,
commonly known
as “Carnivore”, is really about the risks in naively attempting to simply
translate the
policies, law and practices of telephone wiretaps into the digital realm of the
Internet. The
Internet is fundamentally different from the telephone system. As we attempt to
provide
access to Internet traffic for the legitimate purposes of law enforcement, we
must be
exceptionally careful to avoid extending the scope and depth of current wiretap
and
surveillance access in new and unintended ways.

However, in order to get to the heart of the matter, it is necessary to
describe the Carnivore
system and describe its abilities to monitor the Internet. Additionally, I will
describe how
the Internet is different from the telephone system, and illuminate some
problem areas that
may open the door to extending the government’s ability to monitor citizens in
unintended
and intrusive directions.

Privacy and Security at the San Diego Supercomputer
Center

In my current duties, I wear two hats, one as a protector of privacy and the
other as a
security researcher.

As the security officer for the San Diego Supercomputer Center (SDSC) my
primary and
overriding mission is to protect the privacy and intellectual property of the
users of the
Center. SDSC is a national laboratory for computational science and
engineering. With
about 6000 users, several hundred computers and five supercomputers, including
he
world’s 9^th fastest supercomputer (Blue Horizon), with Terabytes of
data and numerous
high-speed network connections and we are under constant attack by would-be
computer
intruders. SDSC’s users are performing basic research in fields as wide-ranging
as astro-physics, engineering, life sciences, ecology and medicine. Premature
publication,
destruction, modification or theft of their data could have implications
ranging from
academic embarrassment through the theft of intellectual property worth
millions (or
possibly even billions) of dollars.

As a security researcher and the Principal Investigator of the Pacific
Institute for Computer
Security (PICS), I am constantly working to determine future threats to the
computers
attached to the public Internet, as well as threats to the actual Internet
infrastructure itself.
Researchers at PICS have in the past discovered software flaws in popular
operating
systems as well as vulnerabilities in the basic protocols of the Internet. I
provided
testimony on this topic to the President’s Commission on Critical
Infrastructure
Protection.

The San Diego Supercomputer Center, the Pacific Institute for Computer
Security and
other security activities are sponsored in large part by U. S. Government
activities. These
include the National Science Foundation, the National Institutes of Health,
the
Department of Defense, the Institute for Defense Analyses, the National
Security Agency
and the FBI. PICS’ involvement with the FBI has been limited to a small amount
of
technical assistance for the San Diego office. PICS and other SDSC staff have
provided
expert testimony in cases involving child pornography and computer
intrusions.

It was as a PICS researcher, discussing critical infrastructure
vulnerabilities with the FBI,
that I became aware of and was afforded a chance to see the hardware and
software product
known as “Carnivore”. The date was June 20^th of this year, and the
location was the FBI’s
Engineering Research Facility (ERF) in Quantico.

There are several important issues at play here, and the capabilities and
purpose of
Carnivore may be the least important. All of my observations concerning
Carnivore itself
must be considered in the context of my very limited access to Carnivore. I can
only testify
about what I was told and what I observed concerning Carnivore over a very
short period
of time.

What is Carnivore?

First of all, what is Carnivore? In technical terms, Carnivore is a
high-speed packet “sniffer”
with aggressive filtering capabilities. It examines all the data packets
passing through a
network, and filters out data that does not meet its filtering criteria. In
layman’s terms,
Carnivore is a digital wiretap capable of discarding all information that is
not to or from or
concerning the subject of the wiretap order.

In fact, other than its fancy, easy to use graphical user interface, and its
ability to monitor
high-capacity networks, Carnivore is not very different from the various packet
sniffer
programs available to network managers, system administrators, home computer
users and
so-called “hackers”.

By analogy, if the network is the cellular phone system, packet sniffers are
radio scanners,
capturing or listening to all data that goes by in the air or on the wire. Also
by analogy,
Carnivore is a “smarter” scanner, capable of detecting and recording only those
phone calls
to or from a specific person, or containing certain key words, and not
listening to all the
other users of the cellular system.

Carnivore’s major technical novelty is its apparent aggressive intent to
avoid capturing data
concerning those that are not the subjects of a wiretap order. It is
functionally very similar
to software written by Dr. Andrew Gross (of the Kevin Mitnick case) while he
was the
Principal Investigator of PICS in 1997.

Physically, Carnivore is a personal computer with a network interface, and
ZIP or Jaz
removable disk drive, running a version of the Microsoft Windows operating
system, with
the Carnivore software loaded. In order to use Carnivore, it must be physically
attached to
the network to be monitored. The Carnivore software has a Graphical User
Interface
(GUI) which presents the user with an easy-to-use way to describe the filters
that are to be
used in accepting (and recording) or rejecting network data seen by the system.
The user
interface was designed to be used by a less-technical user, such as an FBI
Special Agent in
the field. The version of Carnivore I saw, as it was described to me had few
provisions for
remote access to the gathered data, but did have the capability to be monitored
itself from a
remote site via telephone. As described to me, this was so that the technical
support staff at
the ERF could assist with technical problems, and so the assigned Special Agent
could
determine when the removable media needed to be changed. This remote access
method
would also allow a remote user to change the filtering criteria from a remote
site via a
telephone call.

As described to me, all gathered data was written to a ZIP or JAZ removable
disk drive,
and the data would be physically collected by a Special Agent visiting the
site. There are
issues involving the collection, storage, custody, and admissibility of digital
evidence. I
believe that this physical collection of the evidence is a conscious effort to
move this
“digital” evidence into the realm of physical evidence, which is well
understood by and
more comfortable to the legal system. Although the system is capable of
transmitting some
gathered data via the telephone connection, this is impractical given the
relative bandwidth
of the telephone and the high-speed networks being monitored.

What is Carnivore Not?

Carnivore does not appear (on its face) to be an ECHELON-like
“monitoring
infrastructure”, capable of real-time monitoring of millions of phone calls and
network
connections. Based on my limited examination of Carnivore, and technical
discussions with
its developers, it appears to be a tool specifically designed to meet the rigid
requirements of
a Title III wiretap order. Such an order is supposed to be a narrowly drawn and
rigidly
interpreted permission from a judge to monitor the electronic activities of a
specific person
or persons.

Quite frankly, Carnivore appears to be the best available technology to try
to implement
the limited permissions to monitor granted by a judge. The device is
capable of filtering
out information concerning those not subject to the wiretap order.

However, Carnivore is just a tool, and its capabilities must be considered
in the context of
how it could be used, the potential for intentional and
unintentional abuse, and the critical
need to consider the privacy and constitutional rights of citizens.

Privacy is “Extrinsic” to technology

Carnivore is just a tool. It is a tool that appears to be designed to be
able to allow the FBI
to balance the rights of citizens against the permission to monitor granted by
a judge in a
wiretap order. However, it is how the tool is used that will actually determine
whether or
not the privacy of innocent and uninvolved people will be violated.

Carnivore has the ability to filter out all “un-allowed” information, but
like any network
sniffer, the actual data collected or rejected is a matter of the configuration
of the device. It
is obvious that there is nothing to stop a person from using Carnivore (or any
other packet
sniffing tool) to gather all the network information they can store.

The fundamental issue really boils down to:

How do we balance the government’s legitimate need to monitor suspects in
ongoing
criminal investigations without trampling the rights of other citizens who
happen to share
the Internet with them?

Carnivore appears to be an attempt to strike such a balance. However,

It still may open too many possibilities for abuse, error and other
unintended
consequences.

Any technology, once created, can be abused. Automobiles enabled bank
robbers in fleeing across state
lines; and pagers, cellular and portable telephones enable the illegal drug
dealer. Packet sniffers are one tool
of the “hacker”, but are also needed by the network manager. These are all
“dual-use” technologies, having
both legitimate and non-legitimate uses. It is the use that determines intent
and effect; the technology just
enables the capabilities.

Of course, the ultimate concern of citizens should be the possibility of
“mass monitoring”
of all the users at an Internet Service Provider (ISP), a company, a
University, or a state or
a country. The technology already exists, it is simply a matter of time and
money to deploy
this technology on the scale required to achieve the goal.

The Internet is Different

The Internet is fundamentally different from the original analog telephone
system. This is
important to understand, because almost all of our legislation, legal precedent
and practice
in monitoring the Internet are derived from the old analog telephone
system.

The telephone system is a collection of tightly integrated systems, operated
by various
companies, sharing a common switching technology. Without this underlying
common
technology, the various parts of the system would be unable to communicate with
each
other in order to provide a telephone connection between the callers. In the
telephone
world, a wiretap order is often implemented the telephone service provider. In
this case,
the law enforcement agency delivering a directive to the operators of the
subject’s telephone
service provider, and the service provider performs whatever action is needed
to provide
access to the subject’s telephone calls. The calls are typically voice, not too
frequent, and
listened to in “real time” by people, in addition to any recordings that may be
made. All of
these factors provide a “gating” function that limits the scale and scope of
any surveillance
activities. It is simply infeasible for the government to implement wide-scale
monitoring of
large numbers of people, due to the need for cooperation from the telephone
service
providers and the labor-intensive nature of the surveillance. This is likely a
major reason
that the National Security Agency and other government agencies have long
sponsored
basic research in speech recognition.

However, the Internet is fundamentally different, and with Carnivore and
other systems,
the monitoring activity is different as well. It is apparent that the digital
nature of the
Internet allows a wider net to be cast, at a lower cost than in the telephone
world. The
Internet is a digital medium, and most of its data remains text-based. These
two attributes
combine to make it very easy to use computers to process large amounts of
collected data.
Textual data is much easier and cheaper to process than voice telephone, for
example. Also,
the government installs Carnivore with little or no participation from the
Internet Service
Provider (ISP). The ISP has no way of knowing what data is being gathered or
who the
target of the wiretap may be. As previously mentioned, the filtering done by
Carnivore can
be changed remotely, without the knowledge of the ISP, as well.

All of these factors combine to provide a capability that is broader and
more scalable than
in the analog telephone world, for which most of the wiretap statutes were
written.

It is important to ensure that any digital wiretap capability and law does
not allow what
Dr. Steve Bellovin of AT&T calls “scaling up to oppression”. It should
remain relatively
expensive for the government to monitor its citizens, so that this capability
will be reserved
for those exceptional cases that warrant electronic surveillance and discourage
casting a
wide net that will gather in information about unintended bystanders.

Any digital wiretap systems and law must provide the same protections,
checks and
balances that exist in the telephone world. It is not obvious that this is
currently the case.
It seems likely that the “law of unintended consequences” applies and that
current digital
wiretap capabilities and legal constraints do not provide the same protections
as in the
telephonic environment.

Control, Oversight and Accountability

If a “dual-use” technology, such as Carnivore and other network monitoring
tools exists,
the only way to protect against mis-use is to find ways to discourage, or
punish abuse.

This is explicitly embodied in current wiretap law, where there are
consequences ranging
from inadmissibility of evidence up to criminal prosecution for an improperly
performed
wiretap. But in order to impose these consequences, the improper activities
must be
discovered. Also, by the nature of a telephonic wiretap, the scope of the
wiretap is limited
to a small number of telephones and the people who use them. With a digital
wiretap, such
as Carnivore, only the FBI knows who is the subject of the wiretap, and whether
or not
data concerning other people is actually being gathered.

It would be trivial for the FBI to monitor ten or a hundred or a thousand
(or more) people
with a single Carnivore system, using a wiretap order which only authorized
monitoring of
a single subject. Essentially there is no way for any outside entity to know
the
configuration of the filters in a Carnivore system, or the true capabilities of
the Carnivore
system without examining the source code of the system during installation and
during the
monitoring itself.

Carnivore and Open Source

The ACLU and others have called for publication of or access to the source
code of the
Carnivore system. While interesting, this is unfortunately insufficient to
determine the true
capabilities of a particular Carnivore system as installed for any given
wiretap order. A
function of a Carnivore system is determined both by the program and the
filter
configuration active at any moment in time.

A one-time publication or review of the source code would provide only a
“snapshot” of
Carnivore’s capabilities, and it might be difficult to prove that the Carnivore
program
installed at an ISP was actually built from the sources reviewed. Since
Carnivore is under
constant development, the snapshot reviewed would be out-of-date within a few
weeks. A
review of the source code would not indicate the filters installed in a
Carnivore system at
any given time.

In the computer security and cryptography communities, no claims are
accepted until
programs or algorithms have undergone public scrutiny and peer review.
Typically,
security-relevant software then remains in the public purview, with many
contributors
making incremental improvements and continuing the review process. For our
computers,
and those at any site truly concerned with security, Open Source security tools
are compiled
from publicly available, peer-reviewed source code. These programs are widely
trusted
because it is believed that this public scrutiny would find and publicize most
flaws and any
“secret” functions. This affords a high level of confidence that these programs
perform
their stated functions properly, and not perform any inappropriate
functions.

It may be that to provide this level of confidence, that the source code for
Carnivore might
need to become publicly available, and that ISPs be permitted to acquire,
examine, compile
and configure the Open Source Carnivore software. Interestingly, this is more
analogous
to the current telephonic wiretap (installed by the telephone service
provider), than the
current use of Carnivore.

Conclusion

The issue of Carnivore is not really about technology. It is really about
the attempts of the
government to extend its lawful and appropriate access to electronic
communications into
the digital Internet realm. It seems that in the process of applying laws,
policies and
procedures into the digital realm, that the privacy of citizens has been eroded
in ways not
intended or permitted under the original wiretap legislation, current practice
or Supreme
Court decisions.

The FBI will always have to live with the legacy of the Hoover era, just as
the Congress will
have to constantly compare itself with the McCarthy hearings, and the Executive
Branch
must always remember Watergate. These and other incidents from our country’s
history
have contributed to an unfortunate general distrust of our public institutions
when they
concern themselves with the rights of our citizens.

I continue to have the utmost regard for the Special Agents it has been my
good fortune to
meet and work with. I understand and support their need for legal and proper
access to the
electronic communications of those subject to investigation for serious crimes.
The
challenge will be to provide the intended monitoring abilities that are
reasonable and
proper in the digital area.

Ladies and Gentlemen of the Subcommittee, thank you for your attention in
the matter,
and for the opportunity to provide this testimony.