Re: [Cbor] Robert Wilton's No Objection on draft-ietf-cbor-file-magic-11: (with COMMENT)

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Carsten,

One other thought on this (when I was out running this morning) ... if C often does use strcpy (or even strncpy), then avoiding the zero byte isn't the only problem, it also has the risk of capturing arbitrary extra bytes which would presumably make the magic number check less reliable?

My instinct here is that we keep the algorithm simple, don't avoid embedded zero bytes, don't zero terminate, and just state that robust implementations should not assume that the magic number is a null terminated string.  Specifically, I'm assuming that C using strncpy isn't a security issue (because they don't know whether a file contains a magic number at all), just a reliability one, and that implementations will hopefully realize and fix this over time.  But this is just my opinion/suggestion.

Regards,
Rob


> -----Original Message-----
> From: Carsten Bormann <[e-mail]>
> Sent: 21 April 2022 18:08
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: The IESG <[e-mail]>; Christian Amsüss <[e-mail]>;
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [Cbor] Robert Wilton's No Objection on draft-ietf-cbor-file-
> magic-11: (with COMMENT)
> 
> Hi Rob,
> 
> thank you for this input.
> 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-cbor-file-magic/
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Hi,
> >
> > Apologies for a late review, and there is just one none blocking issue that I
> > wanted to raise:
> >
> >   It is further
> >   suggested to avoid values that have an embedded zero byte in the four
> >   bytes of their binary representation (such as 0x12003456), as these
> >   may confuse implementations that treat the magic number as a C
> >   string.
> >
> > I was less convinced by this statement because:
> > (1) It seems like C treating this as null terminated string is probably not the
> > right thing to do,
> 
> It is not, but I have seen too much code doing that with magic numbers
> (strncpy, that is).
> 
> > I'm not sure that we should be implicitly endorsing that.
> 
> Of course, we could decide that we make zero bytes prominent enough and
> mention that strncpy is not the way to do this.
> 
> > (2) When translating values from the Content-Format registry means that
> this
> > issue is presumably unavoidable.  I.e., it looks like your example in 2.2.1
> > violates this guidance.
> 
> It does.
> 
> This is easy to fix by using
> 
> 0x63740000 + (ct / 255 + 1) * 256 + ct % 255 + 1
> 
> as the tag number (*).
> 
> So we have the choice between
> 
> (1) not suggesting avoiding zero bytes or
> (2) making the above change to the content—format-number to tag-number
> mapping.
> 
> Grüße, Carsten
> 
> (*) Generally, this will not be a runtime computation, as the content-format
> number will be looked up manually and translated into a tag number using a
> formula at or before compiling — the difference is just the complexity of the
> formula.