This official notice largely restates our position as given in the
BUGTRAQ discussions of fragmentation attacks in late August. CBAC (IOS
Firewall Feature Set) information has been added, there are release
dates, and there are more details.
-- J. Bashinski
Cisco PSIRT
-----BEGIN PGP SIGNED MESSAGE-----
Field Notice:
Cisco PIX and CBAC Fragmentation Attack
Revision 1.1
For release 08:00 AM US/Pacific, Friday, September 11, 1998
Cisco internal use only until release date
==========================================================
Summary
=======
Neither Cisco's PIX Firewall, nor the Context-Based Access Control (CBAC)
feature of Cisco's IOS Firewall Feature Set, protects hosts against certain
denial of service attacks involving fragmented IP packets. This
vulnerability does not permit network "breakins". The vulnerability is most
severe in configurations involving static NAT entries, or in configurations
not involving any use of NAT.
The vulnerability is present in Cisco PIX firewall software up to and
including version 4.2(1), and in CBAC versions of Cisco IOS software through
11.2P and 11.3T, and will be present in initial 12.0 revisions of CBAC
software.
The Cisco Centri firewall does not share this vulnerability.
Stateless packet filtering products, such as the extended access lists
available in non-CBAC versions of Cisco IOS software, share the
vulnerability because of the inherent limitations of stateless operation.
This it is not considered a defect in stateless filtering. More information
is in the section on "Stateless Packet Filters" in this document.
This vulnerability will be fixed in Cisco PIX Firewall software version
4.2(2), which is tentatively scheduled for release on September 14,
1998. The vulnerability is scheduled to be fixed for CBAC in Cisco IOS
software release 12.0(2) and 12.0(3)T, which are tentatively scheduled
for release in late November, 1998, and in late January, 1999,
respectively. All schedules are subject to change.
The possibility of IP fragmentation attacks against packet filters, from
Cisco and other vendors, has been widely known for a very long time.
However, exploitation does not seem to be increasing. Therefore, Cisco does
not believe that the majority of its customers are critically exposed by
this vulnerability. Cisco is, however, prepared to support any customers
who suffer actual attacks, or who have specific reason to think that they
are likely to be attacked in this way.
Who Is Affected
===============
All users of Cisco PIX Firewalls with software versions up to and including
4.2(1) are affected. Users of the CBAC feature on Cisco IOS software
versions up to and including 11.2P and 11.3T (all edit levels), as well as
12.0 versions and 12.0T versions up to and including 12.0(1) and 12.0(2)T,
are also affected.
A similar vulnerability affects all users who rely on stateless packet
filtering products, from Cisco or any other vendor. The packet filters
affected are those which are capable of filtering based on information, such
as TCP or UDP port numbers, that may not be present in every fragment of a
datagram. This vulnerability is not considered a defect for a stateless
packet filtering product.
Packet filtering using non-CBAC Cisco IOS software extended access lists
falls into this category of stateless filtering, and such access lists are
vulnerable in all versions of Cisco IOS software. The affected extended
access lists are numbered lists from 100-199, or named access lists created
with the "extended" keyword. Non-extended Cisco IOS access lists, numbered
from 1-99, are not capable of filtering on port numbers, and are not
affected.
Impact
======
Even though the firewall keeps an attacker from making actual connections to
a given host, he or she may still be able to disrupt services provided by
that host. This is done by sending many unmatched non-initial IP fragments,
which use reassembly resources on the target host. Hosts vary widely in the
quality of their resource management and in their response to this attack.
Some hosts can be made nearly useless by traffic levels that might
realistically be available to attackers.
The attack can be launched only against hosts to which the attackers can
address packets. If dynamic NAT is being used, attack packets can be sent
only to hosts which are actively communicating with the Internet, since NAT
translation table entries will not exist for other hosts.
Because the firewall drops only the initial fragments of blocked datagrams,
attackers can exploit this vulnerability by sending streams of complete
fragmented packets. The attacker in this case deliberately intends the
initial fragments to be blocked by the firewall. Since only the non-initial
fragments will be forwarded, the effect on the target host will be similar
to the effect of sending only the non-initial fragments to begin with. This
method involves some waste of the attacker's resources, and is therefore
slightly less effective than simply sending the non-initial fragments alone.
This method is of interest because it allows attacks to be launched using
relatively standard networking tools, without any special exploit program.
PIX Firewall Details
====================
This vulnerability on the PIX Firewall has been assigned Cisco bug ID
CSCdk36273.
Problem description for the PIX Firewall
- --------------------------------------
PIX firewall software up through version 4.2(1) will pass any non-initial
fragment destined for any host for which either a static or a dynamic NAT
table entry exists. Static NAT table entries are created with the PIX
Firewall static command, and dynamic entries are created by inside hosts
initiating IP traffic exchanges with outside hosts. No checks are made as to
whether or not non-initial fragments belong to actual existing connections,
so it is possible for any outside host to send fragments to any inside host
that has a NAT entry, regardless of whether or not there is a connection
between the two hosts, and regardless of whether a conduit is configured.
Immediate Response for the PIX Firewall
- -------------------------------------
The following changes have been made to the behavior of the PIX Firewall for
version 4.2(2):
* Interfragment state is now being kept. Any non-initial fragment will be
discarded unless the corresponding initial fragment was permitted to
pass through the firewall. Non-initial fragments received before the
corresponding initial fragments will be discarded.
This eliminates the possibility of overloading host resources with
unmatched non-initial fragments, and requires attackers to use
relatively elaborate address spoofing for attacks using unmatched
initial fragments.
This change may have undesirable effects in certain cases, since it
will result in the firewall's discarding any datagram whose fragments
arrive out of order. There are a number of circumstances that may cause
out-of-order delivery of legitimate fragments. Cisco therefore advises
caution in installing the new software, although Cisco does not believe
that legitimate out-of-order fragmented traffic (or indeed fragmented
traffic of any kind) is common at Internet firewalls.
* Fragments received for hosts without conduits are discarded unless
those fragments can be matched with active connections. Matching is
performed using IP source and destination address and protocol type.
* The amount of memory dedicated to fragmentation state is limited in
order to reduce the chance of denial of service attacks against the PIX
Firewall itself. Fragmentation state is created only in response to
initial fragments, and is kept until either all fragments of the
datagram in question have been processed, or a timeout expires. Initial
fragments received when fragmentation state resources are exhausted are
discarded.
Unfragmented traffic will never be discarded because of lack of
fragment state memory. Even when the system is under heavy attack with
fragmented packets, legitimate fragmented traffic, if any, will still
get some fraction of the firewall's fragment state resources, and
legitimate unfragmented traffic will flow unimpeded.
These or equivalent changes will be carried forward into all PIX Firewall
software versions after version 4.2(2).
Getting Fixed Software for the PIX Firewall
- -----
Cisco is offering free upgrades to 4.2(2) software for all PIX Firewall
customers, regardless of service contract status. The upgrades will be
available as soon as the 4.2(2) software has been released.
Once the software has been released, customers with service contracts may
download it from Cisco's Worldwide Web site.
Customers without service contracts should get their upgrades by contacting
the Cisco TAC. TAC contacts are as follows:
* +1 800 553 2447 (toll-free from within North America)
* +1 408 526 7209 (toll call from anywhere in the world)
e-mail: tacat_private
Give the URL of this notice as evidence of your entitlement to a free
upgrade. Free upgrades for non-contract customers must be requested through
the TAC. Please do not contact either "psirtat_private" or
"security-alertat_private" for software upgrades.
As with any new software installation, PIX Firewall customers planning to
upgrade to version 4.2(2) should carefully read the release notes and other
relevant documentation before beginning any upgrade.
Long-term Plans for the PIX Firewall
- ----------------------------------
Cisco is evaluating the possibility of making additional changes in PIX
Firewall fragment handling, with the intention of closing additional
fragmentation-related vulnerabilities. If further changes are made, they are
likely to be of a relatively major nature, and therefore will probably
appear in a PIX Firewall release after release 4.2.
Workarounds for the PIX Firewall
- ------------------------------
Although there are no direct workarounds for this vulnerability, customers
can reduce their exposure by avoiding reliance on static NAT entries. Hosts
actively using dynamic NAT will remain vulnerable to some degree until fixed
software is installed. However, exploiting the vulnerability against
dynamically allocated addresses is more difficult than exploiting it against
statically allocated addresses. To exploit the vulnerability via dynamic
NAT, an attacker must do extra work to determine which dynamic addresses are
active at any given time, and to which hosts those active addresses
correspond.
CBAC (IOS Firewall Feature Set) Details
=======================================
This vulnerability in the CBAC feature has been assigned Cisco bug ID
CSCdk41516.
Problem Description for CBAC
- --------------------------
The Cisco IOS CBAC feature, up through all 11.2- and 11.3-based versions
including 11.2P and 11.3T, and up through 12.0-based versions through
12.0(1) and 12.0(2)T, does no filtering of non-initial IP fragments. The
CBAC feature performs much of its filtering by dynamically modifying
extended IP access lists, and, as with all Cisco IOS extended access lists,
the access lists modified by CBAC always pass non-initial fragments.
Immediate Response for CBAC
- -------------------------
The following changes will be made to the behavior of the CBAC feature, and
are presently targeted for versions 12.0(2) and 12.0(3)T:
* Interfragment state will be kept. Any non-initial fragment will be
discarded unless the corresponding initial fragment was permitted to
pass through the firewall. Non-initial fragments received before the
corresponding initial fragments will be discarded.
This applies only to packets being processed by CBAC as configured with
the ip inspect configuration commands; fragmentation state checks will
not be applied to router traffic not being inspected by CBAC, even if
that traffic is filtered with access lists.
This change eliminates the possibility of overloading host resources
with unmatched non-initial fragments, and requires attackers to use
relatively elaborate address spoofing for attacks using unmatched
initial fragments.
This change may have undesirable effects in certain cases, since it
will result in the firewall's discarding any packet whose fragments
arrive out of order. There are a number of circumstances that may cause
out-of-order delivery of legitimate fragments. Because routers running
Cisco IOS software are used in a very large variety of networks, and
because the CBAC feature is often used to isolate parts of internal
networks from one another, the new behavior will not be enabled by
default. Fragment checking must be explicitly enabled using the ip
inspect name inspect-name fragment configuration command. Cisco
recommends that this command be used whenever CBAC is being used as an
Internet firewall, unless there are special circumstances that dictate
otherwise. Cisco believes that legitimate out-of-order fragments are
rare at Internet firewalls.
* The amount of memory dedicated to fragmentation state is limited in
order to reduce the chance of denial of service attacks against the
firewall router itself. Fragmentation state is created only in response
to initial fragments, and is kept until either all fragments of the
datagram in question have been processed, or a timeout expires. Initial
fragments received when fragmentation state resources are exhausted are
discarded.
Unfragmented traffic will never be discarded because of lack of
fragment state memory. Even when the system is under heavy attack with
fragmented packets, legitimate fragmented traffic, if any, will still
get some fraction of the firewall's fragment state resources, and
legitimate unfragmented traffic will flow unimpeded.
* Fragment lengths will be checked for legality, and fragment offsets
will be checked to avoid port-number overwrite attacks. This offset
check duplicates the check already applied by extended access lists,
for those unusual configurations where CBAC is being used without
access lists.
These or equivalent changes will be carried forward into all future versions
of the IOS Firewall Feature Set.
Getting Fixed Software for CBAC
- -----
Cisco is offering free upgrades to all customers who have purchased the
IOS Firewall Feature set, regardless of service contract status. Since there
is no defect in stateless packet filtering, this free upgrade program does
not apply to customers who have purchased only non-firewall IOS.
When the updated software has been released, customers with service
contracts should obtain Cisco IOS software updates through their usual
channels. Customers with service contracts purchased from Cisco or from most
resellers may download updates from Cisco's Worldwide Web site.
Customers without service contracts should get their upgrades by contacting
the Cisco TAC. TAC contacts are as follows:
* +1 800 553 2447 (toll-free from within North America)
* +1 408 526 7209 (toll call from anywhere in the world)
e-mail: tacat_private
Give the URL of this notice as evidence of your entitlement to a free
upgrade. Free upgrades for non-contract customers must be requested through
the TAC. Please do not contact either "psirtat_private" or
"security-alertat_private" for software upgrades.
As with any new software installation, customers planning to upgrade should
carefully read the release notes and other relevant documentation before
beginning any upgrade. Also, it is important to be certain that the new
version of Cisco IOS software is supported by your hardware, and especially
that enough DRAM is available.
Long-term Plans for CBAC
- ----------------------
Cisco is evaluating the possibility of making additional changes in Cisco
IOS Firewall Feature Set fragment handling, with the intention of closing
additional fragmentation-related vulnerabilities. If further changes are
made, they are likely to be of a relatively major nature, and therefore will
probably appear in a Cisco IOS software release after release 12.0.
Workarounds for CBAC
- ------------------
There are no CBAC workarounds specific to this vulnerability. However,
customers may be able to reduce their exposure by using dynamic NAT. Also,
non-extended IP access lists can filter IP fragments, and may be useful in
controlling potential attacks in some configurations.
Stateless Packet Filters
========================
A stateless IP packet filter, such as a traditional access list in Cisco
IOS software, must make all of its forwarding decisions for any specific
packet based only on information in that packet. If the filtering is based
on criteria such as TCP or UDP port numbers, the necessary information is
typically present only in the initial fragment of a fragmented datagram. It
is therefore impossible to tell if a non-initial fragment is part of a
forbidden datagram or of a permitted one. Therefore, stateless packet
filters that use such criteria must pass all, or substantially all,
non-initial fragments. Such filters rely on blocking of initial fragments to
prevent completed delivery of any forbidden datagrams. This makes them
vulnerable to the fragmentation denial of service attacks discussed in this
notice.
Extended access lists in Cisco IOS software can filter based on TCP and
UDP port numbers, as well as based on ICMP packet types, and therefore fall
into the vulnerable category. A Cisco IOS software extended access list will
pass any non-initial fragment of a fragmented IP datagram.
Stateless packet filters that do not use information such as port numbers do
not suffer from this vulnerability, since all the information used by such
filters is present in every fragment of a datagram. Cisco IOS software's
non-extended access lists do not match on port numbers. They therefore can
(and do) filter non-initial fragments as well as initial fragments.
Vulnerability to fragmentation attacks is a well-known and largely inherent
limitation of stateless IP packet filtering. Cisco does not consider this a
defect in its stateless packet filtering products, and plans no immediate
response for those products. Although Cisco may in the future choose to
improve the fragment handling in its stateless filtering products, there is
no way to completely prevent an attacker from constructing fragments that
will pass any given stateless packet filter if the filtering criteria
include port numbers. There is therefore no way to entirely avoid
fragmentation-based denial of service attacks using such a filter.
Exploitation and Public Announcements
=====================================
This vulnerability is common to numerous packet filtering devices, both
stateful and stateless, from Cisco and other vendors. This vulnerability is
a well-known one in the area of router-based stateless packet filtering, and
is occasionally exploited by attackers when stateless filters are in use.
Exploitation against stateful filters such as the PIX firewall and CBAC may
reasonably be expected to occur from time to time.
Because it is possible to exploit this vulnerability "by accident" with
packet floods of various sorts, this vulnerability probably causes some
number of problems in cases where even the attackers themselves do not fully
understand the mechanism by which they are damaging their targets, as well
as in cases where the attackers have deliberately decided to target this
specific problem.
Cisco knows of no organized, systematic exploitation specific to this
vulnerability, but flooding attacks that could exercise it are reasonably
common events on the Internet. Such flooding attacks cause a wide range of
negative responses in targeted networks, and this vulnerability represents
one of those negative responses.
Flooding tools capable of exploiting this vulnerability are widely
available. Special-purpose tools designed to selectively exploit this
vulnerability seem relatively uncommon, but Cisco has not conducted a
thorough search for such tools. Such a tool would be easy for a moderately
sophisticated network programmer to produce.
This vulnerability has been publicly discussed with specific reference to
the Cisco PIX Firewall on the BUGTRAQ mailing list, beginning in late August
of 1998. There have been many other discussions in other public forums
regarding this vulnerability as it applies to packet filters in general, and
it is reasonable to suppose that there may have been public discussions of
this vulnerability as applied specifically to Cisco products. This
vulnerability should be considered to be widely known in both the computer
security community and the "cracker" community.
Status of This Notice
=====================
This is a final field notice. Although Cisco cannot guarantee the accuracy
of all statements in this notice, all the facts have been checked to the
best of our ability. Cisco does not anticipate issuing updated versions of
this notice unless there is some material change in the facts. Should there
be a significant change in the facts, Cisco may update this notice.
Distribution
- ----------
This notice will be posted on Cisco's Worldwide Web site at
http://www.cisco.com/warp/public/770/nifrag.shtml. In addition to Worldwide
Web posting, the initial version of this notice is being sent to the
following e-mail and Usenet news recipients:
* cust-security-announceat_private
* bugtraqat_private
* first-teamsat_private (includes CERT/CC)
* ciscoat_private
* comp.dcom.sys.cisco
* first-infoat_private
* Various internal Cisco mailing lists
Future updates of this notice, if any, will be placed on Cisco's Worldwide
Web server, but may or may not be actively announced on mailing lists or
newsgroups. Users concerned about this problem are encouraged to check the
URL given above for any updates.
Revision History
- --------------
Revision 1.0, Initial released version
15:30 US/Pacific,
10-SEP-1998
Revision 1.1, REAL initial released version; corrected PIX
07:00 AM US/Pacific, release date
11-SEP-1998
Cisco Security Procedures
=========================
Please report security issues with Cisco products, and/or sensitive security
intrusion emergencies involving Cisco products, to security-alertat_private
Reports may be encrypted using PGP; public RSA and DSS keys for
"security-alertat_private" are on the public PGP keyservers.
The alias "security-alertat_private" is used only for reports incoming to
Cisco. Mail sent to the list goes only to a very small group of users within
Cisco. Neither outside users nor unauthorized Cisco employees may subscribe
to "security-alertat_private".
Please do not use "security-alertat_private" for configuration questions,
for security intrusions that you do not consider to be sensitive
emergencies, or for general, non-security-related support requests. We do
not have the capacity to handle such requests through this channel, and will
refer them to the TAC, delaying response to your questions. We advise
contacting the TAC directly with these requests. TAC contact numbers are as
follows:
* +1 800 553 2447 (toll-free from within North America)
* +1 408 526 7209 (toll call from anywhere in the world)
* e-mail: tacat_private
All formal public security notices generated by Cisco are sent to the public
mailing list "cust-security-announceat_private". For information on
subscribing to this mailing list, send a message containing the single line
"info cust-security-announce" to "majordomoat_private". An analogous list,
"cust-security-discussat_private" is available for public discussion of the
notices and of other Cisco security issues.
==========================================================
This notice is copyright 1998 by Cisco Systems, Inc. This notice may be
redistributed freely after the release date given at the top of the notice,
provided that redistributed copies are complete and unmodified, including
all date and version information.
==========================================================
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQEVAwUBNfk/BnLSeEveylnrAQG6yAf+J2M+2N0hFcLBbQIVIpSatRD9xF3MHFMv
OsCKDHCSr38FyclylnSh+ezV/VV832VOYoFOVmUvWyReEvhz+qxRKS0xUhiat+ck
Pwrz7DeIeRgs6UNVSvomK6kc+vCc6nWewN7gTOksB2IwR5NDTBt2jJ+aXrklLalJ
Uo5P0gp5jKrKg6u85GmTNfZDjUchQMYIvhUTJA+0CTpExLs2cuOtSlO78frudWGU
3fTfgl6SQo2JpzCJ8TJVjVzIzbO4xJMb9HO3fD0HbLrYI1i9a1dg1eeuOuRurKza
AJi/IeRURX4ndTPIloByJ/HG9ZOAxswYA/S5MbO6FMUOpJ9SFzhCsw==
=gpSf
-----END PGP SIGNATURE-----
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGP for Personal Privacy 5.0
mQENAzXPH5oC2wEIAMeLeBbPlxIznjaMMKWFlhVgQ85n4wm6A1ZeVCm0D8zRzATl
IKC365xXRKx8bwTn5XjKxZ5/XVuZjhsMS/CCa7B4FfxqjYBpEvfWEYDmPfzipTC3
nPAEc3T4yNWfaDKPxqv85WK+3yn0rpygWEgqw8+/n8QvoSbBEA9DU+5RTHIDEfOF
vmqtDYB/2luIubN4X2jazwLeGhocarrbZmEW4fKsOpQ1xS1IuWbn9AWXjchMfL8z
i+ow9p6BA2I0eqmP/c1Ld+cL/befk3/l8rPA7UUFOn1je7Fng0WAAUvjoHU56fO2
oF6rO5jfHFu6yBt2ouRem/KMzx6WctJ4S97KWesABRG0R0Npc2NvIFN5c3RlbXMg
UHJvZHVjdCBTZWN1cml0eSBJbmNpZGVudCBSZXNwb25zZSBUZWFtIDxwc2lydEBj
aXNjby5jb20+iQEVAwUQNc8fmnLSeEveylnrAQE/OAf8DGH1DxPga+LKFyqf6lKT
5SDnmeTOu9D4hnHe/14Vu+AFfmrXqlGJ+GeK6mlNTOSSW84p5DQ7Pswbp6QNJBw/
08AAkvwqKTnowHUdtBM3GSvepMEkQuZcFFPtrobgXYrOgRumG1Lbuni/UysnYxZx
zkcetSkPyYSzjH1aHFd89BJNGYn1dy8hu/znbLVtUxfAhK3tPOlC7EfygEsOF2VC
7nUA13uGUBrs34zwJi/GalgKDGU+HxeEC5lmYxJVu1ftMy+g+0VGTBpXSSK3G99y
HfokysYr/RsB50ZEUZKprz5tmYIEUAGyf6nOIfC5ctmGwnXh7xX7OppzFl7Zqk5D
iYkAPwMFEDXPIpCWgad8PVLgfxECuK8AoNBJNor02wuTI9mVACgaknKdSqn9AJ9v
Zg3u0d5lx3l+QmkupOtBU40us4kBFQMFEDXPJBwMj7Lhmx7xKQEBhscIAJEkpzdv
pzjHfETEZymleUvq9IO1mVDQDQiyG02akI2PUe39Tl57jKjQ8Lyus0cfvHs7qVc8
jj2e1+mUyXA1AwWOZaJsgVdkZIFKJnU9MfN3XIxwwkg7g3dB99oPrAbTgWkKdodJ
mTnKsXntAYcmg7/4a5UYujJ2+J/7z1ZmiMtqHu4hU7B36DoxZadmaOPe1cIzsy+5
vBgg5vesDLb4O+3dae6BgsCay0eSLdfLkxI9hTGGiFTHrkgBaxOvQn6oUxVxnJC3
EWfasJzFjjxSrXxNuUqL9fRXDNOYH2P9tcQtjOypZPOGgtLvwCf0rQl/6jNxIWTJ
Hk/WXKbunvRKDIS0USBDaXNjbyBTeXN0ZW1zIHByb2R1Y3Qgc2VjdXJpdHkgaW5j
aWRlbnQvYnVnIHJlcG9ydGluZyA8c2VjdXJpdHktYWxlcnRAY2lzY28uY29tPokB
FQMFEDXPIS9y0nhL3spZ6wEBGHEH/2CYREeuDDx1lrlqKcTuSn13eyuVasAC4nIR
kuY5T+ipAHq0p2fwQ0QyxGvMD8naoEiTwtO4tHWEfqaqG/txt0draa+//mX/qr86
5K/4qtDe2n6dDz3uBy/wUn5i76302dthoUnbHpxug1NkKqop/FHYk9GztBMFlF+5
COlBk5fYtYzD2Nrhc5oA8lPBmJNAcM9ifVIEzYHEnJIcdoqrwGKCz91xxAjW+Xny
WtiJ80mRDJx888qF5lmmmkopgrxrRwikHprFMsSzT9Vqt3Rts7PtPPOaSBlEcGgK
OhN5PcWnpIarMeytrOkctsTjrqMaOEKudgaGgDrIgsBc6iYHwaaJAD8DBRA1zyLl
loGnfD1S4H8RAi/cAKDqOFxJtNzLJ8qazYcPOQC0XsNIGQCg+nlx5dQtcsKzU4lg
x9En0dI/anaJARUDBRA1zyRvDI+y4Zse8SkBAXBEB/9phOUWw7ImfvhALVpXnozU
+9tKgBFEArT3Y8hURYjYW3NMlIZqEPXWSnbo8SkFqWSbf+Ye2seFbT5tybW0M/I4
K7oCWD2HhEUEgKsopr418GuABQ7BsAtXIbTfh5ycLIsaS4h6sfJOAsSrT4iglYy5
mSN5/o2WF7Zam+96TFzhMzjLijZDPHrXlDtvW/4fvqzeljxpUuFGvbeP7Mcu8s+p
uhSx88Lnbm+sJWXw6wWSbobDqvNY+z/kCdKQIvX47Mp9CoeC34xXn3KfvQJkYGBV
uDf0U3Ci5WpJKq4+oghlDJte+MwOL2BKIYtaLbThHwMQ7Rfri1TOfjjVHOrPtZJ7
=YUdx
-----END PGP PUBLIC KEY BLOCK-----
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:16:08 PDT