[prev in list] [next in list] [prev in thread] [next in thread] 

List:       full-disclosure
Subject:    [FD] X41 D-Sec GmbH Security Advisory X41-2021-002: nginx DNS Resolver Off-by-One Heap Write Vulnera
From:       X41 D-Sec GmbH Advisories <advisories () x41-dsec ! de>
Date:       2021-05-25 16:34:31
Message-ID: 865503dd-5852-785c-a4fb-94d3f5c4331c () x41-dsec ! de
[Download RAW message or body]

Advisory X41-2021-002: nginx DNS Resolver Off-by-One Heap Write
Vulnerability
=============================================================================
Severity Rating: High
Confirmed Affected Versions: 0.6.18 - 1.20.0
Confirmed Patched Versions: 1.21.0, 1.20.1
Vendor: F5, Inc.
Vendor URL: https://nginx.org/
Vendor Reference:
http://mailman.nginx.org/pipermail/nginx-announce/2021/000300.html
Vector: Remote / DNS
Credit: X41 D-SEC GmbH, Luis Merino, Markus Vervier, Eric Sesterhenn
Status: Public
CVE: CVE-2021-23017
CWE: 193
CVSS Score: 8.1
CVSS Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C
Advisory-URL:
https://www.x41-dsec.de/lab/advisories/x41-2021-002-nginx-resolver-copy/


Summary and Impact
------------------
An off-by-one error in ngx_resolver_copy() while processing DNS
responses allows a network attacker to write a dot character ('.', 0x2E)
 out of bounds in a heap allocated buffer. The vulnerability can be
triggered by a DNS response in reply to a DNS request from nginx when
the resolver primitive is configured. A specially crafted packet allows
overwriting the least significant byte of next heap chunk metadata with
0x2E. A network attacker capable of providing DNS responses to a nginx
server can achieve Denial-of-Service and likely remote code execution.
Due to the lack of DNS spoofing mitigations in nginx and the fact that
the vulnerable function is called before checking the DNS Transaction
ID, remote attackers might be able to exploit this vulnerability by
flooding the victim server with poisoned DNS responses in a feasible
amount of time.


Root Cause Analysis
-------------------
nginx DNS resolver (core/ngx_resolver.c) is used to resolve hostnames
via DNS for several modules when the resolver primitive is set.
ngx_resolver_copy() is called to validate and decompress each DNS domain
name contained in a DNS response, receiving the network packet as input
and a pointer to the name being processed, and returning a pointer to a
 newly allocated buffer containing the uncompressed name on success.
This is done in two steps,

1) The uncompressed domain name sizelenis calculated and the input
packet is validated, discarding names containing more than 128 pointers
 or containing pointers that fall out of the input buffer boundaries.
2) An output buffer is allocated, and the uncompressed name is copied
into it.

A mismatch between size calculation in part 1 and name decompression in
 part 2 leads to an off-by-one error inlen, allowing to write a dot
character one byte off name->data boundaries.
The miscalculation happens when the last part of the compressed name
contains a pointer to a NUL byte. While the calculation step only
accounts dots between labels, the decompression step writes a dot
character every time a label has been processed and next character is
not NUL. When a label is followed by a pointer that leads to a NUL byte,
the decompression procedure will:

// 1) copy the label to the output buffer,
 ngx_strlow(dst, src, n);
            dst += n;
            src += n;
// 2) read next character,
            n = *src++;
// 3) as its a pointer, its not NUL,
            if (n != 0) {
// 4) so a dot character that was not accounted for is written out of
bounds
                *dst++ = '.';
            }
// 5) Afterwards, the pointer is followed,
        if (n & 0xc0) {
            n = ((n & 0x3f) << 8) + *src;
            src = &buf[n];
            n = *src++;
        }
// 6) and a NULL byte is found, signaling the end of the function
        if (n == 0) {
            name->len = dst - name->data;
            return NGXOK;
        }


If the calculated size happens to align with the heap chunk size, the
dot character, written out of bounds, will overwrite the least
significant byte of next heap chunk size metadata. This might modify the
 size of the next heap chunk, but also overwrite 3 flags, resulting in
PREV_INUSE being cleared and IS_MMAPPED being set:


==7863== Invalid write of size 1
==7863==    at 0x137C2E: ngx_resolver_copy (ngx_resolver.c:4018)
==7863==    by 0x13D12B: ngx_resolver_process_a (ngx_resolver.c:2470)
==7863==    by 0x13D12B: ngx_resolver_process_response (ngx_resolver.c:1844)
==7863==    by 0x13D46A: ngx_resolver_udp_read (ngx_resolver.c:1574)
==7863==    by 0x14AB19: ngx_epoll_process_events (ngx_epoll_module.c:901)
==7863==    by 0x1414D4: ngx_process_events_and_timers (ngx_event.c:247)
==7863==    by 0x148E57: ngx_worker_process_cycle (ngx_process_cycle.c:719)
==7863==    by 0x1474DA: ngx_spawn_process (ngx_process.c:199)
==7863==    by 0x1480A8: ngx_start_worker_processes
(ngx_process_cycle.c:344)
==7863==    by 0x14952D: ngx_master_process_cycle (ngx_process_cycle.c:130)
==7863==    by 0x12237F: main (nginx.c:383)
==7863==  Address 0x4bbcfb8 is 0 bytes after a block of size 24 alloc'd
==7863==    at 0x483E77F: malloc (vg_replace_malloc.c:307)
==7863==    by 0x1448C4: ngx_alloc (ngx_alloc.c:22)
==7863==    by 0x137AE4: ngx_resolver_alloc (ngx_resolver.c:4119)
==7863==    by 0x137B26: ngx_resolver_copy (ngx_resolver.c:3994)
==7863==    by 0x13D12B: ngx_resolver_process_a (ngx_resolver.c:2470)
==7863==    by 0x13D12B: ngx_resolver_process_response (ngx_resolver.c:1844)
==7863==    by 0x13D46A: ngx_resolver_udp_read (ngx_resolver.c:1574)
==7863==    by 0x14AB19: ngx_epoll_process_events (ngx_epoll_module.c:901)
==7863==    by 0x1414D4: ngx_process_events_and_timers (ngx_event.c:247)
==7863==    by 0x148E57: ngx_worker_process_cycle (ngx_process_cycle.c:719)
==7863==    by 0x1474DA: ngx_spawn_process (ngx_process.c:199)
==7863==    by 0x1480A8: ngx_start_worker_processes
(ngx_process_cycle.c:344)
==7863==    by 0x14952D: ngx_master_process_cycle (ngx_process_cycle.c:130)


More information about general exploitability of a similar bug class
found in

* Chrome OS exploit: one byte overflow and symlinks
https://googleprojectzero.blogspot.com/2016/12/chrome-os-exploit-one-byte-overflow-and.html

* Project Zero's Poisoned NULL Byte
https://googleprojectzero.blogspot.com/2014/08/the-poisoned-nul-byte-2014-edition.html

* Hiroki Matsukama's House of Einherjar
  https://www.slideshare.net/codeblue_jp/cb16-matsukuma-en-68459606
  https://www.youtube.com/watch?v=tq3mPjsl-H0
Given the rich interaction opportunities in nginx with user controller
data and the documented precedents this bug is considered exploitable
for remote code execution on some operating systems and architectures.


Attack Vector Analysis
----------------------

There are several ways in which a DNS response can trigger the
vulnerability.

First, nginx must have sent a DNS request and must be waiting for a
response.

Then, a poisoned name can be injected in several parts of a DNS response:

* DNS Questions QNAME,
* DNS Answers NAME,
* DNS Answers RDATA for CNAME and SRV responses,

Keep in mind that the vulnerable function can be hit several times while
processing a response, effectively performing several off-by-one writes,
by crafting a response with several poisoned QNAME, NAME or RDATA  values.
Furthermore, when the attacker delivers a poisoned CNAME, it will be
resolved recursively, triggering an additional OOB write during
ngx_resolve_name_locked() call to ngx_strlow() (ngx_resolver.c:594) and
additional OOB reads during ngx_resolver_dup() (ngx_resolver.c:790) and
ngx_crc32_short() (ngx_resolver.c:596).

<for example payloads please see the attached advisory .txt file>

Fix / Workarounds
-----------------

Allocating an extra byte for the spurious dot character written at the
end of the poisoned domain names mitigates the issue.


--- ngxresolver.c  2021-04-06 15:59:50.293734070 +0200
+++ src/nginx-1.19.8/src/core/ngxresolver.c    2021-04-06
15:54:10.232975235 +0200
@@ -3943,7 +3928,7 @@
     ngx_uint_t   i, n;

     p = src;
-    len = -1;
+    len = 0;

     /*
      * compression pointers allow to create endless loop, so we set limit;
@@ -3986,7 +3971,7 @@
         return NGX_OK;
     }

-    if (len == -1) {
+    if (len == 0) {
         ngx_str_null(name);
         return NGX_OK;
     }


Official fix can be found at
http://nginx.org/download/patch.2021.resolver.txt


Proof-of-Concept
----------------

A dummy DNS server delivering a poisoned payload that triggers this
vulnerability can be downloaded from
https://github.com/x41sec/advisories/blob/master/X41-2021-002/poc.py

The described vulnerability can be tested by running nginx with the
provided config as follows under valgrind (https://www.valgrind.org/):

   valgrind --trace-children=yes objs/nginx -p ../runtime -c
conf/reverse-proxy.conf

Then run the DNS server (will listen on port 1053 by default):

   python poc.py

and trigger a request to the server:

   curl http://127.0.0.1:8080/

Depending on the heap layout when the bug triggers, the malloc
mitigations might detect or not the effect. Several ways of showing up
in the logs arise:

corrupted size vs. prev_size
2021/04/16 13:35:15 [alert] 2501#0: worker process 2502 exited on signal
6 (core dumped)
malloc(): invalid next size (unsorted)
2021/04/16 13:35:34 [alert] 2525#0: worker process 2526 exited on signal
6 (core dumped)


Nevertheless, valgrind and AdressSanitizer will always detect the memory
corruption.


nginx config used
-----------------

daemon off;
http{
    access_log logs/access.log;
    server{
        listen 8080;
        location / {
            resolver 127.0.0.1:1053;
            set $dns http://example.net;
            proxy_pass $dns;
        }
    }
}
events {
    worker_connections  1024;
}


Timeline
--------

2021-04-30 Issue reported to maintainers
2021-05-17 Issue reported to distros mailing list
2021-05-18 CVE assigned
2021-05-25 Public disclosure

About X41 D-SEC GmbH
====================
X41 is an expert provider for application security services. Having
extensive industry experience and expertise in the area of information
security, a strong core security team of world class security experts
enables X41 to perform premium security services.
Fields of expertise in the area of application security are security
centered code reviews, binary reverse engineering and vulnerability
discovery. Custom research and IT security consulting and support
services are core competencies of X41.




["x41-2021-002-nginx-resolver-copy.txt" (text/plain)]


Advisory X41-2021-002: nginx DNS Resolver Off-by-One Heap Write Vulnerability
=============================================================================
Severity Rating: High
Confirmed Affected Versions: 0.6.18 - 1.20.0
Confirmed Patched Versions: 1.21.0, 1.20.1
Vendor: F5, Inc.
Vendor URL: https://nginx.org/
Vendor Reference: http://mailman.nginx.org/pipermail/nginx-announce/2021/000300.html
Vector: Remote / DNS
Credit: X41 D-SEC GmbH, Luis Merino, Markus Vervier, Eric Sesterhenn
Status: Public
CVE: CVE-2021-23017
CWE: 193
CVSS Score: 8.1
CVSS Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C
Advisory-URL: https://www.x41-dsec.de/lab/advisories/x41-2021-002-nginx-resolver-copy/


Summary and Impact
------------------
An off-by-one error in ngx_resolver_copy() while processing DNS responses
allows a network attacker to write a dot character ('.', 0x2E) out of bounds
in a heap allocated buffer. The vulnerability can be triggered by a DNS
response in reply to a DNS request from nginx when the resolver primitive
is configured. A specially crafted packet allows overwriting the least 
significant byte of next heap chunk metadata with 0x2E. A network attacker
capable of providing DNS responses to a nginx server can achieve
Denial-of-Service and likely remote code execution.
Due to the lack of DNS spoofing mitigations in nginx and the fact that the
vulnerable function is called before checking the DNS Transaction ID, remote
attackers might be able to exploit this vulnerability by flooding the
victim server with poisoned DNS responses in a feasible amount of time.


Root Cause Analysis
-------------------
nginx DNS resolver (core/ngx_resolver.c) is used to resolve hostnames via DNS
for several modules when the resolver primitive is set.
ngx_resolver_copy() is called to validate and decompress each DNS domain name
contained in a DNS response, receiving the network packet as input and a
pointer to the name being processed, and returning a pointer to a newly
allocated buffer containing the uncompressed name on success. This is done
in two steps,
1) The uncompressed domain name sizelenis calculated and the input packet is
validated, discarding names containing more than 128 pointers or containing
pointers that fall out of the input buffer boundaries.
2) An output buffer is allocated, and the uncompressed name is copied into it.
A mismatch between size calculation in part 1 and name decompression in part 2
leads to an off-by-one error inlen, allowing to write a dot character one byte
off name->data boundaries.
The miscalculation happens when the last part of the compressed name contains a
pointer to a NUL byte. While the calculation step only accounts dots between
labels, the decompression step writes a dot character every time a label has
been processed and next character is not NUL. When a label is followed by a
pointer that leads to a NUL byte, the decompression procedure will:

// 1) copy the label to the output buffer,
 ngx_strlow(dst, src, n);
            dst += n;
            src += n;
// 2) read next character,
            n = *src++;
// 3) as its a pointer, its not NUL,
            if (n != 0) {
// 4) so a dot character that was not accounted for is written out of bounds
                *dst++ = '.';
            }
// 5) Afterwards, the pointer is followed,
        if (n & 0xc0) {
            n = ((n & 0x3f) << 8) + *src;
            src = &buf[n];
            n = *src++;
        }
// 6) and a NULL byte is found, signaling the end of the function
        if (n == 0) {
            name->len = dst - name->data;
            return NGXOK;
        }


If the calculated size happens to align with the heap chunk size, the dot
character, written out of bounds, will overwrite the least significant byte
of next heap chunk size metadata. This might modify the size of the next heap
chunk, but also overwrite 3 flags, resulting in PREV_INUSE being cleared
and IS_MMAPPED being set:


==7863== Invalid write of size 1
==7863==    at 0x137C2E: ngx_resolver_copy (ngx_resolver.c:4018)
==7863==    by 0x13D12B: ngx_resolver_process_a (ngx_resolver.c:2470)
==7863==    by 0x13D12B: ngx_resolver_process_response (ngx_resolver.c:1844)
==7863==    by 0x13D46A: ngx_resolver_udp_read (ngx_resolver.c:1574)
==7863==    by 0x14AB19: ngx_epoll_process_events (ngx_epoll_module.c:901)
==7863==    by 0x1414D4: ngx_process_events_and_timers (ngx_event.c:247)
==7863==    by 0x148E57: ngx_worker_process_cycle (ngx_process_cycle.c:719)
==7863==    by 0x1474DA: ngx_spawn_process (ngx_process.c:199)
==7863==    by 0x1480A8: ngx_start_worker_processes (ngx_process_cycle.c:344)
==7863==    by 0x14952D: ngx_master_process_cycle (ngx_process_cycle.c:130)
==7863==    by 0x12237F: main (nginx.c:383)
==7863==  Address 0x4bbcfb8 is 0 bytes after a block of size 24 alloc'd
==7863==    at 0x483E77F: malloc (vg_replace_malloc.c:307)
==7863==    by 0x1448C4: ngx_alloc (ngx_alloc.c:22)
==7863==    by 0x137AE4: ngx_resolver_alloc (ngx_resolver.c:4119)
==7863==    by 0x137B26: ngx_resolver_copy (ngx_resolver.c:3994)
==7863==    by 0x13D12B: ngx_resolver_process_a (ngx_resolver.c:2470)
==7863==    by 0x13D12B: ngx_resolver_process_response (ngx_resolver.c:1844)
==7863==    by 0x13D46A: ngx_resolver_udp_read (ngx_resolver.c:1574)
==7863==    by 0x14AB19: ngx_epoll_process_events (ngx_epoll_module.c:901)
==7863==    by 0x1414D4: ngx_process_events_and_timers (ngx_event.c:247)
==7863==    by 0x148E57: ngx_worker_process_cycle (ngx_process_cycle.c:719)
==7863==    by 0x1474DA: ngx_spawn_process (ngx_process.c:199)
==7863==    by 0x1480A8: ngx_start_worker_processes (ngx_process_cycle.c:344)
==7863==    by 0x14952D: ngx_master_process_cycle (ngx_process_cycle.c:130)


More information about general exploitability of a similar bug class found in
* Chrome OS exploit: one byte overflow and symlinks
  https://googleprojectzero.blogspot.com/2016/12/chrome-os-exploit-one-byte-overflow-and.html
* Project Zero's Poisoned NULL Byte
  https://googleprojectzero.blogspot.com/2014/08/the-poisoned-nul-byte-2014-edition.html
* Hiroki Matsukama's House of Einherjar
  https://www.slideshare.net/codeblue_jp/cb16-matsukuma-en-68459606
  https://www.youtube.com/watch?v=tq3mPjsl-H0
Given the rich interaction opportunities in nginx with user controller data
and the documented precedents this bug is considered exploitable for remote
code execution on some operating systems and architectures.


Attack Vector Analysis
----------------------

There are several ways in which a DNS response can trigger the vulnerability.
First, nginx must have sent a DNS request and must be waiting for a response.
Then, a poisoned name can be injected in several parts of a DNS response:
* DNS Questions QNAME,
* DNS Answers NAME,
* DNS Answers RDATA for CNAME and SRV responses,
Keep in mind that the vulnerable function can be hit several times while
processing a response, effectively performing several off-by-one writes,
by crafting a response with several poisoned QNAME, NAME or RDATA values.
Furthermore, when the attacker delivers a poisoned CNAME, it will be
resolved recursively, triggering an additional OOB write during
ngx_resolve_name_locked() call to ngx_strlow() (ngx_resolver.c:594)
and additional OOB reads during ngx_resolver_dup() (ngx_resolver.c:790)
and ngx_crc32_short() (ngx_resolver.c:596).
An example payload of DNS response for a 'example.net' request, containing
a poisoned CNAME:

bcb881800001000100000000076578616d706c65036e657400001c0001c00c0005000100000e10000b0141c004
         ^                                                                        |   ^ pointer \
                to position 0x04 -|
         NULL byte <----------------------------------------------------------------------------------------------|
                
                                                                                  |
                                                                                  ^ 1 byte \
label

A slightly different payload (the one in poc.py) fills enough bytes to
overwrite the nextchunk.mchunk_size least significant byte with a dot:

bcb881800001000100000000076578616d706c65036e657400001c0001c00c0005000100000e10000b18414141414141414141414141414141414141414141414141c004
                
                                                                                  \
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                                                                    |
                                                                                    24 bytes \
label


A 24 bytes label leads to a 24 bytes buffer allocated, which is filled with 24
bytes + an out of bounds dot character.


Fix / Workarounds
-----------------

Allocating an extra byte for the spurious dot character written at the end
of the poisoned domain names mitigates the issue.


--- ngxresolver.c  2021-04-06 15:59:50.293734070 +0200
+++ src/nginx-1.19.8/src/core/ngxresolver.c    2021-04-06 15:54:10.232975235 +0200
@@ -3943,7 +3928,7 @@
     ngx_uint_t   i, n;
 
     p = src;
-    len = -1;
+    len = 0;
 
     /*
      * compression pointers allow to create endless loop, so we set limit;
@@ -3986,7 +3971,7 @@
         return NGX_OK;
     }
 
-    if (len == -1) {
+    if (len == 0) {
         ngx_str_null(name);
         return NGX_OK;
     }


Official fix can be found at http://nginx.org/download/patch.2021.resolver.txt


Proof-of-Concept
----------------

A dummy DNS server delivering a poisoned payload that triggers this
vulnerability can be downloaded from \
https://github.com/x41sec/advisories/blob/master/X41-2021-002/poc.py The described \
vulnerability can be tested by running nginx with the provided config as follows under valgrind \
(https://www.valgrind.org/):

   valgrind --trace-children=yes objs/nginx -p ../runtime -c conf/reverse-proxy.conf

Then run the DNS server (will listen on port 1053 by default):

   python poc.py

and trigger a request to the server:

   curl http://127.0.0.1:8080/

Depending on the heap layout when the bug triggers, the malloc mitigations
might detect or not the effect. Several ways of showing up in the logs arise:

corrupted size vs. prev_size
2021/04/16 13:35:15 [alert] 2501#0: worker process 2502 exited on signal 6 (core dumped)
malloc(): invalid next size (unsorted)
2021/04/16 13:35:34 [alert] 2525#0: worker process 2526 exited on signal 6 (core dumped)


Nevertheless, valgrind and AdressSanitizer will always detect the memory
corruption.


nginx config used
-----------------

daemon off;
http{
    access_log logs/access.log;
    server{
        listen 8080;
        location / {
            resolver 127.0.0.1:1053;
            set $dns http://example.net;
            proxy_pass $dns;
        }
    }
}
events {
    worker_connections  1024;
}


Timeline
--------

2021-04-30 Issue reported to maintainers
2021-05-17 Issue reported to distros mailing list
2021-05-18 CVE assigned
2021-05-25 Public disclosure

About X41 D-SEC GmbH
====================
X41 is an expert provider for application security services. Having extensive industry \
experience and expertise in the area of information security, a strong core security team of \
world class security experts enables X41 to perform premium security services. Fields of \
expertise in the area of application security are security centered code reviews, binary \
reverse engineering and vulnerability discovery. Custom research and IT security consulting and \
support services are core competencies of X41.


["x41-2021-002-nginx-resolver-copy.txt.asc" (text/plain)]

-----BEGIN PGP MESSAGE-----

owHtWX2QHMV1l2RslAFkSgF/gUMrONatbudrv2/FgVZ3J+4Mko5bnSSg4Oid6d0d
3ezMMB+3t3wYbFIYDDE2VCAxtgJ2wAEKHAdXqOBgCickldgBUnFkKjYhokic4JRT
CSmHShUh73XP7M7eLbapgvI/Xkmn25nu16/f+73X7/36s6e8a4O08cu333f/lvCk
Uzc+LJ/Y+MhqQZdzWk6XNS0nOy3LWZV9Frj2CvNlw/V6SrgaXvHw2SdLNXPFCly/
Rw6nZlQJn0Km99XJQjyN7G825UZP3u8wMsuoRw75VsjIwch2mE8blm2FPWny7fxI
dQbrgliyQEPLaVXJrNVqS1Ou07T8DjNJrdlkRgi/HGR+YLlOUCWaUlL0CpGJruQ0
RUsNnqeh0R4aC0N0RcuKobp0kDmm61fJnmKWzDmGEj8giwsXVkk7DL2gqqrcLorr
t9Tk9QJrMp85BhODYEyHWnaHOspgrGd5zMfHYr5MHceNYIqKBlc1TctrmtIOOzYI
NUJUYoF1XLCuii6QpnxmWmEVXUSm5frMFDm/05jNkgsjKyB7wUSOmyV7qb8cBbi9
FYv5WTLjWwapsyBkfps5jlQPaRjBruejhm0Z0tTBmSqBH8Lnubyml6WpQ/BMn8jD
y3qd1A3Xh01VwDT8e6IafqnmFV2tHazuU2tT1Vl1fgF+W5yDH/XqoopP5uBfDf7N
wHew3351Yao61QebPGTTbrerIF7NgBmKyVSbNlQqRlosUH8WlFVJkupRp0MBxNQx
yVzHo0Yoyes+Us0hrgCxCyBmvg/usxzA+upSInEJJY5lSLdt2Yx4vmuwIADs8VCA
QR4ghwUStW23GxBKHBZ2XX+Z0DCkxjJESeiSLg8MSkw3JEab+qANvBjbrmzPEm01
N5MhbhSCJqQBIDADCVSgpI0hhWINiohuRIBtXyEH2oyspEOMGNQhDUZC32q1AHgw
FLbNYZKoh3vymWf3UBkaa35lBFAgTd/txLHdBVSQEMQnW4fdWh0rtFaYBLAyMHBa
ESygkBoJPGZYoB0s79MmKujhdkMSG8KF+bhttBTKtBmF1aTAajlW0wKVQ1ATjAKb
dthqKHZrtCNnmXRYSE0aUtK1wja3Dy641q6SQT3asLkE8MqKZa5zitit2FwAUQA7
QltRo21BHpGmmQM7kN2mXMcQMRgHi20tM9iVL8LNcE3AxSozohBShCJNRwyl8h2B
Grg4LgkLuk1cH83Vojg2EEDCtVEszmiC3+EXij+YlDgRttCE0Mc5BM0MBkQfsiYE
G1iEGcuJDXGlAz51AipGz01nYz2lxCoBaNBqh4gHLhl0Zaue7Vq4JkgfRg4ApWm7
rhkvIIERQquT2Iqb33Mh6hxQaNiyHKFN8KmFq9AO4JYDGKYzBcJvwQWoT9EIsFdz
qN0LrGBE/MnS4FTpg24Ms4yaDkHFyKBlQJiJG4ofk7YbhA7tgDYrlsA7mAyUhxnU
Jh3XjGx491NQjUIDFirSqHgfuAKWXKG2BZAUCDGZ4XY8GB8QBlji2psuJHPwN6gj
QaCE8AVmciulDYf+Mpi1kng0AXUSO2hYD1IBLkMlsL0TigzCB4NwcCzOjdMQM7N8
qM/CyHfwBSWpSZiMunZPWptESKxhogWgL94QDOGrALiCyMAlMOGAKeCvCTDAzAQa
EzhDvCAr6RmejobmpyxBAusqZkOUcVMakc11SKJB7DTeOcAjsTHsybQCg/oclsLB
KYU7GBYQRA7Rc5Vkt5Bv0ruS+o95tDXBAEmGHawc24KnXIrniiLlMgRPhChMvQfl
+/bL9pVfbzKeIT2Lex1sbwGsahCMQQerDHBb2GUARLRI3xg84h0wgR8SnYvmkgb4
Sg/ISZBCTZHTRp5aYOisyL7cr2926uAUzLwSiODryefyZJu2Azq1gz4Y6Nmmnsec
VDjZmM+5ZrFV1xokdkcwDGRK9i1eyBVQyCF+pPK5qZUQW6Al5GBqGJhXEHrwIzah
BMUAs4MsnzdsKj6T7zpYt23MCj2enuAVFwFbCqQGOqUfTcIHeBwNJoJfHZAEWqPC
zOlPhxdNF80dn7iDXSLmBs7qb3iUynxpEw5VyLa2XZUkVSUQVZiDYivjUnECGAJm
VuJlShD6oMKYGYRZEvhGljiZnRJJfeANGZ8kzvBTGBo/hQUB9j6ou2bn2aEJDpkk
O2DW+Difks/wZBUGg4yT5V9jWw1PtppkzCHbJomWIVfj9EKGBO46H3HDdakQEjsf
jItZHYyNjg2Zs6ZUIms+O2C/4+OgLBRXw1u+FhcuQoRDteJ3Ib3EGErclvLnQHuh
+UehCjG47mtNMha/zTcz5JxzSCVDxrmZ1lt7knwUHHepc9nON7XrkKaljDgF0JoC
P0JD2DV4GsooSJdx/oa2IwnCpJJYs4HJ2PRDK/PYh6wBGiBI5FQ2GNZRHC9k3/mH
91+Q1lKS5ppD4QvO4gkuSRYIfxtUFaUEjkyVeTgyDgk3lAawG+3oLA+QflnJUkXl
2ppSGlFTcrWSwjI+00SlBHWC1RTBxgfFhuwLkLiALEQd1raA2oEKeaieaCvAQz2I
bF7qQraeX5g5uDS3b7E+Ex/WBqgJVbPEW5H60t69tfn5men4JdQfEPXQJpcrpTy4
ac7h52CcvEEZrpQ+GAAfiBJtVc+Xp3Iz1fW9Cvh7qHaqFjS9khkSAOkKBUzrud1r
BMSpcImuk5IrlLW3KqXff6wVplcKhdHCCqXaGmGR6S3x9LROSLE8UkihtlufEEKY
BxHdVwfOADxNxgZvRJEIsiY0faQovTBdEKKGhSyBM5fwNPETefhYmGmkoMpMsSwE
YcGXspHRA3wIGUOPQFZZnxgpq1yYjo0UeLTrJPOGhKB9JkZPr2i1Sjw9hPN7jUIs
GK1MfrTHChPF3LSQ1qFILfw8G9PzI6GUy+XLe6qE149jgiuBdSv59NiaafLKW1st
NBpGs1HBrKjxuIezCFM7pMwG1GvL/eDJFUQFt91cH0WFSn6mLBbFIWRspbWEnTI1
2JJ4hCpoo31aqEzF4Ign939FIORGArxcmymsAXhqcjpq9dHez5d350o/T9jnJybe
JMZ+Gfa/DPtfWNhL0l7s4CwHyrqOqPhpA4/6FnN44x7zFQlHAVFMIY47lk2hWYvw
OKVBXAiBFGkHmWr7LpT1++vJ1Gq/yeGHdRNqOl5LBb0O1EzLWDQmTGPLdVs2A0WP
MCO8ivmuArmjBfAFp7odNafpJVXPqQZfQnYDOV4COy8ZV5CTFWRYQTC2O8i8kEcu
AYHbAzKfcCi8lNuNJcpb0aCgahUVahI54WJkJ7LF4vhWRioYyal48VnLd5ctspeG
QbRMOxQUmHWRiAFLzlhOm/lHqJ9SAMnWAEoOFkAJxhSHhSqyXg07YktHPNVo6CW5
w4VFHSozRy5VCsWJklZaI6MHTowajGvdxab3vJXJ8Mp8Z/5IYMuzmnS+tZIwMRZ0
xLzojoks1/NcP4wc2AdL8Wa8agTNRWvvQ+TCr1jASUkbbrpG1GG8S/CQWTF5pHOm
C6EiWMsA9oa0aB9YyLhBTxFTZ8MUH6c+EE6uB+rxmi7oAcA7gSjHfaMNhZkBBTE2
ypJU48RbTIX/VK4L6S7srAH8YOc+T9WlPb7lbhutMkwXcboy5nX5fofoO0XaY/nY
9wlrdSKohdt0BUVDJTxM86LufEADOk0qaFm0Ae2vxbt+ZBAGlJ9o4wW7bDlHxM0K
qJqojt1/IAI0rXUVQIjfL8KVORN60b7a3pls/LjmBF3Mn6OeLUzXDtS4YlP4mqtd
Xzg4IB6z0gUMmnxQomNxDAgylYwiU2PNwV99jTF1B4LKl1JUPk0RdIxfIQFW7R4B
CGCWEnW6kJAiXgTTkJUaMQc+LEmgt2+qxKbCFHzzyFmJDUPJHyGc9kQ+bMZHiis7
YFr6Nwkms0EvP0j7aErIgz3y/qjBpPioRFbQiPyA7ySboIjrCBnXFDkDNNu/f3fc
bJgRvk6ToUuIgCUsppg5luF8KPZ0Kd4hs+54LmLVwUNleA2fEyJijeGT3oy8EXLK
E5qQg88N38jnloI2ZImRS5YyCt7lsFXa8fCWhvZsl5oJO993iUD89ngYprrtSYRk
0/ThWvtCh9YwGpWKXtHgo8f/xKdcKsLhqJfMslYySkUtX2LwpMAHGvEP/L/Yn8X4
fw1I3fiuMGi1Lydv0+caLizFunluwH0BR7dWIPI1gzUH7MI5o3PW2/W5Zh1V8zbs
8x2QeTnRhT049QYJnsDh2GqHkA5Mq8lvdsM+wMY4LefwCzYPyn6vlyFNiMOAMMeN
Wu24LwldaZi4QHaB8wpKh/+3xBuV0XSGSCScK3tHcAhFuf7W/gyj9u2z/Fv+vANK
vDOgItiECizEsAJcDT9KM8b9N/EdROoCQpQJyARa/HKKgyNXkMT4cX43kObNhilW
rFj2WKtEJYeg+qe+4FBH1Ck1sWJ8XABafSrAiCmUc2UeZHIoK9dQuAl3Fx/LzDGl
mFDrZ9TUBVGQ3JdijODFTBBE/PoQdMC8P8jxYEAtp8taQdZKRC9Cyq8WNSU3kS/n
C1pZI+NaTtOk8fFx5FpVXhDJuqJPKBUVHyRXimmB60QWqjqIzOcmysVcvhiL3LWL
yPmJQj5bJuP5iVwF/t+1SyAET6EIUuxSCF+sLKfYxRuPTBJOAsv4TVCssr5TGh98
1fqD1R0x4HaQoZuB5AqLX+kgLgw4QkNuUxvbPtt1vSzS6F2s+EJi463mzljhSkko
XNZTCuNnwOUu9cnca0EVrimSxVw9VBf54vE1T4dJ5LgOWIJ2xB5Df6avHkYvJEn7
m5DbLCgKmoDDuEQTzRxgBvsJaCcE9+P6LdV0uw5mWtXDjkJBjyl9J4arIQiEZstt
yvB3ynUM5oXr4IyxZkadTo8XA/HldlxL9e9MBTaTvC7qSlEyiX5CGiq9E8UT9fCW
AjrEQVMHURk1eCu0WtADZqjUXIE18HpNhf6uoYquWT1c0GUBQy2nihOE375BN2b4
VgPkjlwXAiYU105+5Diioup3TDzafHcF2h4TL6ObVgsva8TlRkDA1LB/KDlbPpbQ
Y+keLnnKbZ+B4wac1h8py5AFDCZDB2SbcAxO9iBs3caRQPiLyB5RFBUU4rdssoEV
VVP1sQIOoHn13dWego94F+Sg5lzVlFPGeA1rWwGn/zEG8GZUK+ZxpyZr0sgOY628
Xth2k0NXEg1h3CjRftcT35sJ6WIelMR2AjM9V1Y0+KNXK1pFUyVpmnkQXWhO1xlc
V9gUW9tBPY6dZYINcYERk4dxMsOWRxKXCybDXhELfbzS4hmRtxcKqafbP2Qq2+Le
NuLNDb/ccFsQ/L6FDRW40fcjr3/BshIo2PCu8LpBQgCpWkHVIY/lq/liVS+SSyk0
y+FlJFfU9LO1KhFsT3LViY9zkNYtlIgdL79PIiUyhpkSo8VjZkYS+xrLVEEncS3B
r0W4CmORA3gOcdi69fOF1Pq54sj1c6Wfvb4k7UMzgTUw42UHUER31zgRXKfIGlyF
Rw9ih9rcoLHduW+gy/d7iQGRJwGxArBxbEQBxMmIM9CkMNXBjm+nhIgRmY8anNMC
73APqeK7Ar+LJCfANsiSMZoRYYPsKA5XEK6uuZRLchsZYBPxv+Y6EbL9R0zoq2Mc
p/qZ4YE85pY85MtwfPruTvy8VorJUaFFTAmCXRxmiNYdwi9X2Clh5j4AYW1bDpMG
JkpO0LxG5vDsBv09DgoMPTzmsaOCMIkHFmW9PGKgCSby3QAn8DtNNNlgRoVMHZyB
BIYYAUclz3NFMh81bMvA6YbtBpHPINNzKhGyKpmW6zNT5PxOY1aaHPGRcIwViOoG
+vwwSZm+6BI9D0QLHwXYR2PyRdda4G2FzNIVVBSCgTnYYUN8mBFsoieEWQxOIg5S
IRtiOIlqCoc4xnua/0wWQPIFLYF3hi6niOKFQ0Y7OAn8Y5sxAdp/KZbAjgPpj4Bv
Hls+wV1gmuhYUWfELqASZLbJs8+bqjnSDjStm4H0G9JrnEeDnGSxLoRqw3IomCPO
/qAcRBxL+Ie1pxp6EBuknkKmwIxwkEIcMOTa+OC5A6nlAJTxXSundCNOHfY3xXXj
xsNaCrKAYyClCDsBsyjSzZsuOGHDRmlD8X3bTvjKyYv7Tt617Wl1379u/vLt992/
JTzp1HdvuuLhs09+/5mD03oXnN+yCcsrJtsg/cqpycjS9ve+UX/hm1ceO/fOP/zY
D76uf+2K1kWnORcrn7zr7z7zYO7xrd6Rl/bf808vZP7yzituPYmO3bR4yfu3H3+i
sXjo+1Hme2dt/q87j//e6qtfuC34640TL2989NMz9hnPPrX1nu+dMb7tPZ9TTv/9
xdcvvyT6aqN4+ZZf2/YvN0xe9e/Xbzj+8IdO+jfrleilD75nuX75K7ef2ineVa7d
/sLWi6n9uQeeqt99MZUueNfRLT9+fd+fljb8zrHuV8546I0Dn7phw+Z/+M9XnQ8s
PjS1+7Fnbrnxli/e+1eP/vOe78hbv/m14MmZv99122n3vvy3m9ufn6zfeUC+5+X7
3rvrtOPjZxz7dOHg7LE/M+94Rp7+4VknPv/57+Zu+MdN41+df+rE06+59PAjF9/9
xm9H/3H0uJZ99qaFyemvv3L80QduvPmOmWO1PwoPPH3X1u8+9YHF65/f9MD9E5+9
+fo7vqS/u2kf1j70pUcyO17Xt8tbztwxEaxewX7riT//xvbvP/6JO+/+mxOeON3o
Pvvri8/8ySPPbXrtlOd+tfaxj1df/falT3/8xfy5j/3w4r845aYfX/3ixEtnXnv2
T6773Q8/NX1IfeCse79tFJ74wmsLOx995qLmXT/5kbHwGzL95OyOsY3fuvW5P34w
v/T8t0pbbt0b3vK+z2w+6k586os3nld47LKzF7besEm+/X+zr/s/OHpY+eCDvf9z
x9wLL/mDkzcVPlH77+Ipj734wnL4+G1HX3ztwHXPbHtp/0NXX/vh/5m97saTfmSe
9+R35pZfOfab9MknvvH/
=raVZ
-----END PGP MESSAGE-----


_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic