Re: [NSE] rpc library; trusted inputs?

[David Fifield <david () bamsoftware com>]

On Mon, Apr 26, 2010 at 07:47:34PM +0100, Djalal Harouni wrote:
> 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.

Yes, that's a good example. That sort of thing is a bug if unchecked. Do
you know of specific places where this happens now?

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