Microsoft ODBC bug

Arran Cudbard-Bell a.cudbardb at freeradius.org
Tue Jul 2 19:16:35 CEST 2019



> On 2 Jul 2019, at 12:21, Dom Latter <freeradius-users at latter.org> wrote:
> 
> 
> 
> On 02/07/2019 16:10, Alan DeKok wrote:
>> On Jul 2, 2019, at 12:18 PM, Dom Latter <freeradius-users at latter.org>
>> wrote:
>>> And again, with PHP, "SELECT 123456789" works fine but a large number gets an error from the ODBC driver.
>>> <snip>
>> That's all well and good, but what should *we* be doing differently?
> 
> Well, if I knew that...
> 
>> We're not Microsoft experts, or experts in ODBC.  The ODBC layer was
>> contributed by someone years ago, and we've maintained it since then.
>> It mostly works, but new features require people who can delve into
>> it and fix things.
> 
> And that is what I am trying to do.  I am looking at the following
> in rlm_sql_unixodbc.c
> 
> /* Executing query */
> {
> 	SQLCHAR *odbc_query;
> 
> 	memcpy(&odbc_query, &query, sizeof(odbc_query));
> 	err_handle = SQLExecDirect(conn->stmt, odbc_query, strlen(query));
> }
> 
> Is that a safe memcpy?  It's a long time since I programmed in C...

It's likely copying a pointer from query to odbc_query to defeat const checks, because SQLExecDirect should likely take a const (read only) query string pointer, and doesn't.

So yes... It's fine.

-Arran


Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2




More information about the Freeradius-Users mailing list