SNOW-3067223: [Bug] JDBC Driver Fails to Initialize in Restricted Security Environments (SecurityManager)

[amit-yadav-tech]

Summary

The Snowflake JDBC driver (v3.22.0) crashes during initialization when Java SecurityManager restricts access to system operations. This affects enterprise environments like Restricted public cloud, containerized applications, and any platform with strict security policies. Five classes perform security-sensitive operations without exception handling, causing complete driver failure.

Impact: Critical - Driver cannot initialize at all. No database connectivity possible.

---

Environment

• Driver Version: 3.22.0
• Affected Platforms: Restricted Public Cloud, enterprise Java containers, any environment with SecurityManager enabled
• Java Version: 8+
• Current Status: No workaround that complies with security policies

---

Root Cause

The driver assumes unrestricted access to:

• System.getProperty() / System.setProperty() - throws SecurityException
• System.getenv() - throws SecurityException
• Security.addProvider() - throws SecurityException

When these operations fail, the driver throws unhandled exceptions that prevent initialization.

---

Affected Files

File	Lines	Issue	Priority
SecurityUtil.java	24-58	BouncyCastle provider registration blocks initialization	P0 - Critical
SessionUtilKeyPair.java	90-94	Property read without exception handling	P1 - Critical
SFClientConfigParser.java	39-95	Direct System.getenv() calls fail	P2 - High
SFLoggerUtil.java	24-45	System.setProperty() without try-catch	P3 - Medium
RestRequest.java	241-245	Direct System.getenv() for test feature	P4 - Low

---

Critical Example: SecurityUtil.java

Current Code (Blocks Driver Initialization)

public static void addBouncyCastleProvider() {
  if (Security.getProvider(BOUNCY_CASTLE_FIPS_PROVIDER) == null) {
    Security.addProvider(instantiateSecurityProvider());  // Throws RuntimeException
  }
}

Issue

When instantiateSecurityProvider() throws SecurityException, it's wrapped in RuntimeException and propagates up, preventing driver initialization entirely.

Proposed Fix

public static void addBouncyCastleProvider() {
  // Check both FIPS and non-FIPS providers before registration
  if (Security.getProvider(BOUNCY_CASTLE_FIPS_PROVIDER) == null
      && Security.getProvider(BOUNCY_CASTLE_PROVIDER) == null) {
    Security.addProvider(instantiateSecurityProvider());
  }
}

---

Why This Matters

1. Driver already has fallback mechanisms - SessionUtilKeyPair can use JDK providers instead of BouncyCastle or we can use Provider registered in the runtime.
2. Helper methods exist - SnowflakeUtil.systemGetEnv() already handles SecurityException gracefully (lines 664-672)
3. Zero breaking changes - Unrestricted environments continue working identically
4. Follows existing patterns - Similar approach in FileCacheManager.build() (lines 120-131)

---

Steps to Reproduce

1. Enable SecurityManager with restrictive policy:

grant {
  permission java.net.SocketPermission "*", "connect,resolve";
  permission java.lang.RuntimePermission "accessDeclaredMembers";
  // Explicitly DENY:
  // permission java.security.SecurityPermission "insertProvider.BC";
  // permission java.util.PropertyPermission "*", "read,write";
  // permission java.lang.RuntimePermission "getenv.*";
};

2. Attempt connection:

Properties props = new Properties();
props.put("user", "username");
props.put("password", "password");
props.put("account", "account");
Connection conn = DriverManager.getConnection(
    "jdbc:snowflake://account.snowflakecomputing.com", props);

3. Expected: Driver initializes with JDK providers, connection succeeds
   Actual: Driver throws RuntimeException during static initialization

Stack Trace

java.lang.RuntimeException: Failed to load org.bouncycastle.jce.provider.BouncyCastleProvider
  at net.snowflake.client.core.SecurityUtil.instantiateSecurityProvider(SecurityUtil.java:55)
  at net.snowflake.client.core.SecurityUtil.addBouncyCastleProvider(SecurityUtil.java:32)
  [... driver initialization fails ...]
Caused by: java.security.SecurityException: Cannot register security provider

---

Proposed Solution

Add defensive checks and use existing helper methods for security-sensitive operations:

• P0: SecurityUtil - Check both FIPS and non-FIPS providers before registration attempt
• P1: SessionUtilKeyPair - Wrap System.getProperty() + auto-detect available providers
• P2-P4: Use existing SnowflakeUtil.systemGetEnv() helper instead of direct System calls

Detailed technical analysis with all 5 solutions:

SNOWFLAKE_JDBC_RESTRICTED_ENV_FIX.md

---

Backward Compatibility

✅ Zero breaking changes - All existing deployments continue working identically
✅ No API changes - Method signatures unchanged
✅ No dependency changes - Same libraries
✅ No configuration changes - Transparent to users

NEW: Driver works in restricted environments without security policy modifications

---

Testing Recommendations

• Unit tests with SecurityManager enabled (deny all security permissions)
• Integration test: Full connection in restricted environment
• Regression: All existing tests pass
• Manual: Validation in Restricted public cloud

[sfc-gh-dszmolka]

hi @amit-yadav-tech thanks for submitting this issue and all the details. The team will take a look (as hinted in the bug template, with no strict SLA).

If it's within your possibilities, you're more than welcome to submit a PR with the fix. Your contribution is appreciated.

[coreywebber]

https://app.snowflake.com/support/case/01301420

[sfc-gh-dszmolka]

A PR is up with the fix , on #2563

[sfc-gh-pfus]

Hi @amit-yadav-tech !
So the “fix” is merged, but the truth is, that it won’t help at all. Explanation:

1. Security managers can prohibit specific jars from invoking some critical low-level operations like accessing JVM properties or env variables and so on.
2. My PR addresses all access to critical operations in JDBC driver. So far so good.
3. But the problem is that we use Apache HTTP client, which also uses getProperty (to check keep alive setting 🤦 ).
4. At first glance we could think, that it’s fine, it’s good enough to give permissions to apache httpcomponents jar (supposing thin jar is in use), but revoke from snowflake-jdbc, but here is the biggest pain point: when permissions are checked, not only the current jar is checked, but the stack is walked up and all jars from classes above are also checked. So if we have JDBC along the stack path, it won’t work.
5. There is one Java solution for such a situation, where we have a potentially untrusted jar like snowflake-jdbc, which uses widely trusted jar like httpcomponents - AccessController.doPrivileged. When this function is applied, it works like a stack cutter - the stack is not checked above this function. But we can’t wrap our HTTP client builder in this function, Apache code would have to do it on their own. I checked that even the newest Apache HTTP client has the same problem.

From JDBC perspective, we did whatever we could.