SNOW-3801358: Panic (nil dereference) in `downloadOCSPCacheServer` with corrupt cache key

[fiadliel]

1. What version of GO driver are you using?

1.19.1 - but I believe this issue is also present on master

2. What operating system and processor architecture are you using?

Linux, x86

3. What version of GO are you using?
   run go version in your console

1.26.2

4.Server version:* E.g. 1.90.1
You may get the server version by running a query:

SELECT CURRENT_VERSION();

10.24.101

5. What did you do?

We ran one of our internal tools which uses gosnowflake. It crashed with a nil dereference error inside a mutex.

6. What did you expect to see?

The program should have run successfully.

7. Can you set logging to DEBUG and collect the logs?

The panic is probably enough here:

panic: runtime error: invalid memory address or nil pointer dereference
  [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x31e17d5]

  goroutine 991 [running]:
  github.com/snowflakedb/gosnowflake.(*ocspValidator).downloadOCSPCacheServer(0x116c1f39e840)
      /home/runner/go/pkg/mod/github.com/snowflakedb/gosnowflake@v1.19.1/ocsp.go:819 +0x2d5
  github.com/snowflakedb/gosnowflake.(*ocspValidator).getAllRevocationStatus(0x116c1f39e840, {0x4e5b178, 0x7e6fee0}, {0x116c1ee8b248, 0x3, 0x4bc66fa?})
      /home/runner/go/pkg/mod/github.com/snowflakedb/gosnowflake@v1.19.1/ocsp.go:828 +0x47
  github.com/snowflakedb/gosnowflake.(*ocspValidator).verifyPeerCertificate(0x116c1f39e840, {0x4e5b178, 0x7e6fee0}, {0x116c1ee8b2c0?, 0x1, 0x116c1f47b530?})
      /home/runner/go/pkg/mod/github.com/snowflakedb/gosnowflake@v1.19.1/ocsp.go:707 +0x94
  github.com/snowflakedb/gosnowflake.(*ocspValidator).verifyPeerCertificateSerial(0x116c1f39e840, {0x116c1f47b450?, 0x116c1eebd208?, 0x63?}, {0x116c1ee8b2c0, 0x1, 0x1})
      /home/runner/go/pkg/mod/github.com/snowflakedb/gosnowflake@v1.19.1/ocsp.go:851 +0x53
  crypto/tls.(*Conn).verifyServerCertificate(0x116c1f2d5188, {0x116c1f6c9bc0, 0x3, 0x4})
      /home/runner/.local/share/mise/installs/go/1.26.4/src/crypto/tls/handshake_client.go:1182 +0x863
  crypto/tls.(*clientHandshakeStateTLS13).readServerCertificate(0x116c1f679c80)
      /home/runner/.local/share/mise/installs/go/1.26.4/src/crypto/tls/handshake_client_tls13.go:635 +0x29a
  crypto/tls.(*clientHandshakeStateTLS13).handshake(0x116c1f679c80)
      /home/runner/.local/share/mise/installs/go/1.26.4/src/crypto/tls/handshake_client_tls13.go:136 +0x76c
  crypto/tls.(*Conn).clientHandshake(0x116c1f2d5188, {0x4e5b290, 0x116c1ec1e8c0})
      /home/runner/.local/share/mise/installs/go/1.26.4/src/crypto/tls/handshake_client.go:339 +0x828
  crypto/tls.(*Conn).handshakeContext(0x116c1f2d5188, {0x4e5b290, 0x116c1e7110e0})
      /home/runner/.local/share/mise/installs/go/1.26.4/src/crypto/tls/conn.go:1562 +0x329
  crypto/tls.(*Conn).HandshakeContext(...)
      /home/runner/.local/share/mise/installs/go/1.26.4/src/crypto/tls/conn.go:1516
  net/http.(*persistConn).addTLS.func2()
      /home/runner/.local/share/mise/installs/go/1.26.4/src/net/http/transport.go:1736 +0x6e
  created by net/http.(*persistConn).addTLS in goroutine 959
      /home/runner/.local/share/mise/installs/go/1.26.4/src/net/http/transport.go:1732 +0x309

Looking at the code here, the cacheKey value comes from decodeCertIDKey, which can return nil if the value is malformed - not standard Base64, not valid ASN.1, or has extra bytes; but no nil check is done.

This might be solved simply with:

if cacheKey == nil {
	continue
}

cacheValue also has no nil check here, but there currently doesn't seem to be a path where this could be nil; this check might be worth adding to be more defensive.

However: I'm not certain that this is the implementation you want, as it silently masks corrupt OCSP cache entries. And I have no explanation for why the key was found to be corrupt; the task ran correctly on retry.

[sfc-gh-dszmolka]

thank you @fiadliel for reporting this issue, it indeed looks nasty. The team will take a look. Until then, unless your company security policy explicitly requires it, i highly recommend disabling the whole OCSP (disableOCSPChecks) to prevent this, and other weird issues from happening (and as a side effect enjoying a bit more performance which is no longer needed to be spent on OCSP validations)

[sfc-gh-dszmolka]

this should now be addressed by #1819 , and again thank you for reporting it !
will be available with the next release, i'll comment again when that's available (we typically release at the end of every month)