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)

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

HOW?

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.

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? :)

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?