flac dev - Jun 2014 - Metadata block max size

On Fri, Jun 20, 2014 at 1:05 AM, lvqcl <lvqcl.mail at gmail.com> wrote:
> I cannot find anything about the size of METADATA_BLOCK_PICTURE block
> in <http://xiph.org/flac/format.html>. Where did you read this?
>
METADATA_BLOCK_HEADER has a 24-bit field to encode the length of
METADATA_BLOCK_DATA ; hence the limitation (which not only applies
to METADATA_BLOCK_PICTURE but all metadata blocks.

Pyt.

--
Pierre-Yves Thoulon
+33 (0)6 33 39 75 76
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/flac-dev/attachments/20140620/a17dcae9/attachment-0001.htm

Pierre-Yves Thoulon wrote:
> METADATA_BLOCK_HEADER has a 24-bit field to encode the length of
> METADATA_BLOCK_DATA ; hence the limitation (which not only applies
> to METADATA_BLOCK_PICTURE but all metadata blocks.
I see. So it's possible to abuse some other metadata blocks too..
I found the following checks in libFLAC and metaflac sources:

src/libFLAC/metadata_iterators.c, write_metadata_block_header_cb_(...):

     FLAC__ASSERT(block->length < (1u <<
FLAC__STREAM_METADATA_LENGTH_LEN));



src/libFLAC/stream_encoder_framing.c, FLAC__add_metadata_block(...):

     FLAC__ASSERT(i < (1u << FLAC__STREAM_METADATA_LENGTH_LEN));



src/metaflac/options.c, FLAC__bool parse_add_padding(...):

     return *out < (1u << FLAC__STREAM_METADATA_LENGTH_LEN);

On Fri, 20 Jun 2014 12:07:31 +0400
lvqcl <lvqcl.mail at gmail.com> wrote:
>Pierre-Yves Thoulon wrote:
>
>> METADATA_BLOCK_HEADER has a 24-bit field to encode the length of
>> METADATA_BLOCK_DATA ; hence the limitation (which not only applies
>> to METADATA_BLOCK_PICTURE but all metadata blocks.
>
>I see. So it's possible to abuse some other metadata blocks too..
>I found the following checks in libFLAC and metaflac sources:
>
>src/libFLAC/metadata_iterators.c, write_metadata_block_header_cb_(...):
>
>     FLAC__ASSERT(block->length < (1u <<
FLAC__STREAM_METADATA_LENGTH_LEN));
>
>
>
>src/libFLAC/stream_encoder_framing.c, FLAC__add_metadata_block(...):
>
>     FLAC__ASSERT(i < (1u << FLAC__STREAM_METADATA_LENGTH_LEN));
>
>
>
>src/metaflac/options.c, FLAC__bool parse_add_padding(...):
>
>     return *out < (1u << FLAC__STREAM_METADATA_LENGTH_LEN);
>
>_______________________________________________
I haven't found where the out of bounds references occur.  They aren't
caught
by those asserts and the code can continue in various ways depending on how big
the block is until something fatal happens.

The problems occur when the metadata blocks are being read by a full decoder
with callbacks.  One symptom is the callbacks being called for more blocks than
exist and with bizarre block properties such as (overflowed?) lengths.

I haven't reported the problem yet because I don't have explicit test
cases
(other than a metadata block longer than 16MB) and I was hoping to identify to
location of the problems.

--ian