Jacek's status report - #14 of 16

[Jacek Wielemborek <wielemborekj1 () gmail com>]

Hi guys,

This week I created another branch, ncat-sa-take2, with the goal of
slimming down the patch size from ncat-lua-callbacks, which became too
hard to merge all at once - there was too much interface to be
reviewed, too many features to test, and so I and David agreed to get
recv() and send() working perfectly first and then plan next features
from that point. I still kept ncat-lua-callbacks though, as a
“playground” branch.

Accomplishments:

* Redesigned connect-mode connect() in ncat-lua-callbacks. It now
actually connects to the host and port specified by the filter, so
filters can change this data to connect to other host and/or port.
This would theoretically allow to implement a SOCKS filter that would
connect to some proxy, using the original address as the CONNECT
method argument.

* Merged httpd.lua. After merging, I discovered a bug related to how
Lua's readline() works that could lead to DOS attacks, which I already
fixed. Announced that on the mailing list (see:
http://seclists.org/nmap-dev/2013/q3/510 ).

* Started a discussion on --lua-exec scripts packaging:
http://seclists.org/nmap-dev/2013/q3/513

* Started a redesign of recv() for socket abstractions. The new model
will be very similar to the one implemented in NSE - which means a
“pseudoblocking” recv() that employs coroutines and nsock callbacks to
seem blocking from the API perspective, but in reality can handle
other activities while waiting for data. This is what took me most of
the week - there's a lot of issues that needed to be addressed and it
was necessary to discuss how should it behave in some edge cases.

* Discussed with David some design details, such as making lua_State
for filters non-global, alternatives to storing filter instances in
connections[] table and inner Ncat API related to how recv() and
send() are handled in listen mode. Some of his ideas I already
implemented.

Priorities:

* Try to get ncat-sa-take2 as close to “ready to merge” state as time
permits. It's obvious now that the branch won't get merged during this
GSoC project, but I'd like to finish it in the best state I could.

Yours,

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