Nmap Development mailing list archives

Re: ASAN stack-buffer-overflow crash in asn-query

From: Daniel Miller <bonsaiviking () gmail com>
Date: Wed, 3 Aug 2016 09:24:17 -0500

Jacek,

I can't reproduce this, but I'm probably using a different version of asan.
The thing is, I'm pretty sure this is a false positive, but I don't know
exactly how to check. Here's what I see is happening:

The trouble starts in nse_nsock.cc, line 308 in static void trace
(nsock_iod nsiod, const char *message, const char *dir). This is trying to
output a line like this:

NSE: UDP 72.14.177.105:45360 > 8.8.4.4:53 | CONNECT

To do this, it creates buffers on the stack to store the sockaddrs and the
string representation of the IP addresses:

      char ipstring_local[INET6_ADDRSTRLEN];
      char ipstring_remote[INET6_ADDRSTRLEN];
      struct sockaddr_storage local;
      struct sockaddr_storage remote;

Then it calls nsock_iod_get_communication_info, passing the
sockaddr_storage structs by reference:

      nsock_iod_get_communication_info(nsiod, &protocol, &af,
          (sockaddr *) &local, (sockaddr *) &remote,
sizeof(sockaddr_storage));

Within nsock_iod_get_communication_info, in nsock/src/nsock_connect.c, we
first check that remote (here declared as struct sockaddr *remote) is not
NULL, then on line 519 we use memcpy to overwrite it with the peer address:

    if (remote)
      memcpy(remote, &(nsi->peer), MIN((unsigned)socklen, nsi->peerlen));

This is the write of size 16 that is mentioned. ASan even says that it is
specifically overwriting the "remote" variable on the stack of the "trace"
function. So it seems to me this is not a problem, but maybe you have more
insight into what could be causing ASan to complain about it? I'm including
the nmap-dev list in this reply so that someone else might be able to offer
insight.

Dan


On Wed, Aug 3, 2016 at 6:10 AM, Jacek Wielemborek <d33tah () gmail com> wrote:

$ nmap --script asn-query 8.8.8.8 -Pn -sn -n --script-trace

Starting Nmap 7.25SVN ( https://nmap.org ) at 2016-08-03 13:06 CEST
NSOCK INFO [0.3030s] nsock_iod_new2(): nsock_iod_new (IOD #1)
NSOCK INFO [0.3130s] nsock_connect_udp(): UDP connection requested to
8.8.4.4:53 (IOD #1) EID 8
NSOCK INFO [0.3130s] nsock_trace_handler_callback(): Callback: CONNECT
SUCCESS for EID 8 [8.8.4.4:53]
=================================================================
==25955==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7ffd1ea5ff90 at pc 0x7f71d3c05d34 bp 0x7ffd1ea5fbe0 sp 0x7ffd1ea5f388
WRITE of size 16 at 0x7ffd1ea5ff90 thread T0
    #0 0x7f71d3c05d33 in __asan_memcpy (/lib64/libasan.so.2+0x8cd33)
    #1 0x63872b in nsock_iod_get_communication_info
/home/d/.nmap/nsock/src/nsock_connect.c:519
    #2 0x611877 in trace /home/d/.nmap/nse_nsock.cc:308
    #3 0x611d47 in callback /home/d/.nmap/nse_nsock.cc:363
    #4 0x647438 in event_dispatch_and_delete
/home/d/.nmap/nsock/src/nsock_event.c:373
    #5 0x63f0be in process_event /home/d/.nmap/nsock/src/nsock_core.c:1076
    #6 0x63f566 in process_iod_events
/home/d/.nmap/nsock/src/nsock_core.c:1141
    #7 0x6502d4 in iterate_through_event_lists
/home/d/.nmap/nsock/src/engine_epoll.c:347
    #8 0x64ff24 in epoll_loop /home/d/.nmap/nsock/src/engine_epoll.c:314
    #9 0x6395c5 in nsock_engine_loop
/home/d/.nmap/nsock/src/nsock_internal.h:414
    #10 0x63e5f3 in nsock_loop /home/d/.nmap/nsock/src/nsock_core.c:943
    #11 0x61244e in l_loop /home/d/.nmap/nse_nsock.cc:431
    #12 0x7f71d2dc97a9  (/lib64/liblua-5.3.so+0x127a9)
    #13 0x7f71d2ddf5bc  (/lib64/liblua-5.3.so+0x285bc)
    #14 0x7f71d2dc9b9e  (/lib64/liblua-5.3.so+0x12b9e)
    #15 0x7f71d2dc9bf0  (/lib64/liblua-5.3.so+0x12bf0)
    #16 0x7f71d2dc077b in lua_callk (/lib64/liblua-5.3.so+0x977b)
    #17 0x60ed49 in run_main /home/d/.nmap/nse_main.cc:652
    #18 0x7f71d2dc97a9  (/lib64/liblua-5.3.so+0x127a9)
    #19 0x7f71d2dc9b92  (/lib64/liblua-5.3.so+0x12b92)
    #20 0x7f71d2dc9bf0  (/lib64/liblua-5.3.so+0x12bf0)
    #21 0x7f71d2dc8fc1  (/lib64/liblua-5.3.so+0x11fc1)
    #22 0x7f71d2dc9e7c  (/lib64/liblua-5.3.so+0x12e7c)
    #23 0x7f71d2dc0850 in lua_pcallk (/lib64/liblua-5.3.so+0x9850)
    #24 0x60f52e in script_scan(std::vector<Target*,
std::allocator<Target*> >&, stype) /home/d/.nmap/nse_main.cc:810
    #25 0x4fd731 in nmap_main(int, char**) /home/d/.nmap/nmap.cc:2160
    #26 0x635961 in main /home/d/.nmap/main.cc:228
    #27 0x7f71d217b57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
    #28 0x4a3998 in _start (/home/d/.nmap/nmap+0x4a3998)

Address 0x7ffd1ea5ff90 is located in stack of thread T0 at offset 512 in
frame
    #0 0x61173a in trace /home/d/.nmap/nse_nsock.cc:295

  This frame has 6 object(s):
    [32, 36) 'protocol'
    [96, 100) 'af'
    [160, 206) 'ipstring_local'
    [256, 302) 'ipstring_remote'
    [352, 480) 'local'
    [512, 640) 'remote' <== Memory access at offset 512 is inside this
variable
HINT: this may be a false positive if your program uses some custom
stack unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow ??:0 __asan_memcpy
Shadow bytes around the buggy address:
  0x100023d43fa0: 00 00 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00
  0x100023d43fb0: 00 00 f1 f1 f1 f1 04 f4 f4 f4 f2 f2 f2 f2 04 f4
  0x100023d43fc0: f4 f4 f2 f2 f2 f2 00 00 00 00 00 06 f4 f4 f2 f2
  0x100023d43fd0: f2 f2 00 00 00 00 00 06 f4 f4 f2 f2 f2 f2 00 00
  0x100023d43fe0: 00 00 00 00 00 00 f4 f4 00 00 00 00 00 f4 f2 f2
=>0x100023d43ff0: f2 f2[f2]f2 00 f4 f4 f4 f2 f2 f2 f2 00 f4 f4 f4
  0x100023d44000: f2 f2 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00
  0x100023d44010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100023d44020: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
  0x100023d44030: 00 00 f1 f1 f1 f1 00 00 00 00 00 f4 f4 f4 f2 f2
  0x100023d44040: f2 f2 00 00 00 00 00 f4 f4 f4 f3 f3 f3 f3 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
==25955==ABORTING

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/

Current thread:

Re: ASAN stack-buffer-overflow crash in asn-query Daniel Miller (Aug 03)