Re: [NSE] rpc library; trusted inputs?

[Djalal Harouni <tixxdz () gmail com>]

On 2010-04-21 18:34:18 -0600, David Fifield wrote:
> On Sat, Apr 17, 2010 at 04:21:59PM +0100, Djalal Harouni wrote:
> > 2) NSE Scripts:
> > - better error handling.
> >
> >
> > I must remind you that some scripts/libs (including these ones) trust
> > remote inputs!!! 
> > I have found this thread: http://seclists.org/nmap-dev/2009/q3/210
> > which is a good start.
>
> Can you explain more in what way external inputs are being trusted? One
> specific example is already handled at a high level; control characters
> in NSE output are always escaped. I'm sure there are other
> possibilities, like a script looping forever. As Solar Designer pointed
> out, in case of a bug in liblua it might be possible for network input
> to escape the scripting environment. If you've found specific examples,
> please share them so they can be fixed.
My point of view:
- Perhaps NSE scripts must validate/check the value of the n variable
  which will be used by the receive_bytes(n) call. If we are
  implementing some protocol libraries or scripts and the protcol's RFC
  says that: the length may not exceed MAXBYTES, so we must check it and
  validate it before issuing another receive_bytes(length) etc

Example:
  st, data = socket:receive_bytes(n)
  _, len = bin.unpack(">I", data, offset)
  st, tmp = socket:receive_bytes(len)
  data = data .. tmp
  ...


If the RFC says that the len must not exceed 32, I think that we should
check it before the next receive_bytes(len) call.
If we are scanning a box which have some tricks to detect Nmap/NSE scans and alter it's network output (big values), 
this can cause Nmap to timeout (long scans) or to eat memory etc, it depends on: how this data is used. 

In this example we are using an unsigned integer, you may also consider
other types.

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

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