Re: [secdir] [Cellar] Secdir early review of draft-ietf-cellar-ffv1-02

Jerome Martinez <jerome@mediaarea.net> Fri, 01 June 2018 15:13 UTC

Return-Path: <jerome@mediaarea.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4438E12D941 for <secdir@ietfa.amsl.com>; Fri, 1 Jun 2018 08:13:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXlGC3jM1g-g for <secdir@ietfa.amsl.com>; Fri, 1 Jun 2018 08:13:01 -0700 (PDT)
Received: from 10.mo68.mail-out.ovh.net (10.mo68.mail-out.ovh.net [46.105.79.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D805B12D940 for <secdir@ietf.org>; Fri, 1 Jun 2018 08:13:00 -0700 (PDT)
Received: from player761.ha.ovh.net (unknown [10.109.122.1]) by mo68.mail-out.ovh.net (Postfix) with ESMTP id 173C7E2A68 for <secdir@ietf.org>; Fri, 1 Jun 2018 17:12:58 +0200 (CEST)
Received: from [192.168.2.120] (p5DDB54A6.dip0.t-ipconnect.de [93.219.84.166]) (Authenticated sender: jerome@mediaarea.net) by player761.ha.ovh.net (Postfix) with ESMTPSA id 2B22E480091; Fri, 1 Jun 2018 17:12:53 +0200 (CEST)
To: Liang Xia <frank.xialiang@huawei.com>
Cc: secdir@ietf.org, draft-ietf-cellar-ffv1.all@ietf.org, cellar@ietf.org, ietf@ietf.org
References: <152784500007.15152.9045057653501275171@ietfa.amsl.com>
From: Jerome Martinez <jerome@mediaarea.net>
Message-ID: <29965bd1-ce37-d8a8-25c4-81f6d2ddff4b@mediaarea.net>
Date: Fri, 1 Jun 2018 17:12:54 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <152784500007.15152.9045057653501275171@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-Ovh-Tracer-Id: 7095984163828273286
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedthedrieeggdekvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/-3uZeCr2oI9JTpLWZlRxoUZ9i5U>
Subject: Re: [secdir] [Cellar] Secdir early review of draft-ietf-cellar-ffv1-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jun 2018 15:13:04 -0000

On 01/06/2018 11:23, Liang Xia wrote:
> Issues for clarification:
> In Security Considerations, besides the DoS attacks brought by the malicious
> payloads, is there any other kinds of attack possibly? For example, virus or
> worm are hidden in the malicious payloads to attack the system for more
> damages? Does it make sense and what's the consideration?

IMO transport of virus or worm is doable in the bitstream and could 
attack the system if there are buffer overflows in the decoding 
software, but not more dangerous than any other protocol or format (it 
depends on bugs in the decoding software).

Checking e.g. Opus spec (I tried AV1 draft, but no security chapter 
right now if I well searched), I see generic sentences like:
"It is extremely
    important for the decoder to be robust against malicious payloads.
    Malicious payloads must not cause the decoder to overrun its
    allocated memory or to take an excessive amount of resources to
    decode."
"The reference implementation contains no known buffer overflow or
    cases where a specially crafted packet or audio segment could cause a
    significant increase in CPU load. "
"The reference implementation was validated in the following
    conditions: (...)" (note: we ran same tests on our side)

We could add such sentences in FFV1 security section.
About the reference decoder, there are some hard coded limitations (e.g. 
maximum 1024 slices per frame, arbitrary choice which is sometimes 
increased in the code) for dropping frames which could use too much 
memory, and the decoder tries to allocate memory for big frames (e.g. if 
you try to decode de 1,000,000x1,000,000 pixel frames, FFmpeg will try 
to allocate corresponding memory as for any other format, and rejects 
the frame because memory can not be allocated. I don't think it is worth 
it to put details about that in spec, as FFmpeg code may change, maybe 
the generic sentences are enough?

Thank you for your review.

Jérôme