Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105303 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 63049 invoked from network); 17 Apr 2019 08:49:08 -0000 Received: from unknown (HELO mail-vs1-f50.google.com) (209.85.217.50) by pb1.pair.com with SMTP; 17 Apr 2019 08:49:08 -0000 Received: by mail-vs1-f50.google.com with SMTP id t78so12931825vsc.1 for ; Tue, 16 Apr 2019 22:47:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=Y1VqgkO+ORsvLEzeyxK3SRnM8aoZrlD5IaziHOlwl9M=; b=DgGhEaVekHkckrgHMykUQfDR9VWvX36OEZ76h61W6Hmets2OMInX2Ub8M2og9EdTl3 fn6WpxEeXNGKiiPwm1WhX2t9V/j8WobCsnZAQFY3z7L9UxV5w60VSHAPPIO84qvv/rfb mB9iScpQqaOQ5SpIWbQE5Xv4PQ6RQmwwoephAdglR9z9dgv3vH/Ape8aQTnWMHZaLgO9 SHI/Fun+Z3SHf20suBFOIt8AAaHh099eYjkCiXAPEd5UbJ2Sknao5Q4d7FH1smRKBAy3 c/kTHQOGccxFMxFlOw5SMZxkkjDAheHzp9nLs5s0rIPAngnI+A8Z9el76RIfCytmSVsS 5vKQ== X-Gm-Message-State: APjAAAW2pwCzMDzidscKZbqrffaokxx16BO29jmjS9KcHw0U3njn4VoO EY8QFK8fqfJsYrOpOhVRtUNdECIYhQA3aLDN4Ns= X-Google-Smtp-Source: APXvYqzfq/BZp2XvpWpEp4vlY3VLcSHJbxrY5l0RRjwjbUO03SYCMNeGRFnONS8kh51Dxt4bFmpL+SFpBa1fvxAcNv4= X-Received: by 2002:a67:f04e:: with SMTP id q14mr47981531vsm.133.1555480077509; Tue, 16 Apr 2019 22:47:57 -0700 (PDT) MIME-Version: 1.0 References: <2e70065b-160b-7134-03ee-1a6025a6467c@gmail.com> <92b1b774-7c4b-555d-671e-d58c1054bd14@gmail.com> <3051b31a-574a-1d93-6fc4-99fa06da685a@gmail.com> In-Reply-To: <3051b31a-574a-1d93-6fc4-99fa06da685a@gmail.com> Reply-To: bishop@php.net Date: Wed, 17 Apr 2019 01:47:31 -0400 Message-ID: To: Stanislav Malyshev Cc: Yasuo Ohgaki , Raymond Irving , PHP Internals Content-Type: multipart/alternative; boundary="00000000000079ab870586b36d27" Subject: Re: [PHP-DEV] PHP deserialization techniques offer rich pickings for security researchers From: bishop@php.net (Bishop Bettini) --00000000000079ab870586b36d27 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 17, 2019 at 12:44 AM Stanislav Malyshev wrote: > Hi! > > > 2. Improve caller control on unserialization. Change the signature to > > public Phar::getMetadata ( mixed $allowed_classes = true ) : mixed, and > > invoke the behavior similar to how unserialize itself works. Since all > > of this problem stems from the use of untrusted content on the phar:// > > stream, we should put into the caller's hands as much control as > possible. > > This, unfortunately, is only a partial solution. As long as > serialization format supports references - and they are likely not going > anywhere - it won't be security, it's virtually impossible to secure > code that can modify references while object is being unserialized. At > least without rewriting whole unserialization code. If somebody > undertakes this task, then yes, maybe it can be made secure (not sure > even then). For now, unserializing insecure data is insecure, regardless > of allowed_classes. Allowed_classes is just a barrier to block most > obvious attacks in the wild now, but it does not guarantee safety. > This issue had an extant report, bug # 76774 [1]. To that report, I've added some detail. I agree that $allowed_classes is a partial fix. But is it not better to incrementally add defensive layers? I'll get to the immediate mitigation after I finish my phar fuzzing work, unless somebody beats me to it. bishop [1]: https://bugs.php.net/bug.php?id=76774 --00000000000079ab870586b36d27--