Published:
14 May 1997
Protect yourself against future threats.
-----BEGIN PGP SIGNED MESSAGE-----
===========================================================================
AUSCERT External Security Bulletin Redistribution
ESB-97.062 -- REVISED 01 Hewlett-Packard Security Bulletin #00060
15 May 1997
===========================================================================
Hewlett-Packard has released the following revised advisory concerning a
vulnerability in 'SYN Flood' denial of service (DOS) attack. The previous
version of this advisory appeared as AUSCERT ESB-97.056. This vulnerability
may cause a potential denial of service for network users.
The following security bulletin is provided as a service to AUSCERT's
members. As AUSCERT did not write this document, AUSCERT has had no
control over its content. As such, the decision to use any or all of this
information is the responsibility of each user or organisation, and should
be done so in accordance with site policies and procedures.
Contact information for Hewlett-Packard is included in the Security Bulletin
below. If you have any questions or need further information, please
contact them directly.
If you believe that your system has been compromised, contact AUSCERT or your
representative in FIRST (Forum of Incident Response and Security Teams).
Previous advisories and external security bulletins can be retrieved from:
http://www.auscert.org.au/information/advisories.html
Internet Email: auscert@auscert.org.au
Facsimile: (07) 3365 4477
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AUSCERT personnel answer during Queensland business hours
which are GMT+10:00 (AEST).
On call after hours for emergencies.
- --------------------------BEGIN INCLUDED TEXT--------------------
- -------------------------------------------------------------------------
**REVISED 01** HEWLETT-PACKARD SECURITY BULLETIN: #00060, 30 April 97
LAST CHANGE 07 May 1997
- -------------------------------------------------------------------------
The information in the following Security Bulletin should be acted upon
as soon as possible. Hewlett Packard will not be liable for any
consequences to any customer resulting from customer's failure to fully
implement instructions in this Security Bulletin as soon as possible.
- -------------------------------------------------------------------------
PROBLEM: Vulnerability to 'SYN Flood' denial of service (DOS) attack
PLATFORM: HP 9000 Series 700/800s running versions of HP-UX 9.X & 10.X
DAMAGE: Potential denial of service for network users.
SOLUTION: If protection is needed in your environment; Apply the
appropriate patch and enable/tune the defense mechanism.
A white paper and tuning script are included within this
bulletin to assist with the tuning process.
AVAILABILITY: All patches are available now.
CHANGE SUMMARY: Section 4 (HP-UX's Solution today) now includes TOS
(formerly CMW/BLS) and VVOS patches.
- -------------------------------------------------------------------------
I.
A. Background
B. Fixing the problem
C. Recommended solution
D. Impact of the patch
Please refer to the following white paper for this information.
The white paper also includes a shell archive containing the
script to enable and tune the syn-flood defense mechanism.
__________________________________________________________________________
SYN Attack And HP-UX's Solution Rev. 1
1. Introduction
This paper explains what a SYN attack is, briefly describes
what defenses are available today, and describes the HP-UX
solution available today. It is assumed that the reader
has a basic knowledge of TCP/IP and Socket. In particular,
the reader is expected to know the fields in a IP header and
a TCP header, and the handshake in establishing a TCP connection.
2. What is a SYN attack?
SYN attack is a denial of service attack in that at least one internet
port is blocked from legitimate access. The attacker achieves this by
sending enough packets to targeted ports to completely block or severely
curtail access to these ports. These packets are legal packets in
compliance with TCP/IP protocols, except that they carry faked source
addresses.
SYN attack is one of the more severe denial of service attacks, since
every faked SYN packet can disproportionately consume a system's resources
for a disproportional amount of time.
A TCP connection establishment process normally takes an exchange of
three TCP packets: an initial SYN packet from a client, a SYN-ACK packet
from a server, and a SYN-ACK-ACK packet from the client. Since the source
address of the attacker's SYN packet is faked, the SYN-ACK-ACK packet will
never come.
Until the connection establishment process times out, a disproportional
amount of system resources are occupied: a slot in the attacked port's
listen queue, memory to maintain connection information, and CPU and
network bandwidth to retransmit the SYN-ACK packet.
A TCP listen port has a finite number of slots in its listen queue and
normally that number of slots is relatively small. When an attacker
sends enough faked SYN packets, the listen queue can be fully occupied and
subsequently deny any legitimate SYN packet from entering into the
listen queue.
3. What are the defenses today against a SYN attack?
The best defense is to stop it at the source. End systems should not
allow unauthorized users or applications to generate any faked SYN packet.
Access to raw socket interface should be restricted to trusted users or
applications.
Routers may provide a second line of defense by screening incoming IP
packets to make sure that they are actually coming from valid sources.
Certain firewall products today also can filter off faked IP packets.
End systems can also provide a last line of defense by accommodating
a much larger number of incoming SYN packets and appropriately replacing
those half-open connections that have been sitting in the listen queue.
**REVISED**
4. HP-UX's solution today
HP-UX restricts raw socket access to root. Raw socket is not an
officially supported interface for normal users on HP-UX.
Applying the appropriate patch (or a superseding patch) from the list
below provides defense against SYN attacks that reach the machine.
Patch Number Release Hardware Platform
- ------------------------------------------------------
PHNE_9525 9.0 s800
PHNE_10864 9.01 s700
PHNE_9100 9.03, 9.05, 9.07 s700
PHNE_9101 9.04 s800
PHNE_9102 10.01 s700
PHNE_9103 10.01 s800
PHNE_9104 10.10 s700
PHNE_9105 10.10 s800
PHNE_9106 10.20 s700
PHNE_9107 10.20 s800
**REVISED**
PHNE_10469 10.16 s700
PHNE_10470 10.16 s800
PHNE_10475 10.24 s800
PHNE_10476 10.24 s700
A system wide kernel parameter is provided to set a minimal length for
a listen socket queue without requiring programatic change. A
replacement algorithm is used to remove a half-open connection from the
listen socket queue when the listen socket queue is full.
4.1. Setting up a SYN attack defense on HP-UX
There are a couple kernel parameters you will have to set. A shell script
called syn_defense may be used to set these kernel parameters: the script
will modify both the core image and the kernel file, so the modification
takes place immediately, and persists across reboots. A copy of the
syn_defense script in the form of a shar file is attached to the end of
this paper.
1. hp_syn_protect
By default, the SYN attack defense is not turned on. To turn it on,
set hp_syn_protect to 1. To turn it off, set hp_syn_protect to 0.
As explained in more detail below, turning on SYN attack defense will
change the system behavior, and in a stress condition can consume more
memory and CPU resources even if the system is not under attack.
Because only a very small percentage of HP systems may be at risk of SYN
attacks, the SYN attack defense is not turned on by default.
2. so_qlimit_min
When enabled, so_qlimit_min specifies the minimum length of a listen
socket queue, applications requesting less will be given so_qlimit_min
entries.
When the socket queue limit is reached, any new incoming TCP connection
request will replace one of the pending TCP connections in the socket
queue using a HP chosen replacement algorithm.
By default, so_qlimit_min is set to 500. This value should comfortably
defend against an attacker using a 56K baud modem. Consult the section
below for different exposures.
4.2. Determining a right so_qlimit_min value for a system
A proper value for so_qlimit_min can be derived from the following formula
that calculates the probability of a successful connection establishment
while a system is under a SYN attack:
P = ((L-1)/L)^(T*R)
where
P = The probability a valid SYN packet can still be processed
and be turned into an established TCP connection while a
system is under a SYN attack.
L = so_qlimit_min
T = Time in seconds that it normally takes between sending
the SYN-ACK packet and receiving the SYN-ACK-ACK packet.
This can be approximated by the round trip time as
reported by the ping command.
R = Incoming rate of SYN packets in packets per second during
a SYN attack. To come up a number with a high confidence
of success, a worse case estimate may be used.
For example, the full bandwidth of a dial-up link may be
assumed to be utilized by an attacker. The intermediate
routers may be assumed not to introduce any delay between
packets. With these assumptions, the incoming rate can be
derived from the the formula below:
R = B/S,
where
B = Bandwidth in bits/sec,
S = SYN packet size in bits
= (F + IP header size + TCP header size)*(8 + I)
= (F + 20 + 20)*(8 + I),
where
F = Frame overhead in bytes per packet
I = Link overhead in bits per packet byte
A formula for so_qlimit_min can be derived from the above probability
formula:
L = 1/(1 - P^(1/(T*R)))
Following is an example showing how to estimate a desired so_qlimit_min
value.
Suppose a 70% success rate is desired during an attack through a 56K baud
SLIP dialup link. In that case,
P=.7
B=57344
F=2
I=2
S= (2 + 20 + 20)*(8+2) = 420
R= B/S = 57344/420 = 137 (round up to nearest integer)
Let T= 1 sec.
L= 1/(1 - .7^(1/137))
= 385 (round up to nearest integer)
Note, in SLIP there is 1 END byte in front and 1 END byte at the end
of a packet. Since only a ballpark number is needed, it can be assumed
that there is no END character or a SLIP ESC character within a SYN
packet itself. It is also assumed that 1 START bit and 1 STOP bit is
used per packet byte.
The round trip time, T, is set to 1 sec. in this calculation. To
establish a round trip time for a system, one may identify a farthest
node from the system and use the ping command to sample the round trip
time between that node and the system.
4.3. What impacts are there to the system if the SYN attack
defense is turned on?
In general, there should not be any direct noticeable
performance impact under normal conditions. However,
turning SYN attack defense on will change the system behavior.
High connection attempt rates on a listen socket will result in
some of the client applications seeing ECONNREFUSED instead of
ETIMEOUT. Likewise, more system resources may be held by the
application than normal under these circumstances.
4.4. Memory Requirement
Amount of memory consumed by faked SYN packets during an
attack is proportional to the attack rate. The worst case
requirement can be approximated with the formula below:
M = 32700 * R
where
M = memory in bytes,
R = Incoming SYN attack rate in packets per second
To fully protect against an attacker using a 56K baud modem, approximately
4.3 megabytes of memory should be added to the networking memory pool.
5 Conclusion
SYN attack is a sophisticated attack against a system attached
to TCP/IP networks. With the technology today, an effective
defense should be a multi-layer approach, using strict access
control at the source, source screening in the intermediate
routers and firewalls, and SYN attack defense solution at the
end system. With sufficient memory, HP-UX can provide an
effective last line of defense against a SYN attack.
#------------------------------ cut here ----------------------------------
# This is a shell archive. Remove anything before this line,
# then unpack it by saving it in a file and typing "sh file".
#
# This archive contains:
# syn_defense
#
# Modification/access file times will be preserved.
# Error checking via wc(1) will be performed.
# Error checking via sum(1) will be performed.
# Files are compressed using compress(1).
LANG=""; export LANG
PATH=/bin:/usr/bin:$PATH; export PATH
if sum -r </dev/null >/dev/null 2>&1
then
sumopt='-r'
else
sumopt=''
fi
rm -f /tmp/uud$$
(echo "begin 666 /tmp/uud$$
#;VL*n#6%@x
end" | uudecode) >/dev/null 2>&1
if [ X"`cat /tmp/uud$$ 2>&1`" = Xok ]
then
unpacker=uudecode
else
echo Compiling unpacker for non-ascii files
pwd=`pwd`; cd /tmp
cat >unpack$$.c <<'EOF'
#include <stdio.h>
#define C (*p++ - ' ' & 077)
main()
{
int n;
char buf[128], *p, a,b;
scanf("begin %o ", &n);
gets(buf);
if (freopen(buf, "w", stdout) == NULL) {
perror(buf);
exit(1);
}
while (gets(p=buf) && (n=C)) {
while (n>0) {
a = C;
if (n-- > 0) putchar(a << 2 | (b=C) >> 4);
if (n-- > 0) putchar(b << 4 | (a=C) >> 2);
if (n-- > 0) putchar(a << 6 | C);
}
}
exit(0);
}
EOF
cc -o unpack$$ unpack$$.c
rm unpack$$.c
cd $pwd
unpacker=/tmp/unpack$$
fi
rm -f /tmp/uud$$
echo x - syn_defense '[compressed]'
$unpacker <<'@eof'
begin 600 syn_defense
M'YV0(T*$)/&S8LU<] H&+$0Q)P;KZ0*6.FC)LY970L; BB(Q4T:>8X'",GX
M#1PZ(-J$R0-"3!D0=3"2 4'G3<HW9-*884D'S4LS;]BP>7.GX!F'>>;0*=,&X
M!)PP<L*T*;-4CDB.'>6481.&CE&:-J=D<0*B*YTP8]: F%CQ8L:-(SK*!8$&X
MSI>'$>'(>;-T#,H6(*90!0LB!F$Z=>2X ?%FL5BR9M&J96L1XPZL<S-KSBP8X
M94T0,&B&1JR8L1DS@<>6I7,V[5J*E<NXP-QQSILO<=BD:9.&SA?>BT$ !KZ[X
M3E/=2BTZ?)-V<)PZ9:"#8&/Q3$7'6EOWBYW2M*E3=F&J<,&94@0-6# 8 '3X
M#?4Y(GO3#2/2I7+MW+>/01/&S9DR9& '0A48T>03""*TP(8(C)V41F.$[=??X
M?_CEIUE/Y]D1!AO0S<907'()P1<:!KXTQAM:@;!;&/^5Y<9,/;VT1AF*;06"X
M&6E0!T)10K7T4ALXZ90&@!YBYIT;9^&AT8>:X241;&Z!L$4+970A90MD6#DEX
M&R#P8!MNNO'F&W ^:-D"&F;*828<7< UUT<O)5@&@VX"*%%88CQ7FJ0L2;9X
M:VUAY.%<==T%T1=Z56&7SOFR*5+#@WV60Q%@NC1@0F20:>=B^4T1YY[/K9:X
M:Y-!*2AFA3J9:%H?CH2QAY9A,,E;Z)J8)=?IG;;KW]5I /FWH%8:PBQ9A2X
M0<4UA1ER2RUF6W,H/1?=2]3YUU.CUQI[1AIV**<AA[*Y*1><")X9[(.+Z540X
M'<6")-)4+$8+I/CWBK'N1!J16R)=-FEZEZLNCB3KF'V"AQFG68AAR CE<>X
M"-]"-T>M]<;9 ASXIEL2DB*]48=G!XZ1F%9(CFJ9)A1%F7$94P,PD?GN>HCX
MO^*1AY)+_-GQ(,-W^.0&9FXT]M(;J!E;I[ 7J2C2''7 8=N1,+5$!)EW$$=X
M:R! (1E4,PV!(APH=H5N0S O39))YHE4A1-35 $%%$](04411 A(X$M=,7;'X
M8B7-L<:@09!Q-( W[M64L;%^@6-$7DTU4DDG[5@2:J)P=(4)V+=1(YW<-W0X
M%9,WJT-'0:C+90PVL!=##CG< $("27R*%@A7-'9& @VY"00*(Z1 @A1EZ#P'X
MNJ-3*@,(),A%0A ?HX'BZ&G<83ORRA/1548@M/X"##2$ ,.A<&@ PTRZ###X
M#,AO!$405"#1PT %Z?!"3'+ [X;5(VA0ZU23#@T:F@90QE.0CB6B00H#",8X
MK94D(T YRZWV968?.6&'L0 =TPB D4<AA(K;$AB&V'+%U)UJ%4MB@X]@$$"X
M$A 7TBQF6! YF6M4=BH1*G""P.E!>E3(PF.Y(5G3"4FSE@,M$$A+.M6R#HFDX
M%A<J, 5L49$#2XA@'#AY0A[J<.+-D*%)D#!"$E@0A'>1X<VP.$@91@@"4B@X
M@(4$02A$N1&*LN<"+ @L?'54P!.F 4K%$$*4TC"$YS0 Q*@0(M2>4D+&,:'X
MLMQ!+2TP G9.L =UE8P$,NC#"5*@@!G5B V*RU$9>B""%]2E!77 @PC<1"!YX
M!:8.8LBB5]Q0!JG%1%XHX.0>VK@HYR'HEO9G9-H^)(I5>E*6;H2E[P4P8(QX
MT UENA*:KL2F598!#[UI8Q_:R"2JL0$.($B"&Q"H$J2],I8>FZ4B03"%GX
M)CU3SIFV LZCH0L$V^K6SQABR1A],Y<*V&5'>FD3$8@J,C,TU4MJ$A0=K'*@X
M^RGH0T% T'*][$!<D%-&&V1./.FI929#:*D")9N)5I1!_3)47@!VPD;U"%*QX
M(@RE3!I1!-'4EPFZZ$LRBJ6-VA-"G@(52 _JIX22U 4W+6A'2+A213%*9C"5X
MU*R0J@"(XI1!5:5H37-*+IXNX8&^Y5/.14I=O&+.&TP#H*R>M*.,$LYSYI1X
MM*"#Q.I<JRC9.E ^O?7!DH* K5M-JD6[FB TC-6<_6S7>>#UJ?]0U:H2!2Q.X
M 4/811[VGOJBBDB8BBB6,JH_ VOF BDH6)0FS"<+:YC-(-;7B6$5LC:5;$$IX
MB]$$P>&R$$HL8S[&+Y')@60H(2JI2ML18K(67"XKFTM?1;,-KA9G8=#9'./IX
M!N*"(&BT- V_?IJTS#-:5 +$%:WZ2:OI<@$(%@"C6C))0."0"MAR(E_' )+X
M61:DE@Q1 'S) 4# G27"HBO&)#G2?:&4D<OF(@=#C*5IO" !R HPA., (?X
M(*^+7PQC$13 61/ZY05$4 !8GPEB!4C8"&WTL&^^-8<>@*&=*"$!AL$H1A TX
M@Q: 6>'/8N21H;AD2"@I$Y @ ),@B $/;!I"IRR,3J@1@0EF(D(V(-)38)!X
M 0]DL8MA?&$OTK@(-L9GCI<#IM$")P_5HN045/DXR%9R4Q>UY.CC" J9_($X
M5U9 8P280@4@4$4J6@P)5-S?#<U! 8++:D?:62 2[/DE#4P #)9(JV,T%EX
MY'$ATZ#H[3S:Q=?4"_(>#8(5% 8,.[C,=E2PY).N:[T;HNAO4331@7YJ#(@6X
M6AL_#0,_SS$-@49>E@V=ZTXS^B6.=H, ZT 25,:166 8)EQ6)!-=WHSGP9#X
MJ!F6[&6;.@:H5O5F6*U5G+Y:,;&FT5[NU>F6H277M&RC')HB8R]KN(T")O!ZX
MMW+@ER0X> QF2I<@?.(*=SG#8N0PIIO*JA^$>,04=+B))YQB'A>:#2U^<=[JX
MC7 PWWC,.W9JCQVIYCT,N<U'3K((1+#D?LY9RG:V,I8+<O&,<YGC7PXSC@=(X
M9@F&=3$^!O*:B6SD-Z^Y4U^>9V1=^<\]K7# -V09!':!87>R[''K6R(?TSX
M9X.@P/P..:NL;:%L;UOKWCYUJJM%W*[&DFPYI*Z:=WN6.[EGK>>I__+'5!X
M#QOC5Y=+UKO-]69/^NO[!B7$<T@"3I==[]K&@Z@)7VJUBULS;M_JN=V0[EFSX
M>R[NQK7@XJU?>L_XWN25D'^BK>+_NJDS_&+91AIRAF]A&6$ 3N7$V& ;?@X
M#OK^9+]!.\%KZ'! X_PA#MBX>*_P WD88/"5=I9D;_@"J A PG$?L+I_TODX
M/ ^#+3/?;],',7Z+4-+PY"!0QY"BK=+3+_Y<RQ %Y] =!FV+T,]!O-?]3X
M)W_LQ!^K!R,V00+R=VG4IV)4M148T6Y;]4=2$#>C8P1A($H&.(#^DU+?%S !X
M"&W8P004@1(;EX#TMTHX(A=M]'[!9V#Y1R7WMWT+5WT!LW^ X$X!8""IGO#X
MIWK_D8$DP(/TUX 85TO^AU,22($@8($8&"$$V"(ZV(+AB/4$8(CN!I2"$HGX
MZ&? EAT*D'I/&&T^]TRN1WNV=US21FZ]U<!UGO" 7Q!F'C#YWS')W /IGP4X
M9G#.!WU"(6*B16T&(7Y$0 *+UT"%Z ;A!QJ#>(CG)V_JQU&M(*H 7("&W2X
M-H84)!SVASR'J'*P'X6%"=^($IXH.$QF5:&F'2(0/>(0%E8124($7^$Y.X
MN(&CN!CR9X5F0((QEH"KB(*<YGZ3F(67Z$R9"(.<^(<_YXF@Z(H(<HO$2(4FX
M$H9 R(._J .:(1R<5*P*(M-^!FFV'/&>&93%X?")XVZR(O$>(TXHDT5MRXUX
M]U]LN%_LUS+8N%7FE1'6]'SJ&(@D&2I.'_]R&.KQ((!J8 =V%)&!P,,8H,6X
M$8K/J(S/U!$ Z8L225K86(00*0*=^(_Q9XF=B )/X!XL$1.$0UT<F&DBIS04X
MQ7D?108I (SW>%4S65#F:Z% UB2#Y!Y!".) B5Y##>)-A!Y0!LY -^8DWX
MZ(P<>9%GYI%$J7A.61#6I)%,V9$^*8<A.9)L4)(RL2,^DY(,UU+GX5'O%)-<X
M^(5MU!!"4 ;;D*H 05[@6-2X2;[L2AJ6?<=6C"*"7(@P)I,!.HM&0MD%VAX
MX9#]MQG]Q'8=T4(,@4H(D7LD0<>4Q8I$C0D2%]P0".HA!%R\%B*V62,&6<EX
M(P)94)EII10S$P::R9DFR3"?(0=:9"#>=38G 9J:L9C;<4WR$0-IV9>4N$=]X
M]$>!-$C"3 Q<)A*^9 )P(/22$JF! >HI$H9^8#-*8?/64I* 5HO8 =I]4/4X
MV8Y_17^%)$+TYX?3]G/E21'%:&8-!)SPUP)Z@#PJH'^(V6G]5'._V3.B)"64X
M:!A)U@+UV05=<!F))GCT@6R&$6E4 @)+1IZ^F0"988HT>$*I]E<)@"M+EA ZX
M00?-EAFT= <45$B&:%S7Z4&*+'V"(D$"=2*"CF1G]U<6DAF'6$@J>F;-X
ME@ 4BHG @3LU2E%6&:2PU93I.9'MY :8.3/OT2[](6PTMXIKM4*:%!BB-KX
MMQU8XJ!B6:%^T6<2BG5AZ*5TL'89RC /:I0GM)YF@) JR2HF*A<W2@(V-)5=X
M-Z%CJF)QNFACZJ,%D:6;<3%<FIL!JB:<2:#VF0^4T7.IH"RJ4510(+*A)/X
?JD5K$#1[XQ10D4A5$:-S 4QE8*BAIV@<NHMWYZEM!$T7 X
X
end
@eof
uncompress <syn_defense >/tmp/compress$$
mv /tmp/compress$$ syn_defense
set `sum $sumopt <syn_defense`; if test $1 -ne 33966
then
echo ERROR: syn_defense checksum is $1 should be 33966
fi
set `wc -lwc <syn_defense`
if test $1$2$3 != 3149857054
then
echo ERROR: wc results of syn_defense are $* should be 314 985 7054
fi
touch -m 0418104397 syn_defense
touch -a 0418124997 syn_defense
chmod 555 syn_defense
rm -f /tmp/unpack$$
exit 0
__________________________________________________________________________
E. To subscribe to automatically receive future NEW HP
Security Bulletins from the HP Electronic Support Center via
electronic mail, do the following:
User your browser to get to the HP Electronic Support
Center page at:
http://us-support.external.hp.com
(for US, Canada, Asia-Pacific, & Latin-America)
http://europe-support.external.hp.com
(for Europe)
Click on the Technical Knowledge Database, register as a user
(remember to save the User ID assigned to you, and your password),
and it will connect to a HP Search Technical Knowledge DB page.
Near the bottom is a hyperlink to our Security Bulletin archive.
Once in the archive there is another link to our current
security patch matrix. Updated daily, this matrix is categorized
by platform/OS release, and by bulletin topic.
F. To report new security vulnerabilities, send email to
security-alert@hp.com
Please encrypt any exploit information using the security-alert
PGP key, available from your local key server, or by sending a
message with a -subject- (not body) of 'get key' (no quotes) to
security-alert@hp.com.
Permission is granted for copying and circulating this Bulletin to
Hewlett-Packard (HP) customers (or the Internet community) for the
purpose of alerting them to problems, if and only if, the Bulletin
is not edited or changed in any way, is attributed to HP, and
provided such reproduction and/or distribution is performed for
non-commercial purposes.
Any other use of this information is prohibited. HP is not liable
for any misuse of this information by any third party.
________________________________________________________________________
- -----End of Document ID: HPSBUX9704-060--------------------------------------
- --------------------------END INCLUDED TEXT--------------------
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: ftp://ftp.auscert.org.au/pub/auscert/AUSCERT_PGP.key
iQCVAwUBM3r4eyh9+71yA2DNAQE5owP+KjTTRvYPG/zeLJmj+LjoDw2v9WS/yJe1
ulE8wtTGMqU5JAgVJQPYvj7+Giw77HF/uCHXqMkourgzWYv+Mye1cUFazPaehstw
Gk7wfzeWVwaF4n4SX2TuALQ1RIGTmwHatJFy4KniFcBQ9rNiWJ7EkkkSowUCLDE5
lauf+4hbaGc=
=xieE
-----END PGP SIGNATURE-----