[Radiance-general] crashes in radiance from fuzzers

[Greg Ward]

Hi John,

There are many ways to overrun buffers in Radiance.  It's not designed as a hardened system, and the general assumption is that it isn't running it in a privileged mode.  It would take a little time and effort to patch the possible attack routes just in the header-reading code, including:

	globmatch()	- needs check as you say for output buffer length
	formatval()	- typically called with a fixed-size buffer in first argument, which is easily overrun by a too-long format string in the HDR file
	oldreadcolrs()	- needs a check for malicious run-length codes
	
If you're only concerned about the HDR input side of things, this might be enough.  If you enlarge it to all Radiance input types, we have a long road ahead....

Cheers,
-Greg

> From: jcupitt at gmail.com
> Date: July 22, 2018 8:24:32 AM EDT
> 
> Hello all,
> 
> I maintain an image processing library that supports HDR files. We've
> been fuzzing it to find bugs, and HDR is one of the ones that seems
> vulnerable to attack.
> 
> The obvious one is the globmatch() function in header.c -- during file
> read, it expands into a 64-byte buffer here:
> 
> https://radiance-online.org/cgi-bin/viewcvs.cgi/ray/src/common/header.c?view=markup#l231
> 
> It's easy to make an HDR file which would overwrite this and let an
> attacker take control of the user's machine (I think), since that
> buffer is usually allocated on the stack.
> 
> Does this sound like something that should be fixed? I could try to
> cook up a patch, if it would be useful.
> 
> John