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

Marco Leise Marco.Leise at gmx.de
Sat Apr 12 12:19:57 PDT 2014


Am Fri, 11 Apr 2014 22:52:23 -0400
schrieb "Steven Schveighoffer" <schveiguy at yahoo.com>:

> On Fri, 11 Apr 2014 18:01:29 -0400, Marco Leise <Marco.Leise at gmx.de> wrote:
> 
> >> But in a D-created struct, the data would be an array, instead of a
> >> ptr+length.
> >>
> >> -Steve
> >
> > If I understand you right, you mean a variation of this:
> >
> > struct Packet { ubyte[] payload; }
> >
> > But indirections don't fly with serialized network packets.
> 
> Indirections were in the struct that was the subject of that article. Here  
> it is:
> 
> typedef struct ssl3_record_st
>      {
>          int type;               /* type of record */
>          unsigned int length;    /* How many bytes available */
>          unsigned int off;       /* read/write offset into 'buf' */
>          unsigned char *data;    /* pointer to the record data */
>          unsigned char *input;   /* where the decode bytes are */
>          unsigned char *comp;    /* only used with decompression -  
> malloc()ed */
>          unsigned long epoch;    /* epoch number, needed by DTLS1 */
>          unsigned char seq_num[8]; /* sequence number, needed by DTLS1 */
>      } SSL3_RECORD;
> 
> No way that's a directly serialized network packet.
> 
> -Steve

If "data" and "length" are the pointer and size of the raw
network packet, yes. I.e. it will turn into:

ssl3_record_st.data[] = socket.receiveRawPacket();

... which is safe. But when you said "D created struct" I
assumed you referred to the network packet itself as a struct,
which means that the length field would come directly from the
client and doesn't need to match the physical length of the
packet. With Kagamin's reply I now understand it better.

-- 
Marco



More information about the Digitalmars-d mailing list