From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 82C3A40428 for ; Mon, 20 Dec 2021 21:22:03 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 656B568AF52; Mon, 20 Dec 2021 23:22:01 +0200 (EET) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id AF61068AAE6 for ; Mon, 20 Dec 2021 23:21:54 +0200 (EET) Received: from localhost (213-47-68-29.cable.dynamic.surfer.at [213.47.68.29]) (Authenticated sender: michael@niedermayer.cc) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 025886000C for ; Mon, 20 Dec 2021 21:21:53 +0000 (UTC) Date: Mon, 20 Dec 2021 22:21:53 +0100 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20211220212153.GY2829255@pb2> References: <20211220204609.199-1-ffmpeg@gyani.pro> <0834efe9-7ae0-301f-4bc3-f58222b6e536@gyani.pro> MIME-Version: 1.0 In-Reply-To: <0834efe9-7ae0-301f-4bc3-f58222b6e536@gyani.pro> Subject: Re: [FFmpeg-devel] [PATCH v2] avformat/mov: abort reading truncated stts X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: multipart/mixed; boundary="===============6765747628250200885==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============6765747628250200885== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZasUHx+esqlhuXD+" Content-Disposition: inline --ZasUHx+esqlhuXD+ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 21, 2021 at 02:31:33AM +0530, Gyan Doshi wrote: >=20 >=20 > On 2021-12-21 02:24 am, Andreas Rheinhardt wrote: > > Gyan Doshi: > > >=20 > > > On 2021-12-21 02:18 am, Andreas Rheinhardt wrote: > > > > Gyan Doshi: > > > > > Avoids overreading the box and ingesting absurd values into stts_= data > > > > > --- > > > > > =A0 libavformat/mov.c | 5 +++++ > > > > > =A0 1 file changed, 5 insertions(+) > > > > >=20 > > > > > diff --git a/libavformat/mov.c b/libavformat/mov.c > > > > > index 2aed6e80ef..5a7209837f 100644 > > > > > --- a/libavformat/mov.c > > > > > +++ b/libavformat/mov.c > > > > > @@ -2935,6 +2935,11 @@ static int mov_read_stts(MOVContext *c, > > > > > AVIOContext *pb, MOVAtom atom) > > > > > =A0=A0=A0=A0=A0 avio_rb24(pb); /* flags */ > > > > > =A0=A0=A0=A0=A0 entries =3D avio_rb32(pb); > > > > > =A0 +=A0=A0=A0 if (atom.size < 8 + (int64_t)entries*8) { > > > > > +=A0=A0=A0=A0=A0=A0=A0 av_log(c->fc, AV_LOG_ERROR, "Truncated STT= S box for st > > > > > %d.\n", c->fc->nb_streams-1); > > > > > +=A0=A0=A0=A0=A0=A0=A0 return AVERROR_INVALIDDATA; > > > > > +=A0=A0=A0 } > > > > > + > > > > > =A0=A0=A0=A0=A0 av_log(c->fc, AV_LOG_TRACE, "track[%u].stts.entr= ies =3D %u\n", > > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 c->fc->nb_streams-1, ent= ries); > > > > This might fix the issue with the fuzzer sample Michael gave you, b= ut > > > > what would stop the fuzzer (or a malicious adversary) from simply u= sing > > > > a gigantic atom size? > > > Do you want the comparison to switch to a strict inequality? > > >=20 > > No, because it might be that the adversary just uses the expected size, > > so this would not fix anything. >=20 > There are real world multi-hour files with large stts boxes, so there is = no > robust solution for that, only heuristics. lets take a closer look at the loop you are adding sample_count =3D avio_rb32(pb); sample_duration =3D avio_rb32(pb); sc->stts_data[i].count=3D sample_count; sc->stts_data[i].duration=3D sample_duration; for (int j =3D 0; j < sample_count; j++) { /* STTS sample offsets are uint32 but some files store it as in= t32 * with negative values used to correct DTS delays. There may be abnormally large values as well. */ if (sample_duration > c->max_stts_delta) { // assume high delta is a negative correction if greater th= an c->max_stts_delta int32_t delta_magnitude =3D *((int32_t *)&sample_duration); sc->stts_data[i].duration =3D 1; dts_correction +=3D (delta_magnitude < 0 ? delta_magnitude = - 1 : 0); } current_dts +=3D sc->stts_data[i].duration; if (!dts_correction || current_dts + dts_correction > last_dts)= { current_dts +=3D dts_correction; if (!j) sc->stts_data[i].duration +=3D dts_correction/sample_co= unt; dts_correction =3D 0; } else { /* Avoid creating non-monotonous DTS */ dts_correction +=3D current_dts - last_dts - 1; current_dts =3D last_dts + 1; } last_dts =3D current_dts; } above you are taking the sample_count read from the bitstream and then iterate based on that. The value can be INT_MAX everytime its read and that would be too slow =20 Iam not sure if this loop is correct as it is, does this produce the same output as before all patches for files which use the logic ? If its correct it can probably be optimized alot this does not go over any array (all indexes are constants)=20 thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you fake or manipulate statistics in a paper in physics you will never get a job again. If you fake or manipulate statistics in a paper in medicin you will get a job for life at the pharma industry. --ZasUHx+esqlhuXD+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCYcDz7QAKCRBhHseHBAsP q5kvAJ9AYdH3yjQvkHHWSfGq2Z1aq4PteQCeIzVxgqePdpuM5kyOC9Z1Cqa7BkE= =dpZc -----END PGP SIGNATURE----- --ZasUHx+esqlhuXD+-- --===============6765747628250200885== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". --===============6765747628250200885==--