Common Weakness Enumeration

CWE-665

Discouraged

Improper Initialization

Abstraction: Class · Status: Draft

The product does not initialize or incorrectly initializes a resource, which might leave the resource in an unexpected state when it is accessed or used.

432 vulnerabilities reference this CWE, most recent first.

GHSA-5X29-3HR9-6WPW

Vulnerability from github – Published: 2022-02-11 23:18 – Updated: 2023-08-29 21:08
VLAI
Summary
TPM 1.2 key authorization values vulnerable to TPM transport eavesdropper in go-tpm
Details

Impact

TPM 2.0 users are unaffected by this issue.

An adversary eavesdropping on the TPM 1.2 transport path can calculate usageAuth for a key created with CreateWrapKey, even though this value is encrypted as part of the TPM 1.2 command protocol.

The TPM 1.2 CreateWrapKey command accepts two secrets: usageAuth and migrationAuth. The ADIP protocol (TPM 1.2 specification, part 1, section 13.4) calls for these values to be encrypted with two different XOR keys. Due to a bug in go-tpm prior to version 0.3.0, both usageAuth and migrationAuth are encrypted with the same XOR keystream. This allows an adversary to XOR encUsageAuth and encMigrationAuth together to calculate usageAuth ^ encMigrationAuth. Since migrationAuth is moot for all keys created with go-tpm's CreateWrapKey (since all keys created with this function are marked non-migratable), an adversary may guess or know (from code/binary inspection) that migrationAuth is all 0x00 bytes or some other fixed value. Such an adversary can then calculate usageAuth and use this value later to improperly use the created key, unbeknownst to the creator of the key.

Patches

Fixed in go-tpm version 0.3.0.

Workarounds

  • TPM 2.0 users: No workaround needed. This issue only affects TPM 1.2 users.
  • TPM 1.2 users: Call CreateWrapKey with a random 20-byte value for migrationAuth, even though that value is not used again (since CreateWrapKey creates keys that are non-migratable). Do not store or log this value.

Details

TPM 1.2 uses a protocol called ADIP (Authorization Data Insertion Protocol) to encrypt authorization values over-the-wire for newly created objects. This prevents a bus-snooping attack like those publicized by TPM Genie. TPM 2.0 makes this optional (the way to do it is with parameter-encryption sessions). You can read more about ADIP in section 13.4 of Part 1: Design Principles in the latest TPM 1.2 specification. Normally, ADIP consists of the following steps:

Key := SHA1(authSession.SharedSecret || a nonce)
Note: nonces and auth values in TPM 1.2 are always 20 bytes
EncAuth := XOR(Key, Auth)

When commands require one ADIP-encrypted auth value, the nonce is the last nonceEven (last nonce from the TPM). When commands require two ADIP-encrypted auth values, the nonce for the first auth value is still nonceEven, and the nonce for the second auth value is the last nonceOdd, which is the one being provided by the caller along with the current command on the session. The reason for this is that you wouldn't want an adversary to be able to XOR the two encrypted auth values together and come up with (auth 1 XOR key) XOR (auth 2 XOR key) where the "one-time" pad key is used twice and cancels itself out.

Here are the commands that take one authorization value by ADIP:

  • Seal (the sealed data's auth value)
  • Sealx (the sealed data's auth value)
  • CreateKey (the key's auth value)
  • MakeIdentity (the AIK's auth value)
  • ChangeAuth (the entity's new auth value)
  • ChangeAuthOwner (the new owner auth value)
  • Delegate_CreateKeyDelegation (the new delegation auth value)
  • Delegate_CreateOwnerDelegation (the new delegation auth value)
  • NV_DefineSpace (the NV's auth value)
  • CreateCounter (the counter's auth value)

Here are the commands that take two authorization values by ADIP:

  • CreateWrapKey (the key's auth value, and the key's migration (to export out of the TPM) auth value)

The migrationAuth value is never used if the key does not have the TPM_KEY_FLAGS.migratable flag set on it. go-tpm does not currently allow the caller to set this flag. Here was the bug in our implementation of CreateWrapKey():

https://github.com/google/go-tpm/blob/16766ac4521425bd02ad23868fbdf24749268669/tpm/tpm.go#L1322-L1329

Here we see that both usageAuth and migrationAuth are encrypted by the same XOR key. This is the correct key (i.e., it is based on nonceEven) for usageAuth, but not migrationAuth.

This means 2 things:

First: migrationAuth is being set to some value that is effectively unrelated to migrationAuth as passed by the caller. Again, this is not interesting to all current callers (given that there is no way for them to pass TPM_KEY_FLAGS.migratable via the current API; migrationAuth is not a meaningful value).

Second, and much more importantly: a user of go-tpm is vulnerable to the following attack by a passive bus-snooping adversary (CVE-2020-8918) 1. Wait for a CreateWrapKey command 2. Collect encUsageAuth and encMigrationAuth 3. Calculate (usageAuth XOR migrationAuth) := (encUsageAuth XOR encMigrationAuth) 4. Assuming migrationAuth is all 0x00 (a reasonable assumption for a caller who knows the key is not migratable), the calculation in (3) is the usage auth of the key.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/google/go-tpm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-8918"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-665"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-24T18:32:13Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\nTPM 2.0 users are unaffected by this issue.\n\nAn adversary eavesdropping on the TPM 1.2 transport path can calculate `usageAuth` for a key created with CreateWrapKey, even though this value is encrypted as part of the TPM 1.2 command protocol.\n\nThe TPM 1.2 CreateWrapKey command accepts two secrets: `usageAuth` and `migrationAuth`. The ADIP protocol ([TPM 1.2 specification, part 1, section 13.4](https://trustedcomputinggroup.org/wp-content/uploads/TPM-Main-Part-1-Design-Principles_v1.2_rev116_01032011.pdf)) calls for these values to be encrypted with two different XOR keys. Due to a bug in go-tpm prior to version 0.3.0, both `usageAuth` and `migrationAuth` are encrypted with the same XOR keystream. This allows an adversary to XOR `encUsageAuth` and `encMigrationAuth` together to calculate `usageAuth ^ encMigrationAuth`. Since `migrationAuth` is moot for all keys created with go-tpm\u0027s `CreateWrapKey` (since all keys created with this function are marked non-migratable), an adversary may guess or know (from code/binary inspection) that `migrationAuth` is all 0x00 bytes or some other fixed value. Such an adversary can then calculate `usageAuth` and use this value later to improperly use the created key, unbeknownst to the creator of the key.\n\n### Patches\nFixed in go-tpm version 0.3.0.\n\n### Workarounds\n\n- TPM 2.0 users: No workaround needed. This issue only affects TPM 1.2 users.\n- TPM 1.2 users: Call CreateWrapKey with a random 20-byte value for `migrationAuth`, even though that value is not used again (since CreateWrapKey creates keys that are non-migratable). Do not store or log this value.\n\n\n### Details\n\nTPM 1.2 uses a protocol called ADIP (Authorization Data Insertion Protocol) to encrypt authorization values over-the-wire for newly created objects. This prevents a bus-snooping attack like those publicized by TPM Genie. TPM 2.0 makes this optional (the way to do it is with parameter-encryption sessions). You can read more about ADIP in section 13.4 of Part 1: Design Principles in the latest [TPM 1.2 specification](https://trustedcomputinggroup.org/resource/tpm-main-specification/). Normally, ADIP consists of the following steps:\n```\nKey := SHA1(authSession.SharedSecret || a nonce)\nNote: nonces and auth values in TPM 1.2 are always 20 bytes\nEncAuth := XOR(Key, Auth)\n```\nWhen commands require one ADIP-encrypted auth value, the nonce is the last nonceEven (last nonce from the TPM).\nWhen commands require two ADIP-encrypted auth values, the nonce for the first auth value is still nonceEven, and the nonce for the second auth value is the last nonceOdd, which is the one being provided by the caller along with the current command on the session.\nThe reason for this is that you wouldn\u0027t want an adversary to be able to XOR the two encrypted auth values together and come up with (auth 1 XOR key) XOR (auth 2 XOR key) where the \"one-time\" pad key is used twice and cancels itself out.\n\nHere are the commands that take one authorization value by ADIP:\n\n- Seal (the sealed data\u0027s auth value)\n- Sealx (the sealed data\u0027s auth value)\n- CreateKey (the key\u0027s auth value)\n- MakeIdentity (the AIK\u0027s auth value)\n- ChangeAuth (the entity\u0027s new auth value)\n- ChangeAuthOwner (the new owner auth value)\n- Delegate_CreateKeyDelegation (the new delegation auth value)\n- Delegate_CreateOwnerDelegation (the new delegation auth value)\n- NV_DefineSpace (the NV\u0027s auth value)\n- CreateCounter (the counter\u0027s auth value)\n\nHere are the commands that take two authorization values by ADIP:\n\n- CreateWrapKey (the key\u0027s auth value, and the key\u0027s migration (to export out of the TPM) auth value)\n\nThe migrationAuth value is never used if the key does not have the `TPM_KEY_FLAGS.migratable` flag set on it. go-tpm does not currently allow the caller to set this flag.\nHere was the bug in our implementation of `CreateWrapKey()`:\n\nhttps://github.com/google/go-tpm/blob/16766ac4521425bd02ad23868fbdf24749268669/tpm/tpm.go#L1322-L1329\n\nHere we see that both usageAuth and migrationAuth are encrypted by the same XOR key. This is the correct key (i.e., it is based on nonceEven) for usageAuth, but not migrationAuth.\n\nThis means 2 things:\n\n**First: migrationAuth is being set to some value that is effectively unrelated to migrationAuth as passed by the caller.** Again, this is not interesting to all current callers (given that there is no way for them to pass `TPM_KEY_FLAGS.migratable` via the current API; migrationAuth is not a meaningful value).\n\n**Second, and much more importantly: a user of go-tpm is vulnerable to the following attack by a passive bus-snooping adversary (CVE-2020-8918)**\n1. Wait for a `CreateWrapKey` command\n2. Collect `encUsageAuth` and `encMigrationAuth`\n3. Calculate `(usageAuth XOR migrationAuth) := (encUsageAuth XOR encMigrationAuth)`\n4. Assuming migrationAuth is all 0x00 (a reasonable assumption for a caller who knows the key is not migratable), the calculation in (3) is the usage auth of the key.",
  "id": "GHSA-5x29-3hr9-6wpw",
  "modified": "2023-08-29T21:08:37Z",
  "published": "2022-02-11T23:18:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/google/go-tpm/security/advisories/GHSA-5x29-3hr9-6wpw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8918"
    },
    {
      "type": "WEB",
      "url": "https://github.com/google/go-tpm/pull/195"
    },
    {
      "type": "WEB",
      "url": "https://github.com/google/go-tpm/commit/d7806cce857a1a020190c03348e5361725d8f141"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/google/go-tpm"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2021-0095"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "TPM 1.2 key authorization values vulnerable to TPM transport eavesdropper in go-tpm"
}

GHSA-62PR-J2HQ-8W9P

Vulnerability from github – Published: 2022-05-24 17:44 – Updated: 2022-05-24 17:44
VLAI
Details

In the Titan M chip firmware, there is a possible disclosure of stack memory due to uninitialized data. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-175117965

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-0449"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-665"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-03-10T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In the Titan M chip firmware, there is a possible disclosure of stack memory due to uninitialized data. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-175117965",
  "id": "GHSA-62pr-j2hq-8w9p",
  "modified": "2022-05-24T17:44:09Z",
  "published": "2022-05-24T17:44:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0449"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/pixel/2021-03-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-676X-HFQR-52VW

Vulnerability from github – Published: 2022-05-13 01:26 – Updated: 2022-05-13 01:26
VLAI
Details

Skia, as used in Google Chrome before 16.0.912.77, does not perform all required initialization of values, which allows remote attackers to cause a denial of service or possibly have unspecified other impact via unknown vectors.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2011-3927"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-665"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2012-01-24T04:03:00Z",
    "severity": "HIGH"
  },
  "details": "Skia, as used in Google Chrome before 16.0.912.77, does not perform all required initialization of values, which allows remote attackers to cause a denial of service or possibly have unspecified other impact via unknown vectors.",
  "id": "GHSA-676x-hfqr-52vw",
  "modified": "2022-05-13T01:26:57Z",
  "published": "2022-05-13T01:26:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2011-3927"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A13948"
    },
    {
      "type": "WEB",
      "url": "http://code.google.com/p/chromium/issues/detail?id=108605"
    },
    {
      "type": "WEB",
      "url": "http://googlechromereleases.blogspot.com/2012/01/stable-channel-update_23.html"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/47694"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id?1026569"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-682W-9RVW-QW43

Vulnerability from github – Published: 2023-01-18 18:30 – Updated: 2023-01-26 18:30
VLAI
Details

An issue in MatrixSSL 4.5.1-open and earlier leads to failure to securely check the SessionID field, resulting in the misuse of an all-zero MasterSecret that can decrypt secret data.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-46505"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-665",
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-18T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue in MatrixSSL 4.5.1-open and earlier leads to failure to securely check the SessionID field, resulting in the misuse of an all-zero MasterSecret that can decrypt secret data.",
  "id": "GHSA-682w-9rvw-qw43",
  "modified": "2023-01-26T18:30:47Z",
  "published": "2023-01-18T18:30:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-46505"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SmallTown123/details-for-CVE-2022-46505"
    },
    {
      "type": "WEB",
      "url": "https://smalltown123.notion.site/MatrixSSL-session-resume-bug-a0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6C6R-R3R9-H62J

Vulnerability from github – Published: 2024-02-06 09:31 – Updated: 2024-02-06 09:31
VLAI
Details

An improper initialization vulnerability was found in Galleon. When using Galleon to provision custom EAP or EAP-XP servers, the servers are created unsecured. This issue could allow an attacker to access remote HTTP services available from the server.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-4503"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-665"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-06T09:15:52Z",
    "severity": "MODERATE"
  },
  "details": "An improper initialization vulnerability was found in Galleon. When using Galleon to provision custom EAP or EAP-XP servers, the servers are created unsecured. This issue could allow an attacker to access remote HTTP services available from the server.",
  "id": "GHSA-6c6r-r3r9-h62j",
  "modified": "2024-02-06T09:31:38Z",
  "published": "2024-02-06T09:31:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4503"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:7637"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:7638"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:7639"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:7641"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2023-4503"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2184751"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6FQ2-2MW9-3J26

Vulnerability from github – Published: 2022-05-13 01:23 – Updated: 2022-05-13 01:23
VLAI
Details

drivers/scsi/bfa/bfa_core.c in the Linux kernel before 2.6.35 does not initialize a certain port data structure, which allows local users to cause a denial of service (system crash) via read operations on an fc_host statistics file.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2010-4343"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-665"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2010-12-29T18:00:00Z",
    "severity": "MODERATE"
  },
  "details": "drivers/scsi/bfa/bfa_core.c in the Linux kernel before 2.6.35 does not initialize a certain port data structure, which allows local users to cause a denial of service (system crash) via read operations on an fc_host statistics file.",
  "id": "GHSA-6fq2-2mw9-3j26",
  "modified": "2022-05-13T01:23:33Z",
  "published": "2022-05-13T01:23:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2010-4343"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=661182"
    },
    {
      "type": "WEB",
      "url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git%3Ba=commit%3Bh=7873ca4e4401f0ecd8868bf1543113467e6bae61"
    },
    {
      "type": "WEB",
      "url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7873ca4e4401f0ecd8868bf1543113467e6bae61"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/42884"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/46397"
    },
    {
      "type": "WEB",
      "url": "http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.35"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2010/12/08/3"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2010/12/09/15"
    },
    {
      "type": "WEB",
      "url": "http://www.redhat.com/support/errata/RHSA-2011-0017.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/520102/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/45262"
    },
    {
      "type": "WEB",
      "url": "http://www.spinics.net/lists/linux-scsi/msg43772.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vmware.com/security/advisories/VMSA-2011-0012.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6GFX-CX3G-JX7C

Vulnerability from github – Published: 2024-07-05 09:33 – Updated: 2024-07-08 18:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

media: v4l: async: Properly re-initialise notifier entry in unregister

The notifier_entry of a notifier is not re-initialised after unregistering the notifier. This leads to dangling pointers being left there so use list_del_init() to return the notifier_entry an empty list.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-39485"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-665"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-05T07:15:10Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: v4l: async: Properly re-initialise notifier entry in unregister\n\nThe notifier_entry of a notifier is not re-initialised after unregistering\nthe notifier. This leads to dangling pointers being left there so use\nlist_del_init() to return the notifier_entry an empty list.",
  "id": "GHSA-6gfx-cx3g-jx7c",
  "modified": "2024-07-08T18:31:16Z",
  "published": "2024-07-05T09:33:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39485"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1aa6cd4adfc0380fa1ccc2f146848940ff882a66"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/87100b09246202a91fce4a1562955c32229173bb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9537a8425a7a0222999d5839a0b394b1e8834b4a"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6J77-RPRV-M39J

Vulnerability from github – Published: 2022-05-13 01:42 – Updated: 2022-05-13 01:42
VLAI
Details

Nagios Core before 4.3.3 creates a nagios.lock PID file after dropping privileges to a non-root account, which might allow local users to kill arbitrary processes by leveraging access to this non-root account for nagios.lock modification before a root script executes a "kill cat /pathname/nagios.lock" command.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-12847"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-665"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-08-23T21:29:00Z",
    "severity": "MODERATE"
  },
  "details": "Nagios Core before 4.3.3 creates a nagios.lock PID file after dropping privileges to a non-root account, which might allow local users to kill arbitrary processes by leveraging access to this non-root account for nagios.lock modification before a root script executes a \"kill `cat /pathname/nagios.lock`\" command.",
  "id": "GHSA-6j77-rprv-m39j",
  "modified": "2022-05-13T01:42:46Z",
  "published": "2022-05-13T01:42:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12847"
    },
    {
      "type": "WEB",
      "url": "https://github.com/NagiosEnterprises/nagioscore/issues/404"
    },
    {
      "type": "WEB",
      "url": "https://github.com/NagiosEnterprises/nagioscore/commit/1b197346d490df2e2d3b1dcce5ac6134ad0c8752"
    },
    {
      "type": "WEB",
      "url": "https://github.com/NagiosEnterprises/nagioscore/commit/3baffa78bafebbbdf9f448890ba5a952ea2d73cb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/NagiosEnterprises/nagioscore/blob/master/Changelog"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/201710-20"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/100403"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6JJ2-4Q5C-X8G6

Vulnerability from github – Published: 2026-06-19 20:46 – Updated: 2026-06-19 20:46
VLAI
Summary
CoreWCF NetNamedPipe transport accepts attach to a pre-existing named pipe instance
Details

Impact

CoreWCF NetNamedPipe transport accepts attach to a pre-existing named pipe instance, allowing local interception of NetNamedPipe traffic. NetNamedPipe creates a shared memory object based on the listening url, then generated a unique GUID for the named pipe it will be using and saves this to the shared memory object. Then it creates the named pipe to listen for clients. This requires an attacker to race the service and create the named pipe between the service publishing the GUID to the shared memory location (which the attacker needs to read) and the service creating the named pipe itself.

Patches

Fixed in CoreWCF v1.8.1 and v1.9.1

Workarounds

None

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "CoreWCF.NetNamedPipe"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "CoreWCF.NetNamedPipe"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.9.0"
            },
            {
              "fixed": "1.9.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54777"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367",
      "CWE-665"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T20:46:55Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\nCoreWCF NetNamedPipe transport accepts attach to a pre-existing named pipe instance, allowing local interception of NetNamedPipe traffic. NetNamedPipe creates a shared memory object based on the listening url, then generated a unique GUID for the named pipe it will be using and saves this to the shared memory object. Then it creates the named pipe to listen for clients. This requires an attacker to race the service and create the named pipe between the service publishing the GUID to the shared memory location (which the attacker needs to read) and the service creating the named pipe itself.\n\n### Patches\nFixed in CoreWCF v1.8.1 and v1.9.1\n\n### Workarounds\nNone",
  "id": "GHSA-6jj2-4q5c-x8g6",
  "modified": "2026-06-19T20:46:55Z",
  "published": "2026-06-19T20:46:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/CoreWCF/CoreWCF/security/advisories/GHSA-6jj2-4q5c-x8g6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/CoreWCF/CoreWCF"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "CoreWCF NetNamedPipe transport accepts attach to a pre-existing named pipe instance"
}

GHSA-6MFV-842H-V848

Vulnerability from github – Published: 2022-05-24 17:33 – Updated: 2022-05-24 17:33
VLAI
Details

In rw_i93_sm_format of rw_i93.cc, there is a possible out of bounds read due to uninitialized data. This could lead to remote information disclosure over NFC with no additional execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-8.0 Android-8.1 Android-9 Android-10 Android-11Android ID: A-157650336

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-0450"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-665"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-11-10T13:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In rw_i93_sm_format of rw_i93.cc, there is a possible out of bounds read due to uninitialized data. This could lead to remote information disclosure over NFC with no additional execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-8.0 Android-8.1 Android-9 Android-10 Android-11Android ID: A-157650336",
  "id": "GHSA-6mfv-842h-v848",
  "modified": "2022-05-24T17:33:27Z",
  "published": "2022-05-24T17:33:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-0450"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2020-11-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

Mitigation MIT-3
Requirements

Strategy: Language Selection

  • Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, in Java, if the programmer does not explicitly initialize a variable, then the code could produce a compile-time error (if the variable is local) or automatically initialize the variable to the default value for the variable's type. In Perl, if explicit initialization is not performed, then a default value of undef is assigned, which is interpreted as 0, false, or an equivalent value depending on the context in which the variable is accessed.
Mitigation
Architecture and Design

Identify all variables and data stores that receive information from external sources, and apply input validation to make sure that they are only initialized to expected values.

Mitigation
Implementation

Explicitly initialize all your variables and other data stores, either during declaration or just before the first usage.

Mitigation
Implementation

Pay close attention to complex conditionals that affect initialization, since some conditions might not perform the initialization.

Mitigation
Implementation

Avoid race conditions (CWE-362) during initialization routines.

Mitigation
Build and Compilation

Run or compile your product with settings that generate warnings about uninitialized variables or data.

CAPEC-26: Leveraging Race Conditions

The adversary targets a race condition occurring when multiple processes access and manipulate the same resource concurrently, and the outcome of the execution depends on the particular order in which the access takes place. The adversary can leverage a race condition by "running the race", modifying the resource and modifying the normal execution flow. For instance, a race condition can occur while accessing a file: the adversary can trick the system by replacing the original file with their version and cause the system to read the malicious file.

CAPEC-29: Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions

This attack targets a race condition occurring between the time of check (state) for a resource and the time of use of a resource. A typical example is file access. The adversary can leverage a file access race condition by "running the race", meaning that they would modify the resource between the first time the target program accesses the file and the time the target program uses the file. During that period of time, the adversary could replace or modify the file, causing the application to behave unexpectedly.