A serious security bug... caused by no bounds checking.

Kagamin spam at here.lot
Mon Apr 14 02:26:48 PDT 2014


On Saturday, 12 April 2014 at 19:03:58 UTC, Marco Leise wrote:
> Ah! Big misunderstanding. I meant to ask if you used this
> idiom before, that you use just a byte[] for data you
> load/receive to be able to use bounds checks and not some
> header struct with pointers where they become ineffective?
>
> And with scale I was aiming for the software architecture. Can
> you keep this code style with global functions working on
> byte[] instead of structs or will you wish for the style used
> in OpenSSH, which is unsafe but probably easier to maintain?

You can process fixed-length message with structs, but processing 
variable-length message requires access to the buffer with 
packet, as we see in the example of ssl heartbeat.

> Because rawRead and receive are meant to read N bytes. Perfect
> match for a slice. In a library like OpenSSH you know what
> your headers will look like, though.

How is it different from memcpy? It's conceptually copying too.
with slice: read(buffer[0..length]);
with pointer: read(buffer, length);

> hbtype = buffer[0]; // read type, ok
> // but this??? ugh!!!
> payload = bigEndianToHost(*cast(short*)buffer[1 .. 3].ptr);
> bp[0 .. payload] = buffer[3 .. 3+payload];
>
> The code becomes pretty messy in my eyes. I would have just
> used memcpy as well, if that was the alternative.
> That's why I asked if it will scale or if you just made it up
> for the sake of argument.

I think, memcpy is messier than slice copy. It will be clearly 
visible, that you circumvent bounds checking, and that will 
smell, and everyone looking at it will tell you what they think 
about it.


More information about the Digitalmars-d mailing list