From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailgw-01.dd24.net ([193.46.215.41]:45227 "EHLO mailgw-01.dd24.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751395AbbLIFjy (ORCPT ); Wed, 9 Dec 2015 00:39:54 -0500 Message-ID: <1449639588.7835.2.camel@scientia.net> Subject: Re: attacking btrfs filesystems via UUID collisions? From: Christoph Anton Mitterer To: Qu Wenruo , Duncan <1i5t5.duncan@cox.net>, linux-btrfs@vger.kernel.org Date: Wed, 09 Dec 2015 06:39:48 +0100 In-Reply-To: <56644785.4090702@gmx.com> References: <20151204120529.37E47D5A28@emkei.cz> <20151204130758.GR8775@carfax.org.uk> <1449286104.18841.14.camel@scientia.net> <1449366680.3183.37.camel@scientia.net> <56644785.4090702@gmx.com> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-aXy9UE9f0Lco//WfFt2q" Mime-Version: 1.0 Sender: linux-btrfs-owner@vger.kernel.org List-ID: --=-aXy9UE9f0Lco//WfFt2q Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 2015-12-06 at 22:34 +0800, Qu Wenruo wrote: > Not sure about LVM/MD, but they should suffer the same UUID conflict > problem. Well I had that actually quite often in LVM (i.e. same UUIDs visible on the same system), basically because we made clones from one template VM image and when that is normally booted, LVM doesn't allow to change the UUIDs of already active PV/VG/LVs (or maybe just some of these three, forgot the details) But there was never any issue, LVM on the host system, when one set was already used, continues to use that just fine and the toolset reports which it would use (more below). > The only idea I have can only enhance the behavior, but never fix it. > For example, if found multiple btrfs devices with same devid, just=20 > refuse to mount. > And for already mounted btrfs, ignore any duplicated fsid/devid. Well I think that's already a perfectly valid solution... basically the idea that I had before. I'd call that a 100% fix, not just a workaround. If then the tools (i.e. btrfstune) allows to change the UUID of the duplica= te set of devices (perhaps again with the necessity to specify each of them= via device=3D/dev/sda,etc.) I'd be completely happy again,... and the show= could get on ;) > The problem can get even tricky for case like device missing for a > while=20 > and appear again case. I had thought about that too: a) In the non-malicious case, this could e.g. mean that a device from a btrfs RAID was missing and a clone with the same UUID / dev ID get's added to the system Possible consequences, AFAICS: - The data is simply auto-rebuilt on the clone. - Some corruptions occur when the clone is older, and data that was only on the newer device is now missing (not sure if this can happen at all or whether generation IDs prevent it). b) In the malicious/attack case, one possible scenario could be: A device is missing from a btrfs RAID... the machine is left unattended. An attacker comes plugs in the USB stick with the missing UUID. Is the rebuild (and thus data leakage) now happening automatically? In any case though, a simply solution could be, that not automatic assemblies happen per default, and the people who still want to do that, are properly warned about the possible implications in the docs. > But just as you mentioned, it *IS* a real problem, and we should need > to=20 > enhance it. Should one (or I) add this as a ticket to the kernel bugzilla, or as an entry to the btrfs wiki? > I'd like to see how LVM/DM behaves first, at least as a reference if=20 > they are really so safe. Well that's very simple to check, I did it here for the LV case only: root@lcg-lrz-admin:~# truncate -s 1G image1 root@lcg-lrz-admin:~# losetup -f image1=C2=A0 root@lcg-lrz-admin:~# pvcreate /dev/loop0 =C2=A0 Physical volume "/dev/loop0" successfully created root@lcg-lrz-admin:~# losetup -d /dev/loop0=C2=A0 root@lcg-lrz-admin:~# cp image1 image2 root@lcg-lrz-admin:~# losetup -f image1=C2=A0 root@lcg-lrz-admin:~# pvscan=C2=A0 =C2=A0 PV /dev/sdb=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0VG vg_data=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0lvm2 [50,00 GiB / 0=C2=A0=C2=A0=C2=A0=C2=A0free] =C2=A0 PV /dev/sda1=C2=A0=C2=A0=C2=A0=C2=A0VG vg_system=C2=A0=C2=A0=C2=A0lv= m2 [9,99 GiB / 0=C2=A0=C2=A0=C2=A0=C2=A0free] =C2=A0 PV /dev/loop0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0lvm2 [1,00 GiB] =C2=A0 Total: 3 [60,99 GiB] / in use: 2 [59,99 GiB] / in no VG: 1 [1,00 GiB= ] root@lcg-lrz-admin:~# losetup -f image2=C2=A0 root@lcg-lrz-admin:~# pvscan=C2=A0 =C2=A0 Found duplicate PV tSK9Cdpw6bcmocZnxFPD6ThNz1opRXsB: using /dev/loop= 1 not /dev/loop0 =C2=A0 PV /dev/sdb=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0VG vg_data=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0lvm2 [50,00 GiB / 0=C2=A0=C2=A0=C2=A0=C2=A0free] =C2=A0 PV /dev/sda1=C2=A0=C2=A0=C2=A0=C2=A0VG vg_system=C2=A0=C2=A0=C2=A0lv= m2 [9,99 GiB / 0=C2=A0=C2=A0=C2=A0=C2=A0free] =C2=A0 PV /dev/loop1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0lvm2 [1,00 GiB] =C2=A0 Total: 3 [60,99 GiB] / in use: 2 [59,99 GiB] / in no VG: 1 [1,00 GiB= ] Obviously, with PVs alone, there is no "x is already used" case. As one can see it just says it would ignore one of them, which I think is rather stupid in that particular case (i.e. non of the devices already used somehow), because it probably just "randomly" decides which is to be used, which is ambiguous. > And what will rescan show if they are not active? My experience was always (it's just quite late and I don't want to simulate everything right now, which is trivial anyway): - It shows warnings about the duplicates in the tools - It continues to use the already active devices (if any) - Unfortunately, while the kernel continues to use the already used devices, the toolset may use other device (kinda stupid, but at least it warns and the already used devices seem to be still properly used): continuation from the setup above: root@lcg-lrz-admin:~# losetup -d /dev/loop1=C2=A0 (now only image1 is seen as loop0) root@lcg-lrz-admin:~# vgcreate vg_test /dev/loop0 =C2=A0 Volume group "vg_test" successfully created root@lcg-lrz-admin:~# lvcreate -n test vg_test -l 100 =C2=A0 Logical volume "test" created root@lcg-lrz-admin:~# mkfs.ext4 /dev/vg_test/test=C2=A0 mke2fs 1.42.12 (29-Aug-2014) ... root@lcg-lrz-admin:~# mount /dev/vg_test/test /mnt/ root@lcg-lrz-admin:~# losetup -a /dev/loop0: [64768]:518297 (/root/image1) root@lcg-lrz-admin:~# losetup -f image2=C2=A0 root@lcg-lrz-admin:~# vgs =C2=A0 Found duplicate PV tSK9Cdpw6bcmocZnxFPD6ThNz1opRXsB: using /dev/loop= 1 not /dev/loop0 =C2=A0 VG=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0#PV #LV #SN Attr= =C2=A0=C2=A0=C2=A0VSize=C2=A0=C2=A0VFree =C2=A0 vg_data=C2=A0=C2=A0=C2=A0=C2=A0=C2=A01=C2=A0=C2=A0=C2=A01=C2=A0=C2= =A0=C2=A00 wz--n- 50,00g=C2=A0=C2=A0=C2=A0=C2=A00=C2=A0 =C2=A0 vg_system=C2=A0=C2=A0=C2=A01=C2=A0=C2=A0=C2=A02=C2=A0=C2=A0=C2=A00 w= z--n-=C2=A0=C2=A09,99g=C2=A0=C2=A0=C2=A0=C2=A00=C2=A0 root@lcg-lrz-admin:~# lvs =C2=A0 Found duplicate PV tSK9Cdpw6bcmocZnxFPD6ThNz1opRXsB: using /dev/loop= 1 not /dev/loop0 =C2=A0 LV=C2=A0=C2=A0=C2=A0VG=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0Attr=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0LSize=C2=A0=C2=A0=C2=A0=C2= =A0Pool Origin Data%=C2=A0=C2=A0Meta%=C2=A0=C2=A0Move Log Cpy%Sync Convert =C2=A0 data vg_data=C2=A0=C2=A0=C2=A0-wi-ao----=C2=A0=C2=A0=C2=A050,00g=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =C2=A0 root vg_system -wi-ao----=C2=A0=C2=A0=C2=A0=C2=A09,02g=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 swap vg_system -wi-ao---- 1000,00m =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 As you can see, even though loop0 is used (by the kernel) the toolset would use loop1... o.O Yeah, don't ask me why... I once had a discussion with Alastair from the LVM people about that, forgot the exact reasons (if there were any) and I was simply happy that it continued to use the already open devices properly. > Or after a reboot? Haven't checked this right now but I guess it again just decides on one of them (which is pretty bad). > > I would expect that in addition to the fs UUID, it needs a form of > > device ID... so why not simply ignoring any new device for which > > there > > already is a matching fs UUID and device ID, unless the respective > > tool > > (mount, btrfs, etc.) is explicitly told so via some > > device=3D/dev/sda,/dev/sdb option. >=20 > IIRC, there were some btrfs-progs patches for such behavior, not sure > about kernel part though. > But at least an interesting method to solve the problem. > (Better than just rejecting mounting any) Of course if the user wouldn't specify those, it would still need to reject mounting/using/activating/fsck'ing/etc. ... > > If that means that less things work out of the box (in the sense of > > "auto-assembly") well than this is simply necessary. > > data security and consistency is definitely much more important > > than > > any fancy auto-magic. >=20 > Can't agree any more. > Especially when auto leads to wrong behavior (Like kernel version > based=20 > probing). Good to hear... well... you're the developer... spread the word :D > And after all, this topic makes me remember the bugreport of fuzzed > (but=20 > csum recalculated) images. > I used to ignore them and I think that wouldn't happen. >=20 > But the reporter is right, it's a btrfs security problem, and now I'm > super happy to see such report. As I've said, I've been quite surprised that no one seems to have thought about that before (especially the security aspect of that issue). > As it's easy to fix, I can always submit some patches if there is no=20 > other guy faster than me. :) Awesome... showstopper number #1 just seems to be about to walk away :D > So for this one, as long as we find a good behavior to solve it, it=20 > won't be a big thing. Great... keep me/us updated :) Cheers, Chris. --=-aXy9UE9f0Lco//WfFt2q Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTIwOTA1Mzk0 OFowTwYJKoZIhvcNAQkEMUIEQIkU+gUdUSytGkpLzX916Jd4CgzORVtVqxtVbUcYvwEwky0Gxq8C gKRfEDtFkJNIr1d4AYFPgO4OeoaJ9Ll/3mYwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQB8/jMuR64RLTef28Y2FuHC3zgU2D7q IN/eukTHD9uFVYtVU3uaH2gxfTlTxO6Y0xIFrAdj4VMuSrE9OzE+T34VxLWC8j7TX0GpOxt+2s7T y3c1LkkNuR3myLjtmW3veHg9c7zPUiwl4H9Vvytu6q/iUkJRmu9Sxoq7OWnwD995x6qPOF1/0VSq zH1aj6SOleHxTeLu32SielUHeycDxkni6/Jx6WSSCXTy0vsBqNOQP+LnjhtfJnkesSxeKsIyqN4m oddE9CoBIjwmqmOSaN3u+0Ubcxj0DFb62AwGqRou7kSetx+dwm7Pe69xmQJttupJ2cfJJNU/fDen FR0kKsLsAAAAAAAA --=-aXy9UE9f0Lco//WfFt2q--