| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> | 
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se> | 
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> | 
| Subject: | Re: Unbounded %s in sscanf | 
| Date: | 2021-06-28 16:45:10 | 
| Message-ID: | 202106281645.eb555hja6lxs@alvherre.pgsql | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2021-06-28 17:02:37 | Re: cleaning up PostgresNode.pm | 
| Previous Message | Tom Lane | 2021-06-28 16:43:30 | Re: Overflow hazard in pgbench |