Re: som: buffer overflow writing strings

[Alan Modra <amodra@gmail.com>]

On Tue, Aug 29, 2023 at 12:32:20PM -0600, Jeff Law wrote:
> 
> 
> On 8/25/23 00:33, Alan Modra via Binutils wrote:
> > Code in som_write_symbol_strings neglected to allow for padding, which
> > can result in a buffer overflow.  It also used xrealloc, which we're
> > not supposed to use in libbfd because libbfd isn't supposed to call
> > exit.  Also a realloc is perhaps not a good idea when none of the
> > buffer contents are needed, so replace with free, bfd_malloc.  There
> > were three copies of the string handling code, so rather than fix them
> > all I've extracted them to a function.  This necessitated making one
> > of the fields in struct som_symbol unsigned.
> > 
> > 	* som.c (add_string): New function.
> > 	(som_write_space_strings, som_write_symbol_strings): Use it.
> > 	* som.h (som_symbol_type <stringtab_offset>): Make unsigned.
> Thanks for fixing this.  Amazing how this problem slipped through as long as
> it did.  Of course SOM died ~20+ years ago, so that may explain how the bug
> has survived so long.

I suspect the bug could only be tickled by fuzzed object files.  Most
of the bugs reported by projects like oss-fuzz against old binutils
code are like that.  ie. fixing them doesn't really improve anything
for users, except for people who are silly enough to run any of the
binutils as root outside of a sandbox, on random executables they
might have downloaded from evil-hacker-site.

> One could certainly argue about how useful being able to write object files
> for a dead format on a dead architecture is.  I wouldn't lose any sleep if
> SOM quietly went away.

Yeah, but this sort of fix isn't difficult at all.

On the other hand, I refuse to look at fuzzed input for the assembler
any more.

-- 
Alan Modra
Australia Development Lab, IBM