Re: Unbounded %s in sscanf
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-06-28T16:45:10Z
Lists: pgsql-hackers
On 2021-Jun-28, Daniel Gustafsson wrote:
> I happened to spot the below call in src/bin/pg_basebackup/streamutil.c which
> has an unbounded %s in the format.
>
> /* fetch xlog value and unit from the result */
> if (sscanf(PQgetvalue(res, 0, 0), "%d%s", &xlog_val, xlog_unit) != 2)
>
> There is no risk of overflow as the unit is defined to be at most 2 characters,
> but that's not explained (like how a similar %s is handled in pg_dump). The
> attached adds a small explanation in the comment to save readers time from
> following the bouncing ball to make sure.
Can you attack the system by crafting malicious output from the query?
I think the answer is still no, because the output comes from the query
SHOW wal_segment_size
which, if the attacker can control, the person running pg_basebackup has
way more serious problems.
But TBH it seems easy enough to limit to the output variable width.
--
Álvaro Herrera 39°49'30"S 73°17'W
"How amazing is that? I call it a night and come back to find that a bug has
been identified and patched while I sleep." (Robert Davidson)
http://archives.postgresql.org/pgsql-sql/2006-03/msg00378.php
Commits
-
Fix bug in TOC file error message printing
- ef1f15819a38 9.6.24 landed
- e788883de715 12.9 landed
- 998d060f3db7 15.0 landed
- 687fe8a9d7a6 13.5 landed
- 4fda03b671a6 10.19 landed
- 3e2f32b01d3b 14.1 landed
- 038892c81018 11.14 landed
-
Fix sscanf limits in pg_basebackup and pg_dump
- d3a4c1eb3d21 13.5 landed
- 931f3926a9f6 11.14 landed
- 57bf8f7b75ec 12.9 landed
- 1d7641d51a51 15.0 landed
- 121be6a665aa 14.1 landed
-
Fix sscanf limits in pg_dump
- abdf81a20ba2 10.19 landed
- 6b96aafc67ac 9.6.24 landed