From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) by sourceware.org (Postfix) with ESMTPS id D70B3385E02B for ; Thu, 9 Apr 2020 18:52:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D70B3385E02B Received: from [192.168.0.10] ([96.54.106.222]) by shaw.ca with ESMTPA id McHWjyEFo62brMcHXjhHKU; Thu, 09 Apr 2020 12:52:07 -0600 X-Authority-Analysis: v=2.3 cv=LKf9vKe9 c=1 sm=1 tr=0 a=GSwGl4jNSCAoai9wga7JZA==:117 a=GSwGl4jNSCAoai9wga7JZA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=N659UExz7-8A:10 a=SgBdx1R6kS4A:10 a=-OACpT0bBHABtix67jQA:9 a=4JPit2ejeUk_Z3Ba:21 a=4sLP-Gq_YkvHME47:21 a=pILNOxqGKmIA:10 Subject: Re: [PATCH] memcpy: use bhs/bls instead of bge/blt (CVE-2020-6096) [BZ #25620] To: libc-alpha@sourceware.org References: <5bdd50d8-509b-4c60-a023-0e9bf9538e62@redhat.com> <342ca7d7-a7e4-349f-9ee5-c6a47f732a36@shaw.ca> <7855f955-df5b-3d70-30e0-5adea5518a37@shaw.ca> <5b87b579-8b72-7662-cd15-f5d1b18145fb@shaw.ca> From: Robin Miyagi Message-ID: Date: Thu, 9 Apr 2020 11:52:06 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <5b87b579-8b72-7662-cd15-f5d1b18145fb@shaw.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CMAE-Envelope: MS4wfCX2M0tf1AnNy9iOk6nAMRikZdHgENG5J3vxvAYpyBsXp1inEQJ0HDXD9kVNd65LQcY675SMgKOcBVWZ3VXrcwolXF8Qhl1H2rsZ7EQ6b8gGHnOWaZ+4 qfQqy7FsL1r8/5sW3qgHPZZevQJ013jWWIzRApTZFtCyX1KEaeo9EGEpAzi+Pdo3KudFEWw9vn1UIw== X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 18:52:09 -0000 unsubsribe On 9/4/20 11:51 am, Robin Miyagi via Libc-alpha wrote: > unsubsribe > > On 9/4/20 11:51 am, Robin Miyagi via Libc-alpha wrote: >> unsubsribe >> >> On 9/4/20 11:50 am, Robin Miyagi via Libc-alpha wrote: >>> unsubscribe >>> >>> On 9/4/20 11:50 am, Robin Miyagi via Libc-alpha wrote: >>>> unsubscribe >>>> >>>> On 9/4/20 11:50 am, Robin Miyagi via Libc-alpha wrote: >>>>> unsubscribe >>>>> >>>>> On 9/4/20 11:28 am, Robin Miyagi via Libc-alpha wrote: >>>>>> unsubsribe >>>>>> >>>>>> On 9/4/20 11:27 am, Carlos O'Donell via Libc-alpha wrote: >>>>>>> On 4/9/20 12:25 PM, Joseph Myers wrote: >>>>>>>> On Thu, 9 Apr 2020, zhuyan (M) wrote: >>>>>>>> >>>>>>>>> An exploitable signed comparison vulnerability exists in the >>>>>>>>> ARMv7 >>>>>>>>> memcpy() implementation of GNU glibc. Calling memcpy() (on ARMv7 >>>>>>>>> targets that utilize the GNU glibc implementation) with a >>>>>>>>> negative >>>>>>>>> value for the 'num' parameter results in a signed comparison >>>>>>>>> vulnerability. >>>>>>>>> >>>>>>>>> If an attacker underflows the 'num' parameter to memcpy(), this >>>>>>>>> vulnerability could lead to undefined behavior such as writing to >>>>>>>>> out-of-bounds memory and potentially remote code execution. >>>>>>>>> Furthermore, this memcpy() implementation allows for program >>>>>>>>> execution to continue in scenarios where a segmentation fault or >>>>>>>>> crash should have occurred. The dangers occur in that subsequent >>>>>>>>> execution and iterations of this code will be executed with this >>>>>>>>> corrupted data. >>>>>>>> I don't object to changing to use unsigned comparisons, since >>>>>>>> unsigned >>>>>>>> comparisons are what's logically appropriate here, but the >>>>>>>> commit message >>>>>>>> needs to discuss how it's very questionable whether this >>>>>>>> actually counts >>>>>>>> as a vulnerability, given that interfaces such as malloc cannot >>>>>>>> construct >>>>>>>> objects larger than PTRDIFF_MAX bytes and it's not clear what >>>>>>>> exactly is >>>>>>>> permitted to be done with a larger memory region allocated with >>>>>>>> mmap, so >>>>>>>> it's not clear if there are any cases where these functions can >>>>>>>> validly be >>>>>>>> called with a size argument exceeding PTRDIFF_MAX. >>>>>>>> >>>>>>>> Any case where a size argument is passed that is larger than >>>>>>>> the allocated >>>>>>>> memory region cannot be a security vulnerability in glibc, only >>>>>>>> in the >>>>>>>> application passing the bogus size argument (though of course >>>>>>>> we sometimes >>>>>>>> do choose to improve hardening against buggy applications). >>>>>>>> >>>>>>>> Furthermore, there was a comment in the bug saying a new test >>>>>>>> should be >>>>>>>> added to the testsuite.  So either the patch should add a test >>>>>>>> (that fails >>>>>>>> before and passes after the memcpy change is applied) or the >>>>>>>> commit >>>>>>>> message should justify why this is hard to test in the testsuite. >>>>>>> This change should *absolutely* have a test case so we can see >>>>>>> if there >>>>>>> are other similar problems with memcpy on other architectures. A >>>>>>> synthetic >>>>>>> test case should be possible to construct. >>>>>>>