T09 · Insecure Skill Coding Practices
- Location
handler.py:28- Finding
Hard-Coded Signature Token Bypasses Peer Authentication
- Content
View full analysis
Vulnerability Details
File Location:
handler.py, lines 28–40
Vulnerability Type: Hard-coded authentication token and missing cryptographic verification
Risk Level: HighVulnerable Code
python # 【零信任升级】读取 S2 舰队的根证书或公钥配置 self.fleet_pki_root = os.environ.get("S2_SWARM_PKI_ROOT", "") def _verify_peer_signature(self, peer_state: dict) -> bool: """ 密码学身份校验：拒绝未签名的幽灵广播 实际工程中，这里执行 RSA/ECC 公钥验签 """ signature = peer_state.get("cryptographic_signature", "") if not signature or signature != "VALID_S2_FLEET_SIG": return False return TrueTechnical Analysis
The implementation does not perform cryptographic signature verification. It accepts a peer whenever the caller supplies the publicly visible, hard-coded string
VALID_S2_FLEET_SIG.Although
S2_SWARM_PKI_ROOTis read from the environment, its value is never used to authenticate a signature, validate a certificate chain, or bind a signature to the peer payload. Consequently, the result does not establish payload integrity, peer identity, freshness, or possession of a private key.This behavior contradicts the documented security model in
SKILL.md, which states that peer signatures are verified against the fleet PKI root. Once the constant token is supplied, attacker-controlled fields are processed as authenticated data. These include:center_hex, which determines whether the peer is within the collaboration zone.task_type, which controls right-of-way priority.sensors.radar_scan, which can be copied into federated sensor results.causal_broadcast, which can be inherited as a trusted prediction.
The authentication decision is therefore forgeable without any secret key or fleet certificate.
Attack Path
- An attacker reviews the distributed package or otherwise learns the hard-coded value
VALID_S2_FLEET_SIG. - The attacker constructs a peer state containing that ...[truncated 1768 chars]
- Remediation
View remediation
Remediation Suggestions
- Replace the string comparison with real digital-signature verification using a maintained cryptographic library and an approved algorithm such as Ed25519 or ECDSA with a suitable curve.
- Parse and validate the public key or certificate trust chain supplied through
S2_SWARM_PKI_ROOT. Reject all peer broadcasts if the trust configuration is missing, malformed, expired, revoked, or otherwise invalid. - Define a deterministic canonical serialization for every security-relevant peer field, including identity, coordinates, task type, sensor data, causal predictions, timestamp, and nonce. Verify the signature over that complete canonical payload.
- Bind certificates or public keys to
agent_idso that a valid fleet member cannot claim another member's identity. - Add freshness controls, including signed timestamps, short acceptance windows, unique nonces, and replay caches.
- Validate authenticated payload fields against strict schemas, size limits, numeric ranges, and permitted task types before using them in physical arbitration.
- Do not treat peer-provided task labels as sufficient authorization for elevated right-of-way. Use signed fleet-issued role or task claims and enforce authorization policy separately from identity authentication.
- Introduce an independent fail-safe layer before physical actuation. Authentication failure, malformed input, stale messages, and ambiguous arbitration should result in a safe operational state rather than unconditional trajectory maintenance or attacker-influenced braking.
- Add tests confirming that modified payload fields, unknown identities, replayed messages, invalid certificates, malformed signatures, and the former hard-coded token are rejected.
- Remove the hard-coded acceptance value from the codebase and update the documentation so that its security claims precisely match the implemented verification process.