malloc and buffer overflow attacks

[H. S. Teoh]

On Fri, Dec 31, 2021 at 12:12:45PM -0800, Walter Bright via Digitalmars-d wrote:
> On 12/30/2021 4:37 PM, sarn wrote:
> > Good thing to do, but Walter's talking about integer overflow with
> > the `len * T.sizeof` calculation itself.
> > 
> > calloc() doesn't have this problem.
> 
> The calculation of `len` can also have overflow problems. `calloc` is
> not sufficient. The provenance of `len` needs to be carefully checked.

At my day job we use Coverity to identify potential issues with our C
codebase.  One of the issues it reports is using external inputs as the
length of a memory allocation, the typical case being reading an int or
long from a file/socket and then passing that to malloc, et al
(potentially with a sizeof multipler).  So imagine a carefully-crafted
malicious input designed to overflow a 64-bit integer just a little --
the malloc call would end up allocating just a tiny amount of memory
while the rest of the code thinks that the buffer has more memory than
can be addressed.

Of course, that tempts the following check (obviously wrong, but I've
seen this scarily often in "professional" code):

	size_t n = ... /* read from file/socket */;
	size_t nbytes = n * sizeof(Element); // oops
	if (nbytes > INT64_MAX)	// never true
		error();	// dead code
	void *p = malloc(n * sizeof(Element)); // uh-oh
	for (i=0; i < n; i++) {
		... /* use p: kaboom */
	}


T

-- 
INTEL = Only half of "intelligence".