RE: LuaSocket: No way to protect against fuzzing attacks?

["Dean Sellers" <dean.sellers@...>]

I did notice the partial result return, but like HyperHacker, I couldn't
make it work reliably. Sometimes I would get no partial result?

As you point out though for this protocol byte by byte makes sense, in
fact this protocol was originally designed as a serial line one. That is
probably why it seems similar.

I do use the prefix argument to receive, which works well.

One of my jobs (in the near future) is to add serial support to the lua
API I am writing, so if you are willing to share I would love to see
your implementation :-)

(As an aside when looking through the luasocket code I was impressed
with how easy serial support looked to add, at least for *nix.)

Dean Sellers applications engineer  
rinstrum smart weighing  
Ph: +61 7 3216 7166  Fax: +61 7 3216 6211    
dean.sellers@rinstrum.com  
41 Success St, Acacia Ridge, QLD, 4110
  
www.rinstrum.com

> -----Original Message-----
> From: lua-l-bounces@lists.lua.org 
> [mailto:lua-l-bounces@lists.lua.org] On Behalf Of Sam Roberts
> Sent: Wednesday, 12 October 2011 5:46 AM
> To: Lua mailing list
> Subject: Re: LuaSocket: No way to protect against fuzzing attacks?
> 
> 
> On Tue, Oct 11, 2011 at 2:47 AM, Dean Sellers 
> <dean.sellers@rinstrum.com> wrote:
> > At least this was how the unix side worked, my code will 
> always run on
> > an embedded nix device so I didn't delve into the windows source.
> 
> Windows is the same.
> 
> > So after a bit of testing my algorithm reads byte by byte until a
> > message is formed or the length is exceeded. The performance is
> > certainly acceptable for a system where 20-100 byte messages are
> > delivered at 25Hz.
> 
> You might not have noticed that receive() will return a 
> partial result after
> the "timeout".
> 
> But as you say, if you are looking for a specific end byte,
> byte-by-byte is reasonable. I did something like this for a serial
> link protocol recently, where we needed to scan the input bytes for a
> start-byte before starting to read a packet (I extended luasocket to
> support serial devices). Also, table.concat or the prefix arg to
> :receive() can get you away from the exponential cost of string tail
> concatenation.
> 
> > In saying this it would be reasonably easy to add a 'return up to n
> > bytes' method to luasocket, I just figured for the small 
> performance hit
> > I would stay with a more portable solution.
> 
> This is easy to write yourself in lua, see :read():
> 
> https://github.com/sam-github/swirl/blob/master/lua/sockext.lua
> 
> Its particularly useful for transparent proxies, where the code doing
> the reading doesn't know what to expect from the network, it just
> wants to pass on data as it becomes available. I might add this to my
> luasocket fork sometime, unless somebody else provides a patch first.
> 
> Cheers,
> Sam
> 
> 
> --
> This message was scanned by ESVA and is believed to be clean.
> Click here to report this message as spam. 
> http://mailscanner.rinstrum.com.au/cgi-bin/learn-msg.cgi?id=02
B9B27DFB.DB40E