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