Nmap Development mailing list archives

Sergey. [Status report 10/17]


From: Sergey Khegay <g.sergeykhegay () gmail com>
Date: Tue, 5 Jul 2016 20:37:12 -0400

[Report 10/17]
Hello Nmap Community,

Thanks to Patrick Donnelly (probably a bit belated, but better late,
than never) for helping to understand how his and Devin's libssh2
hooks work in the current implementation!

Accomplishments:

- Tested libssh2 port to Windows. Although it works, there is a big
  performance issue. At first I thought that it is Windows platform
  related, but after couple tests it turned out that Linux platform
  is also affected.

  The problem is that when using libssh2 module, there is a huge
  memory consumption:  Using ssh-brute.nse script for testing with
  --max-parallelism=100 and brute.threads=100 (aka max_threads) and
  12000 account to iterate, the virtual memory claimed rises from
  18 MB to over 2 GB (!).  Testing under the same conditions but with
  different, ftp-brute.nse, brute script did not reveal such huge
  memory consumption.

  Interestingly, when I run the script on my Mac, the NSE manages to
  iterate over all credentials and find the correct pair. Although
  when on Windows 7, the nmap process gives up with a segmentation
  fault when ~ 2 GB of memory is claimed (private working set). The
  segmentation fault is thrown because of these two lines of code

  nse_libssh2: l_session_open(..)

    state->session = libssh2_session_init();
    ...
    libssh2_session_set_blocking(state->session, 0);

  Because the memory is exhausted (unlikely there is any other reason),
  `libssh2_session_init()` fails to allocate space for a ssh2 session,
  hence `state->session` is set to NULL. The segmentation fault happens
  in `libssh2_session_set_blocking(state->session, 0)` because the
  function tries to access session descriptor at the 0 (NULL) location.

  My assumption is that Lua's garbage collection is to blame, probably
  a user data created to track ssh2 state is not cleaned properly upon
  completion.

  nse_libssh2: l_session_open(..)

    ssh_userdata *state =
        (ssh_userdata *)lua_newuserdata(L, sizeof(ssh_userdata));


  I have not figured out how to properly check the assumption yet and
  force Lua to clean up userdata.


- I cleaned up github repo so that you could try to check how the
  libssh2 port works. It should compile on both Windows and Linux.
  Instructions are described in BUILD_INSTRUCTIONS.txt file.

  You can get the code using this command:
  git clone -b gsoc-ssh https://github.com/sergeykhegay/nmap.git


  Windows.
  Make sure that you have `nmap-mswin32-aux` in the same folder where
  the cloned repo's folder is. To get the former, use this command:

  svn checkout https://svn.nmap.org/nmap-mswin32-aux

  I used Microsoft Visual Studio 2013 Community edition for
  configuration and builds.


- I also found an "EOF" bug when doing brute force attempts against a
  single server, which Patrick told me about. It was hidden from me
  on a more verbose debug output level.

- You can use the following server for testing:
  IP: 52.91.234.209.
  Valid credentials to test on: student:gsoc2016

  It should be available 24/7. There is no limit on traffic.


Goals:
o: Investigate the performance issue. Better understand how memory
   management in Lua works. Make sure that userdata is actually freed.
o: Investigate "EOF" bug.


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

Current thread: