SQLite Forum

A stack overflow vulnerability in SQLite nmakehelp.c allows arbitrary code execution via a crated file
Login

A stack overflow vulnerability in SQLite nmakehelp.c allows arbitrary code execution via a crated file

(1) By salmonx on 2021-06-15 07:18:19 updated by 1.1 [link] [source]

### The local variable 'szBuffer' in GetVersionFromFile can be exploited by a local attacker for arbitrary code execution. 


```
static const char *
GetVersionFromFile(
    const char *filename,
    const char *match)
{
    size_t cbBuffer = 100;
    static char szBuffer[100];
    char *szResult = NULL;
    FILE *fp = fopen(filename, "rt");

    if (fp != NULL) {
	/*
	 * Read data until we see our match string.
	 */

	while (fgets(szBuffer, cbBuffer, fp) != NULL) {
	    LPSTR p, q;

	    p = strstr(szBuffer, match);
	    if (p != NULL) {
		/*
		 * Skip to first digit.
		 */

		while (*p && !isdigit(*p)) {
		    ++p;
		}

		/*
		 * Find ending whitespace.
		 */

		q = p;
		while (*q && (isalnum(*q) || *q == '.')) {
		    ++q;
		}

		memcpy(szBuffer, p, q - p); // Vulnerability
		szBuffer[q-p] = 0;
		szResult = szBuffer;
		break;
	    }
	}
	fclose(fp);
    }
    return szResult;
}
```

A stack overflow in tool used to help build SQLite's TCL extension on Windows

(1.1) Originally by salmonx with edits by Richard Hipp (drh) on 2021-06-15 11:07:34 from 1.0 [link] [source]

The local variable 'szBuffer' in GetVersionFromFile can be exploited by a local attacker for arbitrary code execution.

static const char *
GetVersionFromFile(
    const char *filename,
    const char *match)
{
    size_t cbBuffer = 100;
    static char szBuffer[100];
    char *szResult = NULL;
    FILE *fp = fopen(filename, "rt");

    if (fp != NULL) {
	/*
	 * Read data until we see our match string.
	 */

	while (fgets(szBuffer, cbBuffer, fp) != NULL) {
	    LPSTR p, q;

	    p = strstr(szBuffer, match);
	    if (p != NULL) {
		/*
		 * Skip to first digit.
		 */

		while (*p && !isdigit(*p)) {
		    ++p;
		}

		/*
		 * Find ending whitespace.
		 */

		q = p;
		while (*q && (isalnum(*q) || *q == '.')) {
		    ++q;
		}

		memcpy(szBuffer, p, q - p); // Vulnerability
		szBuffer[q-p] = 0;
		szResult = szBuffer;
		break;
	    }
	}
	fclose(fp);
    }
    return szResult;
}

(Edit: Title changed for clarity)

(2) By Keith Medcalf (kmedcalf) on 2021-06-15 09:22:02 in reply to 1.0 [link] [source]

To use the wonderful error messages from my favourite Operating System (TRSDOS):

HOW?

(3) By Richard Hipp (drh) on 2021-06-15 11:05:05 in reply to 1.0 updated by 3.1 [link] [source]

## This Is Not An SQLite Vulnerability

Just to be clear to people who may be alarmed by the salmonx's title,
this is <u>not</u> a bug in SQLite.

The name of the file is "nmakehlp.c", not "nmakehelp.c".  And it is not
part of SQLite.  "nmakehlp.c" is a helper program used to assist in building
the TCL Extension on Windows.  It is part of TEA or the 
"TCL Extension Architecture".  In other words, the "nmakehlp.exe" program
is built and used to help with the build process for the SQLite TCL
extension under Windows.  Nobody ever runs this program, except when building
the SQLite TCL interface on a Windows host.  The inputs to nmakehlp.exe
are well-controlled such that even if it does contain a vulnerability
(which is probably does not) it would be completely harmless.

So, in other words, salmonx's original post above appears to be complete
nonsense.  One suspects that he is running a source-code scanning tool
across every source file he can find and reporting his results here.

(3.1) By Richard Hipp (drh) on 2021-06-15 11:08:05 edited from 3.0 in reply to 1.0 [link] [source]

This Is Not An SQLite Vulnerability

Just to be clear to people who may be alarmed by the salmonx's title, this is not a bug in SQLite.

The name of the file is "nmakehlp.c", not "nmakehelp.c". And it is not part of SQLite. "nmakehlp.c" is a helper program used to assist in building the TCL Extension on Windows. It is part of TEA or the "TCL Extension Architecture". In other words, the "nmakehlp.exe" program is built and used to help with the build process for the SQLite TCL extension under Windows. Nobody ever runs this program, except when building the SQLite TCL interface on a Windows host. The inputs to nmakehlp.exe are well-controlled such that even if it does contain a vulnerability (which is probably does not) it would be completely harmless.

So, in other words, salmonx's original post above appears to be complete nonsense. One suspects that he is running a source-code scanning tool across every source file he can find and reporting his results here.

Edit: The original title has been edited to make this point clear.

(4) By salmonx on 2021-06-15 11:34:08 in reply to 3.1 [link] [source]

Thanks for your timely response. But you could delete the vulnerable code or fix it to make SQLite more secure, don't you think so? :)

(5) By Richard Hipp (drh) on 2021-06-15 11:43:40 in reply to 4 [source]

It's not our code. We copy/pasted from another project. I'll check for updates. Nevertheless, we haven't yet seen a vulnerability in the current code. Can you elaborate on what you think is incorrect?

(6) By Jan Nijtmans (jan.nijtmans) on 2021-07-01 06:41:04 in reply to 5 [link] [source]

There's a new version of nmakehlp.c now, which eliminates the (potential) problem: https://core.tcl-lang.org/tcl/artifact/b01f822eabbe1ed2