Re: [Json] Nested JSON encoding style too likely to be insecure

John Cowan <cowan@mercury.ccil.org> Tue, 23 February 2016 14:00 UTC

Return-Path: <cowan@ccil.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603D01B2DB6 for <json@ietfa.amsl.com>; Tue, 23 Feb 2016 06:00:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.607
X-Spam-Level:
X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
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 vhrAPW1DDvSu for <json@ietfa.amsl.com>; Tue, 23 Feb 2016 06:00:39 -0800 (PST)
Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C258F1B2DAE for <json@ietf.org>; Tue, 23 Feb 2016 06:00:39 -0800 (PST)
Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from <cowan@ccil.org>) id 1aYDVw-0007lQ-Ko; Tue, 23 Feb 2016 09:00:33 -0500
Date: Tue, 23 Feb 2016 09:00:32 -0500
From: John Cowan <cowan@mercury.ccil.org>
To: Phillip Hallam-Baker <ietf@hallambaker.com>
Message-ID: <20160223140032.GP20304@mercury.ccil.org>
References: <255B9BB34FB7D647A506DC292726F6E13BBADBF674@WSMSG3153V.srv.dir.telstra.com> <CAMm+LwjwWEmJqcicdwZ+fE3+XMamoDF8RfCMLRz75MpFB=tiWg@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E13BBADBF6C2@WSMSG3153V.srv.dir.telstra.com> <CAMm+LwgsOMFGv3Ts=CZghwwdv2teiviDCC+0E2u4EO+S5WR3Tw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAMm+LwgsOMFGv3Ts=CZghwwdv2teiviDCC+0E2u4EO+S5WR3Tw@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: John Cowan <cowan@ccil.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/json/_lslpGOW87zPQ1zBu2odnggm2I0>
Cc: "Manger, James" <James.H.Manger@team.telstra.com>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Nested JSON encoding style too likely to be insecure
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Feb 2016 14:00:42 -0000

Phillip Hallam-Baker scripsit:

> This isn't the normal buffer overrun type malicious request, you are
> postulating one of the requests is valid and the other isn't. How is
> an attacker meant to inject the second attack?

As I understand it, the idea is that there is a service which permits
anyone to read, but requires credentials of some kind in order to write.
There is a two-stage pipeline consisting of a validator and an execution
agent.  A hybrid (invalid) request containing both read and write
is sent by the black hat.  The validator by chance looks at the read
request and passes the hybrid through without checking any credentials.
The execution agent, however, by chance sees the write request and acts
on it, assuming that the validator has properly checked it.  Oops.

Obviously the problem is that the validator is too liberal in what
it accepts, and should ensure that the request is well-formed before
applying its rules.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan@ccil.org
Eric Raymond is the Margaret Mead of the Open Source movement.
          --Bruce Perens, a long time ago