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 37535385E00C for ; Thu, 9 Apr 2020 18:28:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 37535385E00C Received: from [192.168.0.10] ([96.54.106.222]) by shaw.ca with ESMTPA id MbuKjy3F062brMbuLjh8KO; Thu, 09 Apr 2020 12:28:10 -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=6sh6I4xQPOafbG3db5QA:9 a=C1Emof5gD2Nao83w:21 a=neuOnGFYhuovYUwi: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> From: Robin Miyagi Message-ID: <342ca7d7-a7e4-349f-9ee5-c6a47f732a36@shaw.ca> Date: Thu, 9 Apr 2020 11:28:08 -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: <5bdd50d8-509b-4c60-a023-0e9bf9538e62@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-CMAE-Envelope: MS4wfKPIA0eR97sv8C9BzHljvKaJu3CmktjOD56K1u9lboNSmJNk28k7Z0HcsCmazSa6PVxYHmgN7JwOYX09BO+MIqLrffDAd+ekdAbtePjJGJsPmZ+Ud6dv fG/3r8OUx4t6kxeYI1yMRjvCpMfCfkwQh7DIx5swjVCvtqXwWxD7/I1rZYyVzOj9ONzvevDOQpY/CA== X-Spam-Status: No, score=-2.2 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:28:12 -0000 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. >