Re: Bug report:brute.lua and oracle-brute NSE script

[Patrik Karlsson <patrik () cqure net>]

Den 2011-03-11 05.13 skrev Tod Beardsley <todb () planb-security net>:

> I've been messing with the oracle-brute script today in an effort to
> get my hands dirty in NSE-land and to solve an immediate problem. I
> noticed that oracle-brute's disconnect() method doesn't actually wait
> around for the disconnect to occur, which can leave the script in a
> state where it continuously fails to reconnect, which then rapidly
> decrements the retries counter.

That's not entirely true. The code does not handle any errors that could
occur when disconnecting. However, as far as I can tell, it does wait
until the close function has been called on the socket descriptor.

> By setting a brute.delay of 0.25 seconds, or by setting brute.retries
> to 8000, the problem is avoided
>
> This came up when bruting a local VM running Oracle 10.2.0.1.0 on
> Linux (the stock deb package), I don't know if this problem even
> manifests in a non-vmnet network, but it certainly will stymie normal
> testing. I've confirmed it using nmap from svn trunk.

I've not been able to reproduce this against my test environment running
in VirtualBox (against which I do most testing).

Have you tuned the file-max value on your Debian server according to the
suggestions here?
http://download.oracle.com/docs/html/B15521_01/toc.htm

If you haven't please do and test the script again to see if you're still
experiencing the same problem.

> The problem is around doAuthenticate in brute.lua -- the status fails
> when we've not yet /ack'ed the Oracle server's FIN, so we skip down to
> the retries decrementor. This condition occurs at exactly 15 attempts
> for me, every time (after the 15th fail, i get a pile of un-ack'ed
> FINs).

I've looked into the code and as far as I can tell a potential problem
closing a socket should have no direct impact on the retries being
decremented as the code completely disregards these errors. That said, an
indirect problem could occur either if the client or server runs out of
free sockets. This would result in new connect attempts failing, which
would decrement the retries counter, that in the end could result in the
script aborting.

In regards to un-ack'ed FINs, we have no control of this from the socket
perspective in NSE. We can simply call the socket:close() function, which
in turn ends up calling the nsi_delete function in nsock, which then calls
the close function on the socket descriptor. While this could fail, I'm
not sure how it should/could be handled in NSE.

In order to better understand what's happening in NSE, I propose that you
apply the attached patch and run the script again. The patch adds some
more debugging around the NSE connect and close calls in oracle-brute and
should print any errors occurring there. You need to run the script using
the debug option -d.

> I now have about 4 hours of Lua experience, so I don't know what the
> best way is to ensure the disconnect actually happens, but some kind
> of ensure around driver:disconnect() will do the trick, i expect.
>
> Sorry for the lack of a patch. This might be a 5 minute fix for
> someone who's actually lua-savvy.
>
> Thanks!
>
> -todb
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/

Regards,
Patrik
>

Attachment: oracle-brute-debug.patch
Description:

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