BUG #8540: Avoid sscanf buffer overflow

Started by Nonameover 12 years ago2 messagesbugs
Jump to latest
#1Noname
jackie.qq.chang@gmail.com

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

#2Bruce Momjian
bruce@momjian.us
In reply to: Noname (#1)
Re: BUG #8540: Avoid sscanf buffer overflow

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. +

Attachments:

scanf.difftext/x-diff; charset=us-asciiDownload+6-5