psqlODBC vulnerabilities

For updatable cursors, which are enabled by default, psqlODBC adds hidden ctid and, for tables with OIDs, oid columns to the query. It copies each value into a 32-byte stack buffer using the length the server sent, without checking it against the buffer size, so a value of 32 bytes or more writes past the buffer. A server not trusted under current SSL settings can send such a value. So can any database user who can create a view with its own column named ctid that the application reads with an updatable cursor. Builds with _FORTIFY_SOURCE abort; other builds overwrite adjacent stack memory. Versions before psqlODBC 18.00.0006 are affected.

On Unix-like systems, when logging is enabled, psqlODBC creates its log files in /tmp by default, named from the program name, user name, and process ID, with the default permissions, typically world-readable, and follows symbolic links when opening them. A local user can read query text and data from another user's logs, and can place a symbolic link at the predictable path so that the driver appends log data to a file of the attacker's choosing with the victim's privileges. Versions before psqlODBC 18.00.0006 are affected.

In psqlODBC, for an updatable cursor over a table without OIDs that has an auto-increment int4 column, the driver uses that column to identify rows, placing its server-reported name in double quotes without doubling any double quote in the name. A column name containing a double quote therefore changes the SQL executed, including which rows a positioned UPDATE or DELETE affects.

Several psqlODBC entry points use an application-supplied column number or row index as an array index without validating it. SQLBindCol with a column number above 32767 wraps the binding count negative, a negative SQL_DESC_COUNT unbinds columns at negative indexes, and SQLSetPos(SQL_ADD) does not check the row number against the rowset size.

psqlODBC contains a stack buffer overflow when quoting schema or table names into a 128-byte stack buffer. The length check allows writing up to two bytes past the end of the buffer for long names originating from the application's SQL text or from a server-supplied column name. Versions before psqlODBC 18.00.0006 are affected.

SQLSpecialColumns in psqlODBC splices the received table and schema names into its catalog query without escaping them, while other catalog functions escape them. An application passing an untrusted table or schema name to SQLSpecialColumns lets the caller execute arbitrary SQL with the connection's privileges.

The psqlODBC parser for ODBC escape sequences in application SQL text writes the argument offsets of a {fn} escape into a fixed 16-entry stack array without bounds checking and without initialization. An escape with too many arguments overflows the stack, a reference to an unsupplied argument copies arbitrary bytes into the query, and copying a {d}, {t}, {ts}, or {escape} body writes one byte past a 128-byte stack buffer.

psqlODBC trusts server-supplied counts and lengths in three places: SQLBulkOperations can underflow a size subtraction, SQLStatistics iterates index keys without bounding to fixed storage, and bytea octal decoding reads up to two bytes past a truncated escape sequence. A server not trusted under current SSL settings can crash the client or cause out-of-bounds reads. Versions before psqlODBC 18.00.0006 are affected.

In psqlODBC, the server-reported name of an auto-increment int4 column is placed into a printf-style format string and later expanded while building the WHERE clause for an updatable cursor. A column name containing format directives causes reads of unrelated memory, potentially crashing the application or copying client memory into query text sent to the server. Versions before psqlODBC 18.00.0006 are affected.

psqlODBC sizes its row cache from the column count of a cursor's first result but recomputes the column count from each later FETCH reply without checking that it matches. A server not trusted under current SSL settings can answer a later FETCH with more columns and make the driver write tuple records past the end of the heap allocation; a keyset reply with fewer columns than the key fields underflows the unsigned field count. This is reachable with UseDeclareFetch enabled.

psqlODBC copies the reply to a large-object read (loread) into the application's buffer using the length sent by the server, without comparing it to the buffer size. A server not trusted under current SSL settings, or a man-in-the-middle, can return more bytes than the buffer holds and overwrite adjacent memory in the client process with server-chosen bytes. Fetching any large-object column is sufficient to trigger it.

Integer wraparound in psqlODBC SQLBindParameter allows an application, or an attacker who controls how many parameters the application binds on one statement, to corrupt heap memory. psqlODBC stores the binding count in a signed 16-bit field. Binding parameter number 32768 wraps that count to -32768. Binding parameter 32769 then writes about 2.5 MB of zeros starting 1.25 MB before the binding array, which crashes the application or leaves it running on a corrupted heap. Applications that build parameter lists from untrusted input, such as an IN (?, ?, ...) list, are exposed. Versions before psqlODBC 18.00.0005 are affected.