Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
kas persistently disables SSH host key checking for the invoking user when internal SSH key setup is triggered via SSHPRIVATEKEY or SSHPRIVATEKEYFILE and no user-specific SSH configuration file exists so far. When this path is used, kas creates ~/.ssh/config with a global Host rule containing StrictHostKeyChecking no. This was intended to ease the use of kas in short-lived CI environments that lack a pre-configured set of known hosts. In case a local user had no SSH configuration file so far, this approach weakens SSH host authenticity verification beyond the lifetime and scope of the kas command, increasing the risk of successful man-in-the-middle attacks against future SSH connections made by the same user. Patches Such SSH configurations were created since the very first public release. The issue is addressed now by commit <FILLME which is part of kas version 5.4. Workarounds Since kas 2.6.3, a local user's SSH configuration is only written if it didn't exist before. From…
Recommended action: Upgrade to 5.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact So far, kas checks out and processes repositories regarding configuration includes prior to validating signatures of those repositories. This may allow to replace on original repository with one under the control of an attacker under very specific conditions. First of all, the attacker must have gained control of a repository that a kas file of the victim is referencing. Furthermore, the following conditions must be fulfilled: - the victim's kas configuration must include a configuration file from the attacked repository - the repository state is referenced by tag, and no commit ID is specified (this is triggering a warning, though) - the key used for validating the tag or commit signature is stored as file in a repository - no fingerprint for the key is specified - the sourcedir key must not be set by the victim when calling kas (e.g. by avoiding a local .config.yaml) Given these conditions, the attacker could modify the included kas configuration in way that the key used to…
Recommended action: Upgrade to 5.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When relying solely on a git commit ID (SHA-1 or SHA-256) to qualify if a checkout of a repository is equivalent to the state validated while adding its commit ID to a kas configuration, users may be tricked to check out a branch of the same name from this repository. This implies that the referenced repository has been taken over by an attacker and modified to carry such a branch. SHA-1 commits may also be replaced by creating hash collisions, so the primary impact of this issue is on SHA-256 commit IDs. Patches Commit https://github.com/siemens/kas/commit/4cb4a3d01122ffaec9feaae768a5814092f6f9b5 is resolving this issue. It has been released along with kas version 5.3. Workarounds Avoid relying solely on the commit ID for integrity validation of a repository that might become under control of a malicious 3rd party. If available, additional validate cryptographically signed commits or tags. Alternatively, mirror the repository to a save place, validate its integrity, and use…
Recommended action: Upgrade to 5.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.