Horton

Re: Unbounded %s in sscanf

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-07-30T16:03:59Z
Lists: pgsql-hackers 
Daniel Gustafsson <daniel@yesql.se> writes:
> I took another look at this today, and propose to push the attached.  The
> pg_dump fix goes all the way back to 9.6 whereas the pg_basebackup fix is from
> 11 and onwards.  The adjacent shadowed variable bug in pg_dump is also present
> since 9.6.
> Thoughts?

Generally +1, though I wonder if it'd be prudent to deal with the
shadowed-variable bug by renaming *both* variables.  "fname" is
clearly too generic in a function that deals with multiple file
names.

Another thing that is nibbling at the back of my mind is that one
reason we started to use src/port/snprintf.c all the time is that
glibc's *printf functions behave in a very unfriendly fashion when
asked to print text that they think is invalidly encoded, but only
if the format involves an explicit field width spec.  I wonder if
we're opening ourselves to similar problems if we start to use
field widths with *scanf.  In principle, I think the input text
always ought to be ASCII in these cases, so that there's no hazard.
But is there an interesting security aspect here?  That is, if someone
can inject a maliciously-crafted file containing non-ASCII data, what
kind of misbehavior could ensue?  It might be that sscanf would just
report failure and we'd give up, which would be fine.  But if a
stack overrun could be triggered that way, it'd not be fine.

			regards, tom lane

Commits

  1. Fix bug in TOC file error message printing

  2. Fix sscanf limits in pg_basebackup and pg_dump

  3. Fix sscanf limits in pg_dump