avoid running static initializers in CursorFactory.fromProto#310
avoid running static initializers in CursorFactory.fromProto#310sahvx655-wq wants to merge 1 commit into
Conversation
|
Can you please log the issue in JIRA @ https://issues.apache.org ? |
|
Sure, I'll raise it on the Apache JIRA and put the CALCITE key in the PR title so it's tracked properly. For the writeup I'll describe what I found while tracing the server parse path: CursorFactory.fromProto resolves the wire-supplied className with the single-arg Class.forName, which loads and initialises the class in one go. That path is reachable on the server straight from an untrusted ExecuteRequest, through StatementHandle.fromProto then Signature.fromProto then CursorFactory.fromProto, so a client can name any class on the server's classpath and have its static initialiser run at request-parse time. Left unfixed, the concern is initialisation side effects firing before the class is ever legitimately used, which is the usual CWE-470 unsafe class loading case. The change keeps the three-arg Class.forName with initialize=false so the class is still linked and resolved, and genuine initialisation still happens lazily when a cursor actually gets built. I'll post the JIRA link back here once it's raised. |
CursorFactory.fromProto resolves a wire-supplied class name with Class.forName(String), which initializes the class and runs its static initializer. The server hits this while parsing an ExecuteRequest from an untrusted client (StatementHandle -> Signature -> CursorFactory), so a client can make the server load and initialize any class on its classpath. Resolve with the three-arg form and initialize=false; the class is still linked but no static code runs at parse time.