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 5DDF5385DC26 for ; Thu, 9 Apr 2020 18:50:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5DDF5385DC26 Received: from [192.168.0.10] ([96.54.106.222]) by shaw.ca with ESMTPA id McGLjyDii62brMcGNjhGwM; Thu, 09 Apr 2020 12:50:55 -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=SdVKIPhaRcWavhyMXBgA:9 a=yhjvbxtHZKjJG-dV:21 a=J4LBv2AAHmrWMhYD: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> From: Robin Miyagi Message-ID: Date: Thu, 9 Apr 2020 11:50:53 -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: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CMAE-Envelope: MS4wfGTvahW/Pd2IejmrrP0zkIcJFx6NT0TD8dkn3e8z+6PZIS6yFIDcWAvhwGweaOv+pcUf/8in2ZOS9ADVfhx+xdB1lY1VOW1LBlT46HFa4Df/5D9JpZD3 XC/t53ZAFKKzoKs0aM8Cqo9fIzWREour59hn6thL0GCYGUPVLp7aJ46ioezKcEDTuvBxrBC+nChLeA== X-Spam-Status: No, score=-2.4 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:50:56 -0000 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. >>>>