From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1k0pSf-00015J-64 for mharc-grub-devel@gnu.org; Wed, 29 Jul 2020 13:01:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40720) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k0pSd-00013S-WF for grub-devel@gnu.org; Wed, 29 Jul 2020 13:01:48 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:42080) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k0pSb-0000ep-DH for grub-devel@gnu.org; Wed, 29 Jul 2020 13:01:47 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 06TGvw9G032938; Wed, 29 Jul 2020 17:01:13 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references; s=corp-2020-01-29; bh=xjUQJBq74yIWAESC4EGDteZ0zjUpGpI74D/FUYjtX2w=; b=f0eprosW0GqC7QNXBvNZ4J2Ooe/BaBqswBR5/TqhnVBN51dm5wGPlxMYwVgAWay2ZVnz IhfKcWkawQ+FYOOnUThCduRtuC5oOrzWbJ73Z7dNT4LiOgsQLYPMPul4uvJtauiZIzC8 2Jq9/0RUgjxw+fIg/aASaNPnVqYxIbEn5/m43bPqfIW6+dFmp1KfUpdV3siAgd9liCTO PAs1VgVtGl5sviWyE2zDDCUMyptSdACZ9Vn0E4Xdf1kmH5C86iXfb7gJJnXYXBDdiBMl hwuaBRkaGVTB49fQXENYx/aJP/IMpsFpUtv6/nj+XhXBjZGkcuR4lr2GS1oKKz00JkEJ IQ== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2120.oracle.com with ESMTP id 32hu1jpuhn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 29 Jul 2020 17:01:13 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 06TGvPWq035276; Wed, 29 Jul 2020 17:01:12 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3030.oracle.com with ESMTP id 32hu5v5fmw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 29 Jul 2020 17:01:11 +0000 Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 06TH1796015524; Wed, 29 Jul 2020 17:01:07 GMT Received: from tomti.i.net-space.pl (/10.175.200.191) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 29 Jul 2020 10:01:07 -0700 From: Daniel Kiper To: grub-devel@gnu.org Cc: 93sam@debian.org, alexander.burmashev@oracle.com, amakhalov@vmware.com, chris.coulson@canonical.com, cjwatson@debian.org, cperry@redhat.com, darren.kenny@oracle.com, darren.moffat@oracle.com, dave.miner@oracle.com, degranit@microsoft.com, eric.snowberg@oracle.com, ilya.okomin@oracle.com, jan.setjeeilers@oracle.com, jerecox@microsoft.com, jesse@eclypsium.com, john.haxby@oracle.com, kanth.ghatraju@oracle.com, konrad.wilk@oracle.com, mbenatto@redhat.com, mickey@eclypsium.com, msrc57813grub@microsoft.com, phcoder@gmail.com, pjones@redhat.com, sajacobu@microsoft.com, todd.vierling@oracle.com, xnox@ubuntu.com Subject: [SECURITY PATCH 01/28] yylex: Make lexer fatal errors actually be fatal Date: Wed, 29 Jul 2020 19:00:14 +0200 Message-Id: <20200729170041.14082-2-daniel.kiper@oracle.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20200729170041.14082-1-daniel.kiper@oracle.com> References: <20200729170041.14082-1-daniel.kiper@oracle.com> X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9697 signatures=668679 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxlogscore=999 mlxscore=0 suspectscore=1 bulkscore=0 malwarescore=0 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007290115 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9697 signatures=668679 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1011 mlxlogscore=999 malwarescore=0 impostorscore=0 priorityscore=1501 spamscore=0 phishscore=0 suspectscore=1 bulkscore=0 mlxscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007290115 Received-SPF: pass client-ip=156.151.31.85; envelope-from=daniel.kiper@oracle.com; helo=userp2120.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/07/29 13:01:26 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Spam_score_int: -53 X-Spam_score: -5.4 X-Spam_bar: ----- X-Spam_report: (-5.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 17:01:48 -0000 From: Peter Jones When presented with a command that can't be tokenized to anything smaller than YYLMAX characters, the parser calls YY_FATAL_ERROR(errmsg), expecting that will stop further processing, as such: #define YY_DO_BEFORE_ACTION \ yyg->yytext_ptr = yy_bp; \ yyleng = (int) (yy_cp - yy_bp); \ yyg->yy_hold_char = *yy_cp; \ *yy_cp = '\0'; \ if ( yyleng >= YYLMAX ) \ YY_FATAL_ERROR( "token too large, exceeds YYLMAX" ); \ yy_flex_strncpy( yytext, yyg->yytext_ptr, yyleng + 1 , yyscanner); \ yyg->yy_c_buf_p = yy_cp; The code flex generates expects that YY_FATAL_ERROR() will either return for it or do some form of longjmp(), or handle the error in some way at least, and so the strncpy() call isn't in an "else" clause, and thus if YY_FATAL_ERROR() is *not* actually fatal, it does the call with the questionable limit, and predictable results ensue. Unfortunately, our implementation of YY_FATAL_ERROR() is: #define YY_FATAL_ERROR(msg) \ do { \ grub_printf (_("fatal error: %s\n"), _(msg)); \ } while (0) The same pattern exists in yyless(), and similar problems exist in users of YY_INPUT(), several places in the main parsing loop, yy_get_next_buffer(), yy_load_buffer_state(), yyensure_buffer_stack, yy_scan_buffer(), etc. All of these callers expect YY_FATAL_ERROR() to actually be fatal, and the things they do if it returns after calling it are wildly unsafe. Fixes: CVE-2020-10713 Signed-off-by: Peter Jones Reviewed-by: Daniel Kiper --- grub-core/script/yylex.l | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/grub-core/script/yylex.l b/grub-core/script/yylex.l index 7b44c37b7..b7203c823 100644 --- a/grub-core/script/yylex.l +++ b/grub-core/script/yylex.l @@ -37,11 +37,11 @@ /* * As we don't have access to yyscanner, we cannot do much except to - * print the fatal error. + * print the fatal error and exit. */ #define YY_FATAL_ERROR(msg) \ do { \ - grub_printf (_("fatal error: %s\n"), _(msg)); \ + grub_fatal (_("fatal error: %s\n"), _(msg));\ } while (0) #define COPY(str, hint) \ -- 2.11.0