Add support for Oracle Call Interface (OCI) to C/C++ coverage

[ebickle]

Description of the issue

The Oracle Call Interface (OCI) is the main low-level C API for Oracle databases. CodeQL lacks coverage for it, particularly for SQL injection sinks.

While I haven't done a robust analysis of the API surface area, the official documentation shows the following functions as accepting SQL input:

• OCIStmtPrepare:
  sword OCIStmtPrepare(OCIStmt* stmtp, OCIError* errhp, const OraText* stmt, ub4 stmt_len, ub4 language, ub4 mode);
• OCIStmtPrepare2:
  sword OCIStmtPrepare2(OCISvcCtx* svchp, OCIStmt** stmthp, OCIError* errhp, const OraText* stmttext, ub4 stmt_len, const OraText* key, ub4 keylen, ub4 language, ub4 mode);

oratypes.h of the OCI (Simple Client) SDK has the following typedefs:

• typedef unsigned char oratext;
• typedef unsigned int ub4;

It looks relatively simple to treat the stmt parameter of OCIStmtPrepare and the stmttext of OCIStmtPrepare2 as SQL sinks within CodeQL. The function names, starting with OCI, are unlikely to collide with other libraries.

I looked at adding this as a PR to expand model coverage, but it looks like the sql-injection sink type isn't supported for C++ CodeQL extension models yet.

[mbg]

Hi @ebickle 👋🏻

Thanks for this feature request and the detailed summary of what you think would be needed. I'll pass this on to the relevant team, but can't make any promises for whether we will be able to officially support this anytime soon.

I looked at adding this as a PR to expand model coverage, but it looks like the sql-injection sink type isn't supported for C++ CodeQL extension models yet.

That does seem to be the case, although we have summary models for SQLite. Combined with the minimal QL code in https://github.com/github/codeql/blob/d83cbde1cb1263fb476a55ea5fd7972307138905/cpp/ql/lib/semmle/code/cpp/models/implementations/SqLite3.qll that's enough to support SQLite. If you are feeling adventurous, you could add a similar implementation for OCI.

[geoffw0]

Hi @ebickle , the QL approach described above (as in SqLite3.qll) should work. Alternatively I believe you could add support for the sql-injection models-as-data sink type in C++ with a very small change to isSink in SqlTainted.ql:

    or
    // sink defined using models-as-data
    sinkNode(node, "sql-injection")

Ideally you would also add at least one model row in a .yml that uses this and one test case alongside to prove everything is working - see the test for this query. Happy to help with any problems that come up if you decide to do this.

[ebickle]

Appreciate all the advice!

I'll look into adding support for sql-injection models-as-data since it would be the most flexible long term and allow for extensibility.

May need some help figuring out how to write appropriate tests for it. Should I add some tests for the new data-as-code support directly into SqlTainted.c, or is there a different preferred approach for testing models?