by Robert C. Seacord
The cutoff for new feature proposals for the next C Language Standard (C23) has come and gone meaning that we know some of the things that will be in the next standard and all of the things that will not be. There are still a bunch of papers that have been submitted but not yet adopted into C23. Some of these papers will be accepted, some will be rejected, and potentially some good ideas won’t make it because of lack of time to perfect them and gain consensus. NCC Group has already had a number of proposals accepted into C23. This blog posts reviews an additional five papers that we have submitted which are currently under consideration.
Clarifying integer terms v2
During a committee discussion of the behavior of calloc, it became clear that the committee lacks a consensus definition of terms such as “overflow” and “wraparound” that are commonly used to discuss integer arithmetic. As a result, the committee can’t answer the simple question “do unsigned numbers overflow?”.
This paper [N2837] is unlikely to change the behavior of the language. However, having taught Secure Coding in C and C++ for 16 years I can tell you it is extremely important that we have a common shared vocabulary to discuss language behaviors; especially behaviors like overflow and wraparound that commonly result in exploitable vulnerabilites.
Identifier Syntax using Unicode Standard Annex 31
Unicode® Standard Annex #31 Unicode Identifier and Pattern Syntax [Davis 2009] describes specifications for recommended defaults for the use of Unicode in the definitions of identifiers and in pattern-based syntax and has been adopted by has been adopted by C++, Rust, Python, and other languages. By adopting the recommendations of UAX #31, C will be easier to work with in international environments and less prone to accidental problems. This paper [N2836] also aligns the C language with other current languages that defer to Unicode UAX #31 for identifier syntax.
calloc Wraparound Handling
RUS-CERT [RUS-CERT 2002, Weimer 2002] documented the defect in calloc implementations and similar routines:
Integer overflow can occur during the computation of the memory region size by calloc and similar functions. As a result, the function returns a buffer which is too small, possibly resulting in a subsequent buffer overflow.
While most implementations were repaired, the standard was not updated to clarify the existing requirement.
The problem subsequently reoccurred [MSRC 2021]. The same vulnerability exists in standard memory allocation functions spanning widely used real-time operating systems (RTOS), embedded software development kits (SDKs), and C standard library (libc) implementations. This paper [N2810] clarifies the existing behavior of calloc in the event that nmemb * size wraps around, to help prevent future implementation defects resulting in security vulnerabilities.
Annex K Repairs
Annex K Bounds-checking interfaces provides alternative library functions that promote safer, more secure programming. Annex K contains the *_s functions verify that output buffers are large enough for the intended result and return a failure indicator if they are not. Annex K’s set_constraint_handler_s function is specified to set the global process-wide runtime-constraint handler and return a pointer to the previously registered process-wide handler. However, because the process-wide handler is shared among all threads in a program, it is not well-suited for multithreaded programs where code runs in separate threads. This paper [N2809] proposes two alternative solutions for using constraint handlers in multithreaded programs.
Volatile C++ Compatibility
The volatile keyword imposes restrictions on access and caching and is often necessary for memory that can be externally modified. Some uses of the volatile keyword are ambiguous, incorrect, or insecure. Consequently, C++ has deprecated many of these uses[P1152R4]. This paper [N2743] proposed deprecating these same uses of the volatile keyword in C for the same reasons, and to maintain compatibility with C++.
[Davis 2009] Mark Davis. Unicode Standard Annex #31 Unicode Identifier and Pattern Syntax. September, 2009. URL: http://www.unicode.org/reports/tr31/tr31-11.html
[MSRC 2021] MSRC Team. “BadAlloc” – Memory allocation vulnerabilities could affect wide range of IoT and OT devices in industrial, medical, and enterprise networks. April 29, 2021. URL: https://msrcblog.microsoft.com/2021/04/29/badalloc-memory-allocation-vulnerabilities-could-affect-widerange-of-iot-and-ot-devices-in-industrial-medical-and-enterprise-networks/
[N2743] Robert C. Seacord. Volatile C++ Compatibility. May, 2021. URL:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2743.pdf
[N2809] Robert C. Seacord. Annex K Repairs. October, 2021. URL:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2809.pdf
[N2810] Robert C. Seacord. calloc wraparound handling. October, 2021. URL:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2810.pdf
[N2836] Robert C. Seacord. Identifier Syntax using Unicode Standard Annex 31. October, 2021. URL: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2836.pdf
[N2837] Robert C. Seacord, Clarifying integer terms v2. October, 2021. URL:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2837.pdf
[P1152R4] JF Bastien. Deprecating volatile. 19 July 2019. URL: http://wg21.link/P1152R4
[RUS-CERT 2002] RUS-CERT Advisory. Flaw in calloc and similar routines 2002-08:02. URL:
https://web.archive.org/web/20081225201357/http://cert.uni-stuttgart.de/advisories/calloc.php
[Weimer 2002] Florian Weimer. RUS-CERT Advisory 2002-08:02: Flaw in calloc and similar routines. August, 2002. URL: https://www.opennet.ru/base/cert/1028651886_905.txt.html
Published