From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) by sourceware.org (Postfix) with ESMTPS id 495773858CDB for ; Thu, 18 May 2023 10:46:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 495773858CDB Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oi1-x235.google.com with SMTP id 5614622812f47-39413ccb5a5so707590b6e.1 for ; Thu, 18 May 2023 03:46:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684406802; x=1686998802; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=nNlo77LghpVgXZjfnRBzPjgHdhEpTlJcU3/MzXwQCZs=; b=bKt6g5LGtBA5WW5UOdhluuzrfInVMz8E/HsD+vOlMW2d73eKopRtLD0ZxBMgi4ugl2 hgGBKlb/vfFB8TblNi7MfhpqmLS/V7j2Arq2Yr1ssGlDAKXTbCds5pRXIydU9+vRHEqr VN8/iXDlLgU/1Cjdq9Wle++FANWamqRCOe/fGTfaqsiHknQE4145jiGV4p+A70Bq64C7 v8TUl9R02HmKQiJS58hzQ6od7KJFF0EDidt73+2uuU5jv+3FTKFJqLo51/3IhxRPaQjR bkv/KfAWu1uonIihCVGpnPWhNMY/kJ+noeER9g7q0AjRSRY0UXBM1K7JfRF1GaWuP/8K Sd3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684406802; x=1686998802; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=nNlo77LghpVgXZjfnRBzPjgHdhEpTlJcU3/MzXwQCZs=; b=YwuBU6pWXefGE4CZIUaVKPiOfOAhYRSiGusx5jyvKzG9yDeBzgq5Pk/d8iYgWWD68E fdFMFV4XvkMjDe6afLps23NoYoVnnPfK2MmmoWwGnwDPjwVYHENhu1y3CfNQZ4pL17Q1 vyQ5roAO6gaL+sdH45vqRC/Gspt3lssE54OdXUrwG0Zz3UqptNoH4dF3U3Fllc4Qalhh lpJPVpJW77CKo1BQOt1KZPhj+1lUluhhBp1Qq9XCsZMFQ6blbGgckhVOZcf46dxmTakX kPThFJbwR8lthHgSiPD6645upVqATQxHqW3Yfu3sIlK86kYJYfYyDDTAe/hauBsw6FvR CRgQ== X-Gm-Message-State: AC+VfDx9F8w3NSYiYl12ZwSC2jDcKgmugWIZ9Et+ZW02jTqV/7UnBCWK 7R5qGCzzT9/0PbwYIdJSoALangNjavapZkRV2pTWwRQnbUk= X-Google-Smtp-Source: ACHHUZ4pexf2r8ooegl4tV1EKRK5EJP4+tfUkhJoLtaCuYBnbVL3hM94/el7x97bekHgZ2//dzH6aJthHMfs4CqPDQA= X-Received: by 2002:aca:ba46:0:b0:38e:ca21:db29 with SMTP id k67-20020acaba46000000b0038eca21db29mr919209oif.27.1684406802087; Thu, 18 May 2023 03:46:42 -0700 (PDT) MIME-Version: 1.0 From: Magal Baz Date: Thu, 18 May 2023 11:46:31 +0100 Message-ID: Subject: Stack Canary Security Issue in gcc-arm-none-eabi-9 To: gcc-bugs@gcc.gnu.org Content-Type: multipart/mixed; boundary="00000000000018b5f405fbf585de" X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --00000000000018b5f405fbf585de Content-Type: multipart/alternative; boundary="00000000000018b5f205fbf585dc" --00000000000018b5f205fbf585dc Content-Type: text/plain; charset="UTF-8" Hello, I encountered a security issue affecting gcc-arm-none-eabi-9, causing it to produce ineffective stack protection. The issue is public as it was described in a blog on May 2021 https://blog.inhq.net/posts/faulty-stack-canary-arm-systems/ by Christian Reitter. However it was never reported as a bug in an active platform*, so no fix was issued and no CVE was assigned to it. As this is a major security issue I think it would be good if a CVE was issued to alert developers and vendors still using GCC 9. Short issue description (see Reitter's blog for comprehensive details): Older versions of gcc-arm-none-eabi, such as gcc-arm-none-eabi-9-2019-q4-major, have a bug where the global address of the stack guard is placed on the stack as a canary rather than the actual value of the stack guard. This undermines the purpose of the protection as it makes the canary value knowable. In addition, the embedded environments that this toolchain targets often lack Address Space Layout Randomization, meaning the global guard address is in itself constant, making the protection entirely ineffective. See the following code and results built with gcc-arm-none-eabi-9-2019-q4-major and targeting arm cortex m-33. *Code (also attached as check_stack_protection.c):* extern uint32_t *__stack_chk_guard; bool check_stack_bug(uint32_t const *data, int dump_len) { for (int i = 0; i < dump_len; i++) { console_printf("%p : %p\n", &data[i], data[i]); if (data[i] == (const uint32_t)&__stack_chk_guard) { console_printf( "canary is at offset %d from dummy and equals to the address of __stack_chk_guard\n", i); return true; } } return false; } static int app_stack_guard_cmd_handler() { // A dummy var to get the stack frame address uint32_t dummy = 0x57AC57AC; bool is_buggy = check_stack_bug((uint32_t const *)&dummy, 5); if (is_buggy) console_printf("stack protection bug detected\n"); } *output (also attached as output.c):* Stack dump: 0x2013bdb8 : 0x57ac57ac 0x2013bdbc : 0x2012f83c canary is at offset 1 from dummy and equals to the address of __stack_chk_guard stack protection bug detected *binary (also attached as binary_prologue_epiloguge.txt):* Canary setting: 8ad48: 1a 4a ldr r2, [pc, #104] 8ad4a: 83 b0 sub sp, #12 8ad4c: 12 68 ldr r2, [r2] 8ad4e: 01 92 str r2, [sp, #4] canary check: 8ad8a: 0a 4b ldr r3, [pc, #40] 8ad8c: 1a 68 ldr r2, [r3] 8ad8e: 01 9b ldr r3, [sp, #4] 8ad90: 5a 40 eors r2, r3 Thank you, Magal Baz *It reported in an appeartnly inactive platform in 2020 https://answers.launchpad.net/gcc-arm-embedded/+question/689391 by Daniel Worley. --00000000000018b5f205fbf585dc-- --00000000000018b5f405fbf585de Content-Type: text/plain; charset="US-ASCII"; name="binary_prologue_epilogue.txt" Content-Disposition: attachment; filename="binary_prologue_epilogue.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_lht09xqr0 CiAgIDhhZDQ4OiAxYSA0YSAgICAgICAgCWxkcglyMiwgW3BjLCAjMTA0XSAg ICAgICAgICBAIDB4OGFkYjQgPCRkKzB4ND4KICAgOGFkNGE6IDgzIGIwICAg ICAgICAJc3ViCXNwLCAjMTIKICAgOGFkNGM6IDEyIDY4ICAgICAgICAJbGRy CXIyLCBbcjJdCiAgIDhhZDRlOiAwMSA5MiAgICAgICAgCXN0cglyMiwgW3Nw LCAjNF0KCmNhbmFyeSBjaGVjazoKICAgOGFkOGE6IDBhIDRiICAgICAgICAJ bGRyCXIzLCBbcGMsICM0MF0gICAgICAgICAgIEAgMHg4YWRiNCA8JGQrMHg0 PgogICA4YWQ4YzogMWEgNjggICAgICAgIAlsZHIJcjIsIFtyM10KICAgOGFk OGU6IDAxIDliICAgICAgICAJbGRyCXIzLCBbc3AsICM0XQogICA4YWQ5MDog NWEgNDAgICAgICAgIAllb3JzCXIyLCByMwo= --00000000000018b5f405fbf585de Content-Type: application/octet-stream; name="check_stack_protection.c" Content-Disposition: attachment; filename="check_stack_protection.c" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_lht09xr31 ZXh0ZXJuIHVpbnQzMl90ICpfX3N0YWNrX2Noa19ndWFyZDsKCmJvb2wgY2hl Y2tfc3RhY2tfYnVnKHVpbnQzMl90IGNvbnN0ICpkYXRhLCBpbnQgZHVtcF9s ZW4pCnsKICAgIGZvciAoaW50IGkgPSAwOyBpIDwgZHVtcF9sZW47IGkrKykK ICAgIHsKICAgICAgICBjb25zb2xlX3ByaW50ZigiJXAgOiAlcFxuIiwgJmRh dGFbaV0sIGRhdGFbaV0pOwogICAgICAgIGlmIChkYXRhW2ldID09IChjb25z dCB1aW50MzJfdCkmX19zdGFja19jaGtfZ3VhcmQpCiAgICAgICAgewogICAg ICAgICAgICBjb25zb2xlX3ByaW50ZigKICAgICAgICAgICAgICAgICJjYW5h cnkgaXMgYXQgb2Zmc2V0ICVkIGZyb20gZHVtbXkgYW5kIGVxdWFscyB0byB0 aGUgYWRkcmVzcyBvZiBfX3N0YWNrX2Noa19ndWFyZFxuIiwKICAgICAgICAg ICAgICAgIGkpOwogICAgICAgICAgICByZXR1cm4gdHJ1ZTsKICAgICAgICB9 CiAgICB9CiAgICByZXR1cm4gZmFsc2U7Cn0KCnN0YXRpYyBpbnQgYXBwX3N0 YWNrX2d1YXJkX2NtZF9oYW5kbGVyKCkKewoKICAgIC8vIEEgZHVtbXkgdmFy IHRvIGdldCB0aGUgc3RhY2sgZnJhbWUgYWRkcmVzcwogICAgdWludDMyX3Qg ZHVtbXkgPSAweDU3QUM1N0FDOwoKICAgIGJvb2wgaXNfYnVnZ3kgPSBjaGVj a19zdGFja19idWcoKHVpbnQzMl90IGNvbnN0ICopJmR1bW15LCA1KTsKICAg IGlmIChpc19idWdneSkKICAgICAgICBfY29uc29sZV9wcmludGYoInN0YWNr IHByb3RlY3Rpb24gYnVnIGRldGVjdGVkXG4iKTsKfQo= --00000000000018b5f405fbf585de Content-Type: text/plain; charset="US-ASCII"; name="output.txt" Content-Disposition: attachment; filename="output.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_lht09xr42 U3RhY2sgZHVtcDoKMHgyMDEzYmRiOCA6IDB4NTdhYzU3YWMKMHgyMDEzYmRi YyA6IDB4MjAxMmY4M2MKY2FuYXJ5IGlzIGF0IG9mZnNldCAxIGZyb20gZHVt bXkgYW5kIGVxdWFscyB0byB0aGUgYWRkcmVzcyBvZiBfX3N0YWNrX2Noa19n dWFyZApzdGFjayBwcm90ZWN0aW9uIGJ1ZyBkZXRlY3RlZAo= --00000000000018b5f405fbf585de--