Re: Nmap tty and NSE

["Patrick Donnelly" <batrick.donnelly () gmail com>]

On Mon, Dec 22, 2008 at 1:04 AM, Fyodor <fyodor () insecure org> wrote:
> On Sun, Dec 21, 2008 at 11:36:23PM -0700, Patrick Donnelly wrote:
> > When speaking to Ron and Brandon about some of the problems debugging
> > their scripts, I had thought it would be useful to have some form of
> > interactive debugger they could use at arbitrary moments during a
> > Script Scan to inspect script threads. In particular, they would like
> > to see all the threads waiting/running and inspect the stacks of the
> > threads. I expect it would be as simple as adding an extra character
> > command (like 'v' increases the verbosity) that signals to NSE the
> > debugger should run.
> >
> > I don't think this is possible right now with (the basic) Lua debugger
> > debug.debug [1] because Nmap takes control of the tty. There would
> > need to be some changes (while maintaining compatibility) to
> > nmap_tty.cc module to make this possible. Does this sound like a good
> > idea?
>
> Hi Patrick.  I've also been frustrated by having little insight into
> NSE's operations.  Part of the fix may be this item in nmap-dev/TODO:
>
> o With sufficient debug level, NSE should show all the script
>  instances being run.  It should also say when a script starts and
>  when it completes. [David]

This is fairly easy to do. In fact I had already made a patch (for
Brandon and Ron) that does the first part. Having it print when a
script finishes is about as easy.

Index: nse_main.cc
===================================================================
--- nse_main.cc (revision 11421)
+++ nse_main.cc (working copy)
@@ -391,6 +391,22 @@
   std::list<struct thread_record>::iterator iter;
   struct timeval now;

+  if (o.debugging >= 3)
+  {
+    log_write(LOG_STDOUT, "Running %d script threads:\n", unfinished);
+    for (iter = running_scripts.begin(); iter != running_scripts.end(); iter++)
+    {
+      const char *filename;
+      char name_ip[512];
+      lua_getfield(iter->thread, 1, FILENAME);
+      assert((filename = lua_tostring(iter->thread, -1)) != NULL);
+      iter->rr.host->NameIP(name_ip, 512);
+      log_write(LOG_STDOUT, "Script %s thread %p against target %s.\n",
+        filename, (void *) iter->thread, name_ip);
+      lua_pop(iter->thread, 1);
+    }
+  }
+
   // while there are scripts in running or waiting state, we loop.
   // we rely on nsock_loop to protect us from busy loops when
   // all scripts are waiting.

> I have mixed feelings about enhancing runtime interaction to handle
> NSE debugging.  On the one hand, it definitely sounds useful in many
> cases.  On the other hand, it involves changing Nmap's TTE handling a
> bit and adding an NSE debugger for everyone (even the 99+% of Nmap
> users who are non-developers).  I think it would depend on how
> invovled the implementation is.  Diman integrated an NSE debugger into
> one of his nmap-exp branches a while back, which could make for a good
> start.  I'm interested in how other people feel about including such a
> debugger.  At the very minimum, having such a thing available for
> developers to install sounds like a big win.  And including it in
> mainstream Nmap builds may be worthwhile too if it doesn't bloat the
> code too much or slow things down.  Also, if it is activated by
> runtime interaction, it needs to print out an easy way to resume when
> it is activated.  I can easily see Nmap users triggering it
> accidentally during their scan and then being stuck in a debugger and
> not knowing what to do.  Maybe it should only work when the debug
> level is at least one (which you can of course change on the fly
> during run time if you didn't specify it on the command line).
>
> A simpler (but less powerful) option is to include more information in
> the status information printed when you press enter (or most other
> keys) during a scan.  For example, it could print each currently
> running script thread, including the target/port it is running against
> and the amount of time it has been running for.

Right, we could print out information concerning scripts but I feel
this will never really satisfy script developers. I have the idea that
the majority of the debugger would simply execute input code. This
provides flexibility that a developer can basically do whatever he
wants while maintaining minimal complexity.

A lot of the tools the developer would use to debug scripts can be
moved into a debug library (probably very similar to Diman's debug
library which I haven't looked at closely yet), separating it from the
engine itself. The code can then be loaded on demand and used by the
developer during a script scan. So, NSE would not hold the hand of the
developer by making very user friendly commands but would facilitate
an environment that the developer can use to inspect their code.

-- 
-Patrick Donnelly

"One of the lessons of history is that nothing is often a good thing
to do and always a clever thing to say."

-Will Durant

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org