BUG #8540: Avoid sscanf buffer overflow
The following bug has been logged on the website:
Bug reference: 8540
Logged by: Jackie Chang
Email address: jackie.qq.chang@gmail.com
PostgreSQL version: 9.3.1
Operating system: Any
Description:
sscanf can set the maximum length of string read. If such a number is not
provided, it's vulnerable to buffer overflow.
Diff is:
diff --git a/contrib/pg_upgrade/option.c b/contrib/pg_upgrade/option.c
index 250aeb8..293ef1c 100644
--- a/contrib/pg_upgrade/option.c
+++ b/contrib/pg_upgrade/option.c
@@ -443,7 +443,7 @@ get_sock_dir(ClusterInfo *cluster, bool live_check)
{
cluster->sockdir = pg_malloc(MAXPGPATH);
/* strip off newline */
- sscanf(line, "%s\n", cluster->sockdir);
+ sscanf(line, "%1023s\n", cluster->sockdir);
}
}
fclose(fp);
diff --git a/src/backend/access/transam/xlog.c
b/src/backend/access/transam/xlog.c
index 06f5eb0..560230f 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -10029,7 +10029,7 @@ do_pg_stop_backup(char *labelfile, bool
waitforarchive, TimeLineID *stoptli_p)
* Read and parse the START WAL LOCATION line (this code is pretty crude,
* but we are not expecting any variability in the file format).
*/
- if (sscanf(labelfile, "START WAL LOCATION: %X/%X (file %24s)%c",
+ if (sscanf(labelfile, "START WAL LOCATION: %X/%X (file %63s)%c",
&hi, &lo, startxlogfilename,
&ch) != 4 || ch != '\n')
ereport(ERROR,
diff --git a/src/bin/pg_dump/pg_backup_directory.c
b/src/bin/pg_dump/pg_backup_directory.c
index f803186..48e0db9 100644
--- a/src/bin/pg_dump/pg_backup_directory.c
+++ b/src/bin/pg_dump/pg_backup_directory.c
@@ -452,7 +452,7 @@ _LoadBlobs(ArchiveHandle *AH, RestoreOptions *ropt)
char fname[MAXPGPATH];
char path[MAXPGPATH];
- if (sscanf(line, "%u %s\n", &oid, fname) != 2)
+ if (sscanf(line, "%u %1023s\n", &oid, fname) != 2)
exit_horribly(modulename, "invalid line in large object TOC file \"%s\":
\"%s\"\n",
fname, line);
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Sat, Oct 19, 2013 at 09:49:05PM +0000, jackie.qq.chang@gmail.com wrote:
The following bug has been logged on the website:
Bug reference: 8540
Logged by: Jackie Chang
Email address: jackie.qq.chang@gmail.com
PostgreSQL version: 9.3.1
Operating system: Any
Description:sscanf can set the maximum length of string read. If such a number is not
provided, it's vulnerable to buffer overflow.
I have looked at your patch and I wasn't happy to be adding a hard-coded
constant based on a macro definition. What I did do with the attached,
applied patch is to remove the use of sscanf in pg_upgrade, and add a C
comment in pg_dump explaining why the scanf can't overflow. I didn't
see increasing the xlog.c length as useful.
For pg_dump it would be nice from a sanity perspective if we could do:
sscanf(str, "%" CppAsString2(MAXPGPATH-1) "s\n", ...
but there is no way to string-ify a macro while also computing it during
preprocessing.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +