google.golang.org/grpc@v1.84.0 security report

The code uses unsafe.Pointer and atomic.StorePointer/LoadPointer for updating the internal interceptor. While this is a known pattern for lock-free atomic updates, it bypasses Go's type safety and could lead to memory corruption if misused. However, in this context it appears correct and intentional.

The full policy content is logged at info level (logger.Infof) when a policy is successfully reloaded. This could expose sensitive authorization rules in logs, which might be accessible to unauthorized parties.

The program creates CPU and memory profile files directly in /tmp/ using the user-supplied -test_name flag, which could allow writing files to arbitrary paths if the test name contains path traversal sequences (e.g., ../). This is a local, user-controlled benchmark utility, so the risk is limited.

The client connects to the server using insecure transport credentials (grpc.WithTransportCredentials(insecure.NewCredentials())). While expected for a local benchmark tool, it would be insecure if used in production or against untrusted networks.

The server listens on a TCP port for incoming gRPC connections. This is the intended purpose of the benchmark server and not a security concern.

The program writes CPU and memory profiles to /tmp using a filename derived from the user-supplied -test_name flag. This is expected behavior for a benchmark server and does not indicate malicious intent. However, a non-sanitized test name could theoretically allow path traversal, though this is a local dev tool and not a security boundary.

When pprof_port is specified, an HTTP pprof debug server is started. Although bound to localhost, pprof endpoints can leak runtime details and in some contexts may aid further exploitation.

The function uses os.CreateTemp which is generally safe against race conditions, but the use of a fixed, predictable directory (/tmp) and predictable filename pattern means an attacker with local access could potentially monitor or access these temp files. The sink is explicitly designed to log binary data that may contain sensitive information.

The code checks whether it is running on Google Cloud Platform (GCE) via googlecloud.OnGCE() before proceeding with ALTS handshakes. This is expected behavior for ALTS credentials and not credential harvesting.

Connects to the ALTS handshaker service at a default GCP-internal address (dns:///metadata.google.internal.:8080) or a user-provided address. This is the documented purpose of the package and not exfiltration.

The package uses an init() function to initialize global variables (backoff strategy and ID token credentials constructor). This is a standard Go pattern for package initialization and does not perform any suspicious network, file system, or process operations. The initialized functions are only invoked later when explicitly creating credentials.

OverrideServerName directly mutates c.config.ServerName without validation. If called on a shared config it could redirect certificate verification to an attacker-controlled name. The method is part of the standard TransportCredentials interface, but mutation of the underlying config is a latent risk.

applyDefaults adds all cipher suites reported by tls.CipherSuites() except those explicitly forbidden by RFC 7540 Appendix A. tls.CipherSuites() returns 'secure' suites in modern Go, but the allow-list approach combined with disabled ALPN may still permit suites that are inappropriate for the intended HTTP/2 usage context.

NewClientTLSFromFileWithALPNDisabled and NewServerTLSFromFileWithALPNDisabled read arbitrary file paths supplied by the caller via os.ReadFile / tls.LoadX509KeyPair. This is expected for credential-loading APIs but could be abused if paths are attacker-influenced; no path sanitization is performed.

The init() function registers a glog-based logger as the global grpclog logger. This is intended package behavior documented in the package comment, not malicious. It has no network, filesystem, credential, or execution capabilities beyond routing log messages.

Package documentation references GRPC_GO_LOG_SEVERITY_LEVEL and GRPC_GO_LOG_VERBOSITY_LEVEL environment variables for configuring logging. These are legitimate gRPC logging configuration variables, not credential harvesting.

Fatal/Fatalf/Fatalln/FatalDepth functions call os.Exit(1). This is standard logging behavior for fatal-level logs in Go's grpclog package, not a backdoor or malicious process spawn.

The init() function executes automatically when the package is imported, reading environment variables and initializing the global binary logger. While this is standard Go practice and the action is benign (only configuration parsing), it does constitute import-time code execution.

The init() function reads the GRPC_BINARY_LOG_FILTER environment variable at import time and uses it to configure binary logging behavior. This is a legitimate gRPC feature for logging filter configuration, but it means any process importing this package will read this environment variable at startup.

The code checks envconfig.XDSSNIEnabled to conditionally change SNI and SAN validation behavior. This is not credential harvesting or exfiltration; it is a standard gRPC xDS feature flag. No malicious environment variable reading for secrets was observed.

The init() function sets internal.GetXDSHandshakeInfoForTesting = HandshakeInfoFromAttributes. This runs at package import time but only wires an internal testing hook and does not perform any network, filesystem, or process operations. It is benign for this gRPC package.

The client-side TLS config sets InsecureSkipVerify to true, disabling Go's built-in hostname and certificate chain verification. While this is intentional to perform custom SAN verification via VerifyPeerCertificate, it is a security-sensitive pattern that could allow MITM if the custom verification logic has flaws. In this code the custom function does chain verification and SAN matching, so it is not malicious.

This code reads numerous GRPC_* environment variables to configure gRPC behavior. This is the intended, documented purpose of the file. The environment variables are configuration knobs specific to gRPC (TXT service config, ring hash cap, ALTS handshake limits, header list size, etc.) and do not involve harvesting credentials, tokens, or secrets.

The file uses package-level var initialization to read environment variables at import time. This is normal Go practice for configuration and matches the file's stated purpose. The values are parsed safely via strconv.ParseUint and string comparisons; no external calls, file access, or code execution occur.

The init() function performs standard protobuf registration and descriptor building only. No external calls, file I/O, network access, or process spawning occurs.

Uses unsafe.Slice/unsafe.StringData to compress the embedded proto descriptor. This is standard generated code from protoc-gen-go for efficiency; the data is a static compile-time constant, not attacker-controlled.

The code creates temporary directories and copies certificate/key files into them for use in end-to-end tests. This is normal test utility behavior and does not access sensitive user files or locations outside the test scope.

Files are written with permission 0777 (os.ModePerm), which is overly permissive. However, these are temporary test files in a temporary directory and not a security risk in this context.

The SPIFFE trust bundle map file functionality is gated behind the environment variable XDSSPIFFEEnabled. If not explicitly enabled, the feature is disabled by clearing the config field. This is not malicious but could be used to conditionally activate functionality based on environment, which might be unexpected in a security-sensitive context.

LocalityFromString uses fmt.Sscanf with %q format specifiers to parse locality strings. While not a direct security vulnerability, format-string-based parsing can be fragile and may not handle malformed or adversarial inputs robustly. No direct exploit is evident.

The init() function runs automatically when the package is imported. It registers a callback function via internal.AddressToTelemetryLabels. While this is standard Go practice for package initialization and the assignment itself is benign, it constitutes top-level code execution at import time that modifies global state. In this specific case the callback only returns telemetry labels derived from resolver addresses, but init() functions are a common vector for malicious code and warrant examination.

Imports with blank identifiers (_ "google.golang.org/grpc/balancer/grpclb" and _ "google.golang.org/grpc/xds/googledirectpath") trigger side-effect init() functions in those packages. This is expected gRPC behavior, but blank-import side effects are a common vector for hidden initialization logic.

dialTCPUserTimeout uses syscall.RawConn.Control to set TCP_USER_TIMEOUT via unix.SetsockoptInt, and calls errorLog.Fatalf on error. Uses Fatal inside a Control callback (goroutine context) rather than returning the error, which can terminate the process unexpectedly. Not malicious, but low-level socket manipulation warrants noting.

The client uses insecure.NewCredentials() to connect to the metrics server, meaning the connection is unencrypted. This is a security best-practice concern but not a malicious pattern; it is common in test/interop tooling.

The package is explicitly for gRPC interop testing and uses logger.Fatalf extensively rather than returning errors. If imported and invoked outside a test context, it would terminate the process. Not malicious, but unsafe for production use.

The getServiceAccountJSONKey function reads arbitrary files from the filesystem based on a parameter passed at runtime (serviceAccountKeyFile). It is used to read Google service account JSON keys, which contain private credentials. This is legitimate for interop testing but represents a pattern that reads sensitive credential files from disk.

The package maintains a package-level variable defaultBufferPool that can be arbitrarily reassigned via internal.SetDefaultBufferPool. If an attacker gains control of any dependency that imports this package, they could replace the buffer pool with a malicious implementation (e.g., one that returns buffers containing attacker-controlled data or that exfiltrates data via Put). This is a latent supply-chain risk rather than a direct malicious pattern.

The init() function runs automatically at import time and initializes a default buffer pool. It also registers a callback (internal.SetDefaultBufferPool) that allows replacing the global default buffer pool. While the code itself is not malicious, the init() pattern is a red flag because such hooks can be abused to inject behavior at import time. The SetDefaultBufferPool hook could be repurposed by a malicious package to replace the pool with one that leaks or corrupts data.

The init() function registers a parser with the balancer load subsystem. This is expected behavior for a library that needs to register itself, and the parser only reads metadata to generate load reports locally. There is no network, filesystem, or process activity.

Makes HTTP requests to the GCE metadata server (http://metadata.google.internal) to retrieve instance zone and IPv6 capabilities. While this is a standard GCE metadata call, it could be abused to leak instance metadata if the code were modified by an attacker, though the current usage is legitimate.

Constructs xDS bootstrap configuration dynamically based on environment (GCE detection, metadata, universe domain) and creates a gRPC resolver. This dynamic behavior could be exploited if an attacker can influence the environment, but the code follows expected patterns for the library.