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
- [Json] Nested JSON encoding style too likely to b… Manger, James
- Re: [Json] Nested JSON encoding style too likely … Phillip Hallam-Baker
- Re: [Json] Nested JSON encoding style too likely … Manger, James
- Re: [Json] Nested JSON encoding style too likely … John Cowan
- Re: [Json] Nested JSON encoding style too likely … Phillip Hallam-Baker
- Re: [Json] Nested JSON encoding style too likely … John Cowan