)[0-9]{4}\.[0-9]{2}\.[0-9]{2}/\1${{ steps.cdate.outputs.date }}
/" docs/index.md
sed -E -i "s/()/\1v${{ github.event.inputs.version }}\2${{ github.event.inputs.version }}\3/g" docs/index.md
- name: Create pull request
- uses: peter-evans/create-pull-request@v6
+ uses: peter-evans/create-pull-request@c5a7806660adbe173f04e3e038b0ccdcd758773c # v6
with:
title: "docs(kicsbot): preparing for release ${{ github.event.inputs.version }}"
token: ${{ secrets.KICS_BOT_PAT }}
diff --git a/.github/workflows/release-apispec.yml b/.github/workflows/release-apispec.yml
index 0f5af9b1132..d41daa8d666 100644
--- a/.github/workflows/release-apispec.yml
+++ b/.github/workflows/release-apispec.yml
@@ -8,13 +8,13 @@ jobs:
runs-on: ubuntu-latest
steps:
- name: Checkout
- uses: actions/checkout@v3
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
fetch-depth: 0
- name: Set short hash
id: shorthash
run: echo "::set-output name=sha8::$(echo ${GITHUB_SHA} | cut -c1-8)"
- - uses: toko-bifrost/ms-teams-deploy-card@master
+ - uses: toko-bifrost/ms-teams-deploy-card@dcc94e4ce4088b1e6b6de5c9a3cda4ddcbe97d2e # 3.1.2
if: always()
with:
github-token: ${{ secrets.KICS_BOT_PAT }}
@@ -34,9 +34,9 @@ jobs:
- name: Set up Go
uses: actions/setup-go@v5
with:
- go-version: 1.22.x
+ go-version: 1.23.x
- name: Run GoReleaser
- uses: goreleaser/goreleaser-action@v5.1.0
+ uses: goreleaser/goreleaser-action@5742e2a039330cbb23ebf35f046f814d4c6ff811 #v5.1.0
with:
version: v0.160.0
args: release --rm-dist --snapshot --skip-validate --config="./release/.goreleaser-apispec.yml"
@@ -46,7 +46,7 @@ jobs:
DESCRIPTIONS_URL: ${{ secrets.DESCRIPTIONS_URL }}
APISCANNER: "true"
- name: delete release
- uses: dev-drprasad/delete-tag-and-release@v1.0.1
+ uses: dev-drprasad/delete-tag-and-release@82600feb9527126eca69833f07bafe53279bd9b4 # v1.1
with:
delete_release: true # default: false
tag_name: apispec # tag name to delete
@@ -110,8 +110,8 @@ jobs:
runs-on: ubuntu-latest
steps:
- name: Check out the repo
- uses: actions/checkout@v3
- - uses: toko-bifrost/ms-teams-deploy-card@master
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
+ - uses: toko-bifrost/ms-teams-deploy-card@dcc94e4ce4088b1e6b6de5c9a3cda4ddcbe97d2e # 3.1.2
if: always()
with:
github-token: ${{ secrets.KICS_BOT_PAT }}
@@ -129,15 +129,15 @@ jobs:
- name: View HEAD Commit
value: https://github.com/Checkmarx/kics/commit/${{ github.sha }}
- name: Set up Docker Buildx
- uses: docker/setup-buildx-action@v3
+ uses: docker/setup-buildx-action@4fd812986e6c8c2a69e18311145f9371337f27d4 # v3.4.0
- name: Login to DockerHub
- uses: docker/login-action@v2.1.0
+ uses: docker/login-action@0d4c9c5ea7693da7b068278f7b52bda2a190a446 # v3.2.0
with:
username: ${{ secrets.DOCKER_USERNAME }}
password: ${{ secrets.DOCKER_PASSWORD }}
- name: Push alpine to Docker Hub
id: build_alpine
- uses: docker/build-push-action@v4.0.0
+ uses: docker/build-push-action@1ca370b3a9802c92e886402e0dd88098a2533b12 # v6.4.1
with:
context: .
push: true
@@ -150,7 +150,7 @@ jobs:
APISCANNER="true"
- name: Build and push debian to Docker Hub
id: build_debian
- uses: docker/build-push-action@v4.0.0
+ uses: docker/build-push-action@1ca370b3a9802c92e886402e0dd88098a2533b12 # v6.4.1
with:
context: .
file: ./docker/Dockerfile.apispec.debian
@@ -182,7 +182,7 @@ jobs:
pip install csvtomd
csvtomd docs/docker/apispec.csv > docs/docker/apispec.md
- name: Create Pull Request
- uses: peter-evans/create-pull-request@v6
+ uses: peter-evans/create-pull-request@c5a7806660adbe173f04e3e038b0ccdcd758773c # v6
with:
title: "docs(kicsbot): update images digest"
token: ${{ secrets.KICS_BOT_PAT }}
diff --git a/.github/workflows/release-commits.yaml b/.github/workflows/release-commits.yaml
index 2c42bc37d07..af5ef0f9943 100644
--- a/.github/workflows/release-commits.yaml
+++ b/.github/workflows/release-commits.yaml
@@ -11,7 +11,7 @@ jobs:
runs-on: ubuntu-latest
steps:
- name: Checkout Source
- uses: actions/checkout@v4
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
- name: Set up Go
uses: actions/setup-go@v5
with:
diff --git a/.github/workflows/release-dkr-image-for-tag.yml b/.github/workflows/release-dkr-image-for-tag.yml
index 27a7341f648..f1d37aeabff 100644
--- a/.github/workflows/release-dkr-image-for-tag.yml
+++ b/.github/workflows/release-dkr-image-for-tag.yml
@@ -18,10 +18,10 @@ jobs:
DOCKER_CLI_EXPERIMENTAL: "enabled"
steps:
- name: Check out the repo
- uses: actions/checkout@v3
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
ref: ${{ github.event.inputs.tag }}
- - uses: toko-bifrost/ms-teams-deploy-card@master
+ - uses: toko-bifrost/ms-teams-deploy-card@dcc94e4ce4088b1e6b6de5c9a3cda4ddcbe97d2e # 3.1.2
if: always()
with:
github-token: ${{ secrets.KICS_BOT_PAT }}
@@ -57,19 +57,19 @@ jobs:
echo ::set-output name=debian_tags::${DEBIAN_TAGS}
echo ::set-output name=ubi8_tags::${UBI8_TAGS}
- name: Set up QEMU
- uses: docker/setup-qemu-action@v2
+ uses: docker/setup-qemu-action@5927c834f5b4fdf503fca6f4c7eccda82949e1ee # v2
with:
image: tonistiigi/binfmt:latest
platforms: linux/amd64,linux/arm64
- name: Set up Docker Buildx
- uses: docker/setup-buildx-action@v3
+ uses: docker/setup-buildx-action@4fd812986e6c8c2a69e18311145f9371337f27d4 # v3.4.0
- name: Login to DockerHub
- uses: docker/login-action@v2.1.0
+ uses: docker/login-action@0d4c9c5ea7693da7b068278f7b52bda2a190a446 # v3.2.0
with:
username: ${{ secrets.DOCKER_USERNAME }}
password: ${{ secrets.DOCKER_PASSWORD }}
- name: Push alpine to Docker Hub
- uses: docker/build-push-action@v4.0.0
+ uses: docker/build-push-action@1ca370b3a9802c92e886402e0dd88098a2533b12 # v6.4.1
with:
context: .
push: true
@@ -83,7 +83,7 @@ jobs:
- name: Push debian to Docker Hub
if: ${{ hashFiles('./docker/Dockerfile.debian') }} != ""
id: build_debian
- uses: docker/build-push-action@v4.0.0
+ uses: docker/build-push-action@1ca370b3a9802c92e886402e0dd88098a2533b12 # v6.4.1
with:
context: .
file: ./docker/Dockerfile.debian
@@ -98,7 +98,7 @@ jobs:
- name: Push ubi8 to Docker Hub
if: ${{ hashFiles('./docker/Dockerfile.ubi8') }} != ""
id: build_ubi8
- uses: docker/build-push-action@v4.0.0
+ uses: docker/build-push-action@1ca370b3a9802c92e886402e0dd88098a2533b12 # v6.4.1
with:
context: .
file: ./docker/Dockerfile.ubi8
diff --git a/.github/workflows/release-dkr-image.yml b/.github/workflows/release-dkr-image.yml
index 2258072fff0..35117f4cbb2 100644
--- a/.github/workflows/release-dkr-image.yml
+++ b/.github/workflows/release-dkr-image.yml
@@ -14,14 +14,14 @@ jobs:
DOCKER_CLI_EXPERIMENTAL: "enabled"
steps:
- name: Check out the repo
- uses: actions/checkout@v3
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
fetch-depth: 0
- name: Get Release version
id: get-version
run: |
echo "::set-output name=version::$(git describe --match='v*' --tags --abbrev=0)"
- - uses: toko-bifrost/ms-teams-deploy-card@master
+ - uses: toko-bifrost/ms-teams-deploy-card@dcc94e4ce4088b1e6b6de5c9a3cda4ddcbe97d2e # 3.1.2
if: always()
with:
github-token: ${{ secrets.KICS_BOT_PAT }}
@@ -36,19 +36,19 @@ jobs:
- name: View HEAD Commit
value: https://github.com/Checkmarx/kics/commit/${{ github.sha }}
- name: Set up QEMU
- uses: docker/setup-qemu-action@v2
+ uses: docker/setup-qemu-action@5927c834f5b4fdf503fca6f4c7eccda82949e1ee # v2
with:
image: tonistiigi/binfmt:latest
platforms: linux/amd64,linux/arm64
- name: Set up Docker Buildx
- uses: docker/setup-buildx-action@v3
+ uses: docker/setup-buildx-action@4fd812986e6c8c2a69e18311145f9371337f27d4 # v3.4.0
- name: Login to DockerHub
- uses: docker/login-action@v2.1.0
+ uses: docker/login-action@0d4c9c5ea7693da7b068278f7b52bda2a190a446 # v3.2.0
with:
username: ${{ secrets.DOCKER_USERNAME }}
password: ${{ secrets.DOCKER_PASSWORD }}
- name: Push alpine to Docker Hub
- uses: docker/build-push-action@v4.0.0
+ uses: docker/build-push-action@1ca370b3a9802c92e886402e0dd88098a2533b12 # v6.4.1
id: build_alpine
with:
context: .
@@ -62,7 +62,7 @@ jobs:
DESCRIPTIONS_URL=${{ secrets.DESCRIPTIONS_URL }}
- name: Build and push debian to Docker Hub
id: build_debian
- uses: docker/build-push-action@v4.0.0
+ uses: docker/build-push-action@1ca370b3a9802c92e886402e0dd88098a2533b12 # v6.4.1
with:
context: .
file: ./docker/Dockerfile.debian
@@ -76,7 +76,7 @@ jobs:
DESCRIPTIONS_URL=${{ secrets.DESCRIPTIONS_URL }}
- name: Build and push ubi8 to Docker Hub
id: build_ubi8
- uses: docker/build-push-action@v4.0.0
+ uses: docker/build-push-action@1ca370b3a9802c92e886402e0dd88098a2533b12 # v6.4.1
with:
context: .
file: ./docker/Dockerfile.ubi8
diff --git a/.github/workflows/release-docker-github-actions.yaml b/.github/workflows/release-docker-github-actions.yaml
index 4b0b4f2d3cd..cb2b87d578a 100644
--- a/.github/workflows/release-docker-github-actions.yaml
+++ b/.github/workflows/release-docker-github-actions.yaml
@@ -13,27 +13,27 @@ jobs:
runs-on: ubuntu-latest
steps:
- name: Check out the repo
- uses: actions/checkout@v4
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
fetch-depth: 0
- name: Check out the tag
- uses: actions/checkout@v4
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
ref: ${{ github.event.inputs.version }}
- name: Set up QEMU
- uses: docker/setup-qemu-action@v2
+ uses: docker/setup-qemu-action@5927c834f5b4fdf503fca6f4c7eccda82949e1ee # v2
with:
image: tonistiigi/binfmt:latest
platforms: linux/amd64,linux/arm64
- name: Set up Docker Buildx
- uses: docker/setup-buildx-action@v3
+ uses: docker/setup-buildx-action@4fd812986e6c8c2a69e18311145f9371337f27d4 # v3.4.0
- name: Login to DockerHub
- uses: docker/login-action@v2.1.0
+ uses: docker/login-action@0d4c9c5ea7693da7b068278f7b52bda2a190a446 # v3.2.0
with:
username: ${{ secrets.DOCKER_USERNAME }}
password: ${{ secrets.DOCKER_PASSWORD }}
- name: Push Github Action Image to Docker Hub
- uses: docker/build-push-action@v5.0.0
+ uses: docker/build-push-action@1ca370b3a9802c92e886402e0dd88098a2533b12 # v6.4.1
id: build_gh_action
with:
context: .
@@ -46,11 +46,11 @@ jobs:
SENTRY_DSN=${{ secrets.SENTRY_DSN }}
DESCRIPTIONS_URL=${{ secrets.DESCRIPTIONS_URL }}
- name: Check out the repo
- uses: actions/checkout@v4
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
fetch-depth: 0
- name: Create Pull Request
- uses: peter-evans/create-pull-request@v6
+ uses: peter-evans/create-pull-request@c5a7806660adbe173f04e3e038b0ccdcd758773c # v6
with:
title: "docs(kicsbot): update images digest"
token: ${{ secrets.KICS_BOT_PAT }}
diff --git a/.github/workflows/release-extract-info.yaml b/.github/workflows/release-extract-info.yaml
index 92c1c7e770b..92ad3d2caaa 100644
--- a/.github/workflows/release-extract-info.yaml
+++ b/.github/workflows/release-extract-info.yaml
@@ -9,7 +9,7 @@ jobs:
runs-on: ubuntu-latest
steps:
- name: Checkout Source
- uses: actions/checkout@v4
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
- uses: actions/setup-python@v4
with:
python-version: "3.x"
@@ -19,7 +19,7 @@ jobs:
pip3 install -r .github/scripts/extract-kics-info/requirements.txt
python3 .github/scripts/extract-kics-info/extract-info.py
- name: Upload binaries to release
- uses: svenstaro/upload-release-action@v2
+ uses: svenstaro/upload-release-action@04733e069f2d7f7f0b4aebc4fbdbce8613b03ccd # v2.9.0
with:
repo_token: ${{ secrets.GITHUB_TOKEN }}
file: .github/scripts/extract-kics-info/extracted-info.zip
diff --git a/.github/workflows/release-kics-queries-repo-branch.yaml b/.github/workflows/release-kics-queries-repo-branch.yaml
index fb182686291..07a11e75d71 100644
--- a/.github/workflows/release-kics-queries-repo-branch.yaml
+++ b/.github/workflows/release-kics-queries-repo-branch.yaml
@@ -10,7 +10,7 @@ jobs:
REPO_NAME: "kics-queries-repo"
steps:
- name: Checkout code
- uses: actions/checkout@v4
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
- name: Set up Git credentials
run: |
diff --git a/.github/workflows/release-nightly.yml b/.github/workflows/release-nightly.yml
index 7d944281945..013fdab20a7 100644
--- a/.github/workflows/release-nightly.yml
+++ b/.github/workflows/release-nightly.yml
@@ -13,7 +13,7 @@ jobs:
sha8: ${{ steps.shorthash.outputs.sha8 }}
steps:
- name: Checkout
- uses: actions/checkout@v3
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
fetch-depth: 0
- name: Check if there are new commits since last nightly
@@ -28,10 +28,10 @@ jobs:
runs-on: ubuntu-latest
steps:
- name: Checkout
- uses: actions/checkout@v3
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
fetch-depth: 0
- - uses: toko-bifrost/ms-teams-deploy-card@master
+ - uses: toko-bifrost/ms-teams-deploy-card@dcc94e4ce4088b1e6b6de5c9a3cda4ddcbe97d2e # 3.1.2
if: always()
with:
github-token: ${{ secrets.KICS_BOT_PAT }}
@@ -51,9 +51,9 @@ jobs:
- name: Set up Go
uses: actions/setup-go@v5
with:
- go-version: 1.22.x
+ go-version: 1.23.x
- name: Run GoReleaser
- uses: goreleaser/goreleaser-action@v5.1.0
+ uses: goreleaser/goreleaser-action@5742e2a039330cbb23ebf35f046f814d4c6ff811 # v5.1.0
with:
version: v0.160.0
args: release --rm-dist --snapshot --skip-validate --config="./release/.goreleaser-nightly.yml"
@@ -62,7 +62,7 @@ jobs:
SENTRY_DSN: ${{ secrets.SENTRY_DSN }}
DESCRIPTIONS_URL: ${{ secrets.DESCRIPTIONS_URL }}
- name: delete release
- uses: dev-drprasad/delete-tag-and-release@v1.0.1
+ uses: dev-drprasad/delete-tag-and-release@82600feb9527126eca69833f07bafe53279bd9b4 # v1.1
with:
delete_release: true # default: false
tag_name: nightly # tag name to delete
@@ -128,8 +128,8 @@ jobs:
runs-on: ubuntu-latest
steps:
- name: Check out the repo
- uses: actions/checkout@v3
- - uses: toko-bifrost/ms-teams-deploy-card@master
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
+ - uses: toko-bifrost/ms-teams-deploy-card@dcc94e4ce4088b1e6b6de5c9a3cda4ddcbe97d2e # 3.1.2
if: always()
with:
github-token: ${{ secrets.KICS_BOT_PAT }}
@@ -147,20 +147,20 @@ jobs:
- name: View HEAD Commit
value: https://github.com/Checkmarx/kics/commit/${{ github.sha }}
- name: Set up QEMU
- uses: docker/setup-qemu-action@v2
+ uses: docker/setup-qemu-action@5927c834f5b4fdf503fca6f4c7eccda82949e1ee # v2
with:
image: tonistiigi/binfmt:latest
platforms: linux/amd64,linux/arm64
- name: Set up Docker Buildx
- uses: docker/setup-buildx-action@v3
+ uses: docker/setup-buildx-action@4fd812986e6c8c2a69e18311145f9371337f27d4 # v3.4.0
- name: Login to DockerHub
- uses: docker/login-action@v2.1.0
+ uses: docker/login-action@0d4c9c5ea7693da7b068278f7b52bda2a190a446 # v3.2.0
with:
username: ${{ secrets.DOCKER_USERNAME }}
password: ${{ secrets.DOCKER_PASSWORD }}
- name: Push alpine to Docker Hub
id: build_alpine
- uses: docker/build-push-action@v4.0.0
+ uses: docker/build-push-action@1ca370b3a9802c92e886402e0dd88098a2533b12 # v6.4.1
with:
context: .
push: true
@@ -172,7 +172,7 @@ jobs:
DESCRIPTIONS_URL=${{ secrets.DESCRIPTIONS_URL }}
- name: Build and push debian to Docker Hub
id: build_debian
- uses: docker/build-push-action@v4.0.0
+ uses: docker/build-push-action@1ca370b3a9802c92e886402e0dd88098a2533b12 # v6.4.1
with:
context: .
file: ./docker/Dockerfile.debian
@@ -185,7 +185,7 @@ jobs:
DESCRIPTIONS_URL=${{ secrets.DESCRIPTIONS_URL }}
- name: Build and push ubi8 to Docker Hub
id: build_ubi8
- uses: docker/build-push-action@v4.0.0
+ uses: docker/build-push-action@1ca370b3a9802c92e886402e0dd88098a2533b12 # v6.4.1
with:
context: .
file: ./docker/Dockerfile.ubi8
@@ -197,7 +197,7 @@ jobs:
COMMIT=${{ github.sha }}
DESCRIPTIONS_URL=${{ secrets.DESCRIPTIONS_URL }}
- name: Create Pull Request
- uses: peter-evans/create-pull-request@v6
+ uses: peter-evans/create-pull-request@c5a7806660adbe173f04e3e038b0ccdcd758773c # v6
with:
title: "docs(kicsbot): update images digest"
token: ${{ secrets.KICS_BOT_PAT }}
diff --git a/.github/workflows/sec-checks.yaml b/.github/workflows/sec-checks.yaml
index 6e1f1aa13d9..3ccf3e5c4db 100644
--- a/.github/workflows/sec-checks.yaml
+++ b/.github/workflows/sec-checks.yaml
@@ -10,9 +10,9 @@ jobs:
runs-on: ubuntu-latest
steps:
- name: Checkout code
- uses: actions/checkout@v4
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
- name: Run Trivy vulnerability scanner in repo mode
- uses: aquasecurity/trivy-action@master
+ uses: aquasecurity/trivy-action@6e7b7d1fd3e4fef0c5fa8cce1229c54b2c9bd0d8 #v 0.24.0
with:
scan-type: 'fs'
ignore-unfixed: true
@@ -26,7 +26,7 @@ jobs:
run: cat ./results.txt
- name: Upload artifact
if: always()
- uses: actions/upload-artifact@v4
+ uses: actions/upload-artifact@0b2256b8c012f0828dc542b3febcab082c67f72b # v4
with:
name: trivy-fs-scan-results
path: ./results.txt
@@ -39,12 +39,12 @@ jobs:
kics-docker: [ "Dockerfile" ]
steps:
- name: Checkout code
- uses: actions/checkout@v4
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
- name: Set up Docker Buildx
- uses: docker/setup-buildx-action@v3
+ uses: docker/setup-buildx-action@4fd812986e6c8c2a69e18311145f9371337f27d4 # v3.4.0
- name: Build
id: docker_build
- uses: docker/build-push-action@v5
+ uses: docker/build-push-action@1ca370b3a9802c92e886402e0dd88098a2533b12 # v6.4.1
with:
load: true
context: ./
@@ -58,7 +58,7 @@ jobs:
cache-from: type=local,src=/tmp/.buildx-cache
cache-to: type=local,dest=/tmp/.buildx-cache
- name: Run Trivy vulnerability scanner
- uses: aquasecurity/trivy-action@master
+ uses: aquasecurity/trivy-action@6e7b7d1fd3e4fef0c5fa8cce1229c54b2c9bd0d8 #v 0.24.0
with:
image-ref: kics:sec-trivy-tests-${{ github.sha }}
ignore-unfixed: true
@@ -74,7 +74,7 @@ jobs:
run: cat ./results.txt
- name: Upload artifact
if: always()
- uses: actions/upload-artifact@v4
+ uses: actions/upload-artifact@0b2256b8c012f0828dc542b3febcab082c67f72b # v4
with:
name: trivy-docker-image-scan-results
path: ./results.txt
@@ -83,10 +83,10 @@ jobs:
runs-on: ubuntu-latest
steps:
- name: Checkout code
- uses: actions/checkout@v4
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
- name: Run Grype vulnerability scanner in repo mode
id: grype-fs-scan
- uses: anchore/scan-action@v3
+ uses: anchore/scan-action@d43cc1dfea6a99ed123bf8f3133f1797c9b44492 # v4.1.0
with:
path: "."
only-fixed: true
@@ -102,14 +102,14 @@ jobs:
kics-docker: [ "Dockerfile" ]
steps:
- name: Check out code
- uses: actions/checkout@v4
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
persist-credentials: false
- name: Set up Docker Buildx
- uses: docker/setup-buildx-action@v3
+ uses: docker/setup-buildx-action@4fd812986e6c8c2a69e18311145f9371337f27d4 # v3.4.0
- name: Build
id: docker_build
- uses: docker/build-push-action@v5
+ uses: docker/build-push-action@1ca370b3a9802c92e886402e0dd88098a2533b12 # v6.4.1
with:
load: true
context: ./
@@ -124,7 +124,7 @@ jobs:
cache-to: type=local,dest=/tmp/.buildx-cache
- name: Scan image
id: grype-image-scan
- uses: anchore/scan-action@v3
+ uses: anchore/scan-action@d43cc1dfea6a99ed123bf8f3133f1797c9b44492 # v4.1.0
with:
image: kics:sec-tests-${{ github.sha }}
only-fixed: true
@@ -136,7 +136,7 @@ jobs:
name: govulncheck fs scan
steps:
- name: Checkout code
- uses: actions/checkout@v4
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
- uses: actions/setup-go@v5
with:
go-version-file: go.mod
@@ -151,7 +151,7 @@ jobs:
run: cat ./results.txt
- name: Upload artifact
if: always()
- uses: actions/upload-artifact@v4
+ uses: actions/upload-artifact@0b2256b8c012f0828dc542b3febcab082c67f72b # v4
with:
name: govulncheck-fs-scan-results
path: ./results.txt
@@ -160,7 +160,7 @@ jobs:
name: govulncheck binary scan
steps:
- name: Checkout code
- uses: actions/checkout@v4
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
- uses: actions/setup-go@v5
with:
go-version-file: go.mod
@@ -177,7 +177,7 @@ jobs:
run: cat ./results.txt
- name: Upload artifact
if: always()
- uses: actions/upload-artifact@v4
+ uses: actions/upload-artifact@0b2256b8c012f0828dc542b3febcab082c67f72b # v4
with:
name: govulncheck-binary-scan-results
path: ./results.txt
diff --git a/.github/workflows/sonarcloud-scan-branch.yml b/.github/workflows/sonarcloud-scan-branch.yml
index 3fe7367184a..b11cded25dd 100644
--- a/.github/workflows/sonarcloud-scan-branch.yml
+++ b/.github/workflows/sonarcloud-scan-branch.yml
@@ -13,7 +13,7 @@ jobs:
runs-on: ubuntu-latest
steps:
- name: Check out the repo
- uses: actions/checkout@v3
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
ref: ${{ github.event.inputs.branch }}
- name: SonarCloud Scan
diff --git a/.github/workflows/sonarcloud.yml b/.github/workflows/sonarcloud.yml
index d2fb7f3c6ea..8bae714aa67 100644
--- a/.github/workflows/sonarcloud.yml
+++ b/.github/workflows/sonarcloud.yml
@@ -10,7 +10,7 @@ jobs:
runs-on: ubuntu-latest
if: github.repository == 'Checkmarx/kics'
steps:
- - uses: actions/checkout@v3
+ - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
fetch-depth: 0 # Shallow clones should be disabled for a better relevancy of analysis
- name: SonarCloud Scan
diff --git a/.github/workflows/statistics.yaml b/.github/workflows/statistics.yaml
index 8e368d59738..c55f4f08a59 100644
--- a/.github/workflows/statistics.yaml
+++ b/.github/workflows/statistics.yaml
@@ -10,7 +10,7 @@ jobs:
runs-on: ubuntu-latest
steps:
- name: Checkout Source
- uses: actions/checkout@v4
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
- name: Set up Go
uses: actions/setup-go@v5
with:
diff --git a/.github/workflows/update-docs-queries.yaml b/.github/workflows/update-docs-queries.yaml
index 9e399b1af31..d2b67739b0c 100644
--- a/.github/workflows/update-docs-queries.yaml
+++ b/.github/workflows/update-docs-queries.yaml
@@ -15,10 +15,10 @@ jobs:
runs-on: ubuntu-latest
steps:
- name: Cancel Previous Runs
- uses: styfle/cancel-workflow-action@0.12.1
+ uses: styfle/cancel-workflow-action@85880fa0301c86cca9da44039ee3bb12d3bedbfa # 0.12.1
with:
access_token: ${{ github.token }}
- - uses: actions/checkout@v4
+ - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
fetch-depth: 0
- uses: actions/setup-python@v4
@@ -39,7 +39,7 @@ jobs:
--t .github/scripts/docs-generator/query-page-generator/templates/query-page-template.md \
--df
- name: Create Pull Request
- uses: peter-evans/create-pull-request@v6
+ uses: peter-evans/create-pull-request@c5a7806660adbe173f04e3e038b0ccdcd758773c # v6
with:
title: "docs(queries): update queries catalog"
token: ${{ secrets.KICS_BOT_PAT }}
diff --git a/.github/workflows/update-docs-release.yaml b/.github/workflows/update-docs-release.yaml
index 7584535f67c..6d29839d747 100644
--- a/.github/workflows/update-docs-release.yaml
+++ b/.github/workflows/update-docs-release.yaml
@@ -12,11 +12,11 @@ jobs:
if: "!github.event.release.prerelease"
steps:
- name: Cancel Previous Runs
- uses: styfle/cancel-workflow-action@0.12.1
+ uses: styfle/cancel-workflow-action@85880fa0301c86cca9da44039ee3bb12d3bedbfa # 0.12.1
with:
access_token: ${{ github.token }}
- name: Checkout project
- uses: actions/checkout@v4
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
fetch-depth: 0
- name: Get release version
diff --git a/.github/workflows/update-infra-version.yaml b/.github/workflows/update-infra-version.yaml
index 45ce738072a..4c326723947 100644
--- a/.github/workflows/update-infra-version.yaml
+++ b/.github/workflows/update-infra-version.yaml
@@ -12,17 +12,17 @@ jobs:
if: "!github.event.release.prerelease"
steps:
- name: Checkout project
- uses: actions/checkout@v4
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
fetch-depth: 0
- name: Update Terraform Cloud Integration
- uses: peter-evans/repository-dispatch@v3
+ uses: peter-evans/repository-dispatch@ff45666b9427631e3450c54a1bcbee4d9ff4d7c0 # v3
with:
token: ${{ secrets.KICS_BOT_PAT }}
repository: ${{ secrets.TFC_REPO_PATH }}
event-type: new-release
- name: Update Infra
- uses: peter-evans/repository-dispatch@v3
+ uses: peter-evans/repository-dispatch@ff45666b9427631e3450c54a1bcbee4d9ff4d7c0 # v3
with:
token: ${{ secrets.KICS_BOT_PAT }}
repository: ${{ secrets.INFRA_REPO }}
diff --git a/.github/workflows/update-install-script.yaml b/.github/workflows/update-install-script.yaml
index 27c0f0ba8b0..6cf07c15285 100644
--- a/.github/workflows/update-install-script.yaml
+++ b/.github/workflows/update-install-script.yaml
@@ -9,11 +9,11 @@ jobs:
runs-on: ubuntu-latest
steps:
- name: Cancel Previous Runs
- uses: styfle/cancel-workflow-action@0.12.1
+ uses: styfle/cancel-workflow-action@85880fa0301c86cca9da44039ee3bb12d3bedbfa # 0.12.1
with:
access_token: ${{ github.token }}
- name: Checkout project
- uses: actions/checkout@v4
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
fetch-depth: 0
- name: Get Godownloader
@@ -50,7 +50,7 @@ jobs:
- name: Update install.sh
run: ./.bin/godownloader --repo Checkmarx/kics <(echo ${{ steps.outputs.filter.goreleaser }}) > install.sh
- name: Create Pull Request
- uses: peter-evans/create-pull-request@v6
+ uses: peter-evans/create-pull-request@c5a7806660adbe173f04e3e038b0ccdcd758773c # v6
with:
title: "chore(install): update install script"
token: ${{ secrets.KICS_BOT_PAT }}
diff --git a/.github/workflows/update_software_versions.yml b/.github/workflows/update_software_versions.yml
index a5967602884..d2927911894 100644
--- a/.github/workflows/update_software_versions.yml
+++ b/.github/workflows/update_software_versions.yml
@@ -7,7 +7,7 @@ jobs:
runs-on: ubuntu-latest
steps:
- name: Checkout project
- uses: actions/checkout@v3
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
fetch-depth: 0
- uses: actions/setup-python@v4
@@ -18,14 +18,14 @@ jobs:
pip3 install -r .github/scripts/update_versions/requirements.txt
python3 .github/scripts/update_versions/update.py
- name: Verify Changed files
- uses: tj-actions/verify-changed-files@v17
+ uses: tj-actions/verify-changed-files@6ed7632824d235029086612d4330d659005af687 # v20.0.1
id: verify-changed-files
with:
files: |
*.json
- name: Create pull request
if: steps.verify-changed-files.outputs.files_changed == 'true'
- uses: peter-evans/create-pull-request@v6
+ uses: peter-evans/create-pull-request@c5a7806660adbe173f04e3e038b0ccdcd758773c # v6
with:
title: "build(deps): updating software versions"
token: ${{ secrets.KICS_BOT_PAT }}
diff --git a/.github/workflows/validate-ansible-samples.yml b/.github/workflows/validate-ansible-samples.yml
index b80221b61a6..731f06cc1b1 100644
--- a/.github/workflows/validate-ansible-samples.yml
+++ b/.github/workflows/validate-ansible-samples.yml
@@ -11,11 +11,11 @@ jobs:
lint-samples:
runs-on: ubuntu-latest
steps:
- - uses: actions/checkout@v3
+ - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
persist-credentials: false
- name: yaml-lint
- uses: ibiqlik/action-yamllint@v3.1
+ uses: ibiqlik/action-yamllint@2576378a8e339169678f9939646ee3ee325e845c # v3.1
with:
file_or_dir: assets/queries/ansible/
config_file: .github/scripts/samples-linters/yamllint_ansible.yml
diff --git a/.github/workflows/validate-arm-samples.yaml b/.github/workflows/validate-arm-samples.yaml
index ca579eb48cc..04e8572a4bd 100644
--- a/.github/workflows/validate-arm-samples.yaml
+++ b/.github/workflows/validate-arm-samples.yaml
@@ -9,7 +9,7 @@ jobs:
lint-json-samples:
runs-on: ubuntu-latest
steps:
- - uses: actions/checkout@v4
+ - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
persist-credentials: false
- uses: actions/setup-node@v4
diff --git a/.github/workflows/validate-cfn-samples.yml b/.github/workflows/validate-cfn-samples.yml
index b53a4c24ba4..1fb389993d1 100644
--- a/.github/workflows/validate-cfn-samples.yml
+++ b/.github/workflows/validate-cfn-samples.yml
@@ -11,7 +11,7 @@ jobs:
validate-cfn-syntax:
runs-on: ubuntu-latest
steps:
- - uses: actions/checkout@v3
+ - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
persist-credentials: false
- uses: actions/setup-python@v4
@@ -19,7 +19,7 @@ jobs:
python-version: '3.x'
- name: Get commit changed files
if: github.event_name != 'workflow_dispatch'
- uses: lots0logs/gh-action-get-changed-files@2.2.2
+ uses: lots0logs/gh-action-get-changed-files@6cb5164a823dbf3318b7c8032a333b4b7ed425b2 # 2.2.2
with:
token: ${{ secrets.GITHUB_TOKEN }}
- name: Get cfn-python-lint
diff --git a/.github/workflows/validate-dkr-samples.yml b/.github/workflows/validate-dkr-samples.yml
index 5d336d6c2e2..9fc0ec9fa4d 100644
--- a/.github/workflows/validate-dkr-samples.yml
+++ b/.github/workflows/validate-dkr-samples.yml
@@ -9,7 +9,7 @@ jobs:
validate-dockerfile-syntax:
runs-on: ubuntu-latest
steps:
- - uses: actions/checkout@v3
+ - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
persist-credentials: false
- name: Get Hadolint
diff --git a/.github/workflows/validate-issues.yaml b/.github/workflows/validate-issues.yaml
index 1d908f6c8c0..1009b33e03e 100644
--- a/.github/workflows/validate-issues.yaml
+++ b/.github/workflows/validate-issues.yaml
@@ -10,7 +10,7 @@ jobs:
TITLE: ${{ github.event.issue.title }}
steps:
- name: Checkout code
- uses: actions/checkout@v4
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
persist-credentials: false
sparse-checkout: |
@@ -69,7 +69,7 @@ jobs:
TITLE: ${{ github.event.issue.title }}
steps:
- name: Checkout code
- uses: actions/checkout@v4
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
persist-credentials: false
sparse-checkout: |
diff --git a/.github/workflows/validate-k8s-samples.yml b/.github/workflows/validate-k8s-samples.yml
index 2147fe7db33..fa50679aab3 100644
--- a/.github/workflows/validate-k8s-samples.yml
+++ b/.github/workflows/validate-k8s-samples.yml
@@ -10,7 +10,7 @@ jobs:
validate-k8s-manifests:
runs-on: ubuntu-latest
steps:
- - uses: actions/checkout@v3
+ - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
persist-credentials: false
- name: Get Kubeval
diff --git a/.github/workflows/validate-openapi-samples.yaml b/.github/workflows/validate-openapi-samples.yaml
index 9abc2d66d50..1ea95ee78df 100644
--- a/.github/workflows/validate-openapi-samples.yaml
+++ b/.github/workflows/validate-openapi-samples.yaml
@@ -10,11 +10,11 @@ jobs:
lint-yaml-samples:
runs-on: ubuntu-latest
steps:
- - uses: actions/checkout@v4
+ - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
persist-credentials: false
- name: yaml-lint
- uses: ibiqlik/action-yamllint@v3.1
+ uses: ibiqlik/action-yamllint@2576378a8e339169678f9939646ee3ee325e845c # v3.1
with:
file_or_dir: assets/queries/openAPI/
config_file: .github/scripts/samples-linters/yamllint.yml
@@ -22,7 +22,7 @@ jobs:
lint-json-samples:
runs-on: ubuntu-latest
steps:
- - uses: actions/checkout@v4
+ - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
persist-credentials: false
- uses: actions/setup-node@v4
diff --git a/.github/workflows/validate-prs.yaml b/.github/workflows/validate-prs.yaml
index 11a8672115d..670b431baec 100644
--- a/.github/workflows/validate-prs.yaml
+++ b/.github/workflows/validate-prs.yaml
@@ -12,7 +12,7 @@ jobs:
TITLE: ${{ github.event.pull_request.title }}
steps:
- name: Checkout code
- uses: actions/checkout@v4
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
persist-credentials: false
sparse-checkout: |
@@ -73,7 +73,7 @@ jobs:
TITLE: ${{ github.event.pull_request.title }}
steps:
- name: Checkout code
- uses: actions/checkout@v4
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
persist-credentials: false
sparse-checkout: |
diff --git a/.github/workflows/validate-queries-metadata.yml b/.github/workflows/validate-queries-metadata.yml
index 894db054e18..7f7256a11fa 100644
--- a/.github/workflows/validate-queries-metadata.yml
+++ b/.github/workflows/validate-queries-metadata.yml
@@ -9,7 +9,7 @@ jobs:
validate-metadata:
runs-on: ubuntu-latest
steps:
- - uses: actions/checkout@v3
+ - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
persist-credentials: false
- name: Run queries metadata validation script
diff --git a/.github/workflows/validate-tf-samples.yml b/.github/workflows/validate-tf-samples.yml
index b997571e5dd..fe24220ef65 100644
--- a/.github/workflows/validate-tf-samples.yml
+++ b/.github/workflows/validate-tf-samples.yml
@@ -9,7 +9,7 @@ jobs:
lint-samples:
runs-on: ubuntu-latest
steps:
- - uses: actions/checkout@v3
+ - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
persist-credentials: false
- name: Get tflint
diff --git a/.golangci.yml b/.golangci.yml
index 913f6ab6f21..51266a830a3 100644
--- a/.golangci.yml
+++ b/.golangci.yml
@@ -49,7 +49,7 @@ linters-settings:
- strings.SplitN
govet:
- check-shadowing: true
+ shadow: true
settings:
printf:
funcs:
@@ -71,7 +71,6 @@ linters:
disable-all: true
enable:
- bodyclose
- - deadcode
- depguard
- dogsled
- dupl
@@ -96,13 +95,11 @@ linters:
- noctx
- nolintlint
- staticcheck
- - structcheck
- stylecheck
- typecheck
- unconvert
- unparam
- unused
- - varcheck
- whitespace
# don't enable:
@@ -128,13 +125,12 @@ issues:
linters:
- gomnd
- scopelint
-
-run:
- timeout: 5m
- tests: false
- skip-dirs:
+ exclude-dirs:
- assets
- docs
- vendor
- pkg/parser/jsonfilter/parser
- - pkg/parser/bicep/antlr
+ - pkg/parser/bicep/antlr
+run:
+ timeout: 5m
+ tests: false
diff --git a/.grype.yaml b/.grype.yaml
index 0db478fb086..1e526650ca5 100644
--- a/.grype.yaml
+++ b/.grype.yaml
@@ -1,5 +1,4 @@
ignore:
- - vulnerability: GHSA-4v7x-pqxf-cx7m # False Positive
- package:
name: anchore/scan-action
- package:
diff --git a/Dockerfile b/Dockerfile
index aacec5eb991..4c62257adba 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -1,4 +1,4 @@
-FROM cgr.dev/chainguard/go@sha256:33158972c85a407c195aa3afb8b9c0b3e29d3c84d807bd1575271b8bd02e1d2d as build_env
+FROM cgr.dev/chainguard/go@sha256:1e17e06119fc26b78a9a2208aeab6209f9ef90b6a19f3fc69d4cc581e70d09bf as build_env
# Copy the source from the current directory to the Working Directory inside the container
WORKDIR /app
@@ -31,7 +31,7 @@ USER nonroot
# Runtime image
# Ignore no User Cmd since KICS container is stopped afer scan
# kics-scan ignore-line
-FROM cgr.dev/chainguard/git@sha256:9dc48ca2f9b643fffece0d7079f4e3b0b40e343de1c8f0f583db551d3df3c419
+FROM cgr.dev/chainguard/git@sha256:d007b76406e3e77d8f35b26620ffd1f82d71c61d0c900530c2ac4666a96822b8
ENV TERM xterm-256color
@@ -49,4 +49,4 @@ WORKDIR /app/bin
ENV PATH $PATH:/app/bin
# Command to run the executable
-ENTRYPOINT ["/app/bin/kics"]
+ENTRYPOINT ["/app/bin/kics"]
\ No newline at end of file
diff --git a/Makefile b/Makefile
index c5f169685cb..54a2ceb5d9f 100644
--- a/Makefile
+++ b/Makefile
@@ -123,16 +123,31 @@ docker: ## build docker image
$(call print-target)
@docker build --build-arg VERSION=${VERSION} --build-arg COMMIT=${COMMIT} -t "kics:${IMAGE_TAG}" .
+.PHONY: podman
+podman: ## build podman image
+ $(call print-target)
+ @podman build --build-arg VERSION=${VERSION} --build-arg COMMIT=${COMMIT} -t "kics:${IMAGE_TAG}" .
+
.PHONY: docker-compose
dkr-compose: ## build docker image and runs docker-compose up
$(call print-target)
VERSION=${VERSION} COMMIT=${COMMIT} IMAGE_TAG=${IMAGE_TAG} docker-compose up --build
+.PHONY: podman-compose
+podman-compose: ## build podman image and runs podman-compose up
+ $(call print-target)
+ VERSION=${VERSION} COMMIT=${COMMIT} IMAGE_TAG=${IMAGE_TAG} podman-compose up --build
+
.PHONY: dkr-build-antlr
dkr-build-antlr: ## build ANTLRv4 docker image and generate parser based on given grammar
@docker build -t antlr4-generator:dev -f ./docker/Dockerfile.antlr .
@docker run --rm -u $(id -u ${USER}):$(id -g ${USER}) -v $(pwd)/pkg/parser:/work -it antlr4-generator:dev
+.PHONY: podman-build-antlr
+podman-build-antlr: ## build ANTLRv4 podman image and generate parser based on given grammar
+ @podman build -t antlr4-generator:dev -f ./docker/Dockerfile.antlr .
+ @podman run --rm -u $(id -u ${USER}):$(id -g ${USER}) -v $(pwd)/pkg/parser:/work -it antlr4-generator:dev
+
.PHONY: release
release: ## goreleaser --rm-dist
release: install
@@ -178,3 +193,7 @@ endef
.PHONY: lint-docker-image
lint-docker-image:
docker run -t --rm -v ./:/app -w /app golangci/golangci-lint:v1.57.2 golangci-lint run -v -c /app/.golangci.yml --timeout 20m
+
+.PHONY: lint-podman-image
+lint-podman-image:
+ podman run -t --rm -v ./:/app -w /app golangci/golangci-lint:v1.57.2 golangci-lint run -v -c /app/.golangci.yml --timeout 20m
\ No newline at end of file
diff --git a/README.md b/README.md
index 45722c64675..90d3f84ff17 100644
--- a/README.md
+++ b/README.md
@@ -262,9 +262,9 @@ KICS is used by various companies and organizations, some are listed below. If y
- [Firefly](https://www.firefly.ai/) ([Firefly Integrates With Checkmarx's KICS](https://www.firefly.ai/blog/firefly-integrates-with-checkmarxs-kics-to-enable-seamless-cloud-governance-from-code-to-cloud))
- [Redpanda](https://redpanda.com/)
- [Keptn](https://github.com/keptn) / [Keptn Lifecycle Toolkit](https://keptn.sh)
-
+
**Keeping Infrastructure as Code Secure!**
---
-© 2024 Checkmarx Ltd. All Rights Reserved.
+© 2024 Checkmarx Ltd. All Rights Reserved.
\ No newline at end of file
diff --git a/assets/cwe_csv/Hardware-Design-CWE.csv b/assets/cwe_csv/Hardware-Design-CWE.csv
new file mode 100644
index 00000000000..0224adae5a3
--- /dev/null
+++ b/assets/cwe_csv/Hardware-Design-CWE.csv
@@ -0,0 +1,109 @@
+CWE-ID,Name,Weakness Abstraction,Status,Description,Extended Description,Related Weaknesses,Weakness Ordinalities,Applicable Platforms,Background Details,Alternate Terms,Modes Of Introduction,Exploitation Factors,Likelihood of Exploit,Common Consequences,Detection Methods,Potential Mitigations,Observed Examples,Functional Areas,Affected Resources,Taxonomy Mappings,Related Attack Patterns,Notes
+203,"Observable Discrepancy",Base,Incomplete,"The product behaves differently or sends different responses under different circumstances in a way that is observable to an unauthorized actor, which exposes security-relevant information about the state of the product, such as whether a particular operation was successful or not.","Discrepancies can take many forms, and variations may be detectable in timing, control flow, communications such as replies or requests, or general behavior. These discrepancies can reveal information about the product's operation or internal state to an unauthorized actor. In some cases, discrepancies can be used by attackers to form a side channel.",::NATURE:ChildOf:CWE ID:200:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:200:VIEW ID:1003:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","::TERM:Side Channel Attack:DESCRIPTION:Observable Discrepancies are at the root of side channel attacks.::","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Access Control:IMPACT:Read Application Data:IMPACT:Bypass Protection Mechanism:NOTE:An attacker can gain access to sensitive information about the system, including authentication information that may allow an attacker to gain access to the system.::SCOPE:Confidentiality:IMPACT:Read Application Data:NOTE:When cryptographic primitives are vulnerable to side-channel-attacks, this could be used to reveal unencrypted plaintext in the worst case.::","","::PHASE:Architecture and Design:STRATEGY:Separation of Privilege:DESCRIPTION:Compartmentalize the system to have safe areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.::PHASE:Implementation:DESCRIPTION:Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.::","::REFERENCE:CVE-2020-8695:DESCRIPTION:Observable discrepancy in the RAPL interface for some Intel processors allows information disclosure.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-8695::REFERENCE:CVE-2019-14353:DESCRIPTION:Crypto hardware wallet's power consumption relates to total number of pixels illuminated, creating a side channel in the USB connection that allows attackers to determine secrets displayed such as PIN numbers and passwords:LINK:https://www.cve.org/CVERecord?id=CVE-2019-14353::REFERENCE:CVE-2019-10071:DESCRIPTION:Java-oriented framework compares HMAC signatures using String.equals() instead of a constant-time algorithm, causing timing discrepancies:LINK:https://www.cve.org/CVERecord?id=CVE-2019-10071::REFERENCE:CVE-2002-2094:DESCRIPTION:This, and others, use .. attacks and monitor error responses, so there is overlap with directory traversal.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-2094::REFERENCE:CVE-2001-1483:DESCRIPTION:Enumeration of valid usernames based on inconsistent responses:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1483::REFERENCE:CVE-2001-1528:DESCRIPTION:Account number enumeration via inconsistent responses.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1528::REFERENCE:CVE-2004-2150:DESCRIPTION:User enumeration via discrepancies in error messages.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-2150::REFERENCE:CVE-2005-1650:DESCRIPTION:User enumeration via discrepancies in error messages.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1650::REFERENCE:CVE-2004-0294:DESCRIPTION:Bulletin Board displays different error messages when a user exists or not, which makes it easier for remote attackers to identify valid users and conduct a brute force password guessing attack.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0294::REFERENCE:CVE-2004-0243:DESCRIPTION:Operating System, when direct remote login is disabled, displays a different message if the password is correct, which allows remote attackers to guess the password via brute force methods.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0243::REFERENCE:CVE-2002-0514:DESCRIPTION:Product allows remote attackers to determine if a port is being filtered because the response packet TTL is different than the default TTL.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0514::REFERENCE:CVE-2002-0515:DESCRIPTION:Product sets a different TTL when a port is being filtered than when it is not being filtered, which allows remote attackers to identify filtered ports by comparing TTLs.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0515::REFERENCE:CVE-2002-0208:DESCRIPTION:Product modifies TCP/IP stack and ICMP error messages in unusual ways that show the product is in use.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0208::REFERENCE:CVE-2004-2252:DESCRIPTION:Behavioral infoleak by responding to SYN-FIN packets.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-2252::REFERENCE:CVE-2001-1387:DESCRIPTION:Product may generate different responses than specified by the administrator, possibly leading to an information leak.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1387::REFERENCE:CVE-2004-0778:DESCRIPTION:Version control system allows remote attackers to determine the existence of arbitrary files and directories via the -X command for an alternate history file, which causes different error messages to be returned.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0778::REFERENCE:CVE-2004-1428:DESCRIPTION:FTP server generates an error message if the user name does not exist instead of prompting for a password, which allows remote attackers to determine valid usernames.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1428::REFERENCE:CVE-2003-0078:DESCRIPTION:SSL implementation does not perform a MAC computation if an incorrect block cipher padding is used, which causes an information leak (timing discrepancy) that may make it easier to launch cryptographic attacks that rely on distinguishing between padding and MAC verification errors, possibly leading to extraction of the original plaintext, aka the Vaudenay timing attack.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0078::REFERENCE:CVE-2000-1117:DESCRIPTION:Virtual machine allows malicious web site operators to determine the existence of files on the client by measuring delays in the execution of the getSystemResource method.:LINK:https://www.cve.org/CVERecord?id=CVE-2000-1117::REFERENCE:CVE-2003-0637:DESCRIPTION:Product uses a shorter timeout for a non-existent user than a valid user, which makes it easier for remote attackers to guess usernames and conduct brute force password guessing.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0637::REFERENCE:CVE-2003-0190:DESCRIPTION:Product immediately sends an error message when a user does not exist, which allows remote attackers to determine valid usernames via a timing attack.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0190::REFERENCE:CVE-2004-1602:DESCRIPTION:FTP server responds in a different amount of time when a given username exists, which allows remote attackers to identify valid usernames by timing the server response.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1602::REFERENCE:CVE-2005-0918:DESCRIPTION:Browser allows remote attackers to determine the existence of arbitrary files by setting the src property to the target filename and using Javascript to determine if the web page immediately stops loading, which indicates whether the file exists or not.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-0918::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Discrepancy Information Leaks::TAXONOMY NAME:OWASP Top Ten 2007:ENTRY ID:A6:ENTRY NAME:Information Leakage and Improper Error Handling:MAPPING FIT:CWE More Specific::TAXONOMY NAME:OWASP Top Ten 2004:ENTRY ID:A7:ENTRY NAME:Improper Error Handling:MAPPING FIT:CWE More Specific::",::189::,"",
+226,"Sensitive Information in Resource Not Removed Before Reuse",Base,Draft,"The product releases a resource such as memory or a file so that it can be made available for reuse, but it does not clear or zeroize the information contained in the resource before the product performs a critical state transition or makes the resource available for reuse by other entities.","When resources are released, they can be made available for reuse. For example, after memory is de-allocated, an operating system may make the memory available to another process, or disk space may be reallocated when a file is deleted. As removing information requires time and additional resources, operating systems do not usually clear the previously written information. Even when the resource is reused by the same process, this weakness can arise when new data is not as large as the old data, which leaves portions of the old data still available. Equivalent errors can occur in other situations where the length of data is variable but the associated data structure is not. If memory is not cleared after use, the information may be read by less trustworthy parties when the memory is reallocated. This weakness can apply in hardware, such as when a device or system switches between power, sleep, or debug states during normal operation, or when execution changes to different users or privilege levels.",::NATURE:ChildOf:CWE ID:459:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:212:VIEW ID:1000::NATURE:CanPrecede:CWE ID:201:VIEW ID:1000::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:IMPACT:Read Application Data::","::METHOD:Manual Analysis:DESCRIPTION:Write a known pattern into each sensitive location. Trigger the release of the resource or cause the desired state transition to occur. Read data back from the sensitive locations. If the reads are successful, and the data is the same as the pattern that was originally written, the test fails and the product needs to be fixed. Note that this test can likely be automated.:EFFECTIVENESS:High::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","::PHASE:Architecture and Design Implementation:DESCRIPTION:During critical state transitions, information not needed in the next state should be removed or overwritten with fixed patterns (such as all 0's) or random data, before the transition to the next state.:EFFECTIVENESS:High::PHASE:Architecture and Design Implementation:DESCRIPTION:When releasing, de-allocating, or deleting a resource, overwrite its data and relevant metadata with fixed patterns or random data. Be cautious about complex resource types whose underlying representation might be non-contiguous or change at a low level, such as how a file might be split into different chunks on a file system, even though logical file positions are contiguous at the application layer. Such resource types might require invocation of special modes or APIs to tell the underlying operating system to perform the necessary clearing, such as SDelete (Secure Delete) on Windows, although the appropriate functionality might not be available at the application layer.:EFFECTIVENESS:High::","::REFERENCE:CVE-2019-3733:DESCRIPTION:Cryptography library does not clear heap memory before release:LINK:https://www.cve.org/CVERecord?id=CVE-2019-3733::REFERENCE:CVE-2003-0001:DESCRIPTION:Ethernet NIC drivers do not pad frames with null bytes, leading to infoleak from malformed packets.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0001::REFERENCE:CVE-2003-0291:DESCRIPTION:router does not clear information from DHCP packets that have been previously used:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0291::REFERENCE:CVE-2005-1406:DESCRIPTION:Products do not fully clear memory buffers when less data is stored into the buffer than previous.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1406::REFERENCE:CVE-2005-1858:DESCRIPTION:Products do not fully clear memory buffers when less data is stored into the buffer than previous.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1858::REFERENCE:CVE-2005-3180:DESCRIPTION:Products do not fully clear memory buffers when less data is stored into the buffer than previous.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-3180::REFERENCE:CVE-2005-3276:DESCRIPTION:Product does not clear a data structure before writing to part of it, yielding information leak of previously used memory.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-3276::REFERENCE:CVE-2002-2077:DESCRIPTION:Memory not properly cleared before reuse.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-2077::",::Memory Management::Networking::,::Memory::,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Sensitive Information Uncleared Before Use::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:MEM03-C:ENTRY NAME:Clear sensitive information stored in reusable resources returned for reuse::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP23:ENTRY NAME:Exposed Data::",::37::,"::TYPE:Relationship:NOTE:There is a close association between CWE-226 and CWE-212. The difference is partially that of perspective. CWE-226 is geared towards the final stage of the resource lifecycle, in which the resource is deleted, eliminated, expired, or otherwise released for reuse. Technically, this involves a transfer to a different control sphere, in which the original contents of the resource are no longer relevant. CWE-212, however, is intended for sensitive data in resources that are intentionally shared with others, so they are still active. This distinction is useful from the perspective of the CWE research view (CWE-1000).::TYPE:Maintenance:NOTE:This entry needs modification to clarify the differences with CWE-212. The description also combines two problems that are distinct from the CWE research perspective: the inadvertent transfer of information to another sphere, and improper initialization/shutdown. Some of the associated taxonomy mappings reflect these different uses.::TYPE:Research Gap:NOTE:This is frequently found for network packets, but it can also exist in local memory allocation, files, etc.::",
+276,"Incorrect Default Permissions",Base,Draft,"During installation, installed file permissions are set to allow anyone to modify those files.","",::NATURE:ChildOf:CWE ID:732:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:732:VIEW ID:1003:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:ICS/OT:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::PHASE:Installation::PHASE:Operation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Application Data:IMPACT:Modify Application Data::","::METHOD:Automated Static Analysis - Binary or Bytecode:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Inter-application Flow Analysis:EFFECTIVENESS:SOAR Partial::METHOD:Manual Static Analysis - Binary or Bytecode:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies:EFFECTIVENESS:SOAR Partial::METHOD:Dynamic Analysis with Automated Results Interpretation:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Host-based Vulnerability Scanners - Examine configuration for flaws, verifying that audit mechanisms work, ensure host configuration meets certain predefined criteria Web Application Scanner Web Services Scanner Database Scanners:EFFECTIVENESS:SOAR Partial::METHOD:Dynamic Analysis with Manual Results Interpretation:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Host Application Interface Scanner Cost effective for partial coverage: Fuzz Tester Framework-based Fuzzer Automated Monitored Execution Forced Path Execution:EFFECTIVENESS:High::METHOD:Manual Static Analysis - Source Code:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Manual Source Code Review (not inspections) Cost effective for partial coverage: Focused Manual Spotcheck - Focused manual analysis of source:EFFECTIVENESS:High::METHOD:Automated Static Analysis - Source Code:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Context-configured Source Code Weakness Analyzer:EFFECTIVENESS:SOAR Partial::METHOD:Automated Static Analysis:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Configuration Checker:EFFECTIVENESS:SOAR Partial::METHOD:Architecture or Design Review:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Formal Methods / Correct-By-Construction Cost effective for partial coverage: Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.):EFFECTIVENESS:High::","::PHASE:Architecture and Design Operation:DESCRIPTION:The architecture needs to access and modification attributes for files to only those users who actually require those actions.::PHASE:Architecture and Design:STRATEGY:Separation of Privilege:DESCRIPTION:Compartmentalize the system to have safe areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.::","::REFERENCE:CVE-2005-1941:DESCRIPTION:Executables installed world-writable.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1941::REFERENCE:CVE-2002-1713:DESCRIPTION:Home directories installed world-readable.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1713::REFERENCE:CVE-2001-1550:DESCRIPTION:World-writable log files allow information loss; world-readable file has cleartext passwords.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1550::REFERENCE:CVE-2002-1711:DESCRIPTION:World-readable directory.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1711::REFERENCE:CVE-2002-1844:DESCRIPTION:Windows product uses insecure permissions when installing on Solaris (genesis: port error).:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1844::REFERENCE:CVE-2001-0497:DESCRIPTION:Insecure permissions for a shared secret key file. Overlaps cryptographic problem.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0497::REFERENCE:CVE-1999-0426:DESCRIPTION:Default permissions of a device allow IP spoofing.:LINK:https://www.cve.org/CVERecord?id=CVE-1999-0426::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Insecure Default Permissions::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:FIO06-C:ENTRY NAME:Create files with appropriate access permissions::TAXONOMY NAME:The CERT Oracle Secure Coding Standard for Java (2011):ENTRY ID:FIO01-J:ENTRY NAME:Create files with appropriate access permission::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 2-4:ENTRY NAME:Req SP.03.08::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-2:ENTRY NAME:Req CR 2.1::",::1::127::81::,"",
+319,"Cleartext Transmission of Sensitive Information",Base,Draft,"The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.","Many communication channels can be sniffed (monitored) by adversaries during data transmission. For example, in networking, packets can traverse many intermediary nodes from the source to the destination, whether across the internet, an internal network, the cloud, etc. Some actors might have privileged access to a network interface or any link along the channel, such as a router, but they might not be authorized to collect the underlying data. As a result, network traffic could be sniffed by adversaries, spilling security-critical data. Applicable communication channels are not limited to software products. Applicable channels include hardware-specific technologies such as internal hardware networks and external debug channels, supporting remote JTAG debugging. When mitigations are not applied to combat adversaries within the product's threat model, this weakness significantly lowers the difficulty of exploitation by such adversaries. When full communications are recorded or logged, such as with a packet dump, an adversary could attempt to obtain the dump long after the transmission has occurred and try to sniff the cleartext from the recorded communications in the dump itself. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information.",::NATURE:ChildOf:CWE ID:311:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:311:VIEW ID:1003:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Cloud Computing:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:Mobile:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:ICS/OT:TECHNOLOGY PREVALENCE:Often::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Test/Debug Hardware:TECHNOLOGY PREVALENCE:Often::,"","","::PHASE:Architecture and Design:NOTE:OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.::PHASE:Architecture and Design:NOTE:For hardware, this may be introduced when design does not plan for an attacker having physical access while a legitimate user is remotely operating the device.::PHASE:Operation::PHASE:System Configuration::","",,"::SCOPE:Integrity:SCOPE:Confidentiality:IMPACT:Read Application Data:IMPACT:Modify Files or Directories:NOTE:Anyone can read the information by gaining access to the channel being used for communication.::","::METHOD:Black Box:DESCRIPTION:Use monitoring tools that examine the software's process as it interacts with the operating system and the network. This technique is useful in cases when source code is unavailable, if the software was not developed by you, or if you want to verify that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon, RegMon, Process Monitor, and other Sysinternals utilities (Windows); and sniffers and protocol analyzers that monitor network traffic. Attach the monitor to the process, trigger the feature that sends the data, and look for the presence or absence of common cryptographic functions in the call tree. Monitor the network and determine if the data packets contain readable commands. Tools exist for detecting if certain encodings are in use. If the traffic contains high entropy, this might indicate the usage of encryption.::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","::PHASE:Architecture and Design:DESCRIPTION:Before transmitting, encrypt the data using reliable, confidentiality-protecting cryptographic protocols.::PHASE:Implementation:DESCRIPTION:When using web applications with SSL, use SSL for the entire session from login to logout, not just for the initial login page.::PHASE:Implementation:DESCRIPTION:When designing hardware platforms, ensure that approved encryption algorithms (such as those recommended by NIST) protect paths from security critical data to trusted user applications.::PHASE:Testing:DESCRIPTION:Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.::PHASE:Operation:DESCRIPTION:Configure servers to use encrypted channels for communication, which may include SSL or other secure protocols.::","::REFERENCE:CVE-2022-29519:DESCRIPTION:Programmable Logic Controller (PLC) sends sensitive information in plaintext, including passwords and session tokens.:LINK:https://www.cve.org/CVERecord?id=CVE-2022-29519::REFERENCE:CVE-2022-30312:DESCRIPTION:Building Controller uses a protocol that transmits authentication credentials in plaintext.:LINK:https://www.cve.org/CVERecord?id=CVE-2022-30312::REFERENCE:CVE-2022-31204:DESCRIPTION:Programmable Logic Controller (PLC) sends password in plaintext.:LINK:https://www.cve.org/CVERecord?id=CVE-2022-31204::REFERENCE:CVE-2002-1949:DESCRIPTION:Passwords transmitted in cleartext.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1949::REFERENCE:CVE-2008-4122:DESCRIPTION:Chain: Use of HTTPS cookie without secure flag causes it to be transmitted across unencrypted HTTP.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-4122::REFERENCE:CVE-2008-3289:DESCRIPTION:Product sends password hash in cleartext in violation of intended policy.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-3289::REFERENCE:CVE-2008-4390:DESCRIPTION:Remote management feature sends sensitive information including passwords in cleartext.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-4390::REFERENCE:CVE-2007-5626:DESCRIPTION:Backup routine sends password in cleartext in email.:LINK:https://www.cve.org/CVERecord?id=CVE-2007-5626::REFERENCE:CVE-2004-1852:DESCRIPTION:Product transmits Blowfish encryption key in cleartext.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1852::REFERENCE:CVE-2008-0374:DESCRIPTION:Printer sends configuration information, including administrative password, in cleartext.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-0374::REFERENCE:CVE-2007-4961:DESCRIPTION:Chain: cleartext transmission of the MD5 hash of password enables attacks against a server that is susceptible to replay (CWE-294).:LINK:https://www.cve.org/CVERecord?id=CVE-2007-4961::REFERENCE:CVE-2007-4786:DESCRIPTION:Product sends passwords in cleartext to a log server.:LINK:https://www.cve.org/CVERecord?id=CVE-2007-4786::REFERENCE:CVE-2005-3140:DESCRIPTION:Product sends file with cleartext passwords in e-mail message intended for diagnostic purposes.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-3140::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Plaintext Transmission of Sensitive Information::TAXONOMY NAME:The CERT Oracle Secure Coding Standard for Java (2011):ENTRY ID:SEC06-J:ENTRY NAME:Do not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar::TAXONOMY NAME:The CERT Oracle Secure Coding Standard for Java (2011):ENTRY ID:SER02-J:ENTRY NAME:Sign then seal sensitive objects before sending them outside a trust boundary::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP23:ENTRY NAME:Exposed Data::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 3-3:ENTRY NAME:Req SR 4.1::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-2:ENTRY NAME:Req CR 4.1B::",::102::117::383::477::65::,"::TYPE:Maintenance:NOTE:The Taxonomy_Mappings to ISA/IEC 62443 were added in CWE 4.10, but they are still under review and might change in future CWE versions. These draft mappings were performed by members of the Mapping CWE to 62443 subgroup of the CWE-CAPEC ICS/OT Special Interest Group (SIG), and their work is incomplete as of CWE 4.10. The mappings are included to facilitate discussion and review by the broader ICS/OT community, and they are likely to change in future CWE versions.::",
+325,"Missing Cryptographic Step",Base,Draft,"The product does not implement a required step in a cryptographic algorithm, resulting in weaker encryption than advertised by the algorithm.","",::NATURE:ChildOf:CWE ID:573:VIEW ID:1000:ORDINAL:Primary::NATURE:PeerOf:CWE ID:358:VIEW ID:1000::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Implementation:NOTE:Developers sometimes omit expensive (resource-intensive) steps in order to improve performance, especially in devices with limited memory or slower CPUs. This step may be taken under a mistaken impression that the step is unnecessary for the cryptographic algorithm.::PHASE:Requirements:NOTE:This issue may happen when the requirements for the cryptographic algorithm are not clearly stated.::","",,"::SCOPE:Access Control:IMPACT:Bypass Protection Mechanism::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Application Data:IMPACT:Modify Application Data::SCOPE:Accountability:SCOPE:Non-Repudiation:IMPACT:Hide Activities::","","","::REFERENCE:CVE-2001-1585:DESCRIPTION:Missing challenge-response step allows authentication bypass using public key.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1585::",::Cryptography::,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Missing Required Cryptographic Step::TAXONOMY NAME:OWASP Top Ten 2007:ENTRY ID:A8:ENTRY NAME:Insecure Cryptographic Storage:MAPPING FIT:CWE More Specific::TAXONOMY NAME:OWASP Top Ten 2007:ENTRY ID:A9:ENTRY NAME:Insecure Communications:MAPPING FIT:CWE More Specific::",::68::,"::TYPE:Relationship:NOTE:Overlaps incomplete/missing security check.::TYPE:Relationship:NOTE:Can be resultant.::",
+440,"Expected Behavior Violation",Base,Draft,"A feature, API, or function does not perform according to its specification.","",::NATURE:ChildOf:CWE ID:684:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::TECHNOLOGY CLASS:ICS/OT:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::PHASE:Operation::","",,"::SCOPE:Other:IMPACT:Quality Degradation:IMPACT:Varies by Context::","","","::REFERENCE:CVE-2003-0187:DESCRIPTION:Program uses large timeouts on unconfirmed connections resulting from inconsistency in linked lists implementations.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0187::REFERENCE:CVE-2003-0465:DESCRIPTION:strncpy in Linux kernel acts different than libc on x86, leading to expected behavior difference - sort of a multiple interpretation error?:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0465::REFERENCE:CVE-2005-3265:DESCRIPTION:Buffer overflow in product stems the use of a third party library function that is expected to have internal protection against overflows, but doesn't.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-3265::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Expected behavior violation::",,"::TYPE:Theoretical:NOTE:The behavior of an application that is not consistent with the expectations of the developer may lead to incorrect use of the software.::",
+441,"Unintended Proxy or Intermediary ('Confused Deputy')",Class,Draft,"The product receives a request, message, or directive from an upstream component, but the product does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the product's control sphere. This causes the product to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor.","If an attacker cannot directly contact a target, but the product has access to the target, then the attacker can send a request to the product and have it be forwarded to the target. The request would appear to be coming from the product's system, not the attacker's system. As a result, the attacker can bypass access controls (such as firewalls) or hide the source of malicious requests, since the requests would not be coming directly from the attacker. Since proxy functionality and message-forwarding often serve a legitimate purpose, this issue only becomes a vulnerability when: The product runs with different privileges or on a different system, or otherwise has different levels of access than the upstream component; The attacker is prevented from making the request directly to the target; and The attacker can create a request that the proxy does not explicitly intend to be forwarded on the behalf of the requester. Such a request might point to an unexpected hostname, port number, hardware IP, or service. Or, the request might be sent to an allowed service, but the request could contain disallowed directives, commands, or resources.",::NATURE:ChildOf:CWE ID:610:VIEW ID:1000:ORDINAL:Primary::NATURE:CanPrecede:CWE ID:668:VIEW ID:1000::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","::TERM:Confused Deputy:DESCRIPTION:This weakness is sometimes referred to as the Confused deputy problem, in which an attacker misused the authority of one victim (the confused deputy) when targeting another victim.::","::PHASE:Architecture and Design:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::","",,"::SCOPE:Non-Repudiation:SCOPE:Access Control:IMPACT:Gain Privileges or Assume Identity:IMPACT:Hide Activities:IMPACT:Execute Unauthorized Code or Commands::","::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","::PHASE:Architecture and Design:DESCRIPTION:Enforce the use of strong mutual authentication mechanism between the two parties.::PHASE:Architecture and Design:DESCRIPTION:Whenever a product is an intermediary or proxy for transactions between two other components, the proxy core should not drop the identity of the initiator of the transaction. The immutability of the identity of the initiator must be maintained and should be forwarded all the way to the target.::","::REFERENCE:CVE-1999-0017:DESCRIPTION:FTP bounce attack. The design of the protocol allows an attacker to modify the PORT command to cause the FTP server to connect to other machines besides the attacker's.:LINK:https://www.cve.org/CVERecord?id=CVE-1999-0017::REFERENCE:CVE-1999-0168:DESCRIPTION:RPC portmapper could redirect service requests from an attacker to another entity, which thinks the requests came from the portmapper.:LINK:https://www.cve.org/CVERecord?id=CVE-1999-0168::REFERENCE:CVE-2005-0315:DESCRIPTION:FTP server does not ensure that the IP address in a PORT command is the same as the FTP user's session, allowing port scanning by proxy.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-0315::REFERENCE:CVE-2002-1484:DESCRIPTION:Web server allows attackers to request a URL from another server, including other ports, which allows proxied scanning.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1484::REFERENCE:CVE-2004-2061:DESCRIPTION:CGI script accepts and retrieves incoming URLs.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-2061::REFERENCE:CVE-2001-1484:DESCRIPTION:Bounce attack allows access to TFTP from trusted side.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1484::REFERENCE:CVE-2010-1637:DESCRIPTION:Web-based mail program allows internal network scanning using a modified POP3 port number.:LINK:https://www.cve.org/CVERecord?id=CVE-2010-1637::REFERENCE:CVE-2009-0037:DESCRIPTION:URL-downloading library automatically follows redirects to file:// and scp:// URLs:LINK:https://www.cve.org/CVERecord?id=CVE-2009-0037::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Unintended proxy/intermediary::TAXONOMY NAME:PLOVER:ENTRY NAME:Proxied Trusted Channel::TAXONOMY NAME:WASC:ENTRY ID:32:ENTRY NAME:Routing Detour::",::219::465::,"::TYPE:Relationship:NOTE:This weakness has a chaining relationship with CWE-668 (Exposure of Resource to Wrong Sphere) because the proxy effectively provides the attacker with access to the target's resources that the attacker cannot directly obtain.::TYPE:Maintenance:NOTE:This could possibly be considered as an emergent resource.::TYPE:Theoretical:NOTE:It could be argued that the confused deputy is a fundamental aspect of most vulnerabilities that require an active attacker. Even for common implementation issues such as buffer overflows, SQL injection, OS command injection, and path traversal, the vulnerable program already has the authorization to run code or access files. The vulnerability arises when the attacker causes the program to run unexpected code or access unexpected files.::",
+1053,"Missing Documentation for Design",Base,Incomplete,"The product does not have documentation that represents how it is designed.","This issue can make it more difficult to understand and maintain the product. It can make it more difficult and time-consuming to detect and/or fix vulnerabilities.",::NATURE:ChildOf:CWE ID:1059:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Indirect::",,"","","","",,"","","","",,,"",,"",
+1059,"Insufficient Technical Documentation",Class,Incomplete,"The product does not contain sufficient technical or engineering documentation (whether on paper or in electronic form) that contains descriptions of all the relevant software/hardware elements of the product, such as its usage, structure, architectural components, interfaces, design, implementation, configuration, operation, etc.","When technical documentation is limited or lacking, products are more difficult to maintain. This indirectly affects security by making it more difficult or time-consuming to find and/or fix vulnerabilities. When using time-limited or labor-limited third-party/in-house security consulting services (such as threat modeling, vulnerability discovery, or pentesting), insufficient documentation can force those consultants to invest unnecessary time in learning how the product is organized, instead of focusing their expertise on finding the flaws or suggesting effective mitigations. With respect to hardware design, the lack of a formal, final manufacturer reference can make it difficult or impossible to evaluate the final product, including post-manufacture verification. One cannot ensure that design functionality or operation is within acceptable tolerances, conforms to specifications, and is free from unexpected behavior. Hardware-related documentation may include engineering artifacts such as hardware description language (HDLs), netlists, Gerber files, Bills of Materials, EDA (Electronic Design Automation) tool files, etc.",::NATURE:ChildOf:CWE ID:710:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Indirect::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:ICS/OT:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Documentation::","",,"::SCOPE:Other:IMPACT:Varies by Context:IMPACT:Hide Activities:IMPACT:Reduce Reliability:IMPACT:Quality Degradation:IMPACT:Reduce Maintainability:NOTE:Without a method of verification, one cannot be sure that everything only functions as expected.::","","::PHASE:Documentation Architecture and Design:DESCRIPTION:Ensure that design documentation is detailed enough to allow for post-manufacturing verification.::","::REFERENCE:CVE-2022-3203:DESCRIPTION:A wireless access point manual specifies that the only method of configuration is via web interface (CWE-1059), but there is an undisclosed telnet server that was activated by default (CWE-912).:LINK:https://www.cve.org/CVERecord?id=CVE-2022-3203::",,,"::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 2-4:ENTRY NAME:Req SP.02.03 BR::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 2-4:ENTRY NAME:Req SP.02.03 RE(1)::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 2-4:ENTRY NAME:Req SP.03.03 RE(1)::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-1:ENTRY NAME:Req SG-1::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-1:ENTRY NAME:Req SG-2::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-1:ENTRY NAME:Req SG-3::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-1:ENTRY NAME:Req SG-4::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-1:ENTRY NAME:Req SG-5::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-1:ENTRY NAME:Req SG-6::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-1:ENTRY NAME:Req SG-7::",,"",
+1189,"Improper Isolation of Shared Resources on System-on-a-Chip (SoC)",Base,Stable,"The System-On-a-Chip (SoC) does not properly isolate shared resources between trusted and untrusted agents.","A System-On-a-Chip (SoC) has a lot of functionality, but it may have a limited number of pins or pads. A pin can only perform one function at a time. However, it can be configured to perform multiple different functions. This technique is called pin multiplexing. Similarly, several resources on the chip may be shared to multiplex and support different features or functions. When such resources are shared between trusted and untrusted agents, untrusted agents may be able to access the assets intended to be accessed only by the trusted agents.",::NATURE:ChildOf:CWE ID:653:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:668:VIEW ID:1000::NATURE:PeerOf:CWE ID:1331:VIEW ID:1000::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Access Control:IMPACT:Bypass Protection Mechanism:NOTE:If resources being used by a trusted user are shared with an untrusted user, the untrusted user may be able to modify the functionality of the shared resource of the trusted user.::SCOPE:Integrity:IMPACT:Quality Degradation:NOTE:The functionality of the shared resource may be intentionally degraded.::","::METHOD:Automated Dynamic Analysis:DESCRIPTION:Pre-silicon / post-silicon: Test access to shared systems resources (memory ranges, control registers, etc.) from untrusted software to verify that the assets are not incorrectly exposed to untrusted agents. Note that access to shared resources can be dynamically allowed or revoked based on system flows. Security testing should cover such dynamic shared resource allocation and access control modification flows.:EFFECTIVENESS:High::","::PHASE:Architecture and Design:STRATEGY:Separation of Privilege:DESCRIPTION:When sharing resources, avoid mixing agents of varying trust levels. Untrusted agents should not share resources with trusted agents.::","::REFERENCE:CVE-2020-8698:DESCRIPTION:Processor has improper isolation of shared resources allowing for information disclosure.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-8698::REFERENCE:CVE-2019-6260:DESCRIPTION:Baseboard Management Controller (BMC) device implements Advanced High-performance Bus (AHB) bridges that do not require authentication for arbitrary read and write access to the BMC's physical address space from the host, and possibly the network [REF-1138].:LINK:https://www.cve.org/CVERecord?id=CVE-2019-6260::",,,"",::124::,"",
+1190,"DMA Device Enabled Too Early in Boot Phase",Base,Draft,"The product enables a Direct Memory Access (DMA) capable device before the security configuration settings are established, which allows an attacker to extract data from or gain privileges on the product.","DMA is included in a number of devices because it allows data transfer between the computer and the connected device, using direct hardware access to read or write directly to main memory without any OS interaction. An attacker could exploit this to access secrets. Several virtualization-based mitigations have been introduced to thwart DMA attacks. These are usually configured/setup during boot time. However, certain IPs that are powered up before boot is complete (known as early boot IPs) may be DMA capable. Such IPs, if not trusted, could launch DMA attacks and gain access to assets that should otherwise be protected.",::NATURE:ChildOf:CWE ID:696:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::","",,"::SCOPE:Access Control:IMPACT:Bypass Protection Mechanism:IMPACT:Modify Memory:LIKELIHOOD:High:NOTE:DMA devices have direct write access to main memory and due to time of attack will be able to bypass OS or Bootloader access control.::","","::PHASE:Architecture and Design:DESCRIPTION:Utilize an IOMMU to orchestrate IO access from the start of the boot process.::","",,,"",::180::,"",
+1191,"On-Chip Debug and Test Interface With Improper Access Control",Base,Stable,"The chip does not implement or does not correctly perform access control to check whether users are authorized to access internal registers and test modes through the physical debug/test interface.","A device's internal information may be accessed through a scan chain of interconnected internal registers, usually through a JTAG interface. The JTAG interface provides access to these registers in a serial fashion in the form of a scan chain for the purposes of debugging programs running on a device. Since almost all information contained within a device may be accessed over this interface, device manufacturers typically insert some form of authentication and authorization to prevent unintended use of this sensitive information. This mechanism is implemented in addition to on-chip protections that are already present. If authorization, authentication, or some other form of access control is not implemented or not implemented correctly, a user may be able to bypass on-chip protection mechanisms through the debug interface. Sometimes, designers choose not to expose the debug pins on the motherboard. Instead, they choose to hide these pins in the intermediate layers of the board. This is primarily done to work around the lack of debug authorization inside the chip. In such a scenario (without debug authorization), when the debug interface is exposed, chip internals are accessible to an attacker.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Confidentiality:IMPACT:Read Application Data:LIKELIHOOD:High::SCOPE:Confidentiality:IMPACT:Read Memory:LIKELIHOOD:High::SCOPE:Authorization:IMPACT:Execute Unauthorized Code or Commands:LIKELIHOOD:High::SCOPE:Integrity:IMPACT:Modify Memory:LIKELIHOOD:High::SCOPE:Integrity:IMPACT:Modify Application Data:LIKELIHOOD:High::SCOPE:Access Control:IMPACT:Bypass Protection Mechanism:LIKELIHOOD:High::","::METHOD:Dynamic Analysis with Manual Results Interpretation:DESCRIPTION:Authentication and authorization of debug and test interfaces should be part of the architecture and design review process. Withholding of private register documentation from the debug and test interface public specification (Security by obscurity) should not be considered as sufficient security.::METHOD:Dynamic Analysis with Manual Results Interpretation:DESCRIPTION:Dynamic tests should be done in the pre-silicon and post-silicon stages to verify that the debug and test interfaces are not open by default.::METHOD:Fuzzing:DESCRIPTION:Tests that fuzz Debug and Test Interfaces should ensure that no access without appropriate authentication and authorization is possible.:EFFECTIVENESS:Moderate::","::PHASE:Architecture and Design:STRATEGY:Separation of Privilege:DESCRIPTION:If feasible, the manufacturer should disable the JTAG interface or implement authentication and authorization for the JTAG interface. If authentication logic is added, it should be resistant to timing attacks. Security-sensitive data stored in registers, such as keys, etc. should be cleared when entering debug mode.:EFFECTIVENESS:High::","::REFERENCE:CVE-2019-18827:DESCRIPTION:chain: JTAG interface is not disabled (CWE-1191) during ROM code execution, introducing a race condition (CWE-362) to extract encryption keys:LINK:https://www.cve.org/CVERecord?id=CVE-2019-18827::",,,"",::1::180::,"::TYPE:Relationship:NOTE:CWE-1191 and CWE-1244 both involve physical debug access, but the weaknesses are different. CWE-1191 is effectively about missing authorization for a debug interface, i.e. JTAG. CWE-1244 is about providing internal assets with the wrong debug access level, exposing the asset to untrusted debug agents.::",
+1192,"Improper Identifier for IP Block used in System-On-Chip (SOC)",Base,Draft,"The System-on-Chip (SoC) does not have unique, immutable identifiers for each of its components.","A System-on-Chip (SoC) comprises several components (IP) with varied trust requirements. It is required that each IP is identified uniquely and should distinguish itself from other entities in the SoC without any ambiguity. The unique secured identity is required for various purposes. Most of the time the identity is used to route a transaction or perform certain actions, including resetting, retrieving a sensitive information, and acting upon or on behalf of something else. There are several variants of this weakness: A missing identifier is when the SoC does not define any mechanism to uniquely identify the IP. An insufficient identifier might provide some defenses - for example, against the most common attacks - but it does not protect against everything that is intended. A misconfigured mechanism occurs when a mechanism is available but not implemented correctly. An ignored identifier occurs when the SoC/IP has not applied any policies or does not act upon the identifier securely.",::NATURE:ChildOf:CWE ID:657:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::PHASE:Operation::","",,"::SCOPE:Access Control:IMPACT:Bypass Protection Mechanism:LIKELIHOOD:High::","","::PHASE:Architecture and Design:STRATEGY:Separation of Privilege:DESCRIPTION:Every identity generated in the SoC should be unique and immutable in hardware. The actions that an IP is trusted or not trusted should be clearly defined, implemented, configured, and tested. If the definition is implemented via a policy, then the policy should be immutable or protected with clear authentication and authorization.::","",,,"",::113::,"",
+1193,"Power-On of Untrusted Execution Core Before Enabling Fabric Access Control",Base,Draft,"The product enables components that contain untrusted firmware before memory and fabric access controls have been enabled.","After initial reset, System-on-Chip (SoC) fabric access controls and other security features need to be programmed by trusted firmware as part of the boot sequence. If untrusted IPs or peripheral microcontrollers are enabled first, then the untrusted component can master transactions on the hardware bus and target memory or other assets to compromise the SoC boot firmware.",::NATURE:ChildOf:CWE ID:696:VIEW ID:1000:ORDINAL:Primary::,"",,"","","","",,"::SCOPE:Access Control:IMPACT:Bypass Protection Mechanism:LIKELIHOOD:High:NOTE:An untrusted component can master transactions on the HW bus and target memory or other assets to compromise the SoC boot firmware.::","","::PHASE:Architecture and Design:DESCRIPTION:The boot sequence should enable fabric access controls and memory protections before enabling third-party hardware IPs and peripheral microcontrollers that use untrusted firmware.::","",,,"",::1::180::,"",
+1209,"Failure to Disable Reserved Bits",Base,Incomplete,"The reserved bits in a hardware design are not disabled prior to production. Typically, reserved bits are used for future capabilities and should not support any functional logic in the design. However, designers might covertly use these bits to debug or further develop new capabilities in production hardware. Adversaries with access to these bits will write to them in hopes of compromising hardware state.","Reserved bits are labeled as such so they can be allocated for a later purpose. They are not to do anything in the current design. However, designers might want to use these bits to debug or control/configure a future capability to help minimize time to market (TTM). If the logic being controlled by these bits is still enabled in production, an adversary could use the logic to induce unwanted/unsupported behavior in the hardware.",::NATURE:ChildOf:CWE ID:710:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:The Designer and Implementer have to make a conscious choice to do this::PHASE:Implementation:NOTE:The Designer and Implementer have to make a conscious choice to do this::PHASE:Documentation:NOTE:If documentation labels anything for future use, reserved, or the like, such labeling could indicate to an attacker a potential attack point::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Access Control:SCOPE:Accountability:SCOPE:Authentication:SCOPE:Authorization:SCOPE:Non-Repudiation:IMPACT:Varies by Context:NOTE:This type of weakness all depends on the capabilities of the logic being controlled or configured by the reserved bits::","","::PHASE:Architecture and Design Implementation:DESCRIPTION:Include a feature to disable reserved bits.::PHASE:Integration:DESCRIPTION:Any writes to these reserve bits are blocked (e.g., ignored, access-protected, etc.), or an exception can be asserted.::","",,,"",::121::,"",
+1220,"Insufficient Granularity of Access Control",Base,Incomplete,"The product implements access controls via a policy or other feature with the intention to disable or restrict accesses (reads and/or writes) to assets in a system from untrusted agents. However, implemented access controls lack required granularity, which renders the control policy too broad because it allows accesses from unauthorized agents to the security-sensitive assets.","Integrated circuits and hardware engines can expose accesses to assets (device configuration, keys, etc.) to trusted firmware or a software module (commonly set by BIOS/bootloader). This access is typically access-controlled. Upon a power reset, the hardware or system usually starts with default values in registers, and the trusted firmware (Boot firmware) configures the necessary access-control protection. A common weakness that can exist in such protection schemes is that access controls or policies are not granular enough. This condition allows agents beyond trusted agents to access assets and could lead to a loss of functionality or the ability to set up the device securely. This further results in security risks from leaked, sensitive, key material to modification of device configuration.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:Such issues could be introduced during hardware architecture and design and identified later during Testing or System Configuration phases.::PHASE:Implementation:NOTE:Such issues could be introduced during hardware implementation and identified later during Testing or System Configuration phases.::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Access Control:IMPACT:Modify Memory:IMPACT:Read Memory:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Gain Privileges or Assume Identity:IMPACT:Bypass Protection Mechanism:IMPACT:Other:LIKELIHOOD:High::","","::PHASE:Architecture and Design Implementation Testing:DESCRIPTION:Access-control-policy protections must be reviewed for design inconsistency and common weaknesses. Access-control-policy definition and programming flow must be tested in pre-silicon, post-silicon testing.:EFFECTIVENESS:High::","::REFERENCE:CVE-2022-24985:DESCRIPTION:A form hosting website only checks the session authentication status for a single form, making it possible to bypass authentication when there are multiple forms:LINK:https://www.cve.org/CVERecord?id=CVE-2022-24985::REFERENCE:CVE-2021-36934:DESCRIPTION:An operating system has an overly permission Access Control List onsome system files, including those related to user passwords:LINK:https://www.cve.org/CVERecord?id=CVE-2021-36934::",,,"",::1::180::,"",
+1221,"Incorrect Register Defaults or Module Parameters",Base,Incomplete,"Hardware description language code incorrectly defines register defaults or hardware Intellectual Property (IP) parameters to insecure values.","Integrated circuits and hardware IP software programmable controls and settings are commonly stored in register circuits. These register contents have to be initialized at hardware reset to defined default values that are hard coded in the hardware description language (HDL) code of the hardware unit. Hardware descriptive languages also support definition of parameter variables, which can be defined in code during instantiation of the hardware IP module. Such parameters are generally used to configure a specific instance of a hardware IP in the design. The system security settings of a hardware design can be affected by incorrectly defined default values or IP parameters. The hardware IP would be in an insecure state at power reset, and this can be exposed or exploited by untrusted software running on the system. Both register defaults and parameters are hardcoded values, which cannot be changed using software or firmware patches but must be changed in hardware silicon. Thus, such security issues are considerably more difficult to address later in the lifecycle. Hardware designs can have a large number of such parameters and register defaults settings, and it is important to have design tool support to check these settings in an automated way and be able to identify which settings are security sensitive.",::NATURE:ChildOf:CWE ID:1419:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE NAME:Verilog:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:VHDL:LANGUAGE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Implementation:NOTE:Such issues could be introduced during implementation of hardware design, since IP parameters and defaults are defined in HDL code and identified later during Testing or System Configuration phases.::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Access Control:IMPACT:Varies by Context:NOTE:Degradation of system functionality, or loss of access control enforcement can occur.::","","::PHASE:Architecture and Design:DESCRIPTION:During hardware design, all the system parameters and register defaults must be reviewed to identify security sensitive settings.::PHASE:Implementation:DESCRIPTION:The default values of these security sensitive settings need to be defined as part of the design review phase.::PHASE:Testing:DESCRIPTION:Testing phase should use automated tools to test that values are configured per design specifications.::","",,,"",::166::,"",
+1222,"Insufficient Granularity of Address Regions Protected by Register Locks",Variant,Incomplete,"The product defines a large address region protected from modification by the same register lock control bit. This results in a conflict between the functional requirement that some addresses need to be writable by software during operation and the security requirement that the system configuration lock bit must be set during the boot process.","Integrated circuits and hardware IPs can expose the device configuration controls that need to be programmed after device power reset by a trusted firmware or software module (commonly set by BIOS/bootloader) and then locked from any further modification. In hardware design, this is commonly implemented using a programmable lock bit which enables/disables writing to a protected set of registers or address regions. When the programmable lock bit is set, the relevant address region can be implemented as a hardcoded value in hardware logic that cannot be changed later. A problem can arise wherein the protected region definition is not granular enough. After the programmable lock bit has been set, then this new functionality cannot be implemented without change to the hardware design.",::NATURE:ChildOf:CWE ID:1220:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:Such issues are introduced during hardware architecture and design since software controls and configuration are defined during these phases and identified later during Testing or System Configuration phases.::","",,"::SCOPE:Access Control:IMPACT:Other:NOTE:System security configuration cannot be defined in a way that does not conflict with functional requirements of device.::","","::PHASE:Architecture and Design:DESCRIPTION:The defining of protected locked registers should be reviewed or tested early in the design phase with software teams to ensure software flows are not blocked by the security locks. As an alternative to using register lock control bits and fixed access control regions, the hardware design could use programmable security access control configuration so that device trusted firmware can configure and change the protected regions based on software usage and security models.::","",,,"",::679::,"",
+1223,"Race Condition for Write-Once Attributes",Base,Incomplete,"A write-once register in hardware design is programmable by an untrusted software component earlier than the trusted software component, resulting in a race condition issue.","Integrated circuits and hardware IP software programmable controls and settings are commonly stored in register circuits. These register contents have to be initialized at hardware reset to defined default values that are hard coded in the hardware description language (HDL) code of the hardware unit. A common security protection method used to protect register settings from modification by software is to make them write-once. This means the hardware implementation only allows writing to such registers once, and they become read-only after having been written once by software. This is useful to allow initial boot software to configure systems settings to secure values while blocking runtime software from modifying such hardware settings. Implementation issues in hardware design of such controls can expose such registers to a race condition security flaw. For example, consider a hardware design that has two different software/firmware modules executing in parallel. One module is trusted (module A) and another is untrusted (module B). In this design it could be possible for Module B to send write cycles to the write-once register before Module A. Since the field is write-once the programmed value from Module A will be ignored and the pre-empted value programmed by Module B will be used by hardware.",::NATURE:ChildOf:CWE ID:362:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE NAME:Verilog:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:VHDL:LANGUAGE PREVALENCE:Undetermined::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:This weakness can appear in designs that use register write-once attributes with two or more software/firmware modules with varying levels of trust executing in parallel.::","",,"::SCOPE:Access Control:IMPACT:Bypass Protection Mechanism:NOTE:System configuration cannot be programmed in a secure way.::","","::PHASE:Architecture and Design:DESCRIPTION:During hardware design all register write-once or sticky fields must be evaluated for proper configuration.::PHASE:Testing:DESCRIPTION:The testing phase should use automated tools to test that values are not reprogrammable and that write-once fields lock on writing zeros.::","",,,"",::26::,"",
+1224,"Improper Restriction of Write-Once Bit Fields",Base,Incomplete,"The hardware design control register sticky bits or write-once bit fields are improperly implemented, such that they can be reprogrammed by software.","Integrated circuits and hardware IP software programmable controls and settings are commonly stored in register circuits. These register contents have to be initialized at hardware reset to define default values that are hard coded in the hardware description language (HDL) code of the hardware unit. A common security protection method used to protect register settings from modification by software is to make the settings write-once or sticky. This allows writing to such registers only once, whereupon they become read-only. This is useful to allow initial boot software to configure systems settings to secure values while blocking runtime software from modifying such hardware settings. Failure to implement write-once restrictions in hardware design can expose such registers to being re-programmed by software and written multiple times. For example, write-once fields could be implemented to only be write-protected if they have been set to value 1, wherein they would work as write-1-once and not write-once.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE NAME:Verilog:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:VHDL:LANGUAGE PREVALENCE:Undetermined::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation:NOTE:Such issues could be introduced during implementation of hardware design, since IP parameters and defaults are defined in HDL code and identified later during Testing or System Configuration phases.::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Access Control:IMPACT:Varies by Context:NOTE:System configuration cannot be programmed in a secure way.::","","::PHASE:Architecture and Design:DESCRIPTION:During hardware design all register write-once or sticky fields must be evaluated for proper configuration.::PHASE:Testing:DESCRIPTION:The testing phase should use automated tools to test that values are not reprogrammable and that write-once fields lock on writing zeros.::","",,,"",::680::,"",
+1231,"Improper Prevention of Lock Bit Modification",Base,Stable,"The product uses a trusted lock bit for restricting access to registers, address regions, or other resources, but the product does not prevent the value of the lock bit from being modified after it has been set.","In integrated circuits and hardware intellectual property (IP) cores, device configuration controls are commonly programmed after a device power reset by a trusted firmware or software module (e.g., BIOS/bootloader) and then locked from any further modification. This behavior is commonly implemented using a trusted lock bit. When set, the lock bit disables writes to a protected set of registers or address regions. Design or coding errors in the implementation of the lock bit protection feature may allow the lock bit to be modified or cleared by software after it has been set. Attackers might be able to unlock the system and features that the bit is intended to protect.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:Such issues could be introduced during hardware architecture and design and identified later during Testing or System Configuration phases.::PHASE:Implementation:NOTE:Such issues could be introduced during implementation and identified later during Testing or System Configuration phases.::","",,"::SCOPE:Access Control:IMPACT:Modify Memory:LIKELIHOOD:High:NOTE:Registers protected by lock bit can be modified even when lock is set.::","::METHOD:Manual Analysis:DESCRIPTION:Set the lock bit. Power cycle the device. Attempt to clear the lock bit. If the information is changed, implement a design fix. Retest. Also, attempt to indirectly clear the lock bit or bypass it.:EFFECTIVENESS:High::","::PHASE:Architecture and Design Implementation Testing:DESCRIPTION:Security lock bit protections must be reviewed for design inconsistency and common weaknesses. Security lock programming flow and lock properties must be tested in pre-silicon and post-silicon testing.:EFFECTIVENESS:High::","::REFERENCE:CVE-2017-6283:DESCRIPTION:chip reset clears critical read/write lock permissions for RSA function:LINK:https://www.cve.org/CVERecord?id=CVE-2017-6283::",,,"",::680::,"",
+1232,"Improper Lock Behavior After Power State Transition",Base,Incomplete,"Register lock bit protection disables changes to system configuration once the bit is set. Some of the protected registers or lock bits become programmable after power state transitions (e.g., Entry and wake from low power sleep modes) causing the system configuration to be changeable.","Devices may allow device configuration controls which need to be programmed after device power reset via a trusted firmware or software module (commonly set by BIOS/bootloader) and then locked from any further modification. This action is commonly implemented using a programmable lock bit, which, when set, disables writes to a protected set of registers or address regions. After a power state transition, the lock bit is set to unlocked. Some common weaknesses that can exist in such a protection scheme are that the lock gets cleared, the values of the protected registers get reset, or the lock become programmable.",::NATURE:ChildOf:CWE ID:667:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Access Control:IMPACT:Modify Memory:LIKELIHOOD:High::","","::PHASE:Architecture and Design Implementation Testing:DESCRIPTION:Security Lock bit protections should be reviewed for behavior across supported power state transitions. Security lock programming flow and lock properties should be tested in pre-silicon and post-silicon testing including testing across power transitions.:EFFECTIVENESS:High::","",,,"",::166::,"",
+1233,"Security-Sensitive Hardware Controls with Missing Lock Bit Protection",Base,Stable,"The product uses a register lock bit protection mechanism, but it does not ensure that the lock bit prevents modification of system registers or controls that perform changes to important hardware system configuration.","Integrated circuits and hardware intellectual properties (IPs) might provide device configuration controls that need to be programmed after device power reset by a trusted firmware or software module, commonly set by BIOS/bootloader. After reset, there can be an expectation that the controls cannot be used to perform any further modification. This behavior is commonly implemented using a trusted lock bit, which can be set to disable writes to a protected set of registers or address regions. The lock protection is intended to prevent modification of certain system configuration (e.g., memory/memory protection unit configuration). However, if the lock bit does not effectively write-protect all system registers or controls that could modify the protected system configuration, then an adversary may be able to use software to access the registers/controls and modify the protected hardware configuration.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:667:VIEW ID:1000::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:Such issues could be introduced during hardware architecture and design and identified later during Testing or System Configuration phases.::PHASE:Implementation:NOTE:Such issues could be introduced during implementation and identified later during Testing or System Configuration phases.::","",,"::SCOPE:Access Control:IMPACT:Modify Memory:NOTE:System Configuration protected by the lock bit can be modified even when the lock is set.::","::METHOD:Manual Analysis:DESCRIPTION:Set the lock bit. Attempt to modify the information protected by the lock bit. If the information is changed, implement a design fix. Retest. Also, attempt to indirectly clear the lock bit or bypass it.:EFFECTIVENESS:High::","::PHASE:Architecture and Design Implementation Testing:DESCRIPTION:Security lock bit protections must be reviewed for design inconsistency and common weaknesses. Security lock programming flow and lock properties must be tested in pre-silicon and post-silicon testing.::","::REFERENCE:CVE-2018-9085:DESCRIPTION:Certain servers leave a write protection lock bit unset after boot, potentially allowing modification of parts of flash memory.:LINK:https://www.cve.org/CVERecord?id=CVE-2018-9085::REFERENCE:CVE-2014-8273:DESCRIPTION:Chain: chipset has a race condition (CWE-362) between when an interrupt handler detects an attempt to write-enable the BIOS (in violation of the lock bit), and when the handler resets the write-enable bit back to 0, allowing attackers to issue BIOS writes during the timing window [REF-1237].:LINK:https://www.cve.org/CVERecord?id=CVE-2014-8273::",,,"",::176::680::,"",
+1234,"Hardware Internal or Debug Modes Allow Override of Locks",Base,Incomplete,"System configuration protection may be bypassed during debug mode.","Device configuration controls are commonly programmed after a device power reset by a trusted firmware or software module (e.g., BIOS/bootloader) and then locked from any further modification. This is commonly implemented using a trusted lock bit, which when set, disables writes to a protected set of registers or address regions. The lock protection is intended to prevent modification of certain system configuration (e.g., memory/memory protection unit configuration). If debug features supported by hardware or internal modes/system states are supported in the hardware design, modification of the lock protection may be allowed allowing access and modification of configuration information.",::NATURE:ChildOf:CWE ID:667:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Access Control:IMPACT:Bypass Protection Mechanism:LIKELIHOOD:High:NOTE:Bypass of lock bit allows access and modification of system configuration even when the lock bit is set.::","","::PHASE:Architecture and Design Implementation Testing:DESCRIPTION:Security Lock bit protections should be reviewed for any bypass/override modes supported. Any supported override modes either should be removed or protected using authenticated debug modes. Security lock programming flow and lock properties should be tested in pre-silicon and post-silicon testing.:EFFECTIVENESS:High::","",,,"",::176::,"",
+1239,"Improper Zeroization of Hardware Register",Variant,Draft,"The hardware product does not properly clear sensitive information from built-in registers when the user of the hardware block changes.","Hardware logic operates on data stored in registers local to the hardware block. Most hardware IPs, including cryptographic accelerators, rely on registers to buffer I/O, store intermediate values, and interface with software. The result of this is that sensitive information, such as passwords or encryption keys, can exist in locations not transparent to the user of the hardware logic. When a different entity obtains access to the IP due to a change in operating mode or conditions, the new entity can extract information belonging to the previous user if no mechanisms are in place to clear register contents. It is important to clear information stored in the hardware if a physical attack on the product is detected, or if the user of the hardware block changes. The process of clearing register contents in a hardware IP is referred to as zeroization in standards for cryptographic hardware modules such as FIPS-140-2 [REF-267].",::NATURE:ChildOf:CWE ID:226:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:226:VIEW ID:1194:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:Lack of hardware mechanisms to zeroize or clear registers in the design or specification.::PHASE:Implementation:NOTE:Mechanisms to zeroize and clear registers are in the design but implemented incorrectly.::PHASE:Operation:NOTE:Hardware-provided zeroization mechanisms are not used appropriately by the IP user (ex. firmware), or data remanence issues are not taken into account.::","",,"::SCOPE:Confidentiality:IMPACT:Varies by Context:NOTE:The consequences will depend on the information disclosed due to the vulnerability.::","","::PHASE:Architecture and Design:DESCRIPTION:Every register potentially containing sensitive information must have a policy specifying how and when information is cleared, in addition to clarifying if it is the responsibility of the hardware logic or IP user to initiate the zeroization procedure at the appropriate time.::","",,,"",::150::204::37::545::,"",
+1240,"Use of a Cryptographic Primitive with a Risky Implementation",Base,Draft,"To fulfill the need for a cryptographic primitive, the product implements a cryptographic algorithm using a non-standard, unproven, or disallowed/non-compliant cryptographic implementation.","Cryptographic protocols and systems depend on cryptographic primitives (and associated algorithms) as their basic building blocks. Some common examples of primitives are digital signatures, one-way hash functions, ciphers, and public key cryptography; however, the notion of primitive can vary depending on point of view. See Terminology Notes for further explanation of some concepts. Cryptographic primitives are defined to accomplish one very specific task in a precisely defined and mathematically reliable fashion. For example, suppose that for a specific cryptographic primitive (such as an encryption routine), the consensus is that the primitive can only be broken after trying out N different inputs (where the larger the value of N, the stronger the cryptography). For an encryption scheme like AES-256, one would expect N to be so large as to be infeasible to execute in a reasonable amount of time. If a vulnerability is ever found that shows that one can break a cryptographic primitive in significantly less than the expected number of attempts, then that primitive is considered weakened (or sometimes in extreme cases, colloquially it is broken). As a result, anything using this cryptographic primitive would now be considered insecure or risky. Thus, even breaking or weakening a seemingly small cryptographic primitive has the potential to render the whole system vulnerable, due to its reliance on the primitive. A historical example can be found in TLS when using DES. One would colloquially call DES the cryptographic primitive for transport encryption in this version of TLS. In the past, DES was considered strong, because no weaknesses were found in it; importantly, DES has a key length of 56 bits. Trying N=2^56 keys was considered impractical for most actors. Unfortunately, attacking a system with 56-bit keys is now practical via brute force, which makes defeating DES encryption practical. It is now practical for an adversary to read any information sent under this version of TLS and use this information to attack the system. As a result, it can be claimed that this use of TLS is weak, and that any system depending on TLS with DES could potentially render the entire system vulnerable to attack. Cryptographic primitives and associated algorithms are only considered safe after extensive research and review from experienced cryptographers from academia, industry, and government entities looking for any possible flaws. Furthermore, cryptographic primitives and associated algorithms are frequently reevaluated for safety when new mathematical and attack techniques are discovered. As a result and over time, even well-known cryptographic primitives can lose their compliance status with the discovery of novel attacks that might either defeat the algorithm or reduce its robustness significantly. If ad-hoc cryptographic primitives are implemented, it is almost certain that the implementation will be vulnerable to attacks that are well understood by cryptographers, resulting in the exposure of sensitive information and other consequences. This weakness is even more difficult to manage for hardware-implemented deployment of cryptographic algorithms. First, because hardware is not patchable as easily as software, any flaw discovered after release and production typically cannot be fixed without a recall of the product. Secondly, the hardware product is often expected to work for years, during which time computation power available to the attacker only increases. Therefore, for hardware implementations of cryptographic primitives, it is absolutely essential that only strong, proven cryptographic primitives are used.",::NATURE:ChildOf:CWE ID:327:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:This weakness is primarily introduced during the architecture and design phase as risky primitives are included.::PHASE:Implementation:NOTE:Even in cases where the Architectural phase properly specifies a cryptographically secure design, the design may be changed during implementation due to unforeseen constraints.::","",,"::SCOPE:Confidentiality:IMPACT:Read Application Data:LIKELIHOOD:High:NOTE:Incorrect usage of crypto primitives could render the supposedly encrypted data as unencrypted plaintext in the worst case.::","::METHOD:Architecture or Design Review:DESCRIPTION:Review requirements, documentation, and product design to ensure that primitives are consistent with the strongest-available recommendations from trusted parties. If the product appears to be using custom or proprietary implementations that have not had sufficient public review and approval, then this is a significant concern.:EFFECTIVENESS:High::METHOD:Manual Analysis:DESCRIPTION:Analyze the product to ensure that implementations for each primitive do not contain any known vulnerabilities and are not using any known-weak algorithms, including MD4, MD5, SHA1, DES, etc.:EFFECTIVENESS:Moderate::METHOD:Dynamic Analysis with Manual Results Interpretation:DESCRIPTION:For hardware, during the implementation (pre-Silicon / post-Silicon) phase, dynamic tests should be done to ensure that outputs from cryptographic routines are indeed working properly, such as test vectors provided by NIST [REF-1236].:EFFECTIVENESS:Moderate::METHOD:Dynamic Analysis with Manual Results Interpretation:DESCRIPTION:It needs to be determined if the output of a cryptographic primitive is lacking entropy, which is one clear sign that something went wrong with the crypto implementation. There exist many methods of measuring the entropy of a bytestream, from sophisticated ones (like calculating Shannon's entropy of a sequence of characters) to crude ones (by compressing it and comparing the size of the original bytestream vs. the compressed - a truly random byte stream should not be compressible and hence the uncompressed and compressed bytestreams should be nearly identical in size).:EFFECTIVENESS:Moderate::","::PHASE:Requirements:DESCRIPTION:Require compliance with the strongest-available recommendations from trusted parties, and require that compliance must be kept up-to-date, since recommendations evolve over time. For example, US government systems require FIPS 140-3 certification, which supersedes FIPS 140-2 [REF-1192] [REF-1226].:EFFECTIVENESS:High::PHASE:Architecture and Design:DESCRIPTION:Ensure that the architecture/design uses the strongest-available primitives and algorithms from trusted parties. For example, US government systems require FIPS 140-3 certification, which supersedes FIPS 140-2 [REF-1192] [REF-1226].:EFFECTIVENESS:High::PHASE:Architecture and Design:DESCRIPTION:Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. As with all cryptographic mechanisms, the source code should be available for analysis. If the algorithm may be compromised when attackers find out how it works, then it is especially weak.:EFFECTIVENESS:Discouraged Common Practice::PHASE:Architecture and Design:DESCRIPTION:Try not to use cryptographic algorithms in novel ways or with new modes of operation even when you know it is secure. For example, using SHA-2 chaining to create a 1-time pad for encryption might sound like a good idea, but one should not do this.:EFFECTIVENESS:Discouraged Common Practice::PHASE:Architecture and Design:DESCRIPTION:Ensure that the design can replace one cryptographic primitive or algorithm with another in the next generation (cryptographic agility). Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. This is especially important for hardware, which can be more difficult to upgrade quickly than software; design the hardware at a replaceable block level.:EFFECTIVENESS:Defense in Depth::PHASE:Architecture and Design:DESCRIPTION:Do not use outdated or non-compliant cryptography algorithms. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong [REF-267].:EFFECTIVENESS:Discouraged Common Practice::PHASE:Architecture and Design Implementation:DESCRIPTION:Do not use a linear-feedback shift register (LFSR) or other legacy methods as a substitute for an accepted and standard Random Number Generator.:EFFECTIVENESS:Discouraged Common Practice::PHASE:Architecture and Design Implementation:DESCRIPTION:Do not use a checksum as a substitute for a cryptographically generated hash.:EFFECTIVENESS:Discouraged Common Practice::PHASE:Architecture and Design:STRATEGY:Libraries or Frameworks:DESCRIPTION:Use a vetted cryptographic library or framework. Industry-standard implementations will save development time and are more likely to avoid errors that can occur during implementation of cryptographic algorithms. However, the library/framework could be used incorrectly during implementation.:EFFECTIVENESS:High::PHASE:Architecture and Design Implementation:DESCRIPTION:When using industry-approved techniques, use them correctly. Don't cut corners by skipping resource-intensive steps (CWE-325). These steps are often essential for the prevention of common attacks.:EFFECTIVENESS:Moderate::PHASE:Architecture and Design Implementation:DESCRIPTION:Do not store keys in areas accessible to untrusted agents. Carefully manage and protect the cryptographic keys (see CWE-320). If the keys can be guessed or stolen, then the strength of the cryptography algorithm is irrelevant.:EFFECTIVENESS:Moderate::","::REFERENCE:CVE-2020-4778:DESCRIPTION:software uses MD5, which is less safe than the default SHA-256 used by related products:LINK:https://www.cve.org/CVERecord?id=CVE-2020-4778::REFERENCE:CVE-2005-2946:DESCRIPTION:Default configuration of product uses MD5 instead of stronger algorithms that are available, simplifying forgery of certificates.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-2946::REFERENCE:CVE-2019-3907:DESCRIPTION:identity card uses MD5 hash of a salt and password:LINK:https://www.cve.org/CVERecord?id=CVE-2019-3907::REFERENCE:CVE-2021-34687:DESCRIPTION:personal key is transmitted over the network using a substitution cipher:LINK:https://www.cve.org/CVERecord?id=CVE-2021-34687::REFERENCE:CVE-2020-14254:DESCRIPTION:product does not disable TLS-RSA cipher suites, allowing decryption of traffic if TLS 2.0 and secure ciphers are not enabled.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-14254::REFERENCE:CVE-2019-1543:DESCRIPTION:SSL/TLS library generates 16-byte nonces but reduces them to 12 byte nonces for the ChaCha20-Poly1305 cipher, converting them in a way that violates the cipher's requirements for unique nonces.:LINK:https://www.cve.org/CVERecord?id=CVE-2019-1543::REFERENCE:CVE-2017-9267:DESCRIPTION:LDAP interface allows use of weak ciphers:LINK:https://www.cve.org/CVERecord?id=CVE-2017-9267::REFERENCE:CVE-2017-7971:DESCRIPTION:SCADA product allows use of outdated cipher suites:LINK:https://www.cve.org/CVERecord?id=CVE-2017-7971::REFERENCE:CVE-2020-6616:DESCRIPTION:Chip implementing Bluetooth uses a low-entropy PRNG instead of a hardware RNG, allowing spoofing.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-6616::REFERENCE:CVE-2019-1715:DESCRIPTION:security product has insufficient entropy in the DRBG, allowing collisions and private key discovery:LINK:https://www.cve.org/CVERecord?id=CVE-2019-1715::REFERENCE:CVE-2014-4192:DESCRIPTION:Dual_EC_DRBG implementation in RSA toolkit does not correctly handle certain byte requests, simplifying plaintext recovery:LINK:https://www.cve.org/CVERecord?id=CVE-2014-4192::REFERENCE:CVE-2007-6755:DESCRIPTION:Recommendation for Dual_EC_DRBG algorithm contains point Q constants that could simplify decryption:LINK:https://www.cve.org/CVERecord?id=CVE-2007-6755::",,,"",::97::,"::TYPE:Terminology:NOTE:Terminology for cryptography varies widely, from informal and colloquial to mathematically-defined, with different precision and formalism depending on whether the stakeholder is a developer, cryptologist, etc. Yet there is a need for CWE to be self-consistent while remaining understandable and acceptable to multiple audiences. As of CWE 4.6, CWE terminology around primitives and algorithms is emerging as shown by the following example, subject to future consultation and agreement within the CWE and cryptography communities. Suppose one wishes to send encrypted data using a CLI tool such as OpenSSL. One might choose to use AES with a 256-bit key and require tamper protection (GCM mode, for instance). For compatibility's sake, one might also choose the ciphertext to be formatted to the PKCS#5 standard. In this case, the cryptographic system would be AES-256-GCM with PKCS#5 formatting. The cryptographic function would be AES-256 in the GCM mode of operation, and the algorithm would be AES. Colloquially, one would say that AES (and sometimes AES-256) is the cryptographic primitive, because it is the algorithm that realizes the concept of symmetric encryption (without modes of operation or other protocol related modifications). In practice, developers and architects typically refer to base cryptographic algorithms (AES, SHA, etc.) as cryptographic primitives.::TYPE:Maintenance:NOTE:Since CWE 4.4, various cryptography-related entries, including CWE-327 and CWE-1240, have been slated for extensive research, analysis, and community consultation to define consistent terminology, improve relationships, and reduce overlap or duplication. As of CWE 4.6, this work is still ongoing.::",
+1241,"Use of Predictable Algorithm in Random Number Generator",Base,Draft,"The device uses an algorithm that is predictable and generates a pseudo-random number.","Pseudo-random number generator algorithms are predictable because their registers have a finite number of possible states, which eventually lead to repeating patterns. As a result, pseudo-random number generators (PRNGs) can compromise their randomness or expose their internal state to various attacks, such as reverse engineering or tampering. It is highly recommended to use hardware-based true random number generators (TRNGs) to ensure the security of encryption schemes. TRNGs generate unpredictable, unbiased, and independent random numbers because they employ physical phenomena, e.g., electrical noise, as sources to generate random numbers.",::NATURE:ChildOf:CWE ID:330:VIEW ID:1000:ORDINAL:Primary::,"",::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation:NOTE:In many cases, the design originally defines a cryptographically secure random number generator, but is then changed during implementation due to unforeseen constraints.::","",,"::SCOPE:Confidentiality:IMPACT:Read Application Data:LIKELIHOOD:High::","","::PHASE:Architecture and Design:DESCRIPTION:A true random number generator should be specified for cryptographic algorithms.::PHASE:Implementation:DESCRIPTION:A true random number generator should be implemented for cryptographic algorithms.::","::REFERENCE:CVE-2021-3692:DESCRIPTION:PHP framework uses mt_rand() function (Marsenne Twister) when generating tokens:LINK:https://www.cve.org/CVERecord?id=CVE-2021-3692::",,,"",::97::,"::TYPE:Maintenance:NOTE:As of CWE 4.5, terminology related to randomness, entropy, and predictability can vary widely. Within the developer and other communities, randomness is used heavily. However, within cryptography, entropy is distinct, typically implied as a measurement. There are no commonly-used definitions, even within standards documents and cryptography papers. Future versions of CWE will attempt to define these terms and, if necessary, distinguish between them in ways that are appropriate for different communities but do not reduce the usability of CWE for mapping, understanding, or other scenarios.::",
+1242,"Inclusion of Undocumented Features or Chicken Bits",Base,Incomplete,"The device includes chicken bits or undocumented features that can create entry points for unauthorized actors.","A common design practice is to use undocumented bits on a device that can be used to disable certain functional security features. These bits are commonly referred to as chicken bits. They can facilitate quick identification and isolation of faulty components, features that negatively affect performance, or features that do not provide the required controllability for debug and test. Another way to achieve this is through implementation of undocumented features. An attacker might exploit these interfaces for unauthorized access.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:ICS/OT:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::PHASE:Documentation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Access Control:IMPACT:Modify Memory:IMPACT:Read Memory:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Gain Privileges or Assume Identity:IMPACT:Bypass Protection Mechanism::","","::PHASE:Architecture and Design Implementation:DESCRIPTION:The implementation of chicken bits in a released product is highly discouraged. If implemented at all, ensure that they are disabled in production devices. All interfaces to a device should be documented.:EFFECTIVENESS:High::","",,,"::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-1:ENTRY NAME:Req SD-4::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-1:ENTRY NAME:Req SVV-3::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-2:ENTRY NAME:Req CR 2.12::",::212::36::,"",
+1243,"Sensitive Non-Volatile Information Not Protected During Debug",Base,Incomplete,"Access to security-sensitive information stored in fuses is not limited during debug.","Several security-sensitive values are programmed into fuses to be used during early-boot flows or later at runtime. Examples of these security-sensitive values include root keys, encryption keys, manufacturing-specific information, chip-manufacturer-specific information, and original-equipment-manufacturer (OEM) data. After the chip is powered on, these values are sensed from fuses and stored in temporary locations such as registers and local memories. These locations are typically access-control protected from untrusted agents capable of accessing them. Even to trusted agents, only read-access is provided. However, these locations are not blocked during debug operations, allowing a user to access this sensitive information.",::NATURE:ChildOf:CWE ID:1263:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Access Control:IMPACT:Modify Memory:IMPACT:Bypass Protection Mechanism::","","::PHASE:Architecture and Design Implementation:DESCRIPTION:Disable access to security-sensitive information stored in fuses directly and also reflected from temporary storage locations when in debug mode.::","",,,"",::116::545::,"",
+1244,"Internal Asset Exposed to Unsafe Debug Access Level or State",Base,Stable,"The product uses physical debug or test interfaces with support for multiple access levels, but it assigns the wrong debug access level to an internal asset, providing unintended access to the asset from untrusted debug agents.","Debug authorization can have multiple levels of access, defined such that different system internal assets are accessible based on the current authorized debug level. Other than debugger authentication (e.g., using passwords or challenges), the authorization can also be based on the system state or boot stage. For example, full system debug access might only be allowed early in boot after a system reset to ensure that previous session data is not accessible to the authenticated debugger. If this protection mechanism does not ensure that internal assets have the correct debug access level during each boot stage or change in system state, an attacker could obtain sensitive information from the internal asset using a debugger.",::NATURE:ChildOf:CWE ID:863:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Confidentiality:IMPACT:Read Memory::SCOPE:Integrity:IMPACT:Modify Memory::SCOPE:Authorization:SCOPE:Access Control:IMPACT:Gain Privileges or Assume Identity:IMPACT:Bypass Protection Mechanism::","::METHOD:Manual Analysis:DESCRIPTION:Check 2 devices for their passcode to authenticate access to JTAG/debugging ports. If the passcodes are missing or the same, update the design to fix and retest. Check communications over JTAG/debugging ports for encryption. If the communications are not encrypted, fix the design and retest.:EFFECTIVENESS:Moderate::","::PHASE:Architecture and Design Implementation:DESCRIPTION:For security-sensitive assets accessible over debug/test interfaces, only allow trusted agents.:EFFECTIVENESS:High::PHASE:Architecture and Design:DESCRIPTION:Apply blinding [REF-1219] or masking techniques in strategic areas.:EFFECTIVENESS:Limited::PHASE:Implementation:DESCRIPTION:Add shielding or tamper-resistant protections to the device, which increases the difficulty and cost for accessing debug/test interfaces.:EFFECTIVENESS:Limited::","::REFERENCE:CVE-2019-18827:DESCRIPTION:After ROM code execution, JTAG access is disabled. But before the ROM code is executed, JTAG access is possible, allowing a user full system access. This allows a user to modify the boot flow and successfully bypass the secure-boot process.:LINK:https://www.cve.org/CVERecord?id=CVE-2019-18827::",,,"",::114::,"::TYPE:Relationship:NOTE:CWE-1191 and CWE-1244 both involve physical debug access, but the weaknesses are different. CWE-1191 is effectively about missing authorization for a debug interface, i.e. JTAG. CWE-1244 is about providing internal assets with the wrong debug access level, exposing the asset to untrusted debug agents.::",
+1245,"Improper Finite State Machines (FSMs) in Hardware Logic",Base,Incomplete,"Faulty finite state machines (FSMs) in the hardware logic allow an attacker to put the system in an undefined state, to cause a denial of service (DoS) or gain privileges on the victim's system.","The functionality and security of the system heavily depend on the implementation of FSMs. FSMs can be used to indicate the current security state of the system. Lots of secure data operations and data transfers rely on the state reported by the FSM. Faulty FSM designs that do not account for all states, either through undefined states (left as don't cares) or through incorrect implementation, might lead an attacker to drive the system into an unstable state from which the system cannot recover without a reset, thus causing a DoS. Depending on what the FSM is used for, an attacker might also gain additional privileges to launch further attacks and compromise the security guarantees.",::NATURE:ChildOf:CWE ID:684:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Availability:SCOPE:Access Control:IMPACT:Unexpected State:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:DoS: Instability:IMPACT:Gain Privileges or Assume Identity::","","::PHASE:Architecture and Design Implementation:DESCRIPTION:Define all possible states and handle all unused states through default statements. Ensure that system defaults to a secure state.:EFFECTIVENESS:High::","",,,"",::74::,"",
+1246,"Improper Write Handling in Limited-write Non-Volatile Memories",Base,Incomplete,"The product does not implement or incorrectly implements wear leveling operations in limited-write non-volatile memories.","Non-volatile memories such as NAND Flash, EEPROM, etc. have individually erasable segments, each of which can be put through a limited number of program/erase or write cycles. For example, the device can only endure a limited number of writes, after which the device becomes unreliable. In order to wear out the cells in a uniform manner, non-volatile memory and storage products based on the above-mentioned technologies implement a technique called wear leveling. Once a set threshold is reached, wear leveling maps writes of a logical block to a different physical block. This prevents a single physical block from prematurely failing due to a high concentration of writes. If wear leveling is improperly implemented, attackers may be able to programmatically cause the storage to become unreliable within a much shorter time than would normally be expected.",::NATURE:ChildOf:CWE ID:400:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Memory Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Storage Hardware:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Availability:IMPACT:DoS: Instability::","","::PHASE:Architecture and Design Implementation Testing:DESCRIPTION:Include secure wear leveling algorithms and ensure they may not be bypassed.:EFFECTIVENESS:High::","",,,"::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-1:ENTRY NAME:Req SD-4::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-1:ENTRY NAME:Req SI-1::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-1:ENTRY NAME:Req SVV-3::",::212::,"",
+1247,"Improper Protection Against Voltage and Clock Glitches",Base,Stable,"The device does not contain or contains incorrectly implemented circuitry or sensors to detect and mitigate voltage and clock glitches and protect sensitive information or software contained on the device.","A device might support features such as secure boot which are supplemented with hardware and firmware support. This involves establishing a chain of trust, starting with an immutable root of trust by checking the signature of the next stage (culminating with the OS and runtime software) against a golden value before transferring control. The intermediate stages typically set up the system in a secure state by configuring several access control settings. Similarly, security logic for exercising a debug or testing interface may be implemented in hardware, firmware, or both. A device needs to guard against fault attacks such as voltage glitches and clock glitches that an attacker may employ in an attempt to compromise the system.",::NATURE:ChildOf:CWE ID:1384:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:ICS/OT:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Power Management Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Clock/Counter Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Sensor Hardware:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Operation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Access Control:IMPACT:Gain Privileges or Assume Identity:IMPACT:Bypass Protection Mechanism:IMPACT:Read Memory:IMPACT:Modify Memory:IMPACT:Execute Unauthorized Code or Commands::","::METHOD:Manual Analysis:DESCRIPTION:Put the processor in an infinite loop, which is then followed by instructions that should not ever be executed, since the loop is not expected to exit. After the loop, toggle an I/O bit (for oscilloscope monitoring purposes), print a console message, and reenter the loop. Note that to ensure that the loop exit is actually captured, many NOP instructions should be coded after the loop branch instruction and before the I/O bit toggle and the print statement. Margining the clock consists of varying the clock frequency until an anomaly occurs. This could be a continuous frequency change or it could be a single cycle. The single cycle method is described here. For every 1000th clock pulse, the clock cycle is shortened by 10 percent. If no effect is observed, the width is shortened by 20%. This process is continued in 10% increments up to and including 50%. Note that the cycle time may be increased as well, down to seconds per cycle. Separately, the voltage is margined. Note that the voltage could be increased or decreased. Increasing the voltage has limits, as the circuitry may not be able to withstand a drastically increased voltage. This process starts with a 5% reduction of the DC supply to the CPU chip for 5 millisecond repeated at 1KHz. If this has no effect, the process is repeated, but a 10% reduction is used. This process is repeated at 10% increments down to a 50% reduction. If no effects are observed at 5 millisecond, the whole process is repeated using a 10 millisecond pulse. If no effects are observed, the process is repeated in 10 millisecond increments out to 100 millisecond pulses. While these are suggested starting points for testing circuitry for weaknesses, the limits may need to be pushed further at the risk of device damage. See [REF-1217] for descriptions of Smart Card attacks against a clock (section 14.6.2) and using a voltage glitch (section 15.5.3).:EFFECTIVENESS:Moderate::METHOD:Dynamic Analysis with Manual Results Interpretation:DESCRIPTION:During the implementation phase where actual hardware is available, specialized hardware tools and apparatus such as ChipWhisperer may be used to check if the platform is indeed susceptible to voltage and clock glitching attacks.::METHOD:Architecture or Design Review:DESCRIPTION:Review if the protections against glitching merely transfer the attack target. For example, suppose a critical authentication routine that an attacker would want to bypass is given the protection of modifying certain artifacts from within that specific routine (so that if the routine is bypassed, one can examine the artifacts and figure out that an attack must have happened). However, if the attacker has the ability to bypass the critical authentication routine, they might also have the ability to bypass the other protection routine that checks the artifacts. Basically, depending on these kind of protections is akin to resorting to Security by Obscurity.::METHOD:Architecture or Design Review:DESCRIPTION:Many SoCs come equipped with a built-in Dynamic Voltage and Frequency Scaling (DVFS) that can control the voltage and clocks via software alone. However, there have been demonstrated attacks (like Plundervolt and CLKSCREW) that target this DVFS [REF-1081] [REF-1082]. During the design and implementation phases, one needs to check if the interface to this power management feature is available from unprivileged SW (CWE-1256), which would make the attack very easy.::","::PHASE:Architecture and Design Implementation:DESCRIPTION:At the circuit-level, using Tunable Replica Circuits (TRCs) or special flip-flops such as Razor flip-flops helps mitigate glitch attacks. Working at the SoC or platform base, level sensors may be implemented to detect glitches. Implementing redundancy in security-sensitive code (e.g., where checks are performed)also can help with mitigation of glitch attacks.::","::REFERENCE:CVE-2019-17391:DESCRIPTION:Lack of anti-glitch protections allows an attacker to launch a physical attack to bypass the secure boot and read protected eFuses.:LINK:https://www.cve.org/CVERecord?id=CVE-2019-17391::REFERENCE:CVE-2021-33478:DESCRIPTION:IP communication firmware allows access to a boot shell via certain impulses:LINK:https://www.cve.org/CVERecord?id=CVE-2021-33478::",::Power::Clock::,,"",::624::625::,"",
+1248,"Semiconductor Defects in Hardware Logic with Security-Sensitive Implications",Base,Incomplete,"The security-sensitive hardware module contains semiconductor defects.","A semiconductor device can fail for various reasons. While some are manufacturing and packaging defects, the rest are due to prolonged use or usage under extreme conditions. Some mechanisms that lead to semiconductor defects include encapsulation failure, die-attach failure, wire-bond failure, bulk-silicon defects, oxide-layer faults, aluminum-metal faults (including electromigration, corrosion of aluminum, etc.), and thermal/electrical stress. These defects manifest as faults on chip-internal signals or registers, have the effect of inputs, outputs, or intermediate signals being always 0 or always 1, and do not switch as expected. If such faults occur in security-sensitive hardware modules, the security objectives of the hardware module may be compromised.",::NATURE:ChildOf:CWE ID:693:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Manufacturing:NOTE:May be introduced due to issues in the manufacturing environment or improper handling of components, for example.::PHASE:Operation:NOTE:May be introduced by improper handling or usage outside of rated operating environments (temperature, humidity, etc.)::","",,"::SCOPE:Availability:SCOPE:Access Control:IMPACT:DoS: Instability::","","::PHASE:Testing:DESCRIPTION:While semiconductor-manufacturing companies implement several mechanisms to continuously improve the semiconductor manufacturing process to ensure reduction of defects, some defects can only be fixed after manufacturing. Post-manufacturing testing of silicon die is critical. Fault models such as stuck-at-0 or stuck-at-1 must be used to develop post-manufacturing test cases and achieve good coverage. Once the silicon packaging is done, extensive post-silicon testing must be performed to ensure that hardware logic implementing security functionalities is defect-free.::PHASE:Operation:DESCRIPTION:Operating the hardware outside device specification, such as at extremely high temperatures, voltage, etc., accelerates semiconductor degradation and results in defects. When these defects manifest as faults in security-critical, hardware modules, it results in compromise of security guarantees. Thus, operating the device within the specification is important.::","",,,"",::624::625::,"",
+1250,"Improper Preservation of Consistency Between Independent Representations of Shared State",Base,Incomplete,"The product has or supports multiple distributed components or sub-systems that are each required to keep their own local copy of shared data - such as state or cache - but the product does not ensure that all local copies remain consistent with each other.","In highly distributed environments, or on systems with distinct physical components that operate independently, there is often a need for each component to store and update its own local copy of key data such as state or cache, so that all components have the same view of the overall system and operate in a coordinated fashion. For example, users of a social media service or a massively multiplayer online game might be using their own personal computers while also interacting with different physical hosts in a globally distributed service, but all participants must be able to have the same view of the world. Alternately, a processor's Memory Management Unit (MMU) might have shadow MMUs to distribute its workload, and all shadow MMUs are expected to have the same accessible ranges of memory. In such environments, it becomes critical for the product to ensure that this shared state is consistently modified across all distributed systems. If state is not consistently maintained across all systems, then critical transactions might take place out of order, or some users might not get the same data as other users. When this inconsistency affects correctness of operations, it can introduce vulnerabilities in mechanisms that depend on consistent state.",::NATURE:ChildOf:CWE ID:664:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Cloud Computing:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Security Hardware:TECHNOLOGY PREVALENCE:Undetermined::,"","","","",,"","","","",,,"",,"::TYPE:Research Gap:NOTE:Issues related to state and cache - creation, preservation, and update - are a significant gap in CWE that is expected to be addressed in future versions. It likely has relationships to concurrency and synchronization, incorrect behavior order, and other areas that already have some coverage in CWE, although the focus has typically been on independent processes on the same operating system - not on independent systems that are all a part of a larger system-of-systems.::",
+1251,"Mirrored Regions with Different Values",Base,Incomplete,"The product's architecture mirrors regions without ensuring that their contents always stay in sync.","Having mirrored regions with different values might result in the exposure of sensitive information or possibly system compromise. In the interest of increased performance, one might need to duplicate a resource. A cache memory is a common example of this concept, which keeps a local copy of a data element in the high speed cache memory. Unfortunately, this speed improvement comes with a downside, since the product needs to ensure that the local copy always mirrors the original copy truthfully. If they get out of sync, the computational result is no longer true. During hardware design, memory is not the only item which gets mirrored. There are many other entities that get mirrored, as well: registers, memory regions, and, in some cases, even whole computational units. For example, within a multi-core processor, if all memory accesses for each and every core goes through a single Memory-Management Unit (MMU) then the MMU will become a performance bottleneck. In such cases, duplicating local MMUs that will serve only a subset of the cores rather than all of them may resolve the performance issue. These local copies are also called shadow copies or mirrored copies. If the original resource never changed, local duplicate copies getting out of sync would never be an issue. However, the values of the original copy will sometimes change. When the original copy changes, the mirrored copies must also change, and change fast. This situation of shadow-copy-possibly-out-of-sync-with-original-copy might occur as a result of multiple scenarios, including the following: After the values in the original copy change, due to some reason the original copy does not send the update request to its shadow copies. After the values in the original copy change, the original copy dutifully sends the update request to its shadow copies, but due to some reason the shadow copy does not execute this update request. After the values in the original copy change, the original copy sends the update request to its shadow copies, and the shadow copy executes this update request faithfully. However, during the small time period when the original copy has new values and the shadow copy is still holding the old values, an attacker can exploit the old values. Then it becomes a race condition between the attacker and the update process of who can reach the target, shadow copy first, and, if the attacker reaches first, the attacker wins. The attacker might send a spoofed update request to the target shadow copy, pretending that this update request is coming from the original copy. This spoofed request might cause the targeted shadow copy to update its values to some attacker-friendly values, while the original copies remain unchanged by the attacker. Suppose a situation where the original copy has a system of reverting back to its original value if it does not hear back from all the shadow copies that such copies have successfully completed the update request. In such a case, an attack might occur as follows: (1) the original copy might send an update request; (2) the shadow copy updates it; (3) the shadow copy sends back the successful completion message; (4) through a separate issue, the attacker is able to intercept the shadow copy's completion message. In this case, the original copy thinks that the update did not succeed, hence it reverts to its original value. Now there is a situation where the original copy has the old value, and the shadow copy has the new value.",::NATURE:ChildOf:CWE ID:1250:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE NAME:VHDL:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:Verilog:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::,"","","","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Access Control:SCOPE:Accountability:SCOPE:Authentication:SCOPE:Authorization:SCOPE:Non-Repudiation:IMPACT:Varies by Context::","","::PHASE:Architecture and Design:DESCRIPTION:Whenever there are multiple, physically different copies of the same value that might change and the process to update them is not instantaneous and atomic, it is impossible to assert that the original and shadow copies will always be in sync - there will always be a time period when they are out of sync. To mitigate the consequential risk, the recommendations essentially are: Make this out-of-sync time period as small as possible, and Make the update process as robust as possible.:EFFECTIVENESS:Moderate::","",,,"",,"::TYPE:Research Gap:NOTE:Issues related to state and cache - creation, preservation, and update - are a significant gap in CWE that is expected to be addressed in future versions. It has relationships to concurrency and synchronization, incorrect behavior order, and other areas that already have some coverage in CWE, although the focus has typically been on independent processes on the same operating system - not on independent systems that are all a part of a larger system-of-systems.::",
+1252,"CPU Hardware Not Configured to Support Exclusivity of Write and Execute Operations",Base,Incomplete,"The CPU is not configured to provide hardware support for exclusivity of write and execute operations on memory. This allows an attacker to execute data from all of memory.","CPUs provide a special bit that supports exclusivity of write and execute operations. This bit is used to segregate areas of memory to either mark them as code (instructions, which can be executed) or data (which should not be executed). In this way, if a user can write to a region of memory, the user cannot execute from that region and vice versa. This exclusivity provided by special hardware bit is leveraged by the operating system to protect executable space. While this bit is available in most modern processors by default, in some CPUs the exclusivity is implemented via a memory-protection unit (MPU) and memory-management unit (MMU) in which memory regions can be carved out with exact read, write, and execute permissions. However, if the CPU does not have an MMU/MPU, then there is no write exclusivity. Without configuring exclusivity of operations via segregated areas of memory, an attacker may be able to inject malicious code onto memory and later execute it.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY NAME:Microcontroller Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Processor Hardware:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Execute Unauthorized Code or Commands::","","::PHASE:Architecture and Design:DESCRIPTION:Implement a dedicated bit that can be leveraged by the Operating System to mark data areas as non-executable. If such a bit is not available in the CPU, implement MMU/MPU (memory management unit / memory protection unit).::PHASE:Integration:DESCRIPTION:If MMU/MPU are not available, then the firewalls need to be implemented in the SoC interconnect to mimic the write-exclusivity operation.::","",,,"",::679::,"",
+1253,"Incorrect Selection of Fuse Values",Base,Draft,"The logic level used to set a system to a secure state relies on a fuse being unblown. An attacker can set the system to an insecure state merely by blowing the fuse.","Fuses are often used to store secret data, including security configuration data. When not blown, a fuse is considered to store a logic 0, and, when blown, it indicates a logic 1. Fuses are generally considered to be one-directional, i.e., once blown to logic 1, it cannot be reset to logic 0. However, if the logic used to determine system-security state (by leveraging the values sensed from the fuses) uses negative logic, an attacker might blow the fuse and drive the system to an insecure state.",::NATURE:ChildOf:CWE ID:693:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Access Control:SCOPE:Authorization:IMPACT:Bypass Protection Mechanism:IMPACT:Gain Privileges or Assume Identity::SCOPE:Availability:IMPACT:DoS: Crash, Exit, or Restart::SCOPE:Confidentiality:IMPACT:Read Memory::SCOPE:Integrity:IMPACT:Modify Memory:IMPACT:Execute Unauthorized Code or Commands::","","::PHASE:Architecture and Design:DESCRIPTION:Logic should be designed in a way that blown fuses do not put the product into an insecure state that can be leveraged by an attacker.::","",,,"",::74::,"::TYPE:Maintenance:NOTE:This entry is still under development and will continue to see updates and content improvements.::",
+1254,"Incorrect Comparison Logic Granularity",Base,Draft,"The product's comparison logic is performed over a series of steps rather than across the entire string in one operation. If there is a comparison logic failure on one of these steps, the operation may be vulnerable to a timing attack that can result in the interception of the process for nefarious purposes.","Comparison logic is used to compare a variety of objects including passwords, Message Authentication Codes (MACs), and responses to verification challenges. When comparison logic is implemented at a finer granularity (e.g., byte-by-byte comparison) and breaks in the case of a comparison failure, an attacker can exploit this implementation to identify when exactly the failure occurred. With multiple attempts, the attacker may be able to guesses the correct password/response to challenge and elevate their privileges.",::NATURE:ChildOf:CWE ID:208:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:697:VIEW ID:1000::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Authorization:IMPACT:Bypass Protection Mechanism::","","::PHASE:Implementation:DESCRIPTION:The hardware designer should ensure that comparison logic is implemented so as to compare in one operation instead in smaller chunks.::","::REFERENCE:CVE-2019-10482:DESCRIPTION:Smartphone OS uses comparison functions that are not in constant time, allowing side channels:LINK:https://www.cve.org/CVERecord?id=CVE-2019-10482::REFERENCE:CVE-2019-10071:DESCRIPTION:Java-oriented framework compares HMAC signatures using String.equals() instead of a constant-time algorithm, causing timing discrepancies:LINK:https://www.cve.org/CVERecord?id=CVE-2019-10071::REFERENCE:CVE-2014-0984:DESCRIPTION:Password-checking function in router terminates validation of a password entry when it encounters the first incorrect character, which allows remote attackers to obtain passwords via a brute-force attack that relies on timing differences in responses to incorrect password guesses, aka a timing side-channel attack.:LINK:https://www.cve.org/CVERecord?id=CVE-2014-0984::",,,"",::26::,"",
+1255,"Comparison Logic is Vulnerable to Power Side-Channel Attacks",Variant,Draft,"A device's real time power consumption may be monitored during security token evaluation and the information gleaned may be used to determine the value of the reference token.","The power consumed by a device may be instrumented and monitored in real time. If the algorithm for evaluating security tokens is not sufficiently robust, the power consumption may vary by token entry comparison against the reference value. Further, if retries are unlimited, the power difference between a good entry and a bad entry may be observed and used to determine whether each entry itself is correct thereby allowing unauthorized parties to calculate the reference value.",::NATURE:ChildOf:CWE ID:1300:VIEW ID:1000:ORDINAL:Primary::NATURE:PeerOf:CWE ID:1259:VIEW ID:1194:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:The design of the algorithm itself may intrinsically allow the power side channel attack to be effective::PHASE:Implementation:NOTE:This weakness may be introduced during implementation despite a robust design that otherwise prevents exploitation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Access Control:SCOPE:Accountability:SCOPE:Authentication:SCOPE:Authorization:SCOPE:Non-Repudiation:IMPACT:Modify Memory:IMPACT:Read Memory:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Gain Privileges or Assume Identity:IMPACT:Bypass Protection Mechanism:IMPACT:Read Application Data:IMPACT:Modify Application Data:IMPACT:Hide Activities:NOTE:As compromising a security token may result in complete system control, the impacts are relatively universal::","","::PHASE:Architecture and Design:DESCRIPTION:The design phase must consider each check of a security token against a standard and the amount of power consumed during the check of a good token versus a bad token. The alternative is an all at once check where a retry counter is incremented PRIOR to the check.::PHASE:Architecture and Design:DESCRIPTION:Another potential mitigation is to parallelize shifting of secret data (see example 2 below). Note that the wider the bus the more effective the result.::PHASE:Architecture and Design:DESCRIPTION:An additional potential mitigation is to add random data to each crypto operation then subtract it out afterwards. This is highly effective but costly in performance, area, and power consumption. It also requires a random number generator.::PHASE:Implementation:DESCRIPTION:If the architecture is unable to prevent the attack, using filtering components may reduce the ability to implement an attack, however, consideration must be given to the physical removal of the filter elements.::PHASE:Integration:DESCRIPTION:During integration, avoid use of a single secret for an extended period (e.g. frequent key updates). This limits the amount of data compromised but at the cost of complexity of use.::","::REFERENCE:CVE-2020-12788:DESCRIPTION:CMAC verification vulnerable to timing and power attacks.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-12788::",::Power::,,"",::189::,"",
+1256,"Improper Restriction of Software Interfaces to Hardware Features",Base,Stable,"The product provides software-controllable device functionality for capabilities such as power and clock management, but it does not properly limit functionality that can lead to modification of hardware memory or register bits, or the ability to observe physical side channels.","It is frequently assumed that physical attacks such as fault injection and side-channel analysis require an attacker to have physical access to the target device. This assumption may be false if the device has improperly secured power management features, or similar features. For mobile devices, minimizing power consumption is critical, but these devices run a wide variety of applications with different performance requirements. Software-controllable mechanisms to dynamically scale device voltage and frequency and monitor power consumption are common features in today's chipsets, but they also enable attackers to mount fault injection and side-channel attacks without having physical access to the device. Fault injection attacks involve strategic manipulation of bits in a device to achieve a desired effect such as skipping an authentication step, elevating privileges, or altering the output of a cryptographic operation. Manipulation of the device clock and voltage supply is a well-known technique to inject faults and is cheap to implement with physical device access. Poorly protected power management features allow these attacks to be performed from software. Other features, such as the ability to write repeatedly to DRAM at a rapid rate from unprivileged software, can result in bit flips in other memory locations (Rowhammer, [REF-1083]). Side channel analysis requires gathering measurement traces of physical quantities such as power consumption. Modern processors often include power metering capabilities in the hardware itself (e.g., Intel RAPL) which if not adequately protected enable attackers to gather measurements necessary for performing side-channel attacks from software.",::NATURE:ChildOf:CWE ID:285:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Memory Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Power Management Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Clock/Counter Hardware:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:An architect may initiate introduction of this weakness via exacting requirements for software accessible power/clock management requirements::PHASE:Implementation:NOTE:An implementer may introduce this weakness by assuming there are no consequences to unbounded power and clock management for secure components from untrusted ones.::","",,"::SCOPE:Integrity:IMPACT:Modify Memory:IMPACT:Modify Application Data:IMPACT:Bypass Protection Mechanism::","::METHOD:Manual Analysis:DESCRIPTION:Perform a security evaluation of system-level architecture and design with software-aided physical attacks in scope.::METHOD:Automated Dynamic Analysis:DESCRIPTION:Use custom software to change registers that control clock settings or power settings to try to bypass security locks, or repeatedly write DRAM to try to change adjacent locations. This can be effective in extracting or changing data. The drawback is that it cannot be run before manufacturing, and it may require specialized software.:EFFECTIVENESS:Moderate::","::PHASE:Architecture and Design Implementation:DESCRIPTION:Ensure proper access control mechanisms protect software-controllable features altering physical operating conditions such as clock frequency and voltage.::","::REFERENCE:CVE-2019-11157:DESCRIPTION:Plundervolt: Improper conditions check in voltage settings for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege and/or information disclosure via local access [REF-1081].:LINK:https://www.cve.org/CVERecord?id=CVE-2019-11157::REFERENCE:CVE-2020-8694:DESCRIPTION:PLATYPUS Attack: Insufficient access control in the Linux kernel driver for some Intel processors allows information disclosure.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-8694::REFERENCE:CVE-2020-8695:DESCRIPTION:Observable discrepancy in the RAPL interface for some Intel processors allows information disclosure.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-8695::REFERENCE:CVE-2020-12912:DESCRIPTION:AMD extension to a Linux service does not require privileged access to the RAPL interface, allowing side-channel attacks.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-12912::REFERENCE:CVE-2015-0565:DESCRIPTION:NaCl in 2015 allowed the CLFLUSH instruction, making Rowhammer attacks possible.:LINK:https://www.cve.org/CVERecord?id=CVE-2015-0565::",::Power::Clock::,,"",::624::625::,"",
+1257,"Improper Access Control Applied to Mirrored or Aliased Memory Regions",Base,Incomplete,"Aliased or mirrored memory regions in hardware designs may have inconsistent read/write permissions enforced by the hardware. A possible result is that an untrusted agent is blocked from accessing a memory region but is not blocked from accessing the corresponding aliased memory region.","Hardware product designs often need to implement memory protection features that enable privileged software to define isolated memory regions and access control (read/write) policies. Isolated memory regions can be defined on different memory spaces in a design (e.g. system physical address, virtual address, memory mapped IO). Each memory cell should be mapped and assigned a system address that the core software can use to read/write to that memory. It is possible to map the same memory cell to multiple system addresses such that read/write to any of the aliased system addresses would be decoded to the same memory cell. This is commonly done in hardware designs for redundancy and simplifying address decoding logic. If one of the memory regions is corrupted or faulty, then that hardware can switch to using the data in the mirrored memory region. Memory aliases can also be created in the system address map if the address decoder unit ignores higher order address bits when mapping a smaller address region into the full system address. A common security weakness that can exist in such memory mapping is that aliased memory regions could have different read/write access protections enforced by the hardware such that an untrusted agent is blocked from accessing a memory address but is not blocked from accessing the corresponding aliased memory address. Such inconsistency can then be used to bypass the access protection of the primary memory block and read or modify the protected memory. An untrusted agent could also possibly create memory aliases in the system address map for malicious purposes if it is able to change the mapping of an address region or modify memory region sizes.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::NATURE:CanPrecede:CWE ID:119:VIEW ID:1000::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY NAME:Memory Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Processor Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Microcontroller Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Network on Chip Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Confidentiality:IMPACT:Read Memory:LIKELIHOOD:High::SCOPE:Integrity:IMPACT:Modify Memory:LIKELIHOOD:High::SCOPE:Availability:IMPACT:DoS: Instability:LIKELIHOOD:High::","","::PHASE:Architecture and Design Implementation:DESCRIPTION:The checks should be applied for consistency access rights between primary memory regions and any mirrored or aliased memory regions. If different memory protection units (MPU) are protecting the aliased regions, their protected range definitions and policies should be synchronized.::PHASE:Architecture and Design Implementation:DESCRIPTION:The controls that allow enabling memory aliases or changing the size of mapped memory regions should only be programmable by trusted software components.::","",,,"",::456::679::,"",
+1258,"Exposure of Sensitive System Information Due to Uncleared Debug Information",Base,Draft,"The hardware does not fully clear security-sensitive values, such as keys and intermediate values in cryptographic operations, when debug mode is entered.","Security sensitive values, keys, intermediate steps of cryptographic operations, etc. are stored in temporary registers in the hardware. If these values are not cleared when debug mode is entered they may be accessed by a debugger allowing sensitive information to be accessible by untrusted parties.",::NATURE:ChildOf:CWE ID:212:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:200:VIEW ID:1000::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Confidentiality:IMPACT:Read Memory::SCOPE:Access Control:IMPACT:Bypass Protection Mechanism::","","::PHASE:Architecture and Design:DESCRIPTION:Whenever debug mode is enabled, all registers containing sensitive assets must be cleared.::","::REFERENCE:CVE-2021-33080:DESCRIPTION:Uncleared debug information in memory accelerator for SSD product exposes sensitive system information:LINK:https://www.cve.org/CVERecord?id=CVE-2021-33080::REFERENCE:CVE-2022-31162:DESCRIPTION:Rust library leaks Oauth client details in application debug logs:LINK:https://www.cve.org/CVERecord?id=CVE-2022-31162::",,,"",::150::204::37::545::,"",
+1259,"Improper Restriction of Security Token Assignment",Base,Incomplete,"The System-On-A-Chip (SoC) implements a Security Token mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Tokens are improperly protected.","Systems-On-A-Chip (Integrated circuits and hardware engines) implement Security Tokens to differentiate and identify which actions originated from which agent. These actions may be one of the directives: 'read', 'write', 'program', 'reset', 'fetch', 'compute', etc. Security Tokens are assigned to every agent in the System that is capable of generating an action or receiving an action from another agent. Multiple Security Tokens may be assigned to an agent and may be unique based on the agent's trust level or allowed privileges. Since the Security Tokens are integral for the maintenance of security in an SoC, they need to be protected properly. A common weakness afflicting Security Tokens is improperly restricting the assignment to trusted components. Consequently, an improperly protected Security Token may be able to be programmed by a malicious agent (i.e., the Security Token is mutable) to spoof the action as if it originated from a trusted agent.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:1294:VIEW ID:1194:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY NAME:Processor HardwareTECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Access Control:IMPACT:Modify Files or Directories:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Bypass Protection Mechanism:IMPACT:Gain Privileges or Assume Identity:IMPACT:Modify Memory:IMPACT:Modify Memory:IMPACT:DoS: Crash, Exit, or Restart:LIKELIHOOD:High::","","::PHASE:Architecture and Design Implementation:DESCRIPTION:Security Token assignment review checks for design inconsistency and common weaknesses. Security-Token definition and programming flow is tested in both pre-silicon and post-silicon testing.::","",,,"",::121::681::,"::TYPE:Maintenance:NOTE:This entry is still under development and will continue to see updates and content improvements. Currently it is expressed as a general absence of a protection mechanism as opposed to a specific mistake, and the entry's name and description could be interpreted as applying to software.::",
+1260,"Improper Handling of Overlap Between Protected Memory Ranges",Base,Stable,"The product allows address regions to overlap, which can result in the bypassing of intended memory protection.","Isolated memory regions and access control (read/write) policies are used by hardware to protect privileged software. Software components are often allowed to change or remap memory region definitions in order to enable flexible and dynamically changeable memory management by system software. If a software component running at lower privilege can program a memory address region to overlap with other memory regions used by software running at higher privilege, privilege escalation may be available to attackers. The memory protection unit (MPU) logic can incorrectly handle such an address overlap and allow the lower-privilege software to read or write into the protected memory region, resulting in privilege escalation attack. An address overlap weakness can also be used to launch a denial of service attack on the higher-privilege software memory regions.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::NATURE:CanPrecede:CWE ID:119:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Primary::ORDINALITY:Resultant::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY NAME:Memory Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Processor Hardware:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:Such issues could be introduced during hardware architecture and design or implementation and identified later during the Testing phase.::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:IMPACT:Modify Memory:IMPACT:Read Memory:IMPACT:DoS: Instability:LIKELIHOOD:High::","::METHOD:Manual Analysis:DESCRIPTION:Create a high privilege memory block of any arbitrary size. Attempt to create a lower privilege memory block with an overlap of the high privilege memory block. If the creation attempt works, fix the hardware. Repeat the test.:EFFECTIVENESS:High::","::PHASE:Architecture and Design:DESCRIPTION:Ensure that memory regions are isolated as intended and that access control (read/write) policies are used by hardware to protect privileged software.::PHASE:Implementation:DESCRIPTION:For all of the programmable memory protection regions, the memory protection unit (MPU) design can define a priority scheme. For example: if three memory regions can be programmed (Region_0, Region_1, and Region_2), the design can enforce a priority scheme, such that, if a system address is within multiple regions, then the region with the lowest ID takes priority and the access-control policy of that region will be applied. In some MPU designs, the priority scheme can also be programmed by trusted software. Hardware logic or trusted firmware can also check for region definitions and block programming of memory regions with overlapping addresses. The memory-access-control-check filter can also be designed to apply a policy filter to all of the overlapping ranges, i.e., if an address is within Region_0 and Region_1, then access to this address is only granted if both Region_0 and Region_1 policies allow the access.:EFFECTIVENESS:High::","::REFERENCE:CVE-2008-7096:DESCRIPTION:virtualization product allows compromise of hardware product by accessing certain remapping registers.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-7096::REFERENCE:[REF-1100]:DESCRIPTION:processor design flaw allows ring 0 code to access more privileged rings by causing a register window to overlap a range of protected system RAM [REF-1100]:LINK:https://github.com/xoreaxeaxeax/sinkhole/blob/master/us-15-Domas-TheMemorySinkhole-wp.pdf::",,,"",::456::679::,"::TYPE:Maintenance:NOTE:As of CWE 4.6, CWE-1260 and CWE-1316 are siblings under view 1000, but CWE-1260 might be a parent of CWE-1316. More analysis is warranted.::",
+1261,"Improper Handling of Single Event Upsets",Base,Draft,"The hardware logic does not effectively handle when single-event upsets (SEUs) occur.","Technology trends such as CMOS-transistor down-sizing, use of new materials, and system-on-chip architectures continue to increase the sensitivity of systems to soft errors. These errors are random, and their causes might be internal (e.g., interconnect coupling) or external (e.g., cosmic radiation). These soft errors are not permanent in nature and cause temporary bit flips known as single-event upsets (SEUs). SEUs are induced errors in circuits caused when charged particles lose energy by ionizing the medium through which they pass, leaving behind a wake of electron-hole pairs that cause temporary failures. If these failures occur in security-sensitive modules in a chip, it might compromise the security guarantees of the chip. For instance, these temporary failures could be bit flips that change the privilege of a regular user to root.",::NATURE:ChildOf:CWE ID:1384:VIEW ID:1000:ORDINAL:Primary::NATURE:PeerOf:CWE ID:1254:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Availability:SCOPE:Access Control:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:DoS: Instability:IMPACT:Gain Privileges or Assume Identity:IMPACT:Bypass Protection Mechanism::","","::PHASE:Architecture and Design:DESCRIPTION:Implement triple-modular redundancy around security-sensitive modules.::PHASE:Architecture and Design:DESCRIPTION:SEUs mostly affect SRAMs. For SRAMs storing security-critical data, implement Error-Correcting-Codes (ECC) and Address Interleaving.::","",,,"",,"",
+1262,"Improper Access Control for Register Interface",Base,Stable,"The product uses memory-mapped I/O registers that act as an interface to hardware functionality from software, but there is improper access control to those registers.","Software commonly accesses peripherals in a System-on-Chip (SoC) or other device through a memory-mapped register interface. Malicious software could tamper with any security-critical hardware data that is accessible directly or indirectly through the register interface, which could lead to a loss of confidentiality and integrity.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:This weakness may be exploited if the register interface design does not adequately protect hardware assets from software.::PHASE:Implementation:NOTE:Mis-implementation of access control policies may inadvertently allow access to hardware assets through the register interface.::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Memory:IMPACT:Read Application Data:IMPACT:Modify Memory:IMPACT:Modify Application Data:IMPACT:Gain Privileges or Assume Identity:IMPACT:Bypass Protection Mechanism:IMPACT:Unexpected State:IMPACT:Alter Execution Logic:NOTE:Confidentiality of hardware assets may be violated if the protected information can be read out by software through the register interface. Registers storing security state, settings, other security-critical data may be corruptible by software without correctly implemented protections.::","::METHOD:Manual Analysis:DESCRIPTION:This is applicable in the Architecture phase before implementation started. Make sure access policy is specified for the entire memory map. Manual analysis may not ensure the implementation is correct.:EFFECTIVENESS:Moderate::METHOD:Manual Analysis:DESCRIPTION:Registers controlling hardware should have access control implemented. This access control may be checked manually for correct implementation. Items to check consist of how are trusted parties set, how are trusted parties verified, how are accesses verified, etc. Effectiveness of a manual analysis will vary depending upon how complicated the interface is constructed.:EFFECTIVENESS:Moderate::METHOD:Simulation / Emulation:DESCRIPTION:Functional simulation is applicable during the Implementation Phase. Testcases must be created and executed for memory mapped registers to verify adherence to the access control policy. This method can be effective, since functional verification needs to be performed on the design, and verification for this weakness will be included. There can be difficulty covering the entire memory space during the test.:EFFECTIVENESS:Moderate::METHOD:Formal Verification:DESCRIPTION:Formal verification is applicable during the Implementation phase. Assertions need to be created in order to capture illegal register access scenarios and prove that they cannot occur. Formal methods are exhaustive and can be very effective, but creating the cases for large designs may be complex and difficult.:EFFECTIVENESS:High::METHOD:Automated Analysis:DESCRIPTION:Information flow tracking can be applicable during the Implementation phase. Security sensitive data (assets) - for example, as stored in registers - is automatically tracked over time through the design to verify the data doesn't reach illegal destinations that violate the access policies for the memory map. This method can be very effective when used together with simulation and emulation, since detecting violations doesn't rely on specific scenarios or data values. This method does rely on simulation and emulation, so testcases must exist in order to use this method.:EFFECTIVENESS:High::METHOD:Architecture or Design Review:DESCRIPTION:Manual documentation review of the system memory map, register specification, and permissions associated with accessing security-relevant functionality exposed via memory-mapped registers.:EFFECTIVENESS:Moderate::METHOD:Fuzzing:DESCRIPTION:Perform penetration testing (either manual or semi-automated with fuzzing) to verify that access control mechanisms such as the memory protection units or on-chip bus firewall settings adequately protect critical hardware registers from software access.:EFFECTIVENESS:Moderate::","::PHASE:Architecture and Design:DESCRIPTION:Design proper policies for hardware register access from software.::PHASE:Implementation:DESCRIPTION:Ensure that access control policies for register access are implemented in accordance with the specified design.::","::REFERENCE:CVE-2014-2915:DESCRIPTION:virtualization product does not restrict access to debug and other processor registers in the hardware, allowing a crash of the host or guest OS:LINK:https://www.cve.org/CVERecord?id=CVE-2014-2915::REFERENCE:CVE-2021-3011:DESCRIPTION:virtual interrupt controller in a virtualization product allows crash of host by writing a certain invalid value to a register, which triggers a fatal error instead of returning an error code:LINK:https://www.cve.org/CVERecord?id=CVE-2021-3011::REFERENCE:CVE-2020-12446:DESCRIPTION:Driver exposes access to Model Specific Register (MSR) registers, allowing admin privileges.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-12446::REFERENCE:CVE-2015-2150:DESCRIPTION:Virtualization product does not restrict access to PCI command registers, allowing host crash from the guest.:LINK:https://www.cve.org/CVERecord?id=CVE-2015-2150::",,,"",::680::,"",
+1263,"Improper Physical Access Control",Class,Incomplete,"The product is designed with access restricted to certain information, but it does not sufficiently protect against an unauthorized actor with physical access to these areas.","Sections of a product intended to have restricted access may be inadvertently or intentionally rendered accessible when the implemented physical protections are insufficient. The specific requirements around how robust the design of the physical protection mechanism needs to be depends on the type of product being protected. Selecting the correct physical protection mechanism and properly enforcing it through implementation and manufacturing are critical to the overall physical security of the product.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::NATURE:PeerOf:CWE ID:1191:VIEW ID:1000::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:This weakness can arise if design decisions are made that do not align with the intended physical protection of the product::PHASE:Manufacturing:NOTE:While the architecture and design phase of the product may have accurately met the intended robustness for product physical protections, this phase may introduce the weakness through errors in physically manufacturing the product.::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Access Control:IMPACT:Varies by Context::","","::PHASE:Architecture and Design:DESCRIPTION:Specific protection requirements depend strongly on contextual factors including the level of acceptable risk associated with compromise to the product's protection mechanism. Designers could incorporate anti-tampering measures that protect against or detect when the product has been tampered with.::PHASE:Testing:DESCRIPTION:The testing phase of the lifecycle should establish a method for determining whether the protection mechanism is sufficient to prevent unauthorized access.::PHASE:Manufacturing:DESCRIPTION:Ensure that all protection mechanisms are fully activated at the time of manufacturing and distribution.::","",,,"",::401::,"::TYPE:Maintenance:NOTE:This entry is still under development and will continue to see updates and content improvements.::",
+1264,"Hardware Logic with Insecure De-Synchronization between Control and Data Channels",Base,Incomplete,"The hardware logic for error handling and security checks can incorrectly forward data before the security check is complete.","Many high-performance on-chip bus protocols and processor data-paths employ separate channels for control and data to increase parallelism and maximize throughput. Bugs in the hardware logic that handle errors and security checks can make it possible for data to be forwarded before the completion of the security checks. If the data can propagate to a location in the hardware observable to an attacker, loss of data confidentiality can occur. 'Meltdown' is a concrete example of how de-synchronization between data and permissions checking logic can violate confidentiality requirements. Data loaded from a page marked as privileged was returned to the cpu regardless of current privilege level for performance reasons. The assumption was that the cpu could later remove all traces of this data during the handling of the illegal memory access exception, but this assumption was proven false as traces of the secret data were not removed from the microarchitectural state.",::NATURE:ChildOf:CWE ID:821:VIEW ID:1000:ORDINAL:Primary::NATURE:PeerOf:CWE ID:1037:VIEW ID:1000::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:The weakness can be introduced in the data transfer or bus protocol itself or in the implementation.::PHASE:Implementation::","",,"::SCOPE:Confidentiality:IMPACT:Read Memory:IMPACT:Read Application Data::","","::PHASE:Architecture and Design:DESCRIPTION:Thoroughly verify the data routing logic to ensure that any error handling or security checks effectively block illegal dataflows.::","::REFERENCE:CVE-2017-5754:DESCRIPTION:Systems with microprocessors utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis of the data cache.:LINK:https://www.cve.org/CVERecord?id=CVE-2017-5754::",,,"",::233::663::,"::TYPE:Maintenance:NOTE:As of CWE 4.9, members of the CWE Hardware SIG are closely analyzing this entry and others to improve CWE's coverage of transient execution weaknesses, which include issues related to Spectre, Meltdown, and other attacks. Additional investigation may include other weaknesses related to microarchitectural state. As a result, this entry might change significantly in CWE 4.10.::",
+1266,"Improper Scrubbing of Sensitive Data from Decommissioned Device",Base,Incomplete,"The product does not properly provide a capability for the product administrator to remove sensitive data at the time the product is decommissioned. A scrubbing capability could be missing, insufficient, or incorrect.","When a product is decommissioned - i.e., taken out of service - best practices or regulatory requirements may require the administrator to remove or overwrite sensitive data first, i.e. scrubbing. Improper scrubbing of sensitive data from a decommissioned device leaves that data vulnerable to acquisition by a malicious actor. Sensitive data may include, but is not limited to, device/manufacturer proprietary information, user/device credentials, network configurations, and other forms of sensitive data.",::NATURE:ChildOf:CWE ID:404:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Policy::PHASE:Implementation::","",,"::SCOPE:Confidentiality:IMPACT:Read Memory::","","::PHASE:Architecture and Design:DESCRIPTION:Functionality to completely scrub data from a product at the conclusion of its lifecycle should be part of the design phase. Trying to add this function on top of an existing architecture could lead to incomplete removal of sensitive information/data.::PHASE:Policy:DESCRIPTION:The manufacturer should describe the location(s) where sensitive data is stored and the policies and procedures for its removal. This information may be conveyed, for example, in an Administrators Guide or a Statement of Volatility.::PHASE:Implementation:DESCRIPTION:If the capability to wipe sensitive data isn't built-in, the manufacturer may need to provide a utility to scrub sensitive data from storage if that data is located in a place which is non-accessible by the administrator. One example of this could be when sensitive data is stored on an EEPROM for which there is no user/admin interface provided by the system.::","",,,"",::150::37::545::546::675::,"::TYPE:Maintenance:NOTE:This entry is still under development and will continue to see updates and content improvements.::",
+1267,"Policy Uses Obsolete Encoding",Base,Draft,"The product uses an obsolete encoding mechanism to implement access controls.","Within a System-On-a-Chip (SoC), various circuits and hardware engines generate transactions for the purpose of accessing (read/write) assets or performing various actions (e.g., reset, fetch, compute, etc.). Among various types of message information, a typical transaction is comprised of source identity (identifying the originator of the transaction) and a destination identity (routing the transaction to the respective entity). Sometimes the transactions are qualified with a Security Token. This Security Token helps the destination agent decide on the set of allowed actions (e.g., access to an asset for reads and writes). A policy encoder is used to map the bus transactions to Security Tokens that in turn are used as access-controls/protection mechanisms. A common weakness involves using an encoding which is no longer trusted, i.e., an obsolete encoding.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Access Control:IMPACT:Modify Memory:IMPACT:Read Memory:IMPACT:Modify Files or Directories:IMPACT:Read Files or Directories:IMPACT:DoS: Resource Consumption (Other):IMPACT:Execute Unauthorized Code or Commands:IMPACT:Gain Privileges or Assume Identity:IMPACT:Bypass Protection Mechanism:IMPACT:Reduce Reliability:LIKELIHOOD:High::","","::PHASE:Architecture and Design Implementation:DESCRIPTION:Security Token Decoders should be reviewed for design inconsistency and common weaknesses. Access and programming flows should be tested in both pre-silicon and post-silicon testing.:EFFECTIVENESS:High::","",,,"",::121::681::,"",
+1268,"Policy Privileges are not Assigned Consistently Between Control and Data Agents",Base,Draft,"The product's hardware-enforced access control for a particular resource improperly accounts for privilege discrepancies between control and write policies.","Integrated circuits and hardware engines may provide access to resources (device-configuration, encryption keys, etc.) belonging to trusted firmware or software modules (commonly set by a BIOS or a bootloader). These accesses are typically controlled and limited by the hardware. Hardware design access control is sometimes implemented using a policy. A policy defines which entity or agent may or may not be allowed to perform an action. When a system implements multiple levels of policies, a control policy may allow direct access to a resource as well as changes to the policies themselves. Resources that include agents in their control policy but not in their write policy could unintentionally allow an untrusted agent to insert itself in the write policy register. Inclusion in the write policy register could allow a malicious or misbehaving agent write access to resources. This action could result in security compromises including leaked information, leaked encryption keys, or modification of device configuration.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:This weakness may be introduced during the design of a device when the architect does not comprehensively specify all of the policies required by an agent.::PHASE:Implementation:NOTE:This weakness may be introduced during implementation if device policy restrictions do not sufficiently constrain less-privileged clients.::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Access Control:IMPACT:Modify Memory:IMPACT:Read Memory:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Gain Privileges or Assume Identity:IMPACT:Bypass Protection Mechanism:IMPACT:Read Files or Directories:IMPACT:Reduce Reliability:LIKELIHOOD:High::","","::PHASE:Architecture and Design Implementation:DESCRIPTION:Access-control-policy definition and programming flow must be sufficiently tested in pre-silicon and post-silicon testing.::","",,,"",::180::,"::TYPE:Maintenance:NOTE:This entry is still under development and will continue to see updates and content improvements.::",
+1269,"Product Released in Non-Release Configuration",Base,Incomplete,"The product released to market is released in pre-production or manufacturing configuration.","Products in the pre-production or manufacturing stages are configured to have many debug hooks and debug capabilities, including but not limited to: Ability to override/bypass various cryptographic checks (including authentication, authorization, and integrity) Ability to read/write/modify/dump internal state (including registers and memory) Ability to change system configurations Ability to run hidden or private commands that are not allowed during production (as they expose IP). The above is by no means an exhaustive list, but it alludes to the greater capability and the greater state of vulnerability of a product during it's preproduction or manufacturing state. Complexity increases when multiple parties are involved in executing the tests before the final production version. For example, a chipmaker might fabricate a chip and run its own preproduction tests, following which the chip would be delivered to the Original Equipment Manufacturer (OEM), who would now run a second set of different preproduction tests on the same chip. Only after both of these sets of activities are complete, can the overall manufacturing phase be called complete and have the Manufacturing Complete fuse blown. However, if the OEM forgets to blow the Manufacturing Complete fuse, then the system remains in the manufacturing stage, rendering the system both exposed and vulnerable.",::NATURE:ChildOf:CWE ID:693:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE NAME:VHDL:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:Verilog:LANGUAGE PREVALENCE:Undetermined::LANGUAGE CLASS:Compiled:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY NAME:Other:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Implementation::PHASE:Integration::PHASE:Manufacturing::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Access Control:SCOPE:Accountability:SCOPE:Authentication:SCOPE:Authorization:SCOPE:Non-Repudiation:IMPACT:Other:LIKELIHOOD:High::","","::PHASE:Implementation:DESCRIPTION:Ensure that there exists a marker for denoting the Manufacturing Complete stage and that the Manufacturing Complete marker gets updated at the Manufacturing Complete stage (i.e., the Manufacturing Complete fuse gets blown).::PHASE:Integration:DESCRIPTION:Ensure that there exists a marker for denoting the Manufacturing Complete stage and that the Manufacturing Complete marker gets updated at the Manufacturing Complete stage (i.e., the Manufacturing Complete fuse gets blown).::PHASE:Manufacturing:DESCRIPTION:Ensure that there exists a marker for denoting the Manufacturing Complete stage and that the Manufacturing Complete marker gets updated at the Manufacturing Complete stage (i.e., the Manufacturing Complete fuse gets blown).::","::REFERENCE:CVE-2019-13945:DESCRIPTION:Regarding SSA-686531, a hardware based manufacturing access on S7-1200 and S7-200 SMART has occurred. A vulnerability has been identified in SIMATIC S7-1200 CPU family (incl. SIPLUS variants) (All versions), SIMATIC S7-200 SMART CPU family (All versions). There is an access mode used during manufacturing of S7-1200 CPUs that allows additional diagnostic functionality. The security vulnerability could be exploited by an attacker with physical access to the UART interface during boot process. At the time of advisory publication, no public exploitation of this security vulnerability was known.:LINK:https://www.cve.org/CVERecord?id=CVE-2019-13945::REFERENCE:CVE-2018-4251:DESCRIPTION:Laptops with Intel chipsets were found to be running in Manufacturing Mode. After this information was reported to the OEM, the vulnerability (CVE-2018-4251) was patched disallowing access to the interface.:LINK:https://www.cve.org/CVERecord?id=CVE-2018-4251::",,,"",::439::,"",
+1270,"Generation of Incorrect Security Tokens",Base,Incomplete,"The product implements a Security Token mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Tokens generated in the system are incorrect.","Systems-On-a-Chip (SoC) (Integrated circuits and hardware engines) implement Security Tokens to differentiate and identify actions originated from various agents. These actions could be read, write, program, reset, fetch, compute, etc. Security Tokens are generated and assigned to every agent on the SoC that is either capable of generating an action or receiving an action from another agent. Every agent could be assigned a unique, Security Token based on its trust level or privileges. Incorrectly generated Security Tokens could result in the same token used for multiple agents or multiple tokens being used for the same agent. This condition could result in a Denial-of-Service (DoS) or the execution of an action that in turn could result in privilege escalation or unintended access.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:1294:VIEW ID:1194:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Access Control:IMPACT:Modify Files or Directories:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Bypass Protection Mechanism:IMPACT:Gain Privileges or Assume Identity:IMPACT:Read Memory:IMPACT:Modify Memory:IMPACT:DoS: Crash, Exit, or Restart:LIKELIHOOD:High::","","::PHASE:Architecture and Design Implementation:DESCRIPTION:Generation of Security Tokens should be reviewed for design inconsistency and common weaknesses. Security-Token definition and programming flow should be tested in pre-silicon and post-silicon testing.::","",,,"",::121::633::681::,"",
+1271,"Uninitialized Value on Reset for Registers Holding Security Settings",Base,Incomplete,"Security-critical logic is not set to a known value on reset.","When the device is first brought out of reset, the state of registers will be indeterminate if they have not been initialized by the logic. Before the registers are initialized, there will be a window during which the device is in an insecure state and may be vulnerable to attack.",::NATURE:ChildOf:CWE ID:909:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Access Control:SCOPE:Authentication:SCOPE:Authorization:IMPACT:Varies by Context::","","::PHASE:Implementation:DESCRIPTION:Design checks should be performed to identify any uninitialized flip-flops used for security-critical functions.::PHASE:Architecture and Design:DESCRIPTION:All registers holding security-critical information should be set to a specific value on reset.::","",,,"",::74::,"::TYPE:Maintenance:NOTE:This entry is still under development and will continue to see updates and content improvements.::",
+1272,"Sensitive Information Uncleared Before Debug/Power State Transition",Base,Stable,"The product performs a power or debug state transition, but it does not clear sensitive information that should no longer be accessible due to changes to information access restrictions.","A device or system frequently employs many power and sleep states during its normal operation (e.g., normal power, additional power, low power, hibernate, deep sleep, etc.). A device also may be operating within a debug condition. State transitions can happen from one power or debug state to another. If there is information available in the previous state which should not be available in the next state and is not properly removed before the transition into the next state, sensitive information may leak from the system.",::NATURE:ChildOf:CWE ID:226:VIEW ID:1000:ORDINAL:Primary::NATURE:CanPrecede:CWE ID:200:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE NAME:VHDL:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:Verilog:LANGUAGE PREVALENCE:Undetermined::LANGUAGE CLASS:Hardware Description Language:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Access Control:SCOPE:Accountability:SCOPE:Authentication:SCOPE:Authorization:SCOPE:Non-Repudiation:IMPACT:Read Memory:IMPACT:Read Application Data:LIKELIHOOD:High:NOTE:Sensitive information may be used to unlock additional capabilities of the device and take advantage of hidden functionalities which could be used to compromise device security.::","::METHOD:Manual Analysis:DESCRIPTION:Write a known pattern into each sensitive location. Enter the power/debug state in question. Read data back from the sensitive locations. If the reads are successful, and the data is the same as the pattern that was originally written, the test fails and the device needs to be fixed. Note that this test can likely be automated.:EFFECTIVENESS:High::","::PHASE:Architecture and Design Implementation:DESCRIPTION:During state transitions, information not needed in the next state should be removed before the transition to the next state.::","::REFERENCE:CVE-2020-12926:DESCRIPTION:Product software does not set a flag as per TPM specifications, thereby preventing a failed authorization attempt from being recorded after a loss of power.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-12926::",::Power::,,"",::150::37::545::546::,"",
+1273,"Device Unlock Credential Sharing",Base,Incomplete,"The credentials necessary for unlocking a device are shared across multiple parties and may expose sensitive information.","Unlocking a device often means activating certain unadvertised debug and manufacturer-specific capabilities of a device using sensitive credentials. Unlocking a device might be necessary for the purpose of troubleshooting device problems. For example, suppose a device contains the ability to dump the content of the full system memory by disabling the memory-protection mechanisms. Since this is a highly security-sensitive capability, this capability is locked in the production part. Unless the device gets unlocked by supplying the proper credentials, the debug capabilities are not available. For cases where the chip designer, chip manufacturer (fabricator), and manufacturing and assembly testers are all employed by the same company, the risk of compromise of the credentials is greatly reduced. However, the risk is greater when the chip designer is employed by one company, the chip manufacturer is employed by another company (a foundry), and the assemblers and testers are employed by yet a third company. Since these different companies will need to perform various tests on the device to verify correct device function, they all need to share the unlock key. Unfortunately, the level of secrecy and policy might be quite different at each company, greatly increasing the risk of sensitive credentials being compromised.",::NATURE:ChildOf:CWE ID:200:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE NAME:VHDL:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:Verilog:LANGUAGE PREVALENCE:Undetermined::LANGUAGE CLASS:Compiled:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY NAME:Other:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Integration::PHASE:Manufacturing::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Access Control:SCOPE:Accountability:SCOPE:Authentication:SCOPE:Authorization:SCOPE:Non-Repudiation:IMPACT:Modify Memory:IMPACT:Read Memory:IMPACT:Modify Files or Directories:IMPACT:Read Files or Directories:IMPACT:Modify Application Data:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Gain Privileges or Assume Identity:IMPACT:Bypass Protection Mechanism:NOTE:Once unlock credentials are compromised, an attacker can use the credentials to unlock the device and gain unauthorized access to the hidden functionalities protected by those credentials.::","","::PHASE:Integration:DESCRIPTION:Ensure the unlock credentials are shared with the minimum number of parties and with utmost secrecy. To limit the risk associated with compromised credentials, where possible, the credentials should be part-specific.::PHASE:Manufacturing:DESCRIPTION:Ensure the unlock credentials are shared with the minimum number of parties and with utmost secrecy. To limit the risk associated with compromised credentials, where possible, the credentials should be part-specific.::","",,,"",::560::,"::TYPE:Maintenance:NOTE:This entry is still under development and will continue to see updates and content improvements.::",
+1274,"Improper Access Control for Volatile Memory Containing Boot Code",Base,Stable,"The product conducts a secure-boot process that transfers bootloader code from Non-Volatile Memory (NVM) into Volatile Memory (VM), but it does not have sufficient access control or other protections for the Volatile Memory.","Adversaries could bypass the secure-boot process and execute their own untrusted, malicious boot code. As a part of a secure-boot process, the read-only-memory (ROM) code for a System-on-Chip (SoC) or other system fetches bootloader code from Non-Volatile Memory (NVM) and stores the code in Volatile Memory (VM), such as dynamic, random-access memory (DRAM) or static, random-access memory (SRAM). The NVM is usually external to the SoC, while the VM is internal to the SoC. As the code is transferred from NVM to VM, it is authenticated by the SoC's ROM code. If the volatile-memory-region protections or access controls are insufficient to prevent modifications from an adversary or untrusted agent, the secure boot may be bypassed or replaced with the execution of an adversary's code.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:This weakness can be introduced during hardware architecture or design but can be identified later during testing.::","",,"::SCOPE:Access Control:SCOPE:Integrity:IMPACT:Modify Memory:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Gain Privileges or Assume Identity:LIKELIHOOD:High::","::METHOD:Manual Analysis:DESCRIPTION:Ensure the volatile memory is lockable or has locks. Ensure the volatile memory is locked for writes from untrusted agents or adversaries. Try modifying the volatile memory from an untrusted agent, and ensure these writes are dropped.:EFFECTIVENESS:High::METHOD:Manual Analysis:DESCRIPTION:Analyze the device using the following steps: Identify all fabric master agents that are active during system Boot Flow when initial code is loaded from Non-volatile storage to volatile memory. Identify the volatile memory regions that are used for storing loaded system executable program. During system boot, test programming the identified memory regions in step 2 from all the masters identified in step 1. Only trusted masters should be allowed to write to the memory regions. For example, pluggable device peripherals should not have write access to program load memory regions.:EFFECTIVENESS:Moderate::","::PHASE:Architecture and Design:DESCRIPTION:Ensure that the design of volatile-memory protections is enough to prevent modification from an adversary or untrusted code.::PHASE:Testing:DESCRIPTION:Test the volatile-memory protections to ensure they are safe from modification or untrusted code.::","::REFERENCE:CVE-2019-2267:DESCRIPTION:Locked memory regions may be modified through other interfaces in a secure-boot-loader image due to improper access control.:LINK:https://www.cve.org/CVERecord?id=CVE-2019-2267::",,,"",::456::679::,"",
+1276,"Hardware Child Block Incorrectly Connected to Parent System",Base,Incomplete,"Signals between a hardware IP and the parent system design are incorrectly connected causing security risks.","Individual hardware IP must communicate with the parent system in order for the product to function correctly and as intended. If implemented incorrectly, while not causing any apparent functional issues, may cause security issues. For example, if the IP should only be reset by a system-wide hard reset, but instead the reset input is connected to a software-triggered debug mode reset (which is also asserted during a hard reset), integrity of data inside the IP can be violated.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Implementation:NOTE:This weakness is introduced when integrating IP into a parent design.::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:IMPACT:Varies by Context::","","::PHASE:Testing:DESCRIPTION:System-level verification may be used to ensure that components are correctly connected and that design security requirements are not violated due to interactions between various IP blocks.::","",,,"",,"",
+1277,"Firmware Not Updateable",Base,Draft,"The product does not provide its users with the ability to update or patch its firmware to address any vulnerabilities or weaknesses that may be present.","Without the ability to patch or update firmware, consumers will be left vulnerable to exploitation of any known vulnerabilities, or any vulnerabilities that are discovered in the future. This can expose consumers to permanent risk throughout the entire lifetime of the device, which could be years or decades. Some external protective measures and mitigations might be employed to aid in preventing or reducing the risk of malicious attack, but the root weakness cannot be corrected.",::NATURE:ChildOf:CWE ID:1329:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Requirements:NOTE:Requirements development might not consider the importance of updates over the lifetime of the product, or might not choose the ability due to concerns such as expense or speed to market.::PHASE:Architecture and Design:NOTE:Lack of planning during architecture development and design, or external pressures such as speed to market, could ignore the capability to update.::PHASE:Implementation:NOTE:The weakness can appear through oversight during implementation.::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Access Control:SCOPE:Authentication:SCOPE:Authorization:IMPACT:Gain Privileges or Assume Identity:IMPACT:Bypass Protection Mechanism:IMPACT:Execute Unauthorized Code or Commands:IMPACT:DoS: Crash, Exit, or Restart:LIKELIHOOD:Medium:NOTE:If an attacker can identify an exploitable vulnerability in one device that has no means of patching, the attack may be used against an entire class of devices.::","::METHOD:Manual Analysis:DESCRIPTION:Create a new installable boot image of the current build with a minor version number change. Use the standard installation method to update the boot image. Verify that the minor version number has changed. Create a fake image. Verify that the boot updater will not install the fake image and generates an invalid image error message or equivalent.:EFFECTIVENESS:High::METHOD:Architecture or Design Review:DESCRIPTION:Check the consumer or maintainer documentation, the architecture/design documentation, or the original requirements to ensure that the documentation includes details for how to update the firmware.:EFFECTIVENESS:Moderate::METHOD:Manual Dynamic Analysis:DESCRIPTION:Determine if there is a lack of a capability to update read-only memory (ROM) structure. This could manifest as a difference between the latest firmware version and the current version within the device.:EFFECTIVENESS:High::","::PHASE:Requirements:DESCRIPTION:Specify requirements to include the ability to update the firmware. Include integrity checks and authentication to ensure that untrusted firmware cannot be installed.::PHASE:Architecture and Design:DESCRIPTION:Design the device to allow for updating the firmware. Ensure that the design specifies how to distribute the updates and ensure their integrity and authentication.::PHASE:Implementation:DESCRIPTION:Implement the necessary functionality to allow the firmware to be updated.::","::REFERENCE:CVE-2020-9054:DESCRIPTION:Chain: network-attached storage (NAS) device has a critical OS command injection (CWE-78) vulnerability that is actively exploited to place IoT devices into a botnet, but some products are end-of-support and cannot be patched (CWE-1277). [REF-1097]:LINK:https://www.cve.org/CVERecord?id=CVE-2020-9054::REFERENCE:[REF-1095]:DESCRIPTION:A hardware smart lock has weak key generation that allows attackers to steal the key by BLE sniffing, but the device's firmware cannot be upgraded and hence remains vulnerable [REF-1095].:LINK:https://www.theregister.com/2019/12/11/f_secure_keywe/::",,,"",::682::,"::TYPE:Terminology:NOTE:The firmware term does not have a single commonly-shared definition, so there may be variations in how this CWE entry is interpreted during mapping.::",
+1278,"Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques",Base,Incomplete,"Information stored in hardware may be recovered by an attacker with the capability to capture and analyze images of the integrated circuit using techniques such as scanning electron microscopy.","The physical structure of a device, viewed at high enough magnification, can reveal the information stored inside. Typical steps in IC reverse engineering involve removing the chip packaging (decapsulation) then using various imaging techniques ranging from high resolution x-ray microscopy to invasive techniques involving removing IC layers and imaging each layer using a scanning electron microscope. The goal of such activities is to recover secret keys, unique device identifiers, and proprietary code and circuit designs embedded in hardware that the attacker has been unsuccessful at accessing through other means. These secrets may be stored in non-volatile memory or in the circuit netlist. Memory technologies such as masked ROM allow easier to extraction of secrets than One-time Programmable (OTP) memory.",::NATURE:ChildOf:CWE ID:693:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::","",,"::SCOPE:Confidentiality:IMPACT:Varies by Context:NOTE:A common goal of malicious actors who reverse engineer ICs is to produce and sell counterfeit versions of the IC.::","","::PHASE:Architecture and Design:DESCRIPTION:The cost of secret extraction via IC reverse engineering should outweigh the potential value of the secrets being extracted. Threat model and value of secrets should be used to choose the technology used to safeguard those secrets. Examples include IC camouflaging and obfuscation, tamper-proof packaging, active shielding, and physical tampering detection information erasure.::","",,,"",::188::37::545::,"::TYPE:Maintenance:NOTE:This entry is still under development and will continue to see updates and content improvements. It is more attack-oriented, so it might be more suited for CAPEC.::",
+1279,"Cryptographic Operations are run Before Supporting Units are Ready",Base,Incomplete,"Performing cryptographic operations without ensuring that the supporting inputs are ready to supply valid data may compromise the cryptographic result.","Many cryptographic hardware units depend upon other hardware units to supply information to them to produce a securely encrypted result. For example, a cryptographic unit that depends on an external random-number-generator (RNG) unit for entropy must wait until the RNG unit is producing random numbers. If a cryptographic unit retrieves a private encryption key from a fuse unit, the fuse unit must be up and running before a key may be supplied.",::NATURE:ChildOf:CWE ID:691:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:665:VIEW ID:1000::,"",::LANGUAGE NAME:Verilog:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:VHDL:LANGUAGE PREVALENCE:Undetermined::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY NAME:Processor Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation:NOTE:The decision to continue using a cryptographic unit even though the input units to it are not producing valid data will compromise the encrypted result.::","",,"::SCOPE:Access Control:SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Accountability:SCOPE:Authentication:SCOPE:Authorization:SCOPE:Non-Repudiation:IMPACT:Varies by Context::","","::PHASE:Architecture and Design:DESCRIPTION:Best practices should be used to design cryptographic systems.::PHASE:Implementation:DESCRIPTION:Continuously ensuring that cryptographic inputs are supplying valid information is necessary to ensure that the encrypted output is secure.::","",,,"",::97::,"",
+1280,"Access Control Check Implemented After Asset is Accessed",Base,Incomplete,"A product's hardware-based access control check occurs after the asset has been accessed.","The product implements a hardware-based access control check. The asset should be accessible only after the check is successful. If, however, this operation is not atomic and the asset is accessed before the check is complete, the security of the system may be compromised.",::NATURE:ChildOf:CWE ID:696:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:284:VIEW ID:1000::,"",::LANGUAGE NAME:Verilog:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:VHDL:LANGUAGE PREVALENCE:Undetermined::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Access Control:SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Modify Memory:IMPACT:Read Memory:IMPACT:Modify Application Data:IMPACT:Read Application Data:IMPACT:Gain Privileges or Assume Identity:IMPACT:Bypass Protection Mechanism::","","::PHASE:Implementation:DESCRIPTION:Implement the access control check first. Access should only be given to asset if agent is authorized.::","",,,"",::180::,"",
+1281,"Sequence of Processor Instructions Leads to Unexpected Behavior",Base,Incomplete,"Specific combinations of processor instructions lead to undesirable behavior such as locking the processor until a hard reset performed.","If the instruction set architecture (ISA) and processor logic are not designed carefully and tested thoroughly, certain combinations of instructions may lead to locking the processor or other unexpected and undesirable behavior. Upon encountering unimplemented instruction opcodes or illegal instruction operands, the processor should throw an exception and carry on without negatively impacting security. However, specific combinations of legal and illegal instructions may cause unexpected behavior with security implications such as allowing unprivileged programs to completely lock the CPU.",::NATURE:ChildOf:CWE ID:691:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Processor Hardware:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:Unexpected behavior from certain instruction combinations can arise from bugs in the ISA::PHASE:Implementation:NOTE:Unexpected behavior from certain instruction combinations can arise because of implementation details such as speculative execution, caching etc.::","",,"::SCOPE:Integrity:SCOPE:Availability:IMPACT:Varies by Context::","","::PHASE:Testing:DESCRIPTION:Implement a rigorous testing strategy that incorporates randomization to explore instruction sequences that are unlikely to appear in normal workloads in order to identify halt and catch fire instruction sequences.::PHASE:Patching and Maintenance:DESCRIPTION:Patch operating system to avoid running Halt and Catch Fire type sequences or to mitigate the damage caused by unexpected behavior. See [REF-1108].::","::REFERENCE:CVE-2021-26339:DESCRIPTION:A bug in AMD CPU's core logic allows a potential DoS by using a specific x86 instruction sequence to hang the processor:LINK:https://www.cve.org/CVERecord?id=CVE-2021-26339::REFERENCE:CVE-1999-1476:DESCRIPTION:A bug in some Intel Pentium processors allow DoS (hang) via an invalid CMPXCHG8B instruction, causing a deadlock:LINK:https://www.cve.org/CVERecord?id=CVE-1999-1476::",,,"",::212::,"",
+1282,"Assumed-Immutable Data is Stored in Writable Memory",Base,Incomplete,"Immutable data, such as a first-stage bootloader, device identifiers, and write-once configuration settings are stored in writable memory that can be re-programmed or updated in the field.","Security services such as secure boot, authentication of code and data, and device attestation all require assets such as the first stage bootloader, public keys, golden hash digests, etc. which are implicitly trusted. Storing these assets in read-only memory (ROM), fuses, or one-time programmable (OTP) memory provides strong integrity guarantees and provides a root of trust for securing the rest of the system. Security is lost if assets assumed to be immutable can be modified.",::NATURE:ChildOf:CWE ID:668:VIEW ID:1000:ORDINAL:Primary::NATURE:CanPrecede:CWE ID:471:VIEW ID:1000::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Implementation:NOTE:Keys, code, configuration settings, and other data should be programmed in write-once or read-only memory instead of writable memory.::","",,"::SCOPE:Integrity:IMPACT:Varies by Context::","","::PHASE:Implementation:DESCRIPTION:All immutable code or data should be programmed into ROM or write-once memory.::","",,,"",::458::679::,"::TYPE:Maintenance:NOTE:This entry is still under development and will continue to see updates and content improvements.::TYPE:Maintenance:NOTE:As of CWE 4.3, CWE-1282 and CWE-1233 are being investigated for potential duplication or overlap.::",
+1283,"Mutable Attestation or Measurement Reporting Data",Base,Incomplete,"The register contents used for attestation or measurement reporting data to verify boot flow are modifiable by an adversary.","A System-on-Chip (SoC) implements secure boot or verified boot. During this boot flow, the SoC often measures the code that it authenticates. The measurement is usually done by calculating the one-way hash of the code binary and extending it to the previous hash. The hashing algorithm should be a Secure One-Way hash function. The final hash, i.e., the value obtained after the completion of the boot flow, serves as the measurement data used in reporting or in attestation. The calculated hash is often stored in registers that can later be read by the party of interest to determine tampering of the boot flow. A common weakness is that the contents in these registers are modifiable by an adversary, thus spoofing the measurement.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:Such issues can be introduced during hardware architecture or design and can be identified later during Testing or System Configuration phases.::PHASE:Implementation:NOTE:If the access-controls which protecting the reporting registers are misconfigured during implementation, this weakness can arise.::","",,"::SCOPE:Confidentiality:IMPACT:Read Memory:IMPACT:Read Application Data::","","::PHASE:Architecture and Design:DESCRIPTION:Measurement data should be stored in registers that are read-only or otherwise have access controls that prevent modification by an untrusted agent.::","",,,"",::680::,"::TYPE:Maintenance:NOTE:This entry is still in development and will continue to see updates and content improvements.::",
+1290,"Incorrect Decoding of Security Identifiers ",Base,Incomplete,"The product implements a decoding mechanism to decode certain bus-transaction signals to security identifiers. If the decoding is implemented incorrectly, then untrusted agents can now gain unauthorized access to the asset.","In a System-On-Chip (SoC), various integrated circuits and hardware engines generate transactions such as to access (reads/writes) assets or perform certain actions (e.g., reset, fetch, compute, etc.). Among various types of message information, a typical transaction is comprised of source identity (to identify the originator of the transaction) and a destination identity (to route the transaction to the respective entity). Sometimes the transactions are qualified with a security identifier. The security identifier helps the destination agent decide on the set of allowed actions (e.g., access an asset for read and writes). A decoder decodes the bus transactions to map security identifiers into necessary access-controls/protections. A common weakness that can exist in this scenario is incorrect decoding because an untrusted agent's security identifier is decoded into a trusted agent's security identifier. Thus, an untrusted agent previously without access to an asset can now gain access to the asset.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:1294:VIEW ID:1194:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY NAME:Bus/Interface Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Implementation::PHASE:Architecture and Design::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Access Control:IMPACT:Modify Memory:IMPACT:Read Memory:IMPACT:DoS: Resource Consumption (Other):IMPACT:Execute Unauthorized Code or Commands:IMPACT:Gain Privileges or Assume Identity:IMPACT:Quality Degradation:LIKELIHOOD:High::","","::PHASE:Architecture and Design:DESCRIPTION:Security identifier decoders must be reviewed for design consistency and common weaknesses.::PHASE:Implementation:DESCRIPTION:Access and programming flows must be tested in pre-silicon and post-silicon testing in order to check for this weakness.::","",,,"",,"",
+1291,"Public Key Re-Use for Signing both Debug and Production Code",Base,Draft,"The same public key is used for signing both debug and production code.","A common usage of public-key cryptography is to verify the integrity and authenticity of another entity (for example a firmware binary). If a company wants to ensure that its firmware runs only on its own hardware, before the firmware runs, an encrypted hash of the firmware image will be decrypted with the public key and then verified against the now-computed hash of the firmware image. This means that the public key forms the root of trust, which necessitates that the public key itself must be protected and used properly. During the development phase, debug firmware enables many hardware debug hooks, debug modes, and debug messages for testing. Those debug facilities provide significant, additional views about the firmware's capability and, in some cases, additional capability into the chip or SoC. If compromised, these capabilities could be exploited by an attacker to take full control of the system. Once the product exits the manufacturing stage and enters production, it is good practice to use a different public key. Debug firmware images are known to leak. With the debug key being reused as the production key, the debug image will also work on the production image. Thus, it will open all the internal, debug capabilities to the attacker. If a different public key is used for the production image, even if the attacker gains access to the debug firmware image, they will not be able to run it on a production machine. Thus, damage will be limited to the intellectual property leakage resulting from the debug image.",::NATURE:ChildOf:CWE ID:693:VIEW ID:1000:ORDINAL:Primary::NATURE:PeerOf:CWE ID:321:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Access Control:SCOPE:Accountability:SCOPE:Authentication:SCOPE:Authorization:SCOPE:Non-Repudiation:SCOPE:Other:IMPACT:Read Memory:IMPACT:Modify Memory:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Gain Privileges or Assume Identity:IMPACT:Varies by Context:LIKELIHOOD:High::","::METHOD:Architecture or Design Review:DESCRIPTION:Compare the debug key with the production key to make sure that they are not the same.:EFFECTIVENESS:High::METHOD:Dynamic Analysis with Manual Results Interpretation:DESCRIPTION:Compare the debug key with the production key to make sure that they are not the same.:EFFECTIVENESS:High::","::PHASE:Implementation:DESCRIPTION:Use different keys for Production and Debug::","",,,"",,"",
+1292,"Incorrect Conversion of Security Identifiers",Base,Draft,"The product implements a conversion mechanism to map certain bus-transaction signals to security identifiers. However, if the conversion is incorrectly implemented, untrusted agents can gain unauthorized access to the asset.","In a System-On-Chip (SoC), various integrated circuits and hardware engines generate transactions such as to access (reads/writes) assets or perform certain actions (e.g., reset, fetch, compute, etc.). Among various types of message information, a typical transaction is comprised of source identity (to identify the originator of the transaction) and a destination identity (to route the transaction to the respective entity). Sometimes the transactions are qualified with a security identifier. This security identifier helps the destination agent decide on the set of allowed actions (e.g., access an asset for read and writes). A typical bus connects several leader and follower agents. Some follower agents implement bus protocols differently from leader agents. A protocol conversion happens at a bridge to seamlessly connect different protocols on the bus. One example is a system that implements a leader with the Advanced High-performance Bus (AHB) protocol and a follower with the Open-Core Protocol (OCP). A bridge AHB-to-OCP is needed to translate the transaction from one form to the other. A common weakness that can exist in this scenario is that this conversion between protocols is implemented incorrectly, whereupon an untrusted agent may gain unauthorized access to an asset.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:1294:VIEW ID:1194:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY NAME:Bus/Interface Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:Such issues could be introduced during hardware architecture and design, then identified later during Testing or System Configuration phases.::PHASE:Implementation:NOTE:Such issues could be introduced during hardware implementation, then identified later during Testing or System Configuration phases.::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Access Control:IMPACT:Modify Memory:IMPACT:Read Memory:IMPACT:DoS: Resource Consumption (Other):IMPACT:Execute Unauthorized Code or Commands:IMPACT:Gain Privileges or Assume Identity:IMPACT:Quality Degradation:LIKELIHOOD:High::","","::PHASE:Architecture and Design:DESCRIPTION:Security identifier decoders must be reviewed for design inconsistency and common weaknesses.::PHASE:Implementation:DESCRIPTION:Access and programming flows must be tested in pre-silicon and post-silicon testing.::","",,,"",,"",
+1294,"Insecure Security Identifier Mechanism",Class,Incomplete,"The System-on-Chip (SoC) implements a Security Identifier mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Identifiers are not correctly implemented.","Systems-On-Chip (Integrated circuits and hardware engines) implement Security Identifiers to differentiate/identify actions originated from various agents. These actions could be 'read', 'write', 'program', 'reset', 'fetch', 'compute', etc. Security identifiers are generated and assigned to every agent in the System (SoC) that is either capable of generating an action or receiving an action from another agent. Every agent could be assigned a unique, Security Identifier based on its trust level or privileges. A broad class of flaws can exist in the Security Identifier process, including but not limited to missing security identifiers, improper conversion of security identifiers, incorrect generation of security identifiers, etc.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY NAME:Bus/Interface Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:Such issues could be introduced during hardware architecture and design, then identified later during Testing or System Configuration phases.::PHASE:Implementation:NOTE:Such issues could be introduced during hardware implementation, then identified later during Testing or System Configuration phases.::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Access Control:IMPACT:Modify Memory:IMPACT:Read Memory:IMPACT:DoS: Resource Consumption (Other):IMPACT:Execute Unauthorized Code or Commands:IMPACT:Gain Privileges or Assume Identity:IMPACT:Quality Degradation:LIKELIHOOD:High::","","::PHASE:Architecture and Design:DESCRIPTION:Security Identifier Decoders must be reviewed for design inconsistency and common weaknesses.::PHASE:Implementation:DESCRIPTION:Access and programming flows must be tested in pre-silicon and post-silicon testing.::","",,,"",::121::681::,"::TYPE:Maintenance:NOTE:This entry is still under development and will continue to see updates and content improvements.::",
+1295,"Debug Messages Revealing Unnecessary Information",Base,Incomplete,"The product fails to adequately prevent the revealing of unnecessary and potentially sensitive system information within debugging messages.","Debug messages are messages that help troubleshoot an issue by revealing the internal state of the system. For example, debug data in design can be exposed through internal memory array dumps or boot logs through interfaces like UART via TAP commands, scan chain, etc. Thus, the more information contained in a debug message, the easier it is to debug. However, there is also the risk of revealing information that could help an attacker either decipher a vulnerability, and/or gain a better understanding of the system. Thus, this extra information could lower the security by obscurity factor. While security by obscurity alone is insufficient, it can help as a part of Defense-in-depth.",::NATURE:ChildOf:CWE ID:200:VIEW ID:1000:ORDINAL:Primary::NATURE:PeerOf:CWE ID:209:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Access Control:SCOPE:Accountability:SCOPE:Authentication:SCOPE:Authorization:SCOPE:Non-Repudiation:IMPACT:Read Memory:IMPACT:Bypass Protection Mechanism:IMPACT:Gain Privileges or Assume Identity:IMPACT:Varies by Context:LIKELIHOOD:Medium::","","::PHASE:Implementation:DESCRIPTION:Ensure that a debug message does not reveal any unnecessary information during the debug process for the intended response.::","::REFERENCE:CVE-2021-25476:DESCRIPTION:Digital Rights Management (DRM) capability for mobile platform leaks pointer information, simplifying ASLR bypass:LINK:https://www.cve.org/CVERecord?id=CVE-2021-25476::REFERENCE:CVE-2020-24491:DESCRIPTION:Processor generates debug message that contains sensitive information (addresses of memory transactions).:LINK:https://www.cve.org/CVERecord?id=CVE-2020-24491::REFERENCE:CVE-2017-18326:DESCRIPTION:modem debug messages include cryptographic keys:LINK:https://www.cve.org/CVERecord?id=CVE-2017-18326::",,,"",::121::,"",
+1296,"Incorrect Chaining or Granularity of Debug Components",Base,Incomplete,"The product's debug components contain incorrect chaining or granularity of debug components.","For debugging and troubleshooting a chip, several hardware design elements are often implemented, including: Various Test Access Ports (TAPs) allow boundary scan commands to be executed. For scanning the internal components of a chip, there are scan cells that allow the chip to be used as a stimulus and response mechanism. Chipmakers might create custom methods to observe the internal components of their chips by placing various tracing hubs within their chip and creating hierarchical or interconnected structures among those hubs. Logic errors during design or synthesis could misconfigure the interconnection of the debug components, which could allow unintended access permissions.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE NAME:Verilog:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:VHDL:LANGUAGE PREVALENCE:Undetermined::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY NAME:Processor Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Access Control:SCOPE:Authentication:SCOPE:Authorization:SCOPE:Availability:SCOPE:Accountability:IMPACT:Gain Privileges or Assume Identity:IMPACT:Bypass Protection Mechanism:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Modify Memory:IMPACT:Modify Files or Directories:LIKELIHOOD:Medium:NOTE:Depending on the access to debug component(s) erroneously granted, an attacker could use the debug component to gain additional understanding about the system to further an attack and/or execute other commands. This could compromise any security property, including the ones listed above.::","::METHOD:Architecture or Design Review:DESCRIPTION:Appropriate Post-Si tests should be carried out at various authorization levels to ensure that debug components are properly chained and accessible only to users with appropriate credentials.:EFFECTIVENESS:High::METHOD:Dynamic Analysis with Manual Results Interpretation:DESCRIPTION:Appropriate Post-Si tests should be carried out at various authorization levels to ensure that debug components are properly chained and accessible only to users with appropriate credentials.:EFFECTIVENESS:High::","::PHASE:Implementation:DESCRIPTION:Ensure that debug components are properly chained and their granularity is maintained at different authentication levels.::","::REFERENCE:CVE-2017-18347:DESCRIPTION:Incorrect access control in RDP Level 1 on STMicroelectronics STM32F0 series devices allows physically present attackers to extract the device's protected firmware via a special sequence of Serial Wire Debug (SWD) commands because there is a race condition between full initialization of the SWD interface and the setup of flash protection.:LINK:https://www.cve.org/CVERecord?id=CVE-2017-18347::REFERENCE:CVE-2020-1791:DESCRIPTION:There is an improper authorization vulnerability in several smartphones. The system has a logic-judging error, and, under certain scenarios, a successful exploit could allow the attacker to switch to third desktop after a series of operations in ADB mode. (Vulnerability ID: HWPSIRT-2019-10114).:LINK:https://www.cve.org/CVERecord?id=CVE-2020-1791::",,,"",::121::702::,"::TYPE:Maintenance:NOTE:This entry is still under development and will continue to see updates and content improvements.::",
+1297,"Unprotected Confidential Information on Device is Accessible by OSAT Vendors",Base,Incomplete,"The product does not adequately protect confidential information on the device from being accessed by Outsourced Semiconductor Assembly and Test (OSAT) vendors.","In contrast to complete vertical integration of architecting, designing, manufacturing, assembling, and testing chips all within a single organization, an organization can choose to simply architect and design a chip before outsourcing the rest of the process to OSAT entities (e.g., external foundries and test houses). In the latter example, the device enters an OSAT facility in a much more vulnerable pre-production stage where many debug and test modes are accessible. Therefore, the chipmaker must place a certain level of trust with the OSAT. To counter this, the chipmaker often requires the OSAT partner to enter into restrictive non-disclosure agreements (NDAs). Nonetheless, OSAT vendors likely have many customers, which increases the risk of accidental sharing of information. There may also be a security vulnerability in the information technology (IT) system of the OSAT facility. Alternatively, a malicious insider at the OSAT facility may carry out an insider attack. Considering these factors, it behooves the chipmaker to minimize any confidential information in the device that may be accessible to the OSAT vendor. Logic errors during design or synthesis could misconfigure the interconnection of the debug components, which could provide improper authorization to sensitive information.",::NATURE:ChildOf:CWE ID:285:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE NAME:Verilog:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:VHDL:LANGUAGE PREVALENCE:Undetermined::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY NAME:Processor Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Access Control:SCOPE:Authentication:SCOPE:Authorization:SCOPE:Availability:SCOPE:Accountability:SCOPE:Non-Repudiation:IMPACT:Gain Privileges or Assume Identity:IMPACT:Bypass Protection Mechanism:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Modify Memory:IMPACT:Modify Files or Directories:LIKELIHOOD:Medium:NOTE:The impact depends on the confidential information itself and who is inadvertently granted access. For example, if the confidential information is a key that can unlock all the parts of a generation, the impact could be severe.::","::METHOD:Architecture or Design Review:DESCRIPTION:Appropriate Post-Si tests should be carried out to ensure that residual confidential information is not left on parts leaving one facility for another facility.:EFFECTIVENESS:High::METHOD:Dynamic Analysis with Manual Results Interpretation:DESCRIPTION:Appropriate Post-Si tests should be carried out to ensure that residual confidential information is not left on parts leaving one facility for another facility.:EFFECTIVENESS:Moderate::","::PHASE:Architecture and Design:DESCRIPTION:Ensure that when an OSAT vendor is allowed to access test interfaces necessary for preproduction and returned parts, the vendor only pulls the minimal information necessary. Also, architect the product in such a way that, when an unlock device request comes, it only unlocks that specific part and not all the parts for that product line. Ensure that the product's non-volatile memory (NVM) is scrubbed of all confidential information and secrets before handing it over to an OSAT. Arrange to secure all communication between an OSAT facility and the chipmaker.:EFFECTIVENESS:Moderate::","",,,"",::1::180::,"::TYPE:Maintenance:NOTE:This entry might be subject to CWE Scope Exclusion SCOPE.SITUATIONS (Focus on situations in which weaknesses may appear); SCOPE.HUMANPROC (Human/organizational process; and/or SCOPE.CUSTREL (Not customer-relevant).::TYPE:Maintenance:NOTE:This entry is still under development and will continue to see updates and content improvements.::",
+1298,"Hardware Logic Contains Race Conditions",Base,Draft,"A race condition in the hardware logic results in undermining security guarantees of the system.","A race condition in logic circuits typically occurs when a logic gate gets inputs from signals that have traversed different paths while originating from the same source. Such inputs to the gate can change at slightly different times in response to a change in the source signal. This results in a timing error or a glitch (temporary or permanent) that causes the output to change to an unwanted state before settling back to the desired state. If such timing errors occur in access control logic or finite state machines that are implemented in security sensitive flows, an attacker might exploit them to circumvent existing protections.",::NATURE:ChildOf:CWE ID:362:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE NAME:Verilog:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:VHDL:LANGUAGE PREVALENCE:Undetermined::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Access Control:IMPACT:Bypass Protection Mechanism:IMPACT:Gain Privileges or Assume Identity:IMPACT:Alter Execution Logic::","","::PHASE:Architecture and Design:DESCRIPTION:Adopting design practices that encourage designers to recognize and eliminate race conditions, such as Karnaugh maps, could result in the decrease in occurrences of race conditions.::PHASE:Implementation:DESCRIPTION:Logic redundancy can be implemented along security critical paths to prevent race conditions. To avoid metastability, it is a good practice in general to default to a secure state in which access is not given to untrusted agents.::","",,,"",::26::,"",
+1299,"Missing Protection Mechanism for Alternate Hardware Interface",Base,Draft,"The lack of protections on alternate paths to access control-protected assets (such as unprotected shadow registers and other external facing unguarded interfaces) allows an attacker to bypass existing protections to the asset that are only performed against the primary path.","An asset inside a chip might have access-control protections through one interface. However, if all paths to the asset are not protected, an attacker might compromise the asset through alternate paths. These alternate paths could be through shadow or mirror registers inside the IP core, or could be paths from other external-facing interfaces to the IP core or SoC. Consider an SoC with various interfaces such as UART, SMBUS, PCIe, USB, etc. If access control is implemented for SoC internal registers only over the PCIe interface, then an attacker could still modify the SoC internal registers through alternate paths by coming through interfaces such as UART, SMBUS, USB, etc. Alternatively, attackers might be able to bypass existing protections by exploiting unprotected, shadow registers. Shadow registers and mirror registers typically refer to registers that can be accessed from multiple addresses. Writing to or reading from the aliased/mirrored address has the same effect as writing to the address of the main register. They are typically implemented within an IP core or SoC to temporarily hold certain data. These data will later be updated to the main register, and both registers will be in synch. If the shadow registers are not access-protected, attackers could simply initiate transactions to the shadow registers and compromise system security.",::NATURE:PeerOf:CWE ID:1191:VIEW ID:1194:ORDINAL:Primary::NATURE:ChildOf:CWE ID:420:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:288:VIEW ID:1000::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY NAME:Microcontroller Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Processor Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Bus/Interface Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Access Control:IMPACT:Modify Memory:IMPACT:Read Memory:IMPACT:DoS: Resource Consumption (Other):IMPACT:Execute Unauthorized Code or Commands:IMPACT:Gain Privileges or Assume Identity:IMPACT:Alter Execution Logic:IMPACT:Bypass Protection Mechanism:IMPACT:Quality Degradation:LIKELIHOOD:High::","","::PHASE:Requirements:DESCRIPTION:Protect assets from accesses against all potential interfaces and alternate paths.:EFFECTIVENESS:Defense in Depth::PHASE:Architecture and Design:DESCRIPTION:Protect assets from accesses against all potential interfaces and alternate paths.:EFFECTIVENESS:Defense in Depth::PHASE:Implementation:DESCRIPTION:Protect assets from accesses against all potential interfaces and alternate paths.:EFFECTIVENESS:Defense in Depth::","::REFERENCE:CVE-2022-38399:DESCRIPTION:Missing protection mechanism on serial connection allows for arbitrary OS command execution.:LINK:https://www.cve.org/CVERecord?id=CVE-2022-38399::REFERENCE:CVE-2020-9285:DESCRIPTION:Mini-PCI Express slot does not restrict direct memory access.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-9285::REFERENCE:CVE-2020-8004:DESCRIPTION:When the internal flash is protected by blocking access on the Data Bus (DBUS), it can still be indirectly accessed through the Instruction Bus (IBUS).:LINK:https://www.cve.org/CVERecord?id=CVE-2020-8004::REFERENCE:CVE-2017-18293:DESCRIPTION:When GPIO is protected by blocking access to corresponding GPIO resource registers, protection can be bypassed by writing to the corresponding banked GPIO registers instead.:LINK:https://www.cve.org/CVERecord?id=CVE-2017-18293::REFERENCE:CVE-2020-15483:DESCRIPTION:monitor device allows access to physical UART debug port without authentication:LINK:https://www.cve.org/CVERecord?id=CVE-2020-15483::",,,"",::457::554::,"",
+1300,"Improper Protection of Physical Side Channels",Base,Stable,"The device does not contain sufficient protection mechanisms to prevent physical side channels from exposing sensitive information due to patterns in physically observable phenomena such as variations in power consumption, electromagnetic emissions (EME), or acoustic emissions.","An adversary could monitor and measure physical phenomena to detect patterns and make inferences, even if it is not possible to extract the information in the digital domain. Physical side channels have been well-studied for decades in the context of breaking implementations of cryptographic algorithms or other attacks against security features. These side channels may be easily observed by an adversary with physical access to the device, or using a tool that is in close proximity. If the adversary can monitor hardware operation and correlate its data processing with power, EME, and acoustic measurements, the adversary might be able to recover of secret keys and data.",::NATURE:ChildOf:CWE ID:203:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:203:VIEW ID:1194:ORDINAL:Primary::,"::ORDINALITY:Primary::ORDINALITY:Resultant::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:IMPACT:Read Memory:IMPACT:Read Application Data::","::METHOD:Manual Analysis:DESCRIPTION:Perform a set of leakage detection tests such as the procedure outlined in the Test Vector Leakage Assessment (TVLA) test requirements for AES [REF-1230]. TVLA is the basis for the ISO standard 17825 [REF-1229]. A separate methodology is provided by [REF-1228]. Note that sole reliance on this method might not yield expected results [REF-1239] [REF-1240].:EFFECTIVENESS:Moderate::METHOD:Manual Analysis:DESCRIPTION:Post-silicon, perform full side-channel attacks (penetration testing) covering as many known leakage models as possible against test code.:EFFECTIVENESS:Moderate::METHOD:Manual Analysis:DESCRIPTION:Pre-silicon - while the aforementioned TVLA methods can be performed post-silicon, models of device power consumption or other physical emanations can be built from information present at various stages of the hardware design process before fabrication. TVLA or known side-channel attacks can be applied to these simulated traces and countermeasures applied before tape-out. Academic research in this field includes [REF-1231] [REF-1232] [REF-1233].:EFFECTIVENESS:Moderate::","::PHASE:Architecture and Design:DESCRIPTION:Apply blinding or masking techniques to implementations of cryptographic algorithms.::PHASE:Implementation:DESCRIPTION:Add shielding or tamper-resistant protections to the device to increase the difficulty of obtaining measurements of the side-channel.::","::REFERENCE:CVE-2022-35888:DESCRIPTION:Power side-channels leak secret information from processor:LINK:https://www.cve.org/CVERecord?id=CVE-2022-35888::REFERENCE:CVE-2021-3011:DESCRIPTION:electromagnetic-wave side-channel in security-related microcontrollers allows extraction of private key:LINK:https://www.cve.org/CVERecord?id=CVE-2021-3011::REFERENCE:CVE-2019-14353:DESCRIPTION:Crypto hardware wallet's power consumption relates to total number of pixels illuminated, creating a side channel in the USB connection that allows attackers to determine secrets displayed such as PIN numbers and passwords:LINK:https://www.cve.org/CVERecord?id=CVE-2019-14353::REFERENCE:CVE-2020-27211:DESCRIPTION:Chain: microcontroller system-on-chip contains uses a register value stored in flash to set product protection state on the memory bus but does not contain protection against fault injection (CWE-1319), which leads to an incorrect initialization of the memory bus (CWE-1419) leading the product to be in an unprotected state.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-27211::REFERENCE:CVE-2013-4576:DESCRIPTION:message encryption software uses certain instruction sequences that allows RSA key extraction using a chosen-ciphertext attack and acoustic cryptanalysis:LINK:https://www.cve.org/CVERecord?id=CVE-2013-4576::REFERENCE:CVE-2020-28368:DESCRIPTION:virtualization product allows recovery of AES keys from the guest OS using a side channel attack against a power/energy monitoring interface.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-28368::REFERENCE:CVE-2019-18673:DESCRIPTION:power consumption varies based on number of pixels being illuminated in a display, allowing reading of secrets such as the PIN by using the USB interface to measure power consumption:LINK:https://www.cve.org/CVERecord?id=CVE-2019-18673::",::Power::,,"",::189::699::,"",
+1301,"Insufficient or Incomplete Data Removal within Hardware Component",Base,Incomplete,"The product's data removal process does not completely delete all data and potentially sensitive information within hardware components.","Physical properties of hardware devices, such as remanence of magnetic media, residual charge of ROMs/RAMs, or screen burn-in may still retain sensitive data after a data removal process has taken place and power is removed. Recovering data after erasure or overwriting is possible due to a phenomenon called data remanence. For example, if the same value is written repeatedly to a memory location, the corresponding memory cells can become physically altered to a degree such that even after the original data is erased that data can still be recovered through physical characterization of the memory cells.",::NATURE:ChildOf:CWE ID:226:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:IMPACT:Read Memory:IMPACT:Read Application Data::","","::PHASE:Architecture and Design:DESCRIPTION:Apply blinding or masking techniques to implementations of cryptographic algorithms.::PHASE:Implementation:DESCRIPTION:Alter the method of erasure, add protection of media, or destroy the media to protect the data.::","::REFERENCE:CVE-2019-8575:DESCRIPTION:Firmware Data Deletion Vulnerability in which a base station factory reset might not delete all user information. The impact of this enables a new owner of a used device that has been factory-default reset with a vulnerable firmware version can still retrieve, at least, the previous owner's wireless network name, and the previous owner's wireless security (such as WPA2) key. This issue was addressed with improved, data deletion.:LINK:https://www.cve.org/CVERecord?id=CVE-2019-8575::",,,"",::37::,"::TYPE:Maintenance:NOTE:This entry is still under development and will continue to see updates and content improvements.::",
+1302,"Missing Source Identifier in Entity Transactions on a System-On-Chip (SOC)",Base,Incomplete,"The product implements a security identifier mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. A transaction is sent without a security identifier.","In a System-On-Chip (SoC), various integrated circuits and hardware engines generate transactions such as to access (reads/writes) assets or perform certain actions (e.g., reset, fetch, compute). A typical transaction is comprised of source identity (to identify the originator of the transaction) and a destination identity (to route the transaction to the respective entity) in addition to much more information in the message. Sometimes the transactions are qualified with a Security Identifier. This Security Identifier helps the destination agent decide on the set of allowed or disallowed actions. A weakness that can exist in such transaction schemes is that the source agent does not consistently include the necessary Security Identifier with the transaction. If the Security Identifier is missing, the destination agent might drop the message (resulting in an inadvertent Denial-of-Service (DoS)) or take inappropriate action by default in its attempt to execute the transaction, resulting in privilege escalation or provision of unintended access.",::NATURE:ChildOf:CWE ID:1294:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:Such issues could be introduced during hardware architecture and design and identified later during Testing or System Configuration phases.::PHASE:Implementation:NOTE:Such issues could be introduced during implementation and identified later during Testing or System Configuration phases.::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Access Control:IMPACT:Modify Memory:IMPACT:Read Memory:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:Bypass Protection Mechanism:IMPACT:Execute Unauthorized Code or Commands:LIKELIHOOD:High::","","::PHASE:Architecture and Design:DESCRIPTION:Transaction details must be reviewed for design inconsistency and common weaknesses.::PHASE:Implementation:DESCRIPTION:Security identifier definition and programming flow must be tested in pre-silicon and post-silicon testing.::","",,,"",::121::681::,"",
+1303,"Non-Transparent Sharing of Microarchitectural Resources",Base,Draft,"Hardware structures shared across execution contexts (e.g., caches and branch predictors) can violate the expected architecture isolation between contexts.","Modern processors use techniques such as out-of-order execution, speculation, prefetching, data forwarding, and caching to increase performance. Details about the implementation of these techniques are hidden from the programmer's view. This is problematic when the hardware implementation of these techniques results in resources being shared across supposedly isolated contexts. Contention for shared resources between different contexts opens covert channels that allow malicious programs executing in one context to recover information from another context. Some examples of shared micro-architectural resources that have been used to leak information between contexts are caches, branch prediction logic, and load or store buffers. Speculative and out-of-order execution provides an attacker with increased control over which data is leaked through the covert channel. If the extent of resource sharing between contexts in the design microarchitecture is undocumented, it is extremely difficult to ensure system assets are protected against disclosure.",::NATURE:ChildOf:CWE ID:1189:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:203:VIEW ID:1000::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:Such issues could be introduced during hardware architecture and design and identified later during Testing or System Configuration phases.::PHASE:Implementation:NOTE:Such issues could be introduced during implementation and identified later during Testing or System Configuration phases.::","",,"::SCOPE:Confidentiality:IMPACT:Read Application Data:IMPACT:Read Memory:NOTE:Microarchitectural side-channels have been used to leak specific information such as cryptographic keys, and Address Space Layout Randomization (ALSR) offsets as well as arbitrary memory.::","","::PHASE:Architecture and Design:DESCRIPTION:Microarchitectural covert channels can be addressed using a mixture of hardware and software mitigation techniques. These include partitioned caches, new barrier and flush instructions, and disabling high resolution performance counters and timers.::PHASE:Requirements:DESCRIPTION:Microarchitectural covert channels can be addressed using a mixture of hardware and software mitigation techniques. These include partitioned caches, new barrier and flush instructions, and disabling high resolution performance counters and timers.::","",,,"",::663::,"::TYPE:Maintenance:NOTE:As of CWE 4.9, members of the CWE Hardware SIG are closely analyzing this entry and others to improve CWE's coverage of transient execution weaknesses, which include issues related to Spectre, Meltdown, and other attacks. Additional investigation may include other weaknesses related to microarchitectural state. Finally, this entry's demonstrative example might not be appropriate. As a result, this entry might change significantly in CWE 4.10.::",
+1304,"Improperly Preserved Integrity of Hardware Configuration State During a Power Save/Restore Operation",Base,Draft,"The product performs a power save/restore operation, but it does not ensure that the integrity of the configuration state is maintained and/or verified between the beginning and ending of the operation.","Before powering down, the Intellectual Property (IP) saves current state (S) to persistent storage such as flash or always-on memory in order to optimize the restore operation. During this process, an attacker with access to the persistent storage may alter (S) to a configuration that could potentially modify privileges, disable protections, and/or cause damage to the hardware. If the IP does not validate the configuration state stored in persistent memory, upon regaining power or becoming operational again, the IP could be compromised through the activation of an unwanted/harmful configuration.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::NATURE:PeerOf:CWE ID:345:VIEW ID:1000::NATURE:PeerOf:CWE ID:1271:VIEW ID:1194::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:Weakness introduced via missing internal integrity guarantees during power save/restore::PHASE:Integration:NOTE:Weakness introduced via missing external integrity verification during power save/restore::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:DoS: Instability:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:DoS: Resource Consumption (Other):IMPACT:Gain Privileges or Assume Identity:IMPACT:Bypass Protection Mechanism:IMPACT:Alter Execution Logic:IMPACT:Quality Degradation:IMPACT:Unexpected State:IMPACT:Reduce Maintainability:IMPACT:Reduce Performance:IMPACT:Reduce Reliability:LIKELIHOOD:High::","","::PHASE:Architecture and Design:DESCRIPTION:Inside the IP, incorporate integrity checking on the configuration state via a cryptographic hash. The hash can be protected inside the IP such as by storing it in internal registers which never lose power. Before powering down, the IP performs a hash of the configuration and saves it in these persistent registers. Upon restore, the IP performs a hash of the saved configuration and compares it with the saved hash. If they do not match, then the IP should not trust the configuration.::PHASE:Integration:DESCRIPTION:Outside the IP, incorporate integrity checking of the configuration state via a trusted agent. Before powering down, the trusted agent performs a hash of the configuration and saves the hash in persistent storage. Upon restore, the IP requests the trusted agent validate its current configuration. If the configuration hash is invalid, then the IP should not trust the configuration.::PHASE:Integration:DESCRIPTION:Outside the IP, incorporate a protected environment that prevents undetected modification of the configuration state by untrusted agents. Before powering down, a trusted agent saves the IP's configuration state in this protected location that only it is privileged to. Upon restore, the trusted agent loads the saved state into the IP.::","",::Power::,,"",::176::,"",
+1310,"Missing Ability to Patch ROM Code",Base,Draft,"Missing an ability to patch ROM code may leave a System or System-on-Chip (SoC) in a vulnerable state.","A System or System-on-Chip (SoC) that implements a boot process utilizing security mechanisms such as Root-of-Trust (RoT) typically starts by executing code from a Read-only-Memory (ROM) component. The code in ROM is immutable, hence any security vulnerabilities discovered in the ROM code can never be fixed for the systems that are already in use. A common weakness is that the ROM does not have the ability to patch if security vulnerabilities are uncovered after the system gets shipped. This leaves the system in a vulnerable state where an adversary can compromise the SoC.",::NATURE:ChildOf:CWE ID:1329:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:This issue could be introduced during hardware architecture and design and can be identified later during Testing.::PHASE:Implementation:NOTE:This issue could be introduced during implementation and can be identified later during Testing.::PHASE:Integration:NOTE:This issue could be introduced during integration and can be identified later during Testing.::PHASE:Manufacturing:NOTE:This issue could be introduced during manufacturing and can be identified later during Testing.::","",,"::SCOPE:Other:IMPACT:Varies by Context:IMPACT:Reduce Maintainability:LIKELIHOOD:High:NOTE:When the system is unable to be patched, it can be left in a vulnerable state.::","","::PHASE:Architecture and Design Implementation:DESCRIPTION:Secure patch support to allow ROM code to be patched on the next boot.:EFFECTIVENESS:Moderate::PHASE:Architecture and Design Implementation:DESCRIPTION:Support patches that can be programmed in-field or during manufacturing through hardware fuses. This feature can be used for limited patching of devices after shipping, or for the next batch of silicon devices manufactured, without changing the full device ROM.:EFFECTIVENESS:Moderate::","",,,"",::682::,"",
+1311,"Improper Translation of Security Attributes by Fabric Bridge",Base,Draft,"The bridge incorrectly translates security attributes from either trusted to untrusted or from untrusted to trusted when converting from one fabric protocol to another.","A bridge allows IP blocks supporting different fabric protocols to be integrated into the system. Fabric end-points or interfaces usually have dedicated signals to transport security attributes. For example, HPROT signals in AHB, AxPROT signals in AXI, and MReqInfo and SRespInfo signals in OCP. The values on these signals are used to indicate the security attributes of the transaction. These include the immutable hardware identity of the controller initiating the transaction, privilege level, and type of transaction (e.g., read/write, cacheable/non-cacheable, posted/non-posted). A weakness can arise if the bridge IP block, which translates the signals from the protocol used in the IP block endpoint to the protocol used by the central bus, does not properly translate the security attributes. As a result, the identity of the initiator could be translated from untrusted to trusted or vice-versa. This could result in access-control bypass, privilege escalation, or denial of service.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE NAME:Verilog:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:VHDL:LANGUAGE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Access Control:IMPACT:Modify Memory:IMPACT:Read Memory:IMPACT:Gain Privileges or Assume Identity:IMPACT:Bypass Protection Mechanism:IMPACT:Execute Unauthorized Code or Commands::","","::PHASE:Architecture and Design:DESCRIPTION:The translation must map signals in such a way that untrusted agents cannot map to trusted agents or vice-versa.::PHASE:Implementation:DESCRIPTION:Ensure that the translation maps signals in such a way that untrusted agents cannot map to trusted agents or vice-versa.::","",,,"",::1::180::233::,"",
+1312,"Missing Protection for Mirrored Regions in On-Chip Fabric Firewall",Base,Draft,"The firewall in an on-chip fabric protects the main addressed region, but it does not protect any mirrored memory or memory-mapped-IO (MMIO) regions.","Few fabrics mirror memory and address ranges, where mirrored regions contain copies of the original data. This redundancy is used to achieve fault tolerance. Whatever protections the fabric firewall implements for the original region should also apply to the mirrored regions. If not, an attacker could bypass existing read/write protections by reading from/writing to the mirrored regions to leak or corrupt the original data.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::NATURE:PeerOf:CWE ID:1251:VIEW ID:1194::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Access Control:IMPACT:Modify Memory:IMPACT:Read Memory:IMPACT:Bypass Protection Mechanism::","::METHOD:Manual Dynamic Analysis:DESCRIPTION:Using an external debugger, send write transactions to mirrored regions to test if original, write-protected regions are modified. Similarly, send read transactions to mirrored regions to test if the original, read-protected signals can be read.:EFFECTIVENESS:High::","::PHASE:Architecture and Design:DESCRIPTION:The fabric firewall should apply the same protections as the original region to the mirrored regions.::PHASE:Implementation:DESCRIPTION:The fabric firewall should apply the same protections as the original region to the mirrored regions.::","",,,"",::456::679::,"",
+1313,"Hardware Allows Activation of Test or Debug Logic at Runtime",Base,Draft,"During runtime, the hardware allows for test or debug logic (feature) to be activated, which allows for changing the state of the hardware. This feature can alter the intended behavior of the system and allow for alteration and leakage of sensitive data by an adversary.","An adversary can take advantage of test or debug logic that is made accessible through the hardware during normal operation to modify the intended behavior of the system. For example, an accessible Test/debug mode may allow read/write access to any system data. Using error injection (a common test/debug feature) during a transmit/receive operation on a bus, data may be modified to produce an unintended message. Similarly, confidentiality could be compromised by such features allowing access to secrets.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:Such issues could be introduced during hardware architecture and design and identified later during Testing or System Configuration phases.::PHASE:Implementation:NOTE:Such issues could be introduced during implementation and identified later during Testing or System Configuration phases.::PHASE:Integration:NOTE:Such issues could be introduced during integration and identified later during Testing or System configuration phases.::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:IMPACT:Modify Memory:IMPACT:Read Memory:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:DoS: Instability:IMPACT:DoS: Resource Consumption (CPU):IMPACT:DoS: Resource Consumption (Memory):IMPACT:DoS: Resource Consumption (Other):IMPACT:Execute Unauthorized Code or Commands:IMPACT:Gain Privileges or Assume Identity:IMPACT:Bypass Protection Mechanism:IMPACT:Alter Execution Logic:IMPACT:Quality Degradation:IMPACT:Unexpected State:IMPACT:Reduce Performance:IMPACT:Reduce Reliability::","","::PHASE:Architecture and Design:DESCRIPTION:Insert restrictions on when the hardware's test or debug features can be activated. For example, during normal operating modes, the hardware's privileged modes that allow access to such features cannot be activated. Configuring the hardware to only enter a test or debug mode within a window of opportunity such as during boot or configuration stage. The result is disablement of such test/debug features and associated modes during normal runtime operations.::PHASE:Implementation:DESCRIPTION:Insert restrictions on when the hardware's test or debug features can be activated. For example, during normal operating modes, the hardware's privileged modes that allow access to such features cannot be activated. Configuring the hardware to only enter a test or debug mode within a window of opportunity such as during boot or configuration stage. The result is disablement of such test/debug features and associated modes during normal runtime operations.::PHASE:Integration:DESCRIPTION:Insert restrictions on when the hardware's test or debug features can be activated. For example, during normal operating modes, the hardware's privileged modes that allow access to such features cannot be activated. Configuring the hardware to only enter a test or debug mode within a window of opportunity such as during boot or configuration stage. The result is disablement of such test/debug features and associated modes during normal runtime operations.::","::REFERENCE:CVE-2021-33150:DESCRIPTION:Hardware processor allows activation of test or debug logic at runtime.:LINK:https://www.cve.org/CVERecord?id=CVE-2021-33150::REFERENCE:CVE-2021-0146:DESCRIPTION:Processor allows the activation of test or debug logic at runtime, allowing escalation of privileges:LINK:https://www.cve.org/CVERecord?id=CVE-2021-0146::",,,"",::121::,"",
+1314,"Missing Write Protection for Parametric Data Values",Base,Draft,"The device does not write-protect the parametric data values for sensors that scale the sensor value, allowing untrusted software to manipulate the apparent result and potentially damage hardware or cause operational failure.","Various sensors are used by hardware to detect any devices operating outside of the design limits. The threshold limit values are set by hardware fuses or trusted software such as the BIOS. These limits may be related to thermal, power, voltage, current, and frequency. Hardware mechanisms may be used to protect against alteration of the threshold limit values by untrusted software. The limit values are generally programmed in standard units for the type of value being read. However, the hardware-sensor blocks may report the settings in different units depending upon sensor design and operation. The raw sensor output value is converted to the desired units using a scale conversion based on the parametric data programmed into the sensor. The final converted value is then compared with the previously programmed limits. While the limit values are usually protected, the sensor parametric data values may not be. By changing the parametric data, safe operational limits may be bypassed.",::NATURE:ChildOf:CWE ID:862:VIEW ID:1000:ORDINAL:Primary::NATURE:PeerOf:CWE ID:1299:VIEW ID:1194:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY NAME:Sensor Hardware:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:The lack of a requirement to protect parametric values may contribute to this weakness.::PHASE:Implementation:NOTE:The lack of parametric value protection may be a cause of this weakness.::","",,"::SCOPE:Availability:IMPACT:Quality Degradation:IMPACT:DoS: Resource Consumption (Other):LIKELIHOOD:High:NOTE:Sensor value manipulation, particularly thermal or power, may allow physical damage to occur or disabling of the device by a false fault shutdown causing a Denial-Of-Service.::","","::PHASE:Architecture and Design:DESCRIPTION:Access controls for sensor blocks should ensure that only trusted software is allowed to change threshold limits and sensor parametric data.:EFFECTIVENESS:High::","::REFERENCE:CVE-2017-8252:DESCRIPTION:Kernel can inject faults in computations during the execution of TrustZone leading to information disclosure in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer Electronics Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon IoT, Snapdragon Mobile, Snapdragon Voice and Music, Snapdragon Wearables, Snapdragon Wired Infrastructure and Networking.:LINK:https://www.cve.org/CVERecord?id=CVE-2017-8252::",,,"",::1::,"",
+1315,"Improper Setting of Bus Controlling Capability in Fabric End-point",Base,Incomplete,"The bus controller enables bits in the fabric end-point to allow responder devices to control transactions on the fabric.","To support reusability, certain fabric interfaces and end points provide a configurable register bit that allows IP blocks connected to the controller to access other peripherals connected to the fabric. This allows the end point to be used with devices that function as a controller or responder. If this bit is set by default in hardware, or if firmware incorrectly sets it later, a device intended to be a responder on a fabric is now capable of controlling transactions to other devices and might compromise system security.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::PHASE:System Configuration::","",,"::SCOPE:Access Control:IMPACT:Modify Memory:IMPACT:Read Memory:IMPACT:Bypass Protection Mechanism::","","::PHASE:Architecture and Design:DESCRIPTION:For responder devices, the register bit in the fabric end-point that enables the bus controlling capability must be set to 0 by default. This bit should not be set during secure-boot flows. Also, writes to this register must be access-protected to prevent malicious modifications to obtain bus-controlling capability.::PHASE:Implementation:DESCRIPTION:For responder devices, the register bit in the fabric end-point that enables the bus controlling capability must be set to 0 by default. This bit should not be set during secure-boot flows. Also, writes to this register must be access-protected to prevent malicious modifications to obtain bus-controlling capability.::PHASE:System Configuration:DESCRIPTION:For responder devices, the register bit in the fabric end-point that enables the bus controlling capability must be set to 0 by default. This bit should not be set during secure-boot flows. Also, writes to this register must be access-protected to prevent malicious modifications to obtain bus-controlling capability.::","",,,"",::1::180::,"",
+1316,"Fabric-Address Map Allows Programming of Unwarranted Overlaps of Protected and Unprotected Ranges",Base,Draft,"The address map of the on-chip fabric has protected and unprotected regions overlapping, allowing an attacker to bypass access control to the overlapping portion of the protected region.","Various ranges can be defined in the system-address map, either in the memory or in Memory-Mapped-IO (MMIO) space. These ranges are usually defined using special range registers that contain information, such as base address and size. Address decoding is the process of determining for which range the incoming transaction is destined. To ensure isolation, ranges containing secret data are access-control protected. Occasionally, these ranges could overlap. The overlap could either be intentional (e.g. due to a limited number of range registers or limited choice in choosing size of the range) or unintentional (e.g. introduced by errors). Some hardware designs allow dynamic remapping of address ranges assigned to peripheral MMIO ranges. In such designs, intentional address overlaps can be created through misconfiguration by malicious software. When protected and unprotected ranges overlap, an attacker could send a transaction and potentially compromise the protections in place, violating the principle of least privilege.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY NAME:Bus/Interface Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Access Control:SCOPE:Authorization:IMPACT:Bypass Protection Mechanism:IMPACT:Read Memory:IMPACT:Modify Memory:LIKELIHOOD:Medium::","::METHOD:Automated Dynamic Analysis:DESCRIPTION:Review address map in specification to see if there are any overlapping ranges.:EFFECTIVENESS:High::METHOD:Manual Static Analysis:DESCRIPTION:Negative testing of access control on overlapped ranges.:EFFECTIVENESS:High::","::PHASE:Architecture and Design:DESCRIPTION:When architecting the address map of the chip, ensure that protected and unprotected ranges are isolated and do not overlap. When designing, ensure that ranges hardcoded in Register-Transfer Level (RTL) do not overlap.::PHASE:Implementation:DESCRIPTION:Ranges configured by firmware should not overlap. If overlaps are mandatory because of constraints such as a limited number of registers, then ensure that no assets are present in the overlapped portion.::PHASE:Testing:DESCRIPTION:Validate mitigation actions with robust testing.::","::REFERENCE:CVE-2009-4419:DESCRIPTION:Attacker can modify MCHBAR register to overlap with an attacker-controlled region, which modification prevents the SENTER instruction from properly applying VT-d protection while a Measured Launch Environment is being launched.:LINK:https://www.cve.org/CVERecord?id=CVE-2009-4419::",,,"",::456::679::,"::TYPE:Maintenance:NOTE:As of CWE 4.6, CWE-1260 and CWE-1316 are siblings under view 1000, but CWE-1260 might be a parent of CWE-1316. More analysis is warranted.::",
+1317,"Improper Access Control in Fabric Bridge",Base,Draft,"The product uses a fabric bridge for transactions between two Intellectual Property (IP) blocks, but the bridge does not properly perform the expected privilege, identity, or other access control checks between those IP blocks.","In hardware designs, different IP blocks are connected through interconnect-bus fabrics (e.g. AHB and OCP). Within a System on Chip (SoC), the IP block subsystems could be using different bus protocols. In such a case, the IP blocks are then linked to the central bus (and to other IP blocks) through a fabric bridge. Bridges are used as bus-interconnect-routing modules that link different protocols or separate, different segments of the overall SoC interconnect. For overall system security, it is important that the access-control privileges associated with any fabric transaction are consistently maintained and applied, even when they are routed or translated by a fabric bridge. A bridge that is connected to a fabric without security features forwards transactions to the slave without checking the privilege level of the master and results in a weakness in SoC access-control security. The same weakness occurs if a bridge does not check the hardware identity of the transaction received from the slave interface of the bridge.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY NAME:Processor Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Access Control:SCOPE:Availability:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:Bypass Protection Mechanism:IMPACT:Read Memory:IMPACT:Modify Memory:LIKELIHOOD:Medium::","::METHOD:Simulation / Emulation:DESCRIPTION:RTL simulation to ensure that bridge-access controls are implemented properly.:EFFECTIVENESS:High::METHOD:Formal Verification:DESCRIPTION:Formal verification of bridge RTL to ensure that access control cannot be bypassed.:EFFECTIVENESS:High::","::PHASE:Architecture and Design:DESCRIPTION:Ensure that the design includes provisions for access-control checks in the bridge for both upstream and downstream transactions.::PHASE:Implementation:DESCRIPTION:Implement access-control checks in the bridge for both upstream and downstream transactions.::","::REFERENCE:CVE-2019-6260:DESCRIPTION:Baseboard Management Controller (BMC) device implements Advanced High-performance Bus (AHB) bridges that do not require authentication for arbitrary read and write access to the BMC's physical address space from the host, and possibly the network [REF-1138].:LINK:https://www.cve.org/CVERecord?id=CVE-2019-6260::",,,"",::122::,"",
+1318,"Missing Support for Security Features in On-chip Fabrics or Buses",Base,Incomplete,"On-chip fabrics or buses either do not support or are not configured to support privilege separation or other security features, such as access control.","Certain on-chip fabrics and buses, especially simple and low-power buses, do not support security features. Apart from data transfer and addressing ports, some fabrics and buses do not have any interfaces to transfer privilege, immutable identity, or any other security attribute coming from the bus master. Similarly, they do not have dedicated signals to transport security-sensitive data from slave to master, such as completions for certain types of transactions. Few other on-chip fabrics and buses support security features and define specific interfaces/signals for transporting security attributes from master to slave or vice-versa. However, including these signals is not mandatory and could be left unconfigured when generating the register-transfer-level (RTL) description for the fabric. Such fabrics or buses should not be used to transport any security attribute coming from the bus master. In general, peripherals with security assets should not be connected to such buses before the transaction from the bus master reaches the bus, unless some form of access control is performed at a fabric bridge or another intermediate module.",::NATURE:ChildOf:CWE ID:693:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY NAME:Processor Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Access Control:SCOPE:Availability:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:Read Memory:IMPACT:Modify Memory:LIKELIHOOD:Medium::","::METHOD:Architecture or Design Review:DESCRIPTION:Review the fabric specification and ensure that it contains signals to transfer security-sensitive signals.:EFFECTIVENESS:High::METHOD:Manual Static Analysis - Source Code:DESCRIPTION:Lack of security features can also be confirmed through manual RTL review of the fabric RTL.:EFFECTIVENESS:High::","::PHASE:Architecture and Design:DESCRIPTION:If fabric does not support security features, implement security checks in a bridge or any component that is between the master and the fabric. Alternatively, connect all fabric slaves that do not have any security assets under one such fabric and connect peripherals with security assets to a different fabric that supports security features.::","",,,"",::1::180::,"",
+1319,"Improper Protection against Electromagnetic Fault Injection (EM-FI)",Base,Incomplete,"The device is susceptible to electromagnetic fault injection attacks, causing device internal information to be compromised or security mechanisms to be bypassed.","Electromagnetic fault injection may allow an attacker to locally and dynamically modify the signals (both internal and external) of an integrated circuit. EM-FI attacks consist of producing a local, transient magnetic field near the device, inducing current in the device wires. A typical EMFI setup is made up of a pulse injection circuit that generates a high current transient in an EMI coil, producing an abrupt magnetic pulse which couples to the target producing faults in the device, which can lead to: Bypassing security mechanisms such as secure JTAG or Secure Boot Leaking device information Modifying program flow Perturbing secure hardware modules (e.g. random number generators)",::NATURE:ChildOf:CWE ID:693:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Microcontroller Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Memory Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Power Management Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Processor Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Test/Debug Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Sensor Hardware:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Access Control:SCOPE:Availability:IMPACT:Modify Memory:IMPACT:Read Memory:IMPACT:Gain Privileges or Assume Identity:IMPACT:Bypass Protection Mechanism:IMPACT:Execute Unauthorized Code or Commands::","","::PHASE:Architecture and Design Implementation:DESCRIPTION:1. Redundancy - By replicating critical operations and comparing the two outputs can help indicate whether a fault has been injected. 2. Error detection and correction codes - Gay, Mael, et al. proposed a new scheme that not only detects faults injected by a malicious adversary but also automatically corrects single nibble/byte errors introduced by low-multiplicity faults. 3. Fail by default coding - When checking conditions (switch or if) check all possible cases and fail by default because the default case in a switch (or the else part of a cascaded if-else-if construct) is used for dealing with the last possible (and valid) value without checking. This is prone to fault injection because this alternative is easily selected as a result of potential data manipulation [REF-1141]. 4. Random Behavior - adding random delays before critical operations, so that timing is not predictable. 5. Program Flow Integrity Protection - The program flow can be secured by integrating run-time checking aiming at detecting control flow inconsistencies. One such example is tagging the source code to indicate the points not to be bypassed [REF-1147]. 6. Sensors - Usage of sensors can detect variations in voltage and current. 7. Shields - physical barriers to protect the chips from malicious manipulation.::","::REFERENCE:CVE-2020-27211:DESCRIPTION:Chain: microcontroller system-on-chip uses a register value stored in flash to set product protection state on the memory bus and does not contain protection against fault injection (CWE-1319) which leads to an incorrect initialization of the memory bus (CWE-1419) causing the product to be in an unprotected state.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-27211::",,,"",::624::625::,"::TYPE:Maintenance:NOTE:This entry is attack-oriented and may require significant modification in future versions, or even deprecation. It is not clear whether there is really a design mistake that enables such attacks, so this is not necessarily a weakness and may be more appropriate for CAPEC.::",
+1320,"Improper Protection for Outbound Error Messages and Alert Signals",Base,Draft,"Untrusted agents can disable alerts about signal conditions exceeding limits or the response mechanism that handles such alerts.","Hardware sensors are used to detect whether a device is operating within design limits. The threshold values for these limits are set by hardware fuses or trusted software such as a BIOS. Modification of these limits may be protected by hardware mechanisms. When device sensors detect out of bound conditions, alert signals may be generated for remedial action, which may take the form of device shutdown or throttling. Warning signals that are not properly secured may be disabled or used to generate spurious alerts, causing degraded performance or denial-of-service (DoS). These alerts may be masked by untrusted software. Examples of these alerts involve thermal and power sensor alerts.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Microcontroller Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Memory Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Power Management Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Processor Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Test/Debug Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Sensor Hardware:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Availability:IMPACT:DoS: Instability:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:Reduce Reliability:IMPACT:Unexpected State:LIKELIHOOD:High::","","::PHASE:Architecture and Design:DESCRIPTION:Alert signals generated by critical events should be protected from access by untrusted agents. Only hardware or trusted firmware modules should be able to alter the alert configuration.::","",,,"",::1::180::,"",
+1323,"Improper Management of Sensitive Trace Data",Base,Draft,"Trace data collected from several sources on the System-on-Chip (SoC) is stored in unprotected locations or transported to untrusted agents.","To facilitate verification of complex System-on-Chip (SoC) designs, SoC integrators add specific IP blocks that trace the SoC's internal signals in real-time. This infrastructure enables observability of the SoC's internal behavior, validation of its functional design, and detection of hardware and software bugs. Such tracing IP blocks collect traces from several sources on the SoC including the CPU, crypto coprocessors, and on-chip fabrics. Traces collected from these sources are then aggregated inside trace IP block and forwarded to trace sinks, such as debug-trace ports that facilitate debugging by external hardware and software debuggers. Since these traces are collected from several security-sensitive sources, they must be protected against untrusted debuggers. If they are stored in unprotected memory, an untrusted software debugger can access these traces and extract secret information. Additionally, if security-sensitive traces are not tagged as secure, an untrusted hardware debugger might access them to extract confidential information.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Confidentiality:IMPACT:Read Memory:NOTE:An adversary can read secret values if they are captured in debug traces and stored unsafely.::","","::PHASE:Implementation:DESCRIPTION:Tag traces to indicate owner and debugging privilege level (designer, OEM, or end user) needed to access that trace.::","",,,"",::150::167::545::,"",
+1326,"Missing Immutable Root of Trust in Hardware",Base,Draft,"A missing immutable root of trust in the hardware results in the ability to bypass secure boot or execute untrusted or adversarial boot code.","A System-on-Chip (SoC) implements secure boot by verifying or authenticating signed boot code. The signing of the code is achieved by an entity that the SoC trusts. Before executing the boot code, the SoC verifies that the code or the public key with which the code has been signed has not been tampered with. The other data upon which the SoC depends are system-hardware settings in fuses such as whether Secure Boot is enabled. These data play a crucial role in establishing a Root of Trust (RoT) to execute secure-boot flows. One of the many ways RoT is achieved is by storing the code and data in memory or fuses. This memory should be immutable, i.e., once the RoT is programmed/provisioned in memory, that memory should be locked and prevented from further programming or writes. If the memory contents (i.e., RoT) are mutable, then an adversary can modify the RoT to execute their choice of code, resulting in a compromised secure boot. Note that, for components like ROM, secure patching/update features should be supported to allow authenticated and authorized updates in the field.",::NATURE:ChildOf:CWE ID:693:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY NAME:Security Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation:NOTE:Such issues could be introduced during policy definition, hardware architecture, design, manufacturing, and/or provisioning. They can be identified later during testing or system configuration phases.::","",,"::SCOPE:Authentication:SCOPE:Authorization:IMPACT:Gain Privileges or Assume Identity:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Modify Memory:LIKELIHOOD:High::","::METHOD:Automated Dynamic Analysis:DESCRIPTION:Automated testing can verify that RoT components are immutable.:EFFECTIVENESS:High::METHOD:Architecture or Design Review:DESCRIPTION:Root of trust elements and memory should be part of architecture and design reviews.:EFFECTIVENESS:High::","::PHASE:Architecture and Design:DESCRIPTION:When architecting the system, the RoT should be designated for storage in a memory that does not allow further programming/writes.::PHASE:Implementation:DESCRIPTION:During implementation and test, the RoT memory location should be demonstrated to not allow further programming/writes.::","",,,"",::679::68::,"",
+1328,"Security Version Number Mutable to Older Versions",Base,Draft,"Security-version number in hardware is mutable, resulting in the ability to downgrade (roll-back) the boot firmware to vulnerable code versions.","A System-on-Chip (SoC) implements secure boot or verified boot. It might support a security version number, which prevents downgrading the current firmware to a vulnerable version. Once downgraded to a previous version, an adversary can launch exploits on the SoC and thus compromise the security of the SoC. These downgrade attacks are also referred to as roll-back attacks. The security version number must be stored securely and persistently across power-on resets. A common weakness is that the security version number is modifiable by an adversary, allowing roll-back or downgrade attacks or, under certain circumstances, preventing upgrades (i.e. Denial-of-Service on upgrades). In both cases, the SoC is in a vulnerable state.",::NATURE:ChildOf:CWE ID:285:VIEW ID:1000:ORDINAL:Primary::NATURE:PeerOf:CWE ID:757:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY NAME:Security Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation:NOTE:Such issues could be introduced during hardware architecture and design, and can be identified later during testing or system configuration phases.::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Authentication:SCOPE:Authorization:IMPACT:Other:LIKELIHOOD:High:NOTE:Impact includes roll-back or downgrade to a vulnerable version of the firmware or DoS (prevent upgrades).::","::METHOD:Automated Dynamic Analysis:DESCRIPTION:Mutability of stored security version numbers and programming with older firmware images should be part of automated testing.:EFFECTIVENESS:High::METHOD:Architecture or Design Review:DESCRIPTION:Anti-roll-back features should be reviewed as part of Architecture or Design review.:EFFECTIVENESS:High::","::PHASE:Architecture and Design:DESCRIPTION:When architecting the system, security version data should be designated for storage in registers that are either read-only or have access controls that prevent modification by an untrusted agent.::PHASE:Implementation:DESCRIPTION:During implementation and test, security version data should be demonstrated to be read-only and access controls should be validated.::","",,,"",::176::,"",
+1329,"Reliance on Component That is Not Updateable",Base,Incomplete,"The product contains a component that cannot be updated or patched in order to remove vulnerabilities or significant bugs.","If the component is discovered to contain a vulnerability or critical bug, but the issue cannot be fixed using an update or patch, then the product's owner will not be able to protect against the issue. The only option might be replacement of the product, which could be too financially or operationally expensive for the product owner. As a result, the inability to patch or update can leave the product open to attacker exploitation or critical operation failures. This weakness can be especially difficult to manage when using ROM, firmware, or similar components that traditionally have had limited or no update capabilities. In industries such as healthcare, legacy devices can be operated for decades. As a US task force report [REF-1197] notes, the inability to update or replace equipment has both large and small health care delivery organizations struggle with numerous unsupported legacy systems that cannot easily be replaced (hardware, software, and operating systems) with large numbers of vulnerabilities and few modern countermeasures. While hardware can be prone to this weakness, software systems can also be affected, such as when a third-party driver or library is no longer actively maintained or supported but is still critical for the required functionality.",::NATURE:ChildOf:CWE ID:1357:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:664:VIEW ID:1000::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:ICS/OT:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Requirements:NOTE:Requirements development might not consider the importance of updates over the lifetime of the product or might intentionally exclude this capability due to concerns such as expense or speed to market.::PHASE:Architecture and Design:NOTE:Lack of planning during architecture development and design, or external pressures such as speed to market, could ignore the capability to update.::PHASE:Architecture and Design:NOTE:Designers might omit capabilities for updating a component due to time pressures to release the product or assumptions about the stability of the component.::PHASE:Implementation:NOTE:The weakness can appear through oversight during implementation.::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Access Control:SCOPE:Authentication:SCOPE:Authorization:SCOPE:Other:IMPACT:Gain Privileges or Assume Identity:IMPACT:Bypass Protection Mechanism:IMPACT:Execute Unauthorized Code or Commands:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:Quality Degradation:IMPACT:Reduce Maintainability:NOTE:If an attacker can identify an exploitable vulnerability in one product that has no means of patching, the attack may be used against all affected versions of that product.::","::METHOD:Architecture or Design Review:DESCRIPTION:Check the consumer or maintainer documentation, the architecture/design documentation, or the original requirements to ensure that the documentation includes details for how to update the firmware.:EFFECTIVENESS:Moderate::","::PHASE:Requirements:DESCRIPTION:Specify requirements that each component should be updateable, including ROM, firmware, etc.::PHASE:Architecture and Design:DESCRIPTION:Design the product to allow for updating of its components. Include the external infrastructure that might be necessary to support updates, such as distribution servers.::PHASE:Architecture and Design Implementation:DESCRIPTION:With hardware, support patches that can be programmed in-field or during manufacturing through hardware fuses. This feature can be used for limited patching of devices after shipping, or for the next batch of silicon devices manufactured, without changing the full device ROM.:EFFECTIVENESS:Moderate::PHASE:Implementation:DESCRIPTION:Implement the necessary functionality to allow each component to be updated.::","::REFERENCE:CVE-2020-9054:DESCRIPTION:Chain: network-attached storage (NAS) device has a critical OS command injection (CWE-78) vulnerability that is actively exploited to place IoT devices into a botnet, but some products are end-of-support and cannot be patched (CWE-1277). [REF-1097]:LINK:https://www.cve.org/CVERecord?id=CVE-2020-9054::",,,"",,"",
+1330,"Remanent Data Readable after Memory Erase",Variant,Draft,"Confidential information stored in memory circuits is readable or recoverable after being cleared or erased.","Data remanence occurs when stored, memory content is not fully lost after a memory-clear or -erase operation. Confidential memory contents can still be readable through data remanence in the hardware. Data remanence can occur because of performance optimization or memory organization during 'clear' or 'erase' operations, like a design that allows the memory-organization metadata (e.g., file pointers) to be erased without erasing the actual memory content. To protect against this weakness, memory devices will often support different commands for optimized memory erase and explicit secure erase. Data remanence can also happen because of the physical properties of memory circuits in use. For example, static, random-access-memory (SRAM) and dynamic, random-access-memory (DRAM) data retention is based on the charge retained in the memory cell, which depends on factors such as power supply, refresh rates, and temperature. Other than explicit erase commands, self-encrypting, secure-memory devices can also support secure erase through cryptographic erase commands. In such designs, only the decryption keys for encrypted data stored on the device are erased. That is, the stored data are always remnant in the media after a cryptographic erase. However, only the encrypted data can be extracted. Thus, protection against data recovery in such designs relies on the strength of the encryption algorithm.",::NATURE:ChildOf:CWE ID:1301:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:1301:VIEW ID:1194:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY NAME:Security Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Confidentiality:IMPACT:Modify Memory:IMPACT:Read Memory:NOTE:Confidential data are readable to untrusted agent.::","::METHOD:Architecture or Design Review:DESCRIPTION:Testing of memory-device contents after clearing or erase commands. Dynamic analysis of memory contents during device operation to detect specific, confidential assets. Architecture and design analysis of memory clear and erase operations.::METHOD:Dynamic Analysis with Manual Results Interpretation:DESCRIPTION:Testing of memory-device contents after clearing or erase commands. Dynamic analysis of memory contents during device operation to detect specific, confidential assets. Architecture and design analysis of memory clear and erase operations.::","::PHASE:Architecture and Design:DESCRIPTION:Support for secure-erase commands that apply multiple cycles of overwriting memory with known patterns and of erasing actual content. Support for cryptographic erase in self-encrypting, memory devices. External, physical tools to erase memory such as ultraviolet-rays-based erase of Electrically erasable, programmable, read-only memory (EEPROM). Physical destruction of media device. This is done for repurposed or scrapped devices that are no longer in use.::","::REFERENCE:CVE-2019-8575:DESCRIPTION:Firmware Data Deletion Vulnerability in which a base station factory reset might not delete all user information. The impact of this enables a new owner of a used device that has been factory-default reset with a vulnerable firmware version can still retrieve, at least, the previous owner's wireless network name, and the previous owner's wireless security (such as WPA2) key. This issue was addressed with improved, data deletion.:LINK:https://www.cve.org/CVERecord?id=CVE-2019-8575::",,,"",::150::37::545::,"",
+1331,"Improper Isolation of Shared Resources in Network On Chip (NoC)",Base,Stable,"The Network On Chip (NoC) does not isolate or incorrectly isolates its on-chip-fabric and internal resources such that they are shared between trusted and untrusted agents, creating timing channels.","Typically, network on chips (NoC) have many internal resources that are shared between packets from different trust domains. These resources include internal buffers, crossbars and switches, individual ports, and channels. The sharing of resources causes contention and introduces interference between differently trusted domains, which poses a security threat via a timing channel, allowing attackers to infer data that belongs to a trusted agent. This may also result in introducing network interference, resulting in degraded throughput and latency.",::NATURE:ChildOf:CWE ID:653:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:668:VIEW ID:1000::NATURE:PeerOf:CWE ID:1189:VIEW ID:1194::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY NAME:Security Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"::Network-on-chip (NoC) is a commonly-used term used for hardware interconnect fabrics used by multicore Systems-on-Chip (SoC). Communication between modules on the chip uses packet-based methods, with improved efficiency and scalability compared to bus architectures [REF-1241].::","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Availability:IMPACT:DoS: Resource Consumption (Other):IMPACT:Varies by Context:IMPACT:Other:LIKELIHOOD:Medium:NOTE:Attackers may infer data that belongs to a trusted agent. The methods used to perform this attack may result in noticeably increased resource consumption.::","::METHOD:Manual Analysis:DESCRIPTION:Providing marker flags to send through the interfaces coupled with examination of which users are able to read or manipulate the flags will help verify that the proper isolation has been achieved and is effective.:EFFECTIVENESS:Moderate::","::PHASE:Architecture and Design Implementation:DESCRIPTION:Implement priority-based arbitration inside the NoC and have dedicated buffers or virtual channels for routing secret data from trusted agents.::","::REFERENCE:CVE-2021-33096:DESCRIPTION:Improper isolation of shared resource in a network-on-chip leads to denial of service:LINK:https://www.cve.org/CVERecord?id=CVE-2021-33096::",,,"",::124::,"",
+1332,"Improper Handling of Faults that Lead to Instruction Skips",Base,Stable,"The device is missing or incorrectly implements circuitry or sensors that detect and mitigate the skipping of security-critical CPU instructions when they occur.","The operating conditions of hardware may change in ways that cause unexpected behavior to occur, including the skipping of security-critical CPU instructions. Generally, this can occur due to electrical disturbances or when the device operates outside of its expected conditions. In practice, application code may contain conditional branches that are security-sensitive (e.g., accepting or rejecting a user-provided password). These conditional branches are typically implemented by a single conditional branch instruction in the program binary which, if skipped, may lead to effectively flipping the branch condition - i.e., causing the wrong security-sensitive branch to be taken. This affects processes such as firmware authentication, password verification, and other security-sensitive decision points. Attackers can use fault injection techniques to alter the operating conditions of hardware so that security-critical instructions are skipped more frequently or more reliably than they would in a natural setting.",::NATURE:ChildOf:CWE ID:1384:VIEW ID:1000:ORDINAL:Primary::NATURE:PeerOf:CWE ID:1247:VIEW ID:1194:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:Failure to design appropriate countermeasures to common fault injection techniques can manifest this weakness.::PHASE:Implementation:NOTE:This weakness can arise if the hardware design incorrectly implements countermeasures to prevent fault injection.::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Authentication:IMPACT:Bypass Protection Mechanism:IMPACT:Alter Execution Logic:IMPACT:Unexpected State:LIKELIHOOD:High:NOTE:Depending on the context, instruction skipping can have a broad range of consequences related to the generic bypassing of security critical code.::","::METHOD:Automated Static Analysis:DESCRIPTION:This weakness can be found using automated static analysis once a developer has indicated which code paths are critical to protect.:EFFECTIVENESS:Moderate::METHOD:Simulation / Emulation:DESCRIPTION:This weakness can be found using automated dynamic analysis. Both emulation of a CPU with instruction skips, as well as RTL simulation of a CPU IP, can indicate parts of the code that are sensitive to faults due to instruction skips.:EFFECTIVENESS:Moderate::METHOD:Manual Analysis:DESCRIPTION:This weakness can be found using manual (static) analysis. The analyst has security objectives that are matched against the high-level code. This method is less precise than emulation, especially if the analysis is done at the higher level language rather than at assembly level.:EFFECTIVENESS:Moderate::","::PHASE:Architecture and Design:DESCRIPTION:Design strategies for ensuring safe failure if inputs, such as Vcc, are modified out of acceptable ranges.::PHASE:Architecture and Design:DESCRIPTION:Design strategies for ensuring safe behavior if instructions attempt to be skipped.::PHASE:Architecture and Design:DESCRIPTION:Identify mission critical secrets that should be wiped if faulting is detected, and design a mechanism to do the deletion.::PHASE:Implementation:DESCRIPTION:Add redundancy by performing an operation multiple times, either in space or time, and perform majority voting. Additionally, make conditional instruction timing unpredictable.::PHASE:Implementation:DESCRIPTION:Use redundant operations or canaries to detect and respond to faults.::PHASE:Implementation:DESCRIPTION:Ensure that fault mitigations are strong enough in practice. For example, a low power detection mechanism that takes 50 clock cycles to trigger at lower voltages may be an insufficient security mechanism if the instruction counter has already progressed with no other CPU activity occurring.::","::REFERENCE:CVE-2019-15894:DESCRIPTION:fault injection attack bypasses the verification mode, potentially allowing arbitrary code execution.:LINK:https://www.cve.org/CVERecord?id=CVE-2019-15894::",::Power::,,"",::624::625::,"",
+1334,"Unauthorized Error Injection Can Degrade Hardware Redundancy",Base,Draft,"An unauthorized agent can inject errors into a redundant block to deprive the system of redundancy or put the system in a degraded operating mode.","To ensure the performance and functional reliability of certain components, hardware designers can implement hardware blocks for redundancy in the case that others fail. This redundant block can be prevented from performing as intended if the design allows unauthorized agents to inject errors into it. In this way, a path with injected errors may become unavailable to serve as a redundant channel. This may put the system into a degraded mode of operation which could be exploited by a subsequent attack.",::NATURE:ChildOf:CWE ID:284:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:Such issues could be introduced during hardware architecture and design and identified later during Testing or System Configuration phases.::PHASE:Implementation:NOTE:Such issues could be introduced during implementation and identified later during Testing or System Configuration phases.::PHASE:Integration:NOTE:Such issues could be introduced during integration and identified later during Testing or System Configuration phases.::","",,"::SCOPE:Integrity:SCOPE:Availability:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:DoS: Instability:IMPACT:Quality Degradation:IMPACT:DoS: Resource Consumption (CPU):IMPACT:DoS: Resource Consumption (Memory):IMPACT:DoS: Resource Consumption (Other):IMPACT:Reduce Performance:IMPACT:Reduce Reliability:IMPACT:Unexpected State::","","::PHASE:Architecture and Design:DESCRIPTION:Ensure the design does not allow error injection in modes intended for normal run-time operation. Provide access controls on interfaces for injecting errors.::PHASE:Implementation:DESCRIPTION:Disallow error injection in modes which are expected to be used for normal run-time operation. Provide access controls on interfaces for injecting errors.::PHASE:Integration:DESCRIPTION:Add an access control layer atop any unprotected interfaces for injecting errors.::","",,,"",::624::625::,"",
+1338,"Improper Protections Against Hardware Overheating",Base,Draft,"A hardware device is missing or has inadequate protection features to prevent overheating.","Hardware, electrical circuits, and semiconductor silicon have thermal side effects, such that some of the energy consumed by the device gets dissipated as heat and increases the temperature of the device. For example, in semiconductors, higher-operating frequency of silicon results in higher power dissipation and heat. The leakage current in CMOS circuits increases with temperature, and this creates positive feedback that can result in thermal runaway and damage the device permanently. Any device lacking protections such as thermal sensors, adequate platform cooling, or thermal insulation is susceptible to attacks by malicious software that might deliberately operate the device in modes that result in overheating. This can be used as an effective denial of service (DoS) or permanent denial of service (PDoS) attack. Depending on the type of hardware device and its expected usage, such thermal overheating can also cause safety hazards and reliability issues. Note that battery failures can also cause device overheating but the mitigations and examples included in this submission cannot reliably protect against a battery failure. There can be similar weaknesses with lack of protection from attacks based on overvoltage or overcurrent conditions. However, thermal heat is generated by hardware operation and the device should implement protection from overheating.",::NATURE:ChildOf:CWE ID:693:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:ICS/OT:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Power Management Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Processor Hardware:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation:NOTE:Such issues could be introduced during hardware architecture, design or implementation.::","",,"::SCOPE:Availability:IMPACT:DoS: Resource Consumption (Other):LIKELIHOOD:High::","::METHOD:Dynamic Analysis with Manual Results Interpretation:DESCRIPTION:Dynamic tests should be performed to stress-test temperature controls.:EFFECTIVENESS:High::METHOD:Architecture or Design Review:DESCRIPTION:Power management controls should be part of Architecture and Design reviews.:EFFECTIVENESS:High::","::PHASE:Architecture and Design:DESCRIPTION:Temperature maximum and minimum limits should be enforced using thermal sensors both in silicon and at the platform level.::PHASE:Implementation:DESCRIPTION:The platform should support cooling solutions such as fans that can be modulated based on device-operation needs to maintain a stable temperature.::","",,,"",::624::625::,"",
+1342,"Information Exposure through Microarchitectural State after Transient Execution",Base,Incomplete,"The processor does not properly clear microarchitectural state after incorrect microcode assists or speculative execution, resulting in transient execution.","In many processor architectures an exception, mis-speculation, or microcode assist results in a flush operation to clear results that are no longer required. This action prevents these results from influencing architectural state that is intended to be visible from software. However, traces of this transient execution may remain in microarchitectural buffers, resulting in a change in microarchitectural state that can expose sensitive information to an attacker using side-channel analysis. For example, Load Value Injection (LVI) [REF-1202] can exploit direct injection of erroneous values into intermediate load and store buffers. Several conditions may need to be fulfilled for a successful attack: incorrect transient execution that results in remanence of sensitive information; attacker has the ability to provoke microarchitectural exceptions; operations and structures in victim code that can be exploited must be identified.",::NATURE:ChildOf:CWE ID:226:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:226:VIEW ID:1194:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Workstation:ARCHITECTURE PREVALENCE:Undetermined::ARCHITECTURE NAME:x86:ARCHITECTURE PREVALENCE:Undetermined::ARCHITECTURE NAME:ARM:ARCHITECTURE PREVALENCE:Undetermined::ARCHITECTURE NAME:Other:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Requirements::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Modify Memory:IMPACT:Read Memory:IMPACT:Execute Unauthorized Code or Commands:LIKELIHOOD:Medium::","","::PHASE:Architecture and Design Requirements:DESCRIPTION:Hardware ensures that no illegal data flows from faulting micro-ops exists at the microarchitectural level.:EFFECTIVENESS:High::PHASE:Build and Compilation:DESCRIPTION:Include instructions that explicitly remove traces of unneeded computations from software interactions with microarchitectural elements e.g. lfence, sfence, mfence, clflush.:EFFECTIVENESS:High::","::REFERENCE:CVE-2020-0551:DESCRIPTION:Load value injection in some processors utilizing speculative execution may allow an authenticated user to enable information disclosure via a side-channel with local access.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-0551::",,,"",::696::,"::TYPE:Relationship:NOTE:CWE-1342 differs from CWE-1303, which is related to misprediction and biasing microarchitectural components, while CWE-1342 addresses illegal data flows and retention. For example, Spectre is an instance of CWE-1303 biasing branch prediction to steer the transient execution indirectly.::TYPE:Maintenance:NOTE:As of CWE 4.9, members of the CWE Hardware SIG are closely analyzing this entry and others to improve CWE's coverage of transient execution weaknesses, which include issues related to Spectre, Meltdown, and other attacks. Additional investigation may include other weaknesses related to microarchitectural state. As a result, this entry might change significantly in CWE 4.10.::",
+1351,"Improper Handling of Hardware Behavior in Exceptionally Cold Environments",Base,Incomplete,"A hardware device, or the firmware running on it, is missing or has incorrect protection features to maintain goals of security primitives when the device is cooled below standard operating temperatures.","The hardware designer may improperly anticipate hardware behavior when exposed to exceptionally cold conditions. As a result they may introduce a weakness by not accounting for the modified behavior of critical components when in extreme environments. An example of a change in behavior is that power loss won't clear/reset any volatile state when cooled below standard operating temperatures. This may result in a weakness when the starting state of the volatile memory is being relied upon for a security decision. For example, a Physical Unclonable Function (PUF) may be supplied as a security primitive to improve confidentiality, authenticity, and integrity guarantees. However, when the PUF is paired with DRAM, SRAM, or another temperature sensitive entropy source, the system designer may introduce weakness by failing to account for the chosen entropy source's behavior at exceptionally low temperatures. In the case of DRAM and SRAM, when power is cycled at low temperatures, the device will not contain the bitwise biasing caused by inconsistencies in manufacturing and will instead contain the data from previous boot. Should the PUF primitive be used in a cryptographic construction which does not account for full adversary control of PUF seed data, weakness would arise. This weakness does not cover Cold Boot Attacks wherein RAM or other external storage is super cooled and read externally by an attacker.",::NATURE:ChildOf:CWE ID:1384:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Embedded:ARCHITECTURE PREVALENCE:Undetermined::ARCHITECTURE CLASS:Microcomputer:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Integrity:SCOPE:Authentication:IMPACT:Varies by Context:IMPACT:Unexpected State:LIKELIHOOD:Low:NOTE:Consequences of this weakness are highly contextual.::","","::PHASE:Architecture and Design:DESCRIPTION:The system should account for security primitive behavior when cooled outside standard temperatures.::","",,,"",::624::625::,"",
+1357,"Reliance on Insufficiently Trustworthy Component",Class,Incomplete,"The product is built from multiple separate components, but it uses a component that is not sufficiently trusted to meet expectations for security, reliability, updateability, and maintainability.","Many modern hardware and software products are built by combining multiple smaller components together into one larger entity, often during the design or architecture phase. For example, a hardware component might be built by a separate supplier, or the product might use an open-source software library from a third party. Regardless of the source, each component should be sufficiently trusted to ensure correct, secure operation of the product. If a component is not trustworthy, it can produce significant risks for the overall product, such as vulnerabilities that cannot be patched fast enough (if at all); hidden functionality such as malware; inability to update or replace the component if needed for security purposes; hardware components built from parts that do not meet specifications in ways that can lead to weaknesses; etc. Note that a component might not be trustworthy even if it is owned by the product vendor, such as a software component whose source code is lost and was built by developers who left the company, or a component that was developed by a separate company that was acquired and brought into the product's own company. Note that there can be disagreement as to whether a component is sufficiently trustworthy, since trust is ultimately subjective. Different stakeholders (e.g., customers, vendors, governments) have various threat models and ways to assess trust, and design/architecture choices might make tradeoffs between security, reliability, safety, privacy, cost, and other characteristics.",::NATURE:ChildOf:CWE ID:710:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Indirect::",::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:ICS/OT:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Requirements:NOTE:Requirements might include criteria for which the only available solutions are provided by insufficiently trusted components.::PHASE:Architecture and Design:NOTE:An insufficiently trusted component might be selected because it is less expensive to do in-house, requires expertise that is not available in-house, or might allow the product to reach the market faster.::","",,"::SCOPE:Other:IMPACT:Reduce Maintainability::","","::PHASE:Requirements Architecture and Design Implementation:DESCRIPTION:For each component, ensure that its supply chain is well-controlled with sub-tier suppliers using best practices. For third-party software components such as libraries, ensure that they are developed and actively maintained by reputable vendors.::PHASE:Architecture and Design Implementation Integration Manufacturing:DESCRIPTION:Maintain a Bill of Materials for all components and sub-components of the product. For software, maintain a Software Bill of Materials (SBOM). According to [REF-1247], An SBOM is a formal, machine-readable inventory of software components and dependencies, information about those components, and their hierarchical relationships.::PHASE:Operation Patching and Maintenance:DESCRIPTION:Continue to monitor changes in each of the product's components, especially when the changes indicate new vulnerabilities, end-of-life (EOL) plans, supplier practices that affect trustworthiness, etc.::","::REFERENCE:CVE-2020-9054:DESCRIPTION:Chain: network-attached storage (NAS) device has a critical OS command injection (CWE-78) vulnerability that is actively exploited to place IoT devices into a botnet, but some products are end-of-support and cannot be patched (CWE-1277). [REF-1097]:LINK:https://www.cve.org/CVERecord?id=CVE-2020-9054::",,,"::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 2-4:ENTRY NAME:Req SP.03.02 RE(1)::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 2-4:ENTRY NAME:Req SP.03.02 RE(2)::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 3-3:ENTRY NAME:Req SR 1.13::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-2:ENTRY NAME:Req EDR 3.12::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-2:ENTRY NAME:Req HDR 3.12::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-2:ENTRY NAME:Req NDR 3.12::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-2:ENTRY NAME:Req EDR 3.13::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-2:ENTRY NAME:Req HDR 3.13::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-2:ENTRY NAME:Req NDR 3.13::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-2:ENTRY NAME:Req CR-7.8::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-1:ENTRY NAME:Req SM-6::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-1:ENTRY NAME:Req SM-9::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-1:ENTRY NAME:Req SM-10::",,"::TYPE:Maintenance:NOTE:As of CWE 4.10, the name and description for this entry has undergone significant change and is still under public discussion, especially by members of the HW SIG.::",
+1384,"Improper Handling of Physical or Environmental Conditions",Class,Incomplete,"The product does not properly handle unexpected physical or environmental conditions that occur naturally or are artificially induced.","Hardware products are typically only guaranteed to behave correctly within certain physical limits or environmental conditions. Such products cannot necessarily control the physical or external conditions to which they are subjected. However, the inability to handle such conditions can undermine a product's security. For example, an unexpected physical or environmental condition may cause the flipping of a bit that is used for an authentication decision. This unexpected condition could occur naturally or be induced artificially by an adversary. Physical or environmental conditions of concern are: Atmospheric characteristics: extreme temperature ranges, etc. Interference: electromagnetic interference (EMI), radio frequency interference (RFI), etc. Assorted light sources: white light, ultra-violet light (UV), lasers, infrared (IR), etc. Power variances: under-voltages, over-voltages, under-current, over-current, etc. Clock variances: glitching, overclocking, clock stretching, etc. Component aging and degradation Materials manipulation: focused ion beams (FIB), etc. Exposure to radiation: x-rays, cosmic radiation, etc.",::NATURE:ChildOf:CWE ID:703:VIEW ID:1000:ORDINAL:Primary::,"",::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:ICS/OT:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:The product's design might not consider checking and handling extreme conditions.::PHASE:Manufacturing:NOTE:For hardware manufacturing, sub-par components might be chosen that are not able to handle the expected environmental conditions.::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:IMPACT:Varies by Context:IMPACT:Unexpected State:NOTE:Consequences of this weakness are highly dependent on the role of affected components within the larger product.::","","::PHASE:Requirements:DESCRIPTION:In requirements, be specific about expectations for how the product will perform when it exceeds physical and environmental boundary conditions, e.g., by shutting down.::PHASE:Architecture and Design Implementation:DESCRIPTION:Where possible, include independent components that can detect excess environmental conditions and have the capability to shut down the product.::PHASE:Architecture and Design Implementation:DESCRIPTION:Where possible, use shielding or other materials that can increase the adversary's workload and reduce the likelihood of being able to successfully trigger a security-related failure.::","::REFERENCE:CVE-2019-17391:DESCRIPTION:Lack of anti-glitch protections allows an attacker to launch a physical attack to bypass the secure boot and read protected eFuses.:LINK:https://www.cve.org/CVERecord?id=CVE-2019-17391::",,,"",,"",
+1420,"Exposure of Sensitive Information during Transient Execution",Base,Incomplete,"A processor event or prediction may allow incorrect operations (or correct operations with incorrect data) to execute transiently, potentially exposing data over a covert channel.","When operations execute but do not commit to the processor's architectural state, this is commonly referred to as transient execution. This behavior can occur when the processor mis-predicts an outcome (such as a branch target), or when a processor event (such as an exception or microcode assist, etc.) is handled after younger operations have already executed. Operations that execute transiently may exhibit observable discrepancies (CWE-203) in covert channels [REF-1400] such as data caches. Observable discrepancies of this kind can be detected and analyzed using timing or power analysis techniques, which may allow an attacker to infer information about the operations that executed transiently. For example, the attacker may be able to infer confidential data that was accessed or used by those operations. Transient execution weaknesses may be exploited using one of two methods. In the first method, the attacker generates a code sequence that exposes data through a covert channel when it is executed transiently (the attacker must also be able to trigger transient execution). Some transient execution weaknesses can only expose data that is accessible within the attacker's processor context. For example, an attacker executing code in a software sandbox may be able to use a transient execution weakness to expose data within the same address space, but outside of the attacker's sandbox. Other transient execution weaknesses can expose data that is architecturally inaccessible, that is, data protected by hardware-enforced boundaries such as page tables or privilege rings. These weaknesses are the subject of CWE-1421. In the second exploitation method, the attacker first identifies a code sequence in a victim program that, when executed transiently, can expose data that is architecturally accessible within the victim's processor context. For instance, the attacker may search the victim program for code sequences that resemble a bounds-check bypass sequence (see Demonstrative Example 1). If the attacker can trigger a mis-prediction of the conditional branch and influence the index of the out-of-bounds array access, then the attacker may be able to infer the value of out-of-bounds data by monitoring observable discrepancies in a covert channel.",::NATURE:ChildOf:CWE ID:669:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:This weakness can be introduced when a computing unit (such as a CPU, GPU, accelerator, or any other processor) uses out-of-order execution, speculation, or any other microarchitectural feature that can allow microarchitectural operations to execute without committing to architectural state.::PHASE:Implementation:NOTE:This weakness can be introduced when sandboxes or managed runtimes are not properly isolated by using hardware-enforced boundaries. Developers of sandbox or managed runtime software should exercise caution when relying on software techniques (such as bounds checking) to prevent code in one sandbox from accessing confidential data in another sandbox. For example, an attacker sandbox may be able to trigger a processor event or mis-prediction in a manner that allows it to transiently read a victim sandbox's private data.::","",,"::SCOPE:Confidentiality:IMPACT:Read Memory:LIKELIHOOD:Medium::","::METHOD:Manual Analysis:DESCRIPTION:This weakness can be detected in hardware by manually inspecting processor specifications. Features that exhibit this weakness may include microarchitectural predictors, access control checks that occur out-of-order, or any other features that can allow operations to execute without committing to architectural state. Academic researchers have demonstrated that new hardware weaknesses can be discovered by exhaustively analyzing a processor's machine clear (or nuke) conditions ([REF-1427]).:EFFECTIVENESS:Moderate::METHOD:Fuzzing:DESCRIPTION:Academic researchers have demonstrated that this weakness can be detected in hardware using software fuzzing tools that treat the underlying hardware as a black box ([REF-1428]).:EFFECTIVENESS:Opportunistic::METHOD:Fuzzing:DESCRIPTION:Academic researchers have demonstrated that this weakness can be detected in software using software fuzzing tools ([REF-1429]).:EFFECTIVENESS:Opportunistic::METHOD:Automated Static Analysis:DESCRIPTION:A variety of automated static analysis tools can identify potentially exploitable code sequences in software. These tools may perform the analysis on source code, on binary code, or on an intermediate code representation (for example, during compilation).:EFFECTIVENESS:Limited::METHOD:Automated Analysis:DESCRIPTION:Software vendors can release tools that detect presence of known weaknesses on a processor. For example, some of these tools can attempt to transiently execute a vulnerable code sequence and detect whether code successfully leaks data in a manner consistent with the weakness under test. Alternatively, some hardware vendors provide enumeration for the presence of a weakness (or lack of a weakness). These enumeration bits can be checked and reported by system software. For example, Linux supports these checks for many commodity processors: $ cat /proc/cpuinfo | grep bugs | head -n 1 bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit srbds mmio_stale_data retbleed:EFFECTIVENESS:High::","::PHASE:Architecture and Design:DESCRIPTION:The hardware designer can attempt to prevent transient execution from causing observable discrepancies in specific covert channels.:EFFECTIVENESS:Limited::PHASE:Requirements:DESCRIPTION:Processor designers may expose instructions or other architectural features that allow software to mitigate the effects of transient execution, but without disabling predictors. These features may also help to limit opportunities for data exposure.:EFFECTIVENESS:Moderate::PHASE:Requirements:DESCRIPTION:Processor designers may expose registers (for example, control registers or model-specific registers) that allow privileged and/or user software to disable specific predictors or other hardware features that can cause confidential data to be exposed during transient execution.:EFFECTIVENESS:Limited::PHASE:Requirements:DESCRIPTION:Processor designers, system software vendors, or other agents may choose to restrict the ability of unprivileged software to access to high-resolution timers that are commonly used to monitor covert channels.:EFFECTIVENESS:Defense in Depth::PHASE:Build and Compilation:DESCRIPTION:Isolate sandboxes or managed runtimes in separate address spaces (separate processes). For examples, see [REF-1421].:EFFECTIVENESS:High::PHASE:Build and Compilation:DESCRIPTION:Include serialization instructions (for example, LFENCE) that prevent processor events or mis-predictions prior to the serialization instruction from causing transient execution after the serialization instruction. For some weaknesses, a serialization instruction can also prevent a processor event or a mis-prediction from occurring after the serialization instruction (for example, CVE-2018-3639 can allow a processor to predict that a load will not depend on an older store; a serialization instruction between the store and the load may allow the store to update memory and prevent the prediction from happening at all).:EFFECTIVENESS:Moderate::PHASE:Build and Compilation:DESCRIPTION:Use control-flow integrity (CFI) techniques to constrain the behavior of instructions that redirect the instruction pointer, such as indirect branch instructions.:EFFECTIVENESS:Moderate::PHASE:Build and Compilation:DESCRIPTION:If the weakness is exposed by a single instruction (or a small set of instructions), then the compiler (or JIT, etc.) can be configured to prevent the affected instruction(s) from being generated, and instead generate an alternate sequence of instructions that is not affected by the weakness. One prominent example of this mitigation is retpoline ([REF-1414]).:EFFECTIVENESS:Limited::PHASE:Build and Compilation:DESCRIPTION:Use software techniques that can mitigate the consequences of transient execution. For example, address masking can be used in some circumstances to prevent out-of-bounds transient reads.:EFFECTIVENESS:Limited::PHASE:Build and Compilation:DESCRIPTION:Use software techniques (including the use of serialization instructions) that are intended to reduce the number of instructions that can be executed transiently after a processor event or misprediction.:EFFECTIVENESS:Incidental::PHASE:Documentation:DESCRIPTION:If a hardware feature can allow incorrect operations (or correct operations with incorrect data) to execute transiently, the hardware designer may opt to disclose this behavior in architecture documentation. This documentation can inform users about potential consequences and effective mitigations.:EFFECTIVENESS:High::","::REFERENCE:CVE-2017-5753:DESCRIPTION:Microarchitectural conditional branch predictors may allow operations to execute transiently after a misprediction, potentially exposing data over a covert channel.:LINK:https://www.cve.org/CVERecord?id=CVE-2017-5753::REFERENCE:CVE-2021-0089:DESCRIPTION:A machine clear triggered by self-modifying code may allow incorrect operations to execute transiently, potentially exposing data over a covert channel.:LINK:https://www.cve.org/CVERecord?id=CVE-2021-0089::REFERENCE:CVE-2022-0002:DESCRIPTION:Microarchitectural indirect branch predictors may allow incorrect operations to execute transiently after a misprediction, potentially exposing data over a covert channel.:LINK:https://www.cve.org/CVERecord?id=CVE-2022-0002::",,,"",,"",
+1421,"Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution",Base,Incomplete,"A processor event may allow transient operations to access architecturally restricted data (for example, in another address space) in a shared microarchitectural structure (for example, a CPU cache), potentially exposing the data over a covert channel.","Many commodity processors have Instruction Set Architecture (ISA) features that protect software components from one another. These features can include memory segmentation, virtual memory, privilege rings, trusted execution environments, and virtual machines, among others. For example, virtual memory provides each process with its own address space, which prevents processes from accessing each other's private data. Many of these features can be used to form hardware-enforced security boundaries between software components. Many commodity processors also share microarchitectural resources that cache (temporarily store) data, which may be confidential. These resources may be shared across processor contexts, including across SMT threads, privilege rings, or others. When transient operations allow access to ISA-protected data in a shared microarchitectural resource, this might violate users' expectations of the ISA feature that is bypassed. For example, if transient operations can access a victim's private data in a shared microarchitectural resource, then the operations' microarchitectural side effects may correspond to the accessed data. If an attacker can trigger these transient operations and observe their side effects through a covert channel [REF-1400], then the attacker may be able to infer the victim's private data. Private data could include sensitive program data, OS/VMM data, page table data (such as memory addresses), system configuration data (see Demonstrative Example 3), or any other data that the attacker does not have the required privileges to access.",::NATURE:ChildOf:CWE ID:1420:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:1420:VIEW ID:1194:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:This weakness can be introduced during hardware architecture and design if a data path allows architecturally restricted data to propagate to operations that execute before an older mis-prediction or processor event (such as an exception) is caught.::PHASE:Implementation:NOTE:This weakness can be introduced during system software implementation if state-sanitizing operations are not invoked when switching from one context to another, according to the hardware vendor's recommendations for mitigating the weakness.::PHASE:System Configuration:NOTE:This weakness can be introduced if the system has not been configured according to the hardware vendor's recommendations for mitigating the weakness.::PHASE:Architecture and Design:NOTE:This weakness can be introduced when an access control check (for example, checking page permissions) can proceed in parallel with the access operation (for example, a load) that is being checked. If the processor can allow the access operation to execute before the check completes, this race condition may allow subsequent transient operations to expose sensitive information.::","",,"::SCOPE:Confidentiality:IMPACT:Read Memory:LIKELIHOOD:Medium:NOTE:<>::","::METHOD:Manual Analysis:DESCRIPTION:This weakness can be detected in hardware by manually inspecting processor specifications. Features that exhibit this weakness may include microarchitectural predictors, access control checks that occur out-of-order, or any other features that can allow operations to execute without committing to architectural state. Academic researchers have demonstrated that new hardware weaknesses can be discovered by examining publicly available patent filings, for example [REF-1405] and [REF-1406]. Hardware designers can also scrutinize aspects of the instruction set architecture that have undefined behavior; these can become a focal point when applying other detection methods.:EFFECTIVENESS:Moderate::METHOD:Automated Analysis:DESCRIPTION:This weakness can be detected (pre-discovery) in hardware by employing static or dynamic taint analysis methods [REF-1401]. These methods can label data in one context (for example, kernel data) and perform information flow analysis (or a simulation, etc.) to determine whether tainted data can appear in another context (for example, user mode). Alternatively, stale or invalid data in shared microarchitectural resources can be marked as tainted, and the taint analysis framework can identify when transient operations encounter tainted data.:EFFECTIVENESS:Moderate::METHOD:Automated Analysis:DESCRIPTION:Software vendors can release tools that detect presence of known weaknesses (post-discovery) on a processor. For example, some of these tools can attempt to transiently execute a vulnerable code sequence and detect whether code successfully leaks data in a manner consistent with the weakness under test. Alternatively, some hardware vendors provide enumeration for the presence of a weakness (or lack of a weakness). These enumeration bits can be checked and reported by system software. For example, Linux supports these checks for many commodity processors: $ cat /proc/cpuinfo | grep bugs | head -n 1 bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit srbds mmio_stale_data retbleed:EFFECTIVENESS:High::METHOD:Fuzzing:DESCRIPTION:Academic researchers have demonstrated that this weakness can be detected in hardware using software fuzzing tools that treat the underlying hardware as a black box ([REF-1406], [REF-1430]):EFFECTIVENESS:Opportunistic::","::PHASE:Architecture and Design:DESCRIPTION:Hardware designers may choose to engineer the processor's pipeline to prevent architecturally restricted data from being used by operations that can execute transiently.:EFFECTIVENESS:High::PHASE:Architecture and Design:DESCRIPTION:Hardware designers may choose not to share microarchitectural resources that can contain sensitive data, such as fill buffers and store buffers.:EFFECTIVENESS:Moderate::PHASE:Architecture and Design:DESCRIPTION:Hardware designers may choose to sanitize specific microarchitectural state (for example, store buffers) when the processor transitions to a different context, such as whenever a system call is invoked. Alternatively, the hardware may expose instruction(s) that allow software to sanitize microarchitectural state according to the user or system administrator's threat model. These mitigation approaches are similar to those that address CWE-226; however, sanitizing microarchitectural state may not be the optimal or best way to mitigate this weakness on every processor design.:EFFECTIVENESS:Moderate::PHASE:Architecture and Design:DESCRIPTION:The hardware designer can attempt to prevent transient execution from causing observable discrepancies in specific covert channels.:EFFECTIVENESS:Limited::PHASE:Architecture and Design:DESCRIPTION:Software architects may design software to enforce strong isolation between different contexts. For example, kernel page table isolation (KPTI) mitigates the Meltdown vulnerability [REF-1401] by separating user-mode page tables from kernel-mode page tables, which prevents user-mode processes from using Meltdown to transiently access kernel memory [REF-1404].:EFFECTIVENESS:Limited::PHASE:Build and Compilation:DESCRIPTION:If the weakness is exposed by a single instruction (or a small set of instructions), then the compiler (or JIT, etc.) can be configured to prevent the affected instruction(s) from being generated, and instead generate an alternate sequence of instructions that is not affected by the weakness.:EFFECTIVENESS:Limited::PHASE:Build and Compilation:DESCRIPTION:Use software techniques (including the use of serialization instructions) that are intended to reduce the number of instructions that can be executed transiently after a processor event or misprediction.:EFFECTIVENESS:Incidental::PHASE:Implementation:DESCRIPTION:System software can mitigate this weakness by invoking state-sanitizing operations when switching from one context to another, according to the hardware vendor's recommendations.:EFFECTIVENESS:Limited::PHASE:System Configuration:DESCRIPTION:Some systems may allow the user to disable (for example, in the BIOS) sharing of the affected resource.:EFFECTIVENESS:Limited::PHASE:System Configuration:DESCRIPTION:Some systems may allow the user to disable (for example, in the BIOS) microarchitectural features that allow transient access to architecturally restricted data.:EFFECTIVENESS:Limited::PHASE:Patching and Maintenance:DESCRIPTION:The hardware vendor may provide a patch to sanitize the affected shared microarchitectural state when the processor transitions to a different context.:EFFECTIVENESS:Moderate::PHASE:Patching and Maintenance:DESCRIPTION:This kind of patch may not be feasible or implementable for all processors or all weaknesses.:EFFECTIVENESS:Limited::PHASE:Requirements:DESCRIPTION:Processor designers, system software vendors, or other agents may choose to restrict the ability of unprivileged software to access to high-resolution timers that are commonly used to monitor covert channels.:EFFECTIVENESS:Defense in Depth::","::REFERENCE:CVE-2017-5715:DESCRIPTION:A fault may allow transient user-mode operations to access kernel data cached in the L1D, potentially exposing the data over a covert channel.:LINK:https://www.cve.org/CVERecord?id=CVE-2017-5715::REFERENCE:CVE-2018-3615:DESCRIPTION:A fault may allow transient non-enclave operations to access SGX enclave data cached in the L1D, potentially exposing the data over a covert channel.:LINK:https://www.cve.org/CVERecord?id=CVE-2018-3615::REFERENCE:CVE-2019-1135:DESCRIPTION:A TSX Asynchronous Abort may allow transient operations to access architecturally restricted data, potentially exposing the data over a covert channel.:LINK:https://www.cve.org/CVERecord?id=CVE-2019-1135::",,,"",,"",
+1422,"Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient Execution",Base,Incomplete,"A processor event or prediction may allow incorrect or stale data to be forwarded to transient operations, potentially exposing data over a covert channel.","Software may use a variety of techniques to preserve the confidentiality of private data that is accessible within the current processor context. For example, the memory safety and type safety properties of some high-level programming languages help to prevent software written in those languages from exposing private data. As a second example, software sandboxes may co-locate multiple users' software within a single process. The processor's Instruction Set Architecture (ISA) may permit one user's software to access another user's data (because the software shares the same address space), but the sandbox prevents these accesses by using software techniques such as bounds checking. If incorrect or stale data can be forwarded (for example, from a cache) to transient operations, then the operations' microarchitectural side effects may correspond to the data. If an attacker can trigger these transient operations and observe their side effects through a covert channel, then the attacker may be able to infer the data. For example, an attacker process may induce transient execution in a victim process that causes the victim to inadvertently access and then expose its private data via a covert channel. In the software sandbox example, an attacker sandbox may induce transient execution in its own code, allowing it to transiently access and expose data in a victim sandbox that shares the same address space. Consequently, weaknesses that arise from incorrect/stale data forwarding might violate users' expectations of software-based memory safety and isolation techniques. If the data forwarding behavior is not properly documented by the hardware vendor, this might violate the software vendor's expectation of how the hardware should behave.",::NATURE:ChildOf:CWE ID:1420:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:1420:VIEW ID:1194:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:This weakness can be introduced by data speculation techniques, or when the processor pipeline is designed to check exception conditions concurrently with other operations. This weakness can also persist after a CWE-1421 weakness has been mitigated. For example, suppose that a processor can forward stale data from a shared microarchitectural buffer to dependent transient operations, and furthermore suppose that the processor has been patched to flush the buffer on context switches. This mitigates the CWE-1421 weakness, but the stale-data forwarding behavior may persist as a CWE-1422 weakness unless this behavior is also patched.::","",,"::SCOPE:Confidentiality:IMPACT:Read Memory:LIKELIHOOD:Medium::","::METHOD:Automated Static Analysis:DESCRIPTION:A variety of automated static analysis tools can identify potentially exploitable code sequences in software. These tools may perform the analysis on source code, on binary code, or on an intermediate code representation (for example, during compilation).:EFFECTIVENESS:Moderate::METHOD:Manual Analysis:DESCRIPTION:This weakness can be detected in hardware by manually inspecting processor specifications. Features that exhibit this weakness may include microarchitectural predictors, access control checks that occur out-of-order, or any other features that can allow operations to execute without committing to architectural state.Hardware designers can also scrutinize aspects of the instruction set architecture that have undefined behavior; these can become a focal point when applying other detection methods.:EFFECTIVENESS:Moderate::METHOD:Automated Analysis:DESCRIPTION:Software vendors can release tools that detect presence of known weaknesses on a processor. For example, some of these tools can attempt to transiently execute a vulnerable code sequence and detect whether code successfully leaks data in a manner consistent with the weakness under test. Alternatively, some hardware vendors provide enumeration for the presence of a weakness (or lack of a weakness). These enumeration bits can be checked and reported by system software. For example, Linux supports these checks for many commodity processors: $ cat /proc/cpuinfo | grep bugs | head -n 1 bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit srbds mmio_stale_data retbleed:EFFECTIVENESS:High::","::PHASE:Architecture and Design:DESCRIPTION:The hardware designer can attempt to prevent transient execution from causing observable discrepancies in specific covert channels.:EFFECTIVENESS:Limited::PHASE:Requirements:DESCRIPTION:Processor designers, system software vendors, or other agents may choose to restrict the ability of unprivileged software to access to high-resolution timers that are commonly used to monitor covert channels.:EFFECTIVENESS:Defense in Depth::PHASE:Requirements:DESCRIPTION:Processor designers may expose instructions or other architectural features that allow software to mitigate the effects of transient execution, but without disabling predictors. These features may also help to limit opportunities for data exposure.:EFFECTIVENESS:Moderate::PHASE:Requirements:DESCRIPTION:Processor designers may expose registers (for example, control registers or model-specific registers) that allow privileged and/or user software to disable specific predictors or other hardware features that can cause confidential data to be exposed during transient execution.:EFFECTIVENESS:Limited::PHASE:Build and Compilation:DESCRIPTION:Use software techniques (including the use of serialization instructions) that are intended to reduce the number of instructions that can be executed transiently after a processor event or misprediction.:EFFECTIVENESS:Incidental::PHASE:Build and Compilation:DESCRIPTION:Isolate sandboxes or managed runtimes in separate address spaces (separate processes).:EFFECTIVENESS:High::PHASE:Build and Compilation:DESCRIPTION:Include serialization instructions (for example, LFENCE) that prevent processor events or mis-predictions prior to the serialization instruction from causing transient execution after the serialization instruction. For some weaknesses, a serialization instruction can also prevent a processor event or a mis-prediction from occurring after the serialization instruction (for example, CVE-2018-3639 can allow a processor to predict that a load will not depend on an older store; a serialization instruction between the store and the load may allow the store to update memory and prevent the mis-prediction from happening at all).:EFFECTIVENESS:Moderate::PHASE:Build and Compilation:DESCRIPTION:Use software techniques that can mitigate the consequences of transient execution. For example, address masking can be used in some circumstances to prevent out-of-bounds transient reads.:EFFECTIVENESS:Limited::PHASE:Build and Compilation:DESCRIPTION:If the weakness is exposed by a single instruction (or a small set of instructions), then the compiler (or JIT, etc.) can be configured to prevent the affected instruction(s) from being generated, and instead generate an alternate sequence of instructions that is not affected by the weakness.:EFFECTIVENESS:Limited::PHASE:Documentation:DESCRIPTION:If a hardware feature can allow incorrect or stale data to be forwarded to transient operations, the hardware designer may opt to disclose this behavior in architecture documentation. This documentation can inform users about potential consequences and effective mitigations.:EFFECTIVENESS:High::","::REFERENCE:CVE-2020-0551:DESCRIPTION:A fault, microcode assist, or abort may allow transient load operations to forward malicious stale data to dependent operations executed by a victim, causing the victim to unintentionally access and potentially expose its own data over a covert channel.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-0551::REFERENCE:CVE-2020-8698:DESCRIPTION:A fast store forwarding predictor may allow store operations to forward incorrect data to transient load operations, potentially exposing data over a covert channel.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-8698::",,,"",,"",
+1423,"Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution",Base,Incomplete,"Shared microarchitectural predictor state may allow code to influence transient execution across a hardware boundary, potentially exposing data that is accessible beyond the boundary over a covert channel.","Many commodity processors have Instruction Set Architecture (ISA) features that protect software components from one another. These features can include memory segmentation, virtual memory, privilege rings, trusted execution environments, and virtual machines, among others. For example, virtual memory provides each process with its own address space, which prevents processes from accessing each other's private data. Many of these features can be used to form hardware-enforced security boundaries between software components. When separate software components (for example, two processes) share microarchitectural predictor state across a hardware boundary, code in one component may be able to influence microarchitectural predictor behavior in another component. If the predictor can cause transient execution, the shared predictor state may allow an attacker to influence transient execution in a victim, and in a manner that could allow the attacker to infer private data from the victim by monitoring observable discrepancies (CWE-203) in a covert channel [REF-1400]. Predictor state may be shared when the processor transitions from one component to another (for example, when a process makes a system call to enter the kernel). Many commodity processors have features which prevent microarchitectural predictions that occur before a boundary from influencing predictions that occur after the boundary. Predictor state may also be shared between hardware threads, for example, sibling hardware threads on a processor that supports simultaneous multithreading (SMT). This sharing may be benign if the hardware threads are simultaneously executing in the same software component, or it could expose a weakness if one sibling is a malicious software component, and the other sibling is a victim software component. Processors that share microarchitectural predictors between hardware threads may have features which prevent microarchitectural predictions that occur on one hardware thread from influencing predictions that occur on another hardware thread. Features that restrict predictor state sharing across transitions or between hardware threads may be always-on, on by default, or may require opt-in from software.",::NATURE:ChildOf:CWE ID:1420:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:1420:VIEW ID:1194:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY NAME:Microcontroller Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Processor Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY NAME:Memory Hardware:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design:NOTE:This weakness can be introduced during hardware architecture and design if predictor state is not properly isolated between modes (for example, user mode and kernel mode), if predictor state is not isolated between hardware threads, or if it is not isolated between other kinds of execution contexts supported by the processor.::PHASE:Implementation:NOTE:This weakness can be introduced during system software implementation if predictor-state-sanitizing operations (for example, the indirect branch prediction barrier on Intel x86) are not invoked when switching from one context to another.::PHASE:System Configuration:NOTE:This weakness can be introduced if the system has not been configured according to the hardware vendor's recommendations for mitigating the weakness.::","",,"::SCOPE:Confidentiality:IMPACT:Read Memory:LIKELIHOOD:Medium::","::METHOD:Manual Analysis:DESCRIPTION:This weakness can be detected in hardware by manually inspecting processor specifications. Features that exhibit this weakness may have microarchitectural predictor state that is shared between hardware threads, execution contexts (for example, user and kernel), or other components that may host mutually distrusting software (or firmware, etc.).:EFFECTIVENESS:Moderate::METHOD:Automated Analysis:DESCRIPTION:Software vendors can release tools that detect presence of known weaknesses on a processor. For example, some of these tools can attempt to transiently execute a vulnerable code sequence and detect whether code successfully leaks data in a manner consistent with the weakness under test. Alternatively, some hardware vendors provide enumeration for the presence of a weakness (or lack of a weakness). These enumeration bits can be checked and reported by system software. For example, Linux supports these checks for many commodity processors: $ cat /proc/cpuinfo | grep bugs | head -n 1 bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit srbds mmio_stale_data retbleed:EFFECTIVENESS:High::METHOD:Automated Analysis:DESCRIPTION:This weakness can be detected in hardware by employing static or dynamic taint analysis methods [REF-1401]. These methods can label each predictor entry (or prediction history, etc.) according to the processor context that created it. Taint analysis or information flow analysis can then be applied to detect when predictor state created in one context can influence predictions made in another context.:EFFECTIVENESS:Moderate::","::PHASE:Architecture and Design:DESCRIPTION:The hardware designer can attempt to prevent transient execution from causing observable discrepancies in specific covert channels.::PHASE:Architecture and Design:DESCRIPTION:Hardware designers may choose to use microarchitectural bits to tag predictor entries. For example, each predictor entry may be tagged with a kernel-mode bit which, when set, indicates that the predictor entry was created in kernel mode. The processor can use this bit to enforce that predictions in the current mode must have been trained in the current mode. This can prevent malicious cross-mode training, such as when user-mode software attempts to create predictor entries that influence transient execution in the kernel. Predictor entry tags can also be used to associate each predictor entry with the SMT thread that created it, and thus the processor can enforce that each predictor entry can only be used by the SMT thread that created it. This can prevent an SMT thread from using predictor entries crafted by a malicious sibling SMT thread.:EFFECTIVENESS:Moderate::PHASE:Architecture and Design:DESCRIPTION:Hardware designers may choose to sanitize microarchitectural predictor state (for example, branch prediction history) when the processor transitions to a different context, for example, whenever a system call is invoked. Alternatively, the hardware may expose instruction(s) that allow software to sanitize predictor state according to the user's threat model. For example, this can allow operating system software to sanitize predictor state when performing a context switch from one process to another.:EFFECTIVENESS:Moderate::PHASE:Implementation:DESCRIPTION:System software can mitigate this weakness by invoking predictor-state-sanitizing operations (for example, the indirect branch prediction barrier on Intel x86) when switching from one context to another, according to the hardware vendor's recommendations.:EFFECTIVENESS:Moderate::PHASE:Build and Compilation:DESCRIPTION:If the weakness is exposed by a single instruction (or a small set of instructions), then the compiler (or JIT, etc.) can be configured to prevent the affected instruction(s) from being generated. One prominent example of this mitigation is retpoline ([REF-1414]).:EFFECTIVENESS:Limited::PHASE:Build and Compilation:DESCRIPTION:Use control-flow integrity (CFI) techniques to constrain the behavior of instructions that redirect the instruction pointer, such as indirect branch instructions.:EFFECTIVENESS:Moderate::PHASE:Build and Compilation:DESCRIPTION:Use software techniques (including the use of serialization instructions) that are intended to reduce the number of instructions that can be executed transiently after a processor event or misprediction.:EFFECTIVENESS:Incidental::PHASE:System Configuration:DESCRIPTION:Some systems may allow the user to disable predictor sharing. For example, this could be a BIOS configuration, or a model-specific register (MSR) that can be configured by the operating system or virtual machine monitor.:EFFECTIVENESS:Moderate::PHASE:Patching and Maintenance:DESCRIPTION:The hardware vendor may provide a patch to, for example, sanitize predictor state when the processor transitions to a different context, or to prevent predictor entries from being shared across SMT threads. A patch may also introduce new ISA that allows software to toggle a mitigation.:EFFECTIVENESS:Moderate::PHASE:Documentation:DESCRIPTION:If a hardware feature can allow microarchitectural predictor state to be shared between contexts, SMT threads, or other architecturally defined boundaries, the hardware designer may opt to disclose this behavior in architecture documentation. This documentation can inform users about potential consequences and effective mitigations.:EFFECTIVENESS:High::PHASE:Requirements:DESCRIPTION:Processor designers, system software vendors, or other agents may choose to restrict the ability of unprivileged software to access to high-resolution timers that are commonly used to monitor covert channels.::","::REFERENCE:CVE-2017-5754:DESCRIPTION:(Branch Target Injection, BTI, Spectre v2). Shared microarchitectural indirect branch predictor state may allow code to influence transient execution across a process, VM, or privilege boundary, potentially exposing data that is accessible beyond the boundary.:LINK:https://www.cve.org/CVERecord?id=CVE-2017-5754::REFERENCE:CVE-2022-0001:DESCRIPTION:(Branch History Injection, BHI, Spectre-BHB). Shared branch history state may allow user-mode code to influence transient execution in the kernel, potentially exposing kernel data over a covert channel.:LINK:https://www.cve.org/CVERecord?id=CVE-2022-0001::REFERENCE:CVE-2021-33149:DESCRIPTION:(RSB underflow, Retbleed). Shared return stack buffer state may allow code that executes before a prediction barrier to influence transient execution after the prediction barrier, potentially exposing data that is accessible beyond the barrier over a covert channel.:LINK:https://www.cve.org/CVERecord?id=CVE-2021-33149::",,,"",,"",
diff --git a/assets/cwe_csv/Research-Concepts-CWE.csv b/assets/cwe_csv/Research-Concepts-CWE.csv
new file mode 100644
index 00000000000..dd78a746e1a
--- /dev/null
+++ b/assets/cwe_csv/Research-Concepts-CWE.csv
@@ -0,0 +1,939 @@
+CWE-ID,Name,Weakness Abstraction,Status,Description,Extended Description,Related Weaknesses,Weakness Ordinalities,Applicable Platforms,Background Details,Alternate Terms,Modes Of Introduction,Exploitation Factors,Likelihood of Exploit,Common Consequences,Detection Methods,Potential Mitigations,Observed Examples,Functional Areas,Affected Resources,Taxonomy Mappings,Related Attack Patterns,Notes
+5,"J2EE Misconfiguration: Data Transmission Without Encryption",Variant,Draft,"Information sent over a network can be compromised while in transit. An attacker may be able to read or modify the contents if the data are sent in plaintext or are weakly encrypted.","",::NATURE:ChildOf:CWE ID:319:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE NAME:Java:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::PHASE:Operation::","",,"::SCOPE:Confidentiality:IMPACT:Read Application Data::SCOPE:Integrity:IMPACT:Modify Application Data::","","::PHASE:System Configuration:DESCRIPTION:The product configuration should ensure that SSL or an encryption mechanism of equivalent strength and vetted reputation is used for all access-controlled pages.::","",,,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:J2EE Misconfiguration: Insecure Transport::",,"::TYPE:Other:NOTE:If an application uses SSL to guarantee confidential communication with client browsers, the application configuration should make it impossible to view any access controlled page without SSL. There are three common ways for SSL to be bypassed: A user manually enters URL and types HTTP rather than HTTPS. Attackers intentionally send a user to an insecure URL. A programmer erroneously creates a relative link to a page in the application, which does not switch from HTTP to HTTPS. (This is particularly easy to do when the link moves between public and secured areas on a web site.)::",
+6,"J2EE Misconfiguration: Insufficient Session-ID Length",Variant,Incomplete,"The J2EE application is configured to use an insufficient session ID length.","If an attacker can guess or steal a session ID, then they may be able to take over the user's session (called session hijacking). The number of possible session IDs increases with increased session ID length, making it more difficult to guess or steal a session ID.",::NATURE:ChildOf:CWE ID:334:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE NAME:Java:LANGUAGE PREVALENCE:Undetermined::,"::Session ID's can be used to identify communicating parties in a web environment. The expected number of seconds required to guess a valid session identifier is given by the equation: (2^B+1)/(2*A*S) Where: - B is the number of bits of entropy in the session identifier. - A is the number of guesses an attacker can try each second. - S is the number of valid session identifiers that are valid and available to be guessed at any given time. The number of bits of entropy in the session identifier is always less than the total number of bits in the session identifier. For example, if session identifiers were provided in ascending order, there would be close to zero bits of entropy in the session identifier no matter the identifier's length. Assuming that the session identifiers are being generated using a good source of random numbers, we will estimate the number of bits of entropy in a session identifier to be half the total number of bits in the session identifier. For realistic identifier lengths this is possible, though perhaps optimistic.::","","::PHASE:Architecture and Design:NOTE:COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.::PHASE:Implementation::","",,"::SCOPE:Access Control:IMPACT:Gain Privileges or Assume Identity:NOTE:If an attacker can guess an authenticated user's session identifier, they can take over the user's session.::","","::PHASE:Implementation:DESCRIPTION:Session identifiers should be at least 128 bits long to prevent brute-force session guessing. A shorter session identifier leaves the application open to brute-force session guessing attacks.::PHASE:Implementation:DESCRIPTION:A lower bound on the number of valid session identifiers that are available to be guessed is the number of users that are active on a site at any given moment. However, any users that abandon their sessions without logging out will increase this number. (This is one of many good reasons to have a short inactive session timeout.) With a 64 bit session identifier, assume 32 bits of entropy. For a large web site, assume that the attacker can try 1,000 guesses per second and that there are 10,000 valid session identifiers at any given moment. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is less than 4 minutes. Now assume a 128 bit session identifier that provides 64 bits of entropy. With a very large web site, an attacker might try 10,000 guesses per second with 100,000 valid session identifiers available to be guessed. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is greater than 292 years.::","",,,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:J2EE Misconfiguration: Insufficient Session-ID Length::",::21::59::,"",
+7,"J2EE Misconfiguration: Missing Custom Error Page",Variant,Incomplete,"The default error page of a web application should not display sensitive information about the product.","A Web application must define a default error page for 4xx errors (e.g. 404), 5xx (e.g. 500) errors and catch java.lang.Throwable exceptions to prevent attackers from mining information from the application container's built-in error response. When an attacker explores a web site looking for vulnerabilities, the amount of information that the site provides is crucial to the eventual success or failure of any attempted attacks.",::NATURE:ChildOf:CWE ID:756:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE NAME:Java:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:IMPACT:Read Application Data:NOTE:A stack trace might show the attacker a malformed SQL query string, the type of database being used, and the version of the application container. This information enables the attacker to target known vulnerabilities in these components.::","","::PHASE:Implementation:DESCRIPTION:Handle exceptions appropriately in source code.::PHASE:Implementation System Configuration:DESCRIPTION:Always define appropriate error pages. The application configuration should specify a default error page in order to guarantee that the application will never leak error messages to an attacker. Handling standard HTTP error codes is useful and user-friendly in addition to being a good security practice, and a good configuration will also define a last-chance error handler that catches any exception that could possibly be thrown by the application.::PHASE:Implementation:DESCRIPTION:Do not attempt to process an error or attempt to mask it.::PHASE:Implementation:DESCRIPTION:Verify return values are correct and do not supply sensitive information about the system.::","",,,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:J2EE Misconfiguration: Missing Error Handling::",,"",
+8,"J2EE Misconfiguration: Entity Bean Declared Remote",Variant,Incomplete,"When an application exposes a remote interface for an entity bean, it might also expose methods that get or set the bean's data. These methods could be leveraged to read sensitive information, or to change data in ways that violate the application's expectations, potentially leading to other vulnerabilities.","",::NATURE:ChildOf:CWE ID:668:VIEW ID:1000:ORDINAL:Primary::,"",,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Application Data:IMPACT:Modify Application Data::","","::PHASE:Implementation:DESCRIPTION:Declare Java beans local when possible. When a bean must be remotely accessible, make sure that sensitive information is not exposed, and ensure that the application logic performs appropriate validation of any data that might be modified by an attacker.::","",,,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:J2EE Misconfiguration: Unsafe Bean Declaration::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP23:ENTRY NAME:Exposed Data::",,"::TYPE:Other:NOTE:Entity beans that expose a remote interface become part of an application's attack surface. For performance reasons, an application should rarely use remote entity beans, so there is a good chance that a remote entity bean declaration is an error.::",
+9,"J2EE Misconfiguration: Weak Access Permissions for EJB Methods",Variant,Draft,"If elevated access rights are assigned to EJB methods, then an attacker can take advantage of the permissions to exploit the product.","If the EJB deployment descriptor contains one or more method permissions that grant access to the special ANYONE role, it indicates that access control for the application has not been fully thought through or that the application is structured in such a way that reasonable access control restrictions are impossible.",::NATURE:ChildOf:CWE ID:266:VIEW ID:1000:ORDINAL:Primary::,"",,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Other:IMPACT:Other::","","::PHASE:Architecture and Design System Configuration:DESCRIPTION:Follow the principle of least privilege when assigning access rights to EJB methods. Permission to invoke EJB methods should not be granted to the ANYONE role.::","",,,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:J2EE Misconfiguration: Weak Access Permissions::",,"",
+11,"ASP.NET Misconfiguration: Creating Debug Binary",Variant,Draft,"Debugging messages help attackers learn about the system and plan a form of attack.","ASP .NET applications can be configured to produce debug binaries. These binaries give detailed debugging messages and should not be used in production environments. Debug binaries are meant to be used in a development or testing environment and can pose a security risk if they are deployed to production.",::NATURE:ChildOf:CWE ID:489:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE NAME:ASP.NET:LANGUAGE PREVALENCE:Undetermined::,"::The debug attribute of the tag defines whether compiled binaries should include debugging information. The use of debug binaries causes an application to provide as much information about itself as possible to the user.::","","::PHASE:Implementation::PHASE:Build and Compilation::","",,"::SCOPE:Confidentiality:IMPACT:Read Application Data:NOTE:Attackers can leverage the additional information they gain from debugging output to mount attacks targeted on the framework, database, or other resources used by the application.::","::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","::PHASE:System Configuration:DESCRIPTION:Avoid releasing debug binaries into the production environment. Change the debug mode to false when the application is deployed into production.::","",,,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:ASP.NET Misconfiguration: Creating Debug Binary::",,"",
+12,"ASP.NET Misconfiguration: Missing Custom Error Page",Variant,Draft,"An ASP .NET application must enable custom error pages in order to prevent attackers from mining information from the framework's built-in responses.","",::NATURE:ChildOf:CWE ID:756:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE NAME:ASP.NET:LANGUAGE PREVALENCE:Undetermined::,"::The mode attribute of the tag defines whether custom or default error pages are used.::","","::PHASE:Implementation::PHASE:Operation::","",,"::SCOPE:Confidentiality:IMPACT:Read Application Data:NOTE:Default error pages gives detailed information about the error that occurred, and should not be used in production environments. Attackers can leverage the additional information provided by a default error page to mount attacks targeted on the framework, database, or other resources used by the application.::","","::PHASE:System Configuration:DESCRIPTION:Handle exceptions appropriately in source code. ASP .NET applications should be configured to use custom error pages instead of the framework default page.::PHASE:Architecture and Design:DESCRIPTION:Do not attempt to process an error or attempt to mask it.::PHASE:Implementation:DESCRIPTION:Verify return values are correct and do not supply sensitive information about the system.::","",,,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:ASP.NET Misconfiguration: Missing Custom Error Handling::",,"",
+13,"ASP.NET Misconfiguration: Password in Configuration File",Variant,Draft,"Storing a plaintext password in a configuration file allows anyone who can read the file access to the password-protected resource making them an easy target for attackers.","",::NATURE:ChildOf:CWE ID:260:VIEW ID:1000:ORDINAL:Primary::,"",,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Access Control:IMPACT:Gain Privileges or Assume Identity::","","::PHASE:Implementation:DESCRIPTION:Credentials stored in configuration files should be encrypted, Use standard APIs and industry accepted algorithms to encrypt the credentials stored in configuration files.::","",,,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:ASP.NET Misconfiguration: Password in Configuration File::",,"",
+14,"Compiler Removal of Code to Clear Buffers",Variant,Draft,"Sensitive memory is cleared according to the source code, but compiler optimizations leave the memory untouched when it is not read from again, aka dead store removal.","This compiler optimization error occurs when: Secret data are stored in memory. The secret data are scrubbed from memory by overwriting its contents. The source code is compiled using an optimizing compiler, which identifies and removes the function that overwrites the contents as a dead store because the memory is not used subsequently.",::NATURE:ChildOf:CWE ID:733:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE NAME:C:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:C++:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::PHASE:Build and Compilation::","",,"::SCOPE:Confidentiality:SCOPE:Access Control:IMPACT:Read Memory:IMPACT:Bypass Protection Mechanism:NOTE:This weakness will allow data that has not been cleared from memory to be read. If this data contains sensitive password information, then an attacker can read the password and use the information to bypass protection mechanisms.::","::METHOD:Black Box:DESCRIPTION:This specific weakness is impossible to detect using black box methods. While an analyst could examine memory to see that it has not been scrubbed, an analysis of the executable would not be successful. This is because the compiler has already removed the relevant code. Only the source code shows whether the programmer intended to clear the memory or not, so this weakness is indistinguishable from others.::METHOD:White Box:DESCRIPTION:This weakness is only detectable using white box methods (see black box detection factor). Careful analysis is required to determine if the code is likely to be removed by the compiler.::","::PHASE:Implementation:DESCRIPTION:Store the sensitive data in a volatile memory location if available.::PHASE:Build and Compilation:DESCRIPTION:If possible, configure your compiler so that it does not remove dead stores.::PHASE:Architecture and Design:DESCRIPTION:Where possible, encrypt sensitive data that are used by a software system.::","",,::Memory::,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:Insecure Compiler Optimization::TAXONOMY NAME:PLOVER:ENTRY NAME:Sensitive memory uncleared by compiler optimization::TAXONOMY NAME:OWASP Top Ten 2004:ENTRY ID:A8:ENTRY NAME:Insecure Storage:MAPPING FIT:CWE More Specific::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:MSC06-C:ENTRY NAME:Be aware of compiler optimization when dealing with sensitive data::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP23:ENTRY NAME:Exposed Data::",,"",
+15,"External Control of System or Configuration Setting",Base,Incomplete,"One or more system settings or configuration elements can be externally controlled by a user.","Allowing external control of system settings can disrupt service or cause an application to behave in unexpected, and potentially malicious ways.",::NATURE:ChildOf:CWE ID:642:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:610:VIEW ID:1000::NATURE:ChildOf:CWE ID:20:VIEW ID:700:ORDINAL:Primary::,"",::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:ICS/OT:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Implementation:NOTE:Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.::PHASE:Implementation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::","",,"::SCOPE:Other:IMPACT:Varies by Context::","::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","::PHASE:Architecture and Design:STRATEGY:Separation of Privilege:DESCRIPTION:Compartmentalize the system to have safe areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.::PHASE:Implementation Architecture and Design:DESCRIPTION:Because setting manipulation covers a diverse set of functions, any attempt at illustrating it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.::PHASE:Implementation Architecture and Design:DESCRIPTION:In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of the attacker.::","",,,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:Setting Manipulation::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP25:ENTRY NAME:Tainted input to variable::",::13::146::176::203::270::271::579::69::76::77::,"",
+20,"Improper Input Validation",Class,Stable,"The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.","Input validation is a frequently-used technique for checking potentially dangerous inputs in order to ensure that the inputs are safe for processing within the code, or when communicating with other components. When software does not validate input properly, an attacker is able to craft the input in a form that is not expected by the rest of the application. This will lead to parts of the system receiving unintended input, which may result in altered control flow, arbitrary control of a resource, or arbitrary code execution. Input validation is not the only technique for processing input, however. Other techniques attempt to transform potentially-dangerous input into something safe, such as filtering (CWE-790) - which attempts to remove dangerous inputs - or encoding/escaping (CWE-116), which attempts to ensure that the input is not misinterpreted when it is included in output to another component. Other techniques exist as well (see CWE-138 for more examples.) Input validation can be applied to: raw data - strings, numbers, parameters, file contents, etc. metadata - information about the raw data, such as headers or size Data can be simple or structured. Structured data can be composed of many nested layers, composed of combinations of metadata and raw data, with other simple or structured data. Many properties of raw data or metadata may need to be validated upon entry into the code, such as: specified quantities such as size, length, frequency, price, rate, number of operations, time, etc. implied or derived quantities, such as the actual size of a file instead of a specified size indexes, offsets, or positions into more complex data structures symbolic keys or other elements into hash tables, associative arrays, etc. well-formedness, i.e. syntactic correctness - compliance with expected syntax lexical token correctness - compliance with rules for what is treated as a token specified or derived type - the actual type of the input (or what the input appears to be) consistency - between individual data elements, between raw data and metadata, between references, etc. conformance to domain-specific rules, e.g. business logic equivalence - ensuring that equivalent inputs are treated the same authenticity, ownership, or other attestations about the input, e.g. a cryptographic signature to prove the source of the data Implied or derived properties of data must often be calculated or inferred by the code itself. Errors in deriving properties may be considered a contributing factor to improper input validation. Note that input validation has very different meanings to different people, or within different classification schemes. Caution must be used when referencing this CWE entry or mapping to it. For example, some weaknesses might involve inadvertently giving control to an attacker over an input when they should not be able to provide an input at all, but sometimes this is referred to as input validation. Finally, it is important to emphasize that the distinctions between input validation and output escaping are often blurred, and developers must be careful to understand the difference, including how input validation is not always sufficient to prevent vulnerabilities, especially when less stringent data types must be supported, such as free-form text. Consider a SQL injection scenario in which a person's last name is inserted into a query. The name O'Reilly would likely pass the validation step since it is a common last name in the English language. However, this valid name cannot be directly inserted into the database because it contains the ' apostrophe character, which would need to be escaped or otherwise transformed. In this case, removing the apostrophe might reduce the risk of SQL injection, but it would produce incorrect behavior because the wrong name would be recorded.",::NATURE:ChildOf:CWE ID:707:VIEW ID:1000:ORDINAL:Primary::NATURE:PeerOf:CWE ID:345:VIEW ID:1000:ORDINAL:Primary::NATURE:CanPrecede:CWE ID:22:VIEW ID:1000::NATURE:CanPrecede:CWE ID:41:VIEW ID:1000::NATURE:CanPrecede:CWE ID:74:VIEW ID:1000::NATURE:CanPrecede:CWE ID:119:VIEW ID:1000::NATURE:CanPrecede:CWE ID:770:VIEW ID:1000::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Often::,"","","::PHASE:Architecture and Design::PHASE:Implementation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic. If a programmer believes that an attacker cannot modify certain inputs, then the programmer might not perform any input validation at all. For example, in web applications, many programmers believe that cookies and hidden form fields can not be modified from a web browser (CWE-472), although they can be altered using a proxy or a custom program. In a client-server architecture, the programmer might assume that client-side security checks cannot be bypassed, even when a custom client could be written that skips those checks (CWE-602).::","",,"::SCOPE:Availability:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:DoS: Resource Consumption (CPU):IMPACT:DoS: Resource Consumption (Memory):NOTE:An attacker could provide unexpected values and cause a program crash or excessive consumption of resources, such as memory and CPU.::SCOPE:Confidentiality:IMPACT:Read Memory:IMPACT:Read Files or Directories:NOTE:An attacker could read confidential data if they are able to control resource references.::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:IMPACT:Modify Memory:IMPACT:Execute Unauthorized Code or Commands:NOTE:An attacker could use malicious input to modify data or possibly alter control flow in unexpected ways, including arbitrary command execution.::","::METHOD:Automated Static Analysis:DESCRIPTION:Some instances of improper input validation can be detected using automated static analysis. A static analysis tool might allow the user to specify which application-specific methods or functions perform input validation; the tool might also have built-in knowledge of validation frameworks such as Struts. The tool may then suppress or de-prioritize any associated warnings. This allows the analyst to focus on areas of the software in which input validation does not appear to be present. Except in the cases described in the previous paragraph, automated static analysis might not be able to recognize when proper input validation is being performed, leading to false positives - i.e., warnings that do not have any security consequences or require any code changes.::METHOD:Manual Static Analysis:DESCRIPTION:When custom input validation is required, such as when enforcing business rules, manual analysis is necessary to ensure that the validation is properly implemented.::METHOD:Fuzzing:DESCRIPTION:Fuzzing techniques can be useful for detecting input validation errors. When unexpected inputs are provided to the software, the software should not crash or otherwise become unstable, and it should generate application-controlled error messages. If exceptions or interpreter-generated error messages occur, this indicates that the input was not detected and handled within the application logic itself.::METHOD:Automated Static Analysis - Binary or Bytecode:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Bytecode Weakness Analysis - including disassembler + source code weakness analysis Binary Weakness Analysis - including disassembler + source code weakness analysis:EFFECTIVENESS:SOAR Partial::METHOD:Manual Static Analysis - Binary or Bytecode:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies:EFFECTIVENESS:SOAR Partial::METHOD:Dynamic Analysis with Automated Results Interpretation:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Web Application Scanner Web Services Scanner Database Scanners:EFFECTIVENESS:High::METHOD:Dynamic Analysis with Manual Results Interpretation:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Fuzz Tester Framework-based Fuzzer Cost effective for partial coverage: Host Application Interface Scanner Monitored Virtual Environment - run potentially malicious code in sandbox / wrapper / virtual machine, see if it does anything suspicious:EFFECTIVENESS:High::METHOD:Manual Static Analysis - Source Code:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Focused Manual Spotcheck - Focused manual analysis of source Manual Source Code Review (not inspections):EFFECTIVENESS:High::METHOD:Automated Static Analysis - Source Code:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer:EFFECTIVENESS:High::METHOD:Architecture or Design Review:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.) Formal Methods / Correct-By-Construction Cost effective for partial coverage: Attack Modeling:EFFECTIVENESS:High::","::PHASE:Architecture and Design:STRATEGY:Attack Surface Reduction:DESCRIPTION:Consider using language-theoretic security (LangSec) techniques that characterize inputs using a formal language and build recognizers for that language. This effectively requires parsing to be a distinct layer that effectively enforces a boundary between raw input and internal data representations, instead of allowing parser code to be scattered throughout the program, where it could be subject to errors or inconsistencies that create weaknesses. [REF-1109] [REF-1110] [REF-1111]::PHASE:Architecture and Design:STRATEGY:Libraries or Frameworks:DESCRIPTION:Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).::PHASE:Architecture and Design Implementation:STRATEGY:Attack Surface Reduction:DESCRIPTION:Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.:EFFECTIVENESS:High::PHASE:Architecture and Design:DESCRIPTION:For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server. Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.::PHASE:Implementation:DESCRIPTION:When your application combines data from multiple sources, perform the validation after the sources have been combined. The individual data elements may pass the validation step but violate the intended restrictions after they have been combined.::PHASE:Implementation:DESCRIPTION:Be especially careful to validate all input when invoking code that crosses language boundaries, such as from an interpreted language to native code. This could create an unexpected interaction between the language boundaries. Ensure that you are not violating any of the expectations of the language with which you are interfacing. For example, even though Java may not be susceptible to buffer overflows, providing a large argument in a call to native code might trigger an overflow.::PHASE:Implementation:DESCRIPTION:Directly convert your input type into the expected data type, such as using a conversion function that translates a string into a number. After converting to the expected data type, ensure that the input's values fall within the expected range of allowable values and that multi-field consistencies are maintained.::PHASE:Implementation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control. Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.::PHASE:Implementation:DESCRIPTION:When exchanging data between components, ensure that both components are using the same character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set the encoding you are using whenever the protocol allows you to do so.::","::REFERENCE:CVE-2022-45918:DESCRIPTION:Chain: a learning management tool debugger uses external input to locate previous session logs (CWE-73) and does not properly validate the given path (CWE-20), allowing for filesystem path traversal using ../ sequences (CWE-24):LINK:https://www.cve.org/CVERecord?id=CVE-2022-45918::REFERENCE:CVE-2021-30860:DESCRIPTION:Chain: improper input validation (CWE-20) leads to integer overflow (CWE-190) in mobile OS, as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2021-30860::REFERENCE:CVE-2021-30663:DESCRIPTION:Chain: improper input validation (CWE-20) leads to integer overflow (CWE-190) in mobile OS, as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2021-30663::REFERENCE:CVE-2021-22205:DESCRIPTION:Chain: backslash followed by a newline can bypass a validation step (CWE-20), leading to eval injection (CWE-95), as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2021-22205::REFERENCE:CVE-2021-21220:DESCRIPTION:Chain: insufficient input validation (CWE-20) in browser allows heap corruption (CWE-787), as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2021-21220::REFERENCE:CVE-2020-9054:DESCRIPTION:Chain: improper input validation (CWE-20) in username parameter, leading to OS command injection (CWE-78), as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-9054::REFERENCE:CVE-2020-3452:DESCRIPTION:Chain: security product has improper input validation (CWE-20) leading to directory traversal (CWE-22), as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-3452::REFERENCE:CVE-2020-3161:DESCRIPTION:Improper input validation of HTTP requests in IP phone, as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-3161::REFERENCE:CVE-2020-3580:DESCRIPTION:Chain: improper input validation (CWE-20) in firewall product leads to XSS (CWE-79), as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-3580::REFERENCE:CVE-2021-37147:DESCRIPTION:Chain: caching proxy server has improper input validation (CWE-20) of headers, allowing HTTP response smuggling (CWE-444) using an LF line ending:LINK:https://www.cve.org/CVERecord?id=CVE-2021-37147::REFERENCE:CVE-2008-5305:DESCRIPTION:Eval injection in Perl program using an ID that should only contain hyphens and numbers.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-5305::REFERENCE:CVE-2008-2223:DESCRIPTION:SQL injection through an ID that was supposed to be numeric.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-2223::REFERENCE:CVE-2008-3477:DESCRIPTION:lack of input validation in spreadsheet program leads to buffer overflows, integer overflows, array index errors, and memory corruption.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-3477::REFERENCE:CVE-2008-3843:DESCRIPTION:insufficient validation enables XSS:LINK:https://www.cve.org/CVERecord?id=CVE-2008-3843::REFERENCE:CVE-2008-3174:DESCRIPTION:driver in security product allows code execution due to insufficient validation:LINK:https://www.cve.org/CVERecord?id=CVE-2008-3174::REFERENCE:CVE-2007-3409:DESCRIPTION:infinite loop from DNS packet with a label that points to itself:LINK:https://www.cve.org/CVERecord?id=CVE-2007-3409::REFERENCE:CVE-2006-6870:DESCRIPTION:infinite loop from DNS packet with a label that points to itself:LINK:https://www.cve.org/CVERecord?id=CVE-2006-6870::REFERENCE:CVE-2008-1303:DESCRIPTION:missing parameter leads to crash:LINK:https://www.cve.org/CVERecord?id=CVE-2008-1303::REFERENCE:CVE-2007-5893:DESCRIPTION:HTTP request with missing protocol version number leads to crash:LINK:https://www.cve.org/CVERecord?id=CVE-2007-5893::REFERENCE:CVE-2006-6658:DESCRIPTION:request with missing parameters leads to information exposure:LINK:https://www.cve.org/CVERecord?id=CVE-2006-6658::REFERENCE:CVE-2008-4114:DESCRIPTION:system crash with offset value that is inconsistent with packet size:LINK:https://www.cve.org/CVERecord?id=CVE-2008-4114::REFERENCE:CVE-2006-3790:DESCRIPTION:size field that is inconsistent with packet size leads to buffer over-read:LINK:https://www.cve.org/CVERecord?id=CVE-2006-3790::REFERENCE:CVE-2008-2309:DESCRIPTION:product uses a denylist to identify potentially dangerous content, allowing attacker to bypass a warning:LINK:https://www.cve.org/CVERecord?id=CVE-2008-2309::REFERENCE:CVE-2008-3494:DESCRIPTION:security bypass via an extra header:LINK:https://www.cve.org/CVERecord?id=CVE-2008-3494::REFERENCE:CVE-2008-3571:DESCRIPTION:empty packet triggers reboot:LINK:https://www.cve.org/CVERecord?id=CVE-2008-3571::REFERENCE:CVE-2006-5525:DESCRIPTION:incomplete denylist allows SQL injection:LINK:https://www.cve.org/CVERecord?id=CVE-2006-5525::REFERENCE:CVE-2008-1284:DESCRIPTION:NUL byte in theme name causes directory traversal impact to be worse:LINK:https://www.cve.org/CVERecord?id=CVE-2008-1284::REFERENCE:CVE-2008-0600:DESCRIPTION:kernel does not validate an incoming pointer before dereferencing it:LINK:https://www.cve.org/CVERecord?id=CVE-2008-0600::REFERENCE:CVE-2008-1738:DESCRIPTION:anti-virus product has insufficient input validation of hooked SSDT functions, allowing code execution:LINK:https://www.cve.org/CVERecord?id=CVE-2008-1738::REFERENCE:CVE-2008-1737:DESCRIPTION:anti-virus product allows DoS via zero-length field:LINK:https://www.cve.org/CVERecord?id=CVE-2008-1737::REFERENCE:CVE-2008-3464:DESCRIPTION:driver does not validate input from userland to the kernel:LINK:https://www.cve.org/CVERecord?id=CVE-2008-3464::REFERENCE:CVE-2008-2252:DESCRIPTION:kernel does not validate parameters sent in from userland, allowing code execution:LINK:https://www.cve.org/CVERecord?id=CVE-2008-2252::REFERENCE:CVE-2008-2374:DESCRIPTION:lack of validation of string length fields allows memory consumption or buffer over-read:LINK:https://www.cve.org/CVERecord?id=CVE-2008-2374::REFERENCE:CVE-2008-1440:DESCRIPTION:lack of validation of length field leads to infinite loop:LINK:https://www.cve.org/CVERecord?id=CVE-2008-1440::REFERENCE:CVE-2008-1625:DESCRIPTION:lack of validation of input to an IOCTL allows code execution:LINK:https://www.cve.org/CVERecord?id=CVE-2008-1625::REFERENCE:CVE-2008-3177:DESCRIPTION:zero-length attachment causes crash:LINK:https://www.cve.org/CVERecord?id=CVE-2008-3177::REFERENCE:CVE-2007-2442:DESCRIPTION:zero-length input causes free of uninitialized pointer:LINK:https://www.cve.org/CVERecord?id=CVE-2007-2442::REFERENCE:CVE-2008-5563:DESCRIPTION:crash via a malformed frame structure:LINK:https://www.cve.org/CVERecord?id=CVE-2008-5563::REFERENCE:CVE-2008-5285:DESCRIPTION:infinite loop from a long SMTP request:LINK:https://www.cve.org/CVERecord?id=CVE-2008-5285::REFERENCE:CVE-2008-3812:DESCRIPTION:router crashes with a malformed packet:LINK:https://www.cve.org/CVERecord?id=CVE-2008-3812::REFERENCE:CVE-2008-3680:DESCRIPTION:packet with invalid version number leads to NULL pointer dereference:LINK:https://www.cve.org/CVERecord?id=CVE-2008-3680::REFERENCE:CVE-2008-3660:DESCRIPTION:crash via multiple . characters in file extension:LINK:https://www.cve.org/CVERecord?id=CVE-2008-3660::",,,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:Input validation and representation::TAXONOMY NAME:OWASP Top Ten 2004:ENTRY ID:A1:ENTRY NAME:Unvalidated Input:MAPPING FIT:CWE More Specific::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:ERR07-C:ENTRY NAME:Prefer functions that support error checking over equivalent functions that don't::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:FIO30-C:ENTRY NAME:Exclude user input from format strings:MAPPING FIT:CWE More Abstract::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:MEM10-C:ENTRY NAME:Define and use a pointer validation function::TAXONOMY NAME:WASC:ENTRY ID:20:ENTRY NAME:Improper Input Handling::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP25:ENTRY NAME:Tainted input to variable::",::10::101::104::108::109::110::120::13::135::136::14::153::182::209::22::23::230::231::24::250::261::267::28::3::31::42::43::45::46::47::473::52::53::588::63::64::664::67::7::71::72::73::78::79::8::80::81::83::85::88::9::,"::TYPE:Relationship:NOTE:CWE-116 and CWE-20 have a close association because, depending on the nature of the structured message, proper input validation can indirectly prevent special characters from changing the meaning of a structured message. For example, by validating that a numeric ID field should only contain the 0-9 characters, the programmer effectively prevents injection attacks.::TYPE:Maintenance:NOTE:As of 2020, this entry is used more often than preferred, and it is a source of frequent confusion. It is being actively modified for CWE 4.1 and subsequent versions.::TYPE:Maintenance:NOTE:Concepts such as validation, data transformation, and neutralization are being refined, so relationships between CWE-20 and other entries such as CWE-707 may change in future versions, along with an update to the Vulnerability Theory document.::TYPE:Maintenance:NOTE:Input validation - whether missing or incorrect - is such an essential and widespread part of secure development that it is implicit in many different weaknesses. Traditionally, problems such as buffer overflows and XSS have been classified as input validation problems by many security professionals. However, input validation is not necessarily the only protection mechanism available for avoiding such problems, and in some cases it is not even sufficient. The CWE team has begun capturing these subtleties in chains within the Research Concepts view (CWE-1000), but more work is needed.::TYPE:Terminology:NOTE:The input validation term is extremely common, but it is used in many different ways. In some cases its usage can obscure the real underlying weakness or otherwise hide chaining and composite relationships. Some people use input validation as a general term that covers many different neutralization techniques for ensuring that input is appropriate, such as filtering, canonicalization, and escaping. Others use the term in a more narrow context to simply mean checking if an input conforms to expectations without changing it. CWE uses this more narrow interpretation.::",
+22,"Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')",Base,Stable,"The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.","Many file operations are intended to take place within a restricted directory. By using special elements such as .. and / separators, attackers can escape outside of the restricted location to access files or directories that are elsewhere on the system. One of the most common special elements is the ../ sequence, which in most modern operating systems is interpreted as the parent directory of the current location. This is referred to as relative path traversal. Path traversal also covers the use of absolute pathnames such as /usr/local/bin, which may also be useful in accessing unexpected files. This is referred to as absolute path traversal. In many programming languages, the injection of a null byte (the 0 or NUL) may allow an attacker to truncate a generated filename to widen the scope of attack. For example, the product may add .txt to any pathname, thus limiting the attacker to text files, but a null injection may effectively remove this restriction.",::NATURE:ChildOf:CWE ID:706:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:706:VIEW ID:1003:ORDINAL:Primary::NATURE:ChildOf:CWE ID:668:VIEW ID:1000::,"::ORDINALITY:Primary::ORDINALITY:Resultant::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","::TERM:Directory traversal::TERM:Path traversal:DESCRIPTION:Path traversal is preferred over directory traversal, but both terms are attack-focused.::","::PHASE:Implementation::","",,"::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:IMPACT:Execute Unauthorized Code or Commands:NOTE:The attacker may be able to create or overwrite critical files that are used to execute code, such as programs or libraries.::SCOPE:Integrity:IMPACT:Modify Files or Directories:NOTE:The attacker may be able to overwrite or create critical files, such as programs, libraries, or important data. If the targeted file is used for a security mechanism, then the attacker may be able to bypass that mechanism. For example, appending a new account at the end of a password file may allow an attacker to bypass authentication.::SCOPE:Confidentiality:IMPACT:Read Files or Directories:NOTE:The attacker may be able read the contents of unexpected files and expose sensitive data. If the targeted file is used for a security mechanism, then the attacker may be able to bypass that mechanism. For example, by reading a password file, the attacker could conduct brute force password guessing attacks in order to break into an account on the system.::SCOPE:Availability:IMPACT:DoS: Crash, Exit, or Restart:NOTE:The attacker may be able to overwrite, delete, or corrupt unexpected critical files such as programs, libraries, or important data. This may prevent the product from working at all and in the case of a protection mechanisms such as authentication, it has the potential to lockout every user of the product.::","::METHOD:Automated Static Analysis:DESCRIPTION:Automated techniques can find areas where path traversal weaknesses exist. However, tuning or customization may be required to remove or de-prioritize path-traversal problems that are only exploitable by the product's administrator - or other privileged users - and thus potentially valid behavior or, at worst, a bug instead of a vulnerability.:EFFECTIVENESS:High::METHOD:Manual Static Analysis:DESCRIPTION:Manual white box techniques may be able to provide sufficient code coverage and reduction of false positives if all file access operations can be assessed within limited time constraints.:EFFECTIVENESS:High::METHOD:Automated Static Analysis - Binary or Bytecode:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Bytecode Weakness Analysis - including disassembler + source code weakness analysis Cost effective for partial coverage: Binary Weakness Analysis - including disassembler + source code weakness analysis:EFFECTIVENESS:High::METHOD:Manual Static Analysis - Binary or Bytecode:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies:EFFECTIVENESS:SOAR Partial::METHOD:Dynamic Analysis with Automated Results Interpretation:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Web Application Scanner Web Services Scanner Database Scanners:EFFECTIVENESS:High::METHOD:Dynamic Analysis with Manual Results Interpretation:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Fuzz Tester Framework-based Fuzzer:EFFECTIVENESS:High::METHOD:Manual Static Analysis - Source Code:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Manual Source Code Review (not inspections) Cost effective for partial coverage: Focused Manual Spotcheck - Focused manual analysis of source:EFFECTIVENESS:High::METHOD:Automated Static Analysis - Source Code:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer:EFFECTIVENESS:High::METHOD:Architecture or Design Review:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Formal Methods / Correct-By-Construction Cost effective for partial coverage: Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.):EFFECTIVENESS:High::","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single . character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as / to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering / is insufficient protection if the filesystem also supports the use of as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if ../ sequences are removed from the .../...// string in a sequential fashion, two instances of ../ would be removed from the original string, but the remaining characters would still form the ../ string.::PHASE:Architecture and Design:DESCRIPTION:For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked. Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes .. sequences and symbolic links (CWE-23, CWE-59). This includes: realpath() in C getCanonicalPath() in Java GetFullPath() in ASP.NET realpath() or abs_path() in Perl realpath() in PHP::PHASE:Architecture and Design:STRATEGY:Libraries or Frameworks:DESCRIPTION:Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.::PHASE:Operation:STRATEGY:Firewall:DESCRIPTION:Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.:EFFECTIVENESS:Moderate::PHASE:Architecture and Design Operation:STRATEGY:Environment Hardening:DESCRIPTION:Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.::PHASE:Architecture and Design:STRATEGY:Enforcement by Conversion:DESCRIPTION:When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs. For example, ID 1 could map to inbox.txt and ID 2 could map to profile.txt. Features such as the ESAPI AccessReferenceMap [REF-185] provide this capability.::PHASE:Architecture and Design Operation:STRATEGY:Sandbox or Jail:DESCRIPTION:Run the code in a jail or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software. OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.:EFFECTIVENESS:Limited::PHASE:Architecture and Design Operation:STRATEGY:Attack Surface Reduction:DESCRIPTION:Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server's access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and it can exit immediately. This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include files. It will also reduce the attack surface.::PHASE:Implementation:DESCRIPTION:Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not. In the context of path traversal, error messages which disclose path information can help attackers craft the appropriate attack strings to move through the file system hierarchy.::PHASE:Operation Implementation:STRATEGY:Environment Hardening:DESCRIPTION:When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.::","::REFERENCE:CVE-2022-45918:DESCRIPTION:Chain: a learning management tool debugger uses external input to locate previous session logs (CWE-73) and does not properly validate the given path (CWE-20), allowing for filesystem path traversal using ../ sequences (CWE-24):LINK:https://www.cve.org/CVERecord?id=CVE-2022-45918::REFERENCE:CVE-2019-20916:DESCRIPTION:Python package manager does not correctly restrict the filename specified in a Content-Disposition header, allowing arbitrary file read using path traversal sequences such as ../:LINK:https://www.cve.org/CVERecord?id=CVE-2019-20916::REFERENCE:CVE-2022-31503:DESCRIPTION:Python package constructs filenames using an unsafe os.path.join call on untrusted input, allowing absolute path traversal because os.path.join resets the pathname to an absolute path that is specified as part of the input.:LINK:https://www.cve.org/CVERecord?id=CVE-2022-31503::REFERENCE:CVE-2022-24877:DESCRIPTION:directory traversal in Go-based Kubernetes operator app allows accessing data from the controller's pod file system via ../ sequences in a yaml file:LINK:https://www.cve.org/CVERecord?id=CVE-2022-24877::REFERENCE:CVE-2021-21972:DESCRIPTION:Chain: Cloud computing virtualization platform does not require authentication for upload of a tar format file (CWE-306), then uses .. path traversal sequences (CWE-23) in the file to access unexpected files, as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2021-21972::REFERENCE:CVE-2020-4053:DESCRIPTION:a Kubernetes package manager written in Go allows malicious plugins to inject path traversal sequences into a plugin archive (Zip slip) to copy a file outside the intended directory:LINK:https://www.cve.org/CVERecord?id=CVE-2020-4053::REFERENCE:CVE-2020-3452:DESCRIPTION:Chain: security product has improper input validation (CWE-20) leading to directory traversal (CWE-22), as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-3452::REFERENCE:CVE-2019-10743:DESCRIPTION:Go-based archive library allows extraction of files to locations outside of the target folder with ../ path traversal sequences in filenames in a zip file, aka Zip Slip:LINK:https://www.cve.org/CVERecord?id=CVE-2019-10743::REFERENCE:CVE-2010-0467:DESCRIPTION:Newsletter module allows reading arbitrary files using ../ sequences.:LINK:https://www.cve.org/CVERecord?id=CVE-2010-0467::REFERENCE:CVE-2006-7079:DESCRIPTION:Chain: PHP app uses extract for register_globals compatibility layer (CWE-621), enabling path traversal (CWE-22):LINK:https://www.cve.org/CVERecord?id=CVE-2006-7079::REFERENCE:CVE-2009-4194:DESCRIPTION:FTP server allows deletion of arbitrary files using .. in the DELE command.:LINK:https://www.cve.org/CVERecord?id=CVE-2009-4194::REFERENCE:CVE-2009-4053:DESCRIPTION:FTP server allows creation of arbitrary directories using .. in the MKD command.:LINK:https://www.cve.org/CVERecord?id=CVE-2009-4053::REFERENCE:CVE-2009-0244:DESCRIPTION:FTP service for a Bluetooth device allows listing of directories, and creation or reading of files using .. sequences.:LINK:https://www.cve.org/CVERecord?id=CVE-2009-0244::REFERENCE:CVE-2009-4013:DESCRIPTION:Software package maintenance program allows overwriting arbitrary files using ../ sequences.:LINK:https://www.cve.org/CVERecord?id=CVE-2009-4013::REFERENCE:CVE-2009-4449:DESCRIPTION:Bulletin board allows attackers to determine the existence of files using the avatar.:LINK:https://www.cve.org/CVERecord?id=CVE-2009-4449::REFERENCE:CVE-2009-4581:DESCRIPTION:PHP program allows arbitrary code execution using .. in filenames that are fed to the include() function.:LINK:https://www.cve.org/CVERecord?id=CVE-2009-4581::REFERENCE:CVE-2010-0012:DESCRIPTION:Overwrite of files using a .. in a Torrent file.:LINK:https://www.cve.org/CVERecord?id=CVE-2010-0012::REFERENCE:CVE-2010-0013:DESCRIPTION:Chat program allows overwriting files using a custom smiley request.:LINK:https://www.cve.org/CVERecord?id=CVE-2010-0013::REFERENCE:CVE-2008-5748:DESCRIPTION:Chain: external control of values for user's desired language and theme enables path traversal.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-5748::REFERENCE:CVE-2009-1936:DESCRIPTION:Chain: library file sends a redirect if it is directly requested but continues to execute, allowing remote file inclusion and path traversal.:LINK:https://www.cve.org/CVERecord?id=CVE-2009-1936::",::File Processing::,::File or Directory::,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Path Traversal::TAXONOMY NAME:OWASP Top Ten 2007:ENTRY ID:A4:ENTRY NAME:Insecure Direct Object Reference:MAPPING FIT:CWE More Specific::TAXONOMY NAME:OWASP Top Ten 2004:ENTRY ID:A2:ENTRY NAME:Broken Access Control:MAPPING FIT:CWE More Specific::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:FIO02-C:ENTRY NAME:Canonicalize path names originating from untrusted sources::TAXONOMY NAME:SEI CERT Perl Coding Standard:ENTRY ID:IDS00-PL:ENTRY NAME:Canonicalize path names before validating them:MAPPING FIT:Exact::TAXONOMY NAME:WASC:ENTRY ID:33:ENTRY NAME:Path Traversal::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::TAXONOMY NAME:OMG ASCSM:ENTRY ID:ASCSM-CWE-22::",::126::64::76::78::79::,"::TYPE:Relationship:NOTE:Pathname equivalence can be regarded as a type of canonicalization error.::TYPE:Relationship:NOTE:Some pathname equivalence issues are not directly related to directory traversal, rather are used to bypass security-relevant checks for whether a file/directory can be accessed by the attacker (e.g. a trailing / on a filename could bypass access rules that don't expect a trailing /, causing a server to provide the file when it normally would not).::TYPE:Terminology:NOTE:Like other weaknesses, terminology is often based on the types of manipulations used, instead of the underlying weaknesses. Some people use directory traversal only to refer to the injection of .. and equivalent sequences whose specific meaning is to traverse directories. Other variants like absolute pathname and drive letter have the *effect* of directory traversal, but some people may not call it such, since it doesn't involve .. or equivalent.::TYPE:Research Gap:NOTE:Many variants of path traversal attacks are probably under-studied with respect to root cause. CWE-790 and CWE-182 begin to cover part of this gap.::TYPE:Research Gap:NOTE:Incomplete diagnosis or reporting of vulnerabilities can make it difficult to know which variant is affected. For example, a researcher might say that .. is vulnerable, but not test ../ which may also be vulnerable. Any combination of directory separators (/, , etc.) and numbers of . (e.g. ....) can produce unique variants; for example, the //../ variant is not listed (CVE-2004-0325). See this entry's children and lower-level descendants.::",
+23,"Relative Path Traversal",Base,Draft,"The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize sequences such as .. that can resolve to a location that is outside of that directory.","This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory.",::NATURE:ChildOf:CWE ID:22:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:22:VIEW ID:1305:ORDINAL:Primary::NATURE:ChildOf:CWE ID:22:VIEW ID:1340:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","::TERM:Zip Slip:DESCRIPTION:Zip slip is an attack that uses file archives (e.g., ZIP, tar, rar, etc.) that contain filenames with path traversal sequences that cause the files to be written outside of the directory under which the archive is expected to be extracted [REF-1282]. It is most commonly used for relative path traversal (CWE-23) and link following (CWE-59).::","::PHASE:Implementation::","",,"::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:IMPACT:Execute Unauthorized Code or Commands:NOTE:The attacker may be able to create or overwrite critical files that are used to execute code, such as programs or libraries.::SCOPE:Integrity:IMPACT:Modify Files or Directories:NOTE:The attacker may be able to overwrite or create critical files, such as programs, libraries, or important data. If the targeted file is used for a security mechanism, then the attacker may be able to bypass that mechanism. For example, appending a new account at the end of a password file may allow an attacker to bypass authentication.::SCOPE:Confidentiality:IMPACT:Read Files or Directories:NOTE:The attacker may be able read the contents of unexpected files and expose sensitive data. If the targeted file is used for a security mechanism, then the attacker may be able to bypass that mechanism. For example, by reading a password file, the attacker could conduct brute force password guessing attacks in order to break into an account on the system.::SCOPE:Availability:IMPACT:DoS: Crash, Exit, or Restart:NOTE:The attacker may be able to overwrite, delete, or corrupt unexpected critical files such as programs, libraries, or important data. This may prevent the product from working at all and in the case of a protection mechanisms such as authentication, it has the potential to lockout every user of the product.::","::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single . character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as / to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering / is insufficient protection if the filesystem also supports the use of as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if ../ sequences are removed from the .../...// string in a sequential fashion, two instances of ../ would be removed from the original string, but the remaining characters would still form the ../ string.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked. Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes .. sequences and symbolic links (CWE-23, CWE-59). This includes: realpath() in C getCanonicalPath() in Java GetFullPath() in ASP.NET realpath() or abs_path() in Perl realpath() in PHP::","::REFERENCE:CVE-2022-45918:DESCRIPTION:Chain: a learning management tool debugger uses external input to locate previous session logs (CWE-73) and does not properly validate the given path (CWE-20), allowing for filesystem path traversal using ../ sequences (CWE-24):LINK:https://www.cve.org/CVERecord?id=CVE-2022-45918::REFERENCE:CVE-2019-20916:DESCRIPTION:Python package manager does not correctly restrict the filename specified in a Content-Disposition header, allowing arbitrary file read using path traversal sequences such as ../:LINK:https://www.cve.org/CVERecord?id=CVE-2019-20916::REFERENCE:CVE-2022-24877:DESCRIPTION:directory traversal in Go-based Kubernetes operator app allows accessing data from the controller's pod file system via ../ sequences in a yaml file:LINK:https://www.cve.org/CVERecord?id=CVE-2022-24877::REFERENCE:CVE-2020-4053:DESCRIPTION:a Kubernetes package manager written in Go allows malicious plugins to inject path traversal sequences into a plugin archive (Zip slip) to copy a file outside the intended directory:LINK:https://www.cve.org/CVERecord?id=CVE-2020-4053::REFERENCE:CVE-2021-21972:DESCRIPTION:Chain: Cloud computing virtualization platform does not require authentication for upload of a tar format file (CWE-306), then uses .. path traversal sequences (CWE-23) in the file to access unexpected files, as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2021-21972::REFERENCE:CVE-2019-10743:DESCRIPTION:Go-based archive library allows extraction of files to locations outside of the target folder with ../ path traversal sequences in filenames in a zip file, aka Zip Slip:LINK:https://www.cve.org/CVERecord?id=CVE-2019-10743::REFERENCE:CVE-2002-0298:DESCRIPTION:Server allows remote attackers to cause a denial of service via certain HTTP GET requests containing a %2e%2e (encoded dot-dot), several /../ sequences, or several ../ in a URI.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0298::REFERENCE:CVE-2002-0661:DESCRIPTION:not in denylist for web server, allowing path traversal attacks when the server is run in Windows and other OSes.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0661::REFERENCE:CVE-2002-0946:DESCRIPTION:Arbitrary files may be read files via .. (dot dot) sequences in an HTTP request.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0946::REFERENCE:CVE-2002-1042:DESCRIPTION:Directory traversal vulnerability in search engine for web server allows remote attackers to read arbitrary files via .. sequences in queries.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1042::REFERENCE:CVE-2002-1209:DESCRIPTION:Directory traversal vulnerability in FTP server allows remote attackers to read arbitrary files via .. sequences in a GET request.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1209::REFERENCE:CVE-2002-1178:DESCRIPTION:Directory traversal vulnerability in servlet allows remote attackers to execute arbitrary commands via .. sequences in an HTTP request.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1178::REFERENCE:CVE-2002-1987:DESCRIPTION:Protection mechanism checks for /.. but doesn't account for Windows-specific .. allowing read of arbitrary files.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1987::REFERENCE:CVE-2005-2142:DESCRIPTION:Directory traversal vulnerability in FTP server allows remote authenticated attackers to list arbitrary directories via a .. sequence in an LS command.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-2142::REFERENCE:CVE-2002-0160:DESCRIPTION:The administration function in Access Control Server allows remote attackers to read HTML, Java class, and image files outside the web root via a .... sequence in the URL to port 2002.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0160::REFERENCE:CVE-2001-0467:DESCRIPTION:... in web server:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0467::REFERENCE:CVE-2001-0963:DESCRIPTION:... in cd command in FTP server:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0963::REFERENCE:CVE-2001-1193:DESCRIPTION:... in cd command in FTP server:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1193::REFERENCE:CVE-2001-1131:DESCRIPTION:... in cd command in FTP server:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1131::REFERENCE:CVE-2001-0480:DESCRIPTION:read of arbitrary files and directories using GET or CD with ... in Windows-based FTP server.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0480::REFERENCE:CVE-2002-0288:DESCRIPTION:read files using . and Unicode-encoded / or characters in the URL.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0288::REFERENCE:CVE-2003-0313:DESCRIPTION:Directory listing of web server using ...:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0313::REFERENCE:CVE-2005-1658:DESCRIPTION:Triple dot:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1658::REFERENCE:CVE-2000-0240:DESCRIPTION:read files via /........../ in URL:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0240::REFERENCE:CVE-2000-0773:DESCRIPTION:read files via .... in web server:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0773::REFERENCE:CVE-1999-1082:DESCRIPTION:read files via ...... in web server (doubled triple dot?):LINK:https://www.cve.org/CVERecord?id=CVE-1999-1082::REFERENCE:CVE-2004-2121:DESCRIPTION:read files via ...... in web server (doubled triple dot?):LINK:https://www.cve.org/CVERecord?id=CVE-2004-2121::REFERENCE:CVE-2001-0491:DESCRIPTION:multiple attacks using .., ..., and .... in different commands:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0491::REFERENCE:CVE-2001-0615:DESCRIPTION:... or .... in chat server:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0615::REFERENCE:CVE-2005-2169:DESCRIPTION:chain: .../...// bypasses protection mechanism using regexp's that remove ../ resulting in collapse into an unsafe value ../ (CWE-182) and resultant path traversal.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-2169::REFERENCE:CVE-2005-0202:DESCRIPTION:.../..../// bypasses regexp's that remove ./ and ../:LINK:https://www.cve.org/CVERecord?id=CVE-2005-0202::REFERENCE:CVE-2004-1670:DESCRIPTION:Mail server allows remote attackers to create arbitrary directories via a .. or rename arbitrary files via a ....// in user supplied parameters.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1670::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Relative Path Traversal::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",::139::76::,"",
+24,"Path Traversal: '../filedir'",Variant,Incomplete,"The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize ../ sequences that can resolve to a location that is outside of that directory.","This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory. The ../ manipulation is the canonical manipulation for operating systems that use / as directory separators, such as UNIX- and Linux-based systems. In some cases, it is useful for bypassing protection schemes in environments for which / is supported but not the primary separator, such as Windows, which uses but can also accept /.",::NATURE:ChildOf:CWE ID:23:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single . character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as / to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering / is insufficient protection if the filesystem also supports the use of as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if ../ sequences are removed from the .../...// string in a sequential fashion, two instances of ../ would be removed from the original string, but the remaining characters would still form the ../ string.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2022-45918:DESCRIPTION:Chain: a learning management tool debugger uses external input to locate previous session logs (CWE-73) and does not properly validate the given path (CWE-20), allowing for filesystem path traversal using ../ sequences (CWE-24):LINK:https://www.cve.org/CVERecord?id=CVE-2022-45918::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:'../filedir::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"",
+25,"Path Traversal: '/../filedir'",Variant,Incomplete,"The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize /../ sequences that can resolve to a location that is outside of that directory.","This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory. Sometimes a program checks for ../ at the beginning of the input, so a /../ can bypass that check.",::NATURE:ChildOf:CWE ID:23:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single . character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as / to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering / is insufficient protection if the filesystem also supports the use of as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if ../ sequences are removed from the .../...// string in a sequential fashion, two instances of ../ would be removed from the original string, but the remaining characters would still form the ../ string.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2022-20775:DESCRIPTION:A cloud management tool allows attackers to bypass the restricted shell using path traversal sequences like /../ in the USER environment variable.:LINK:https://www.cve.org/CVERecord?id=CVE-2022-20775::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:'/../filedir::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"",
+26,"Path Traversal: '/dir/../filename'",Variant,Draft,"The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize /dir/../filename sequences that can resolve to a location that is outside of that directory.","This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory. The '/dir/../filename' manipulation is useful for bypassing some path traversal protection schemes. Sometimes a program only checks for ../ at the beginning of the input, so a /../ can bypass that check.",::NATURE:ChildOf:CWE ID:23:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::TECHNOLOGY NAME:Web Server:TECHNOLOGY PREVALENCE:Often::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single . character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as / to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering / is insufficient protection if the filesystem also supports the use of as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if ../ sequences are removed from the .../...// string in a sequential fashion, two instances of ../ would be removed from the original string, but the remaining characters would still form the ../ string.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:'/directory/../filename::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"",
+27,"Path Traversal: 'dir/../../filename'",Variant,Draft,"The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize multiple internal ../ sequences that can resolve to a location that is outside of that directory.","This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory. The 'directory/../../filename' manipulation is useful for bypassing some path traversal protection schemes. Sometimes a program only removes one ../ sequence, so multiple ../ can bypass that check. Alternately, this manipulation could be used to bypass a check for ../ at the beginning of the pathname, moving up more than one directory level.",::NATURE:ChildOf:CWE ID:23:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single . character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as / to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering / is insufficient protection if the filesystem also supports the use of as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if ../ sequences are removed from the .../...// string in a sequential fashion, two instances of ../ would be removed from the original string, but the remaining characters would still form the ../ string.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2002-0298:DESCRIPTION:Server allows remote attackers to cause a denial of service via certain HTTP GET requests containing a %2e%2e (encoded dot-dot), several /../ sequences, or several ../ in a URI.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0298::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:'directory/../../filename::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"",
+28,"Path Traversal: '..filedir'",Variant,Incomplete,"The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize .. sequences that can resolve to a location that is outside of that directory.","This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory. The '..' manipulation is the canonical manipulation for operating systems that use as directory separators, such as Windows. However, it is also useful for bypassing path traversal protection schemes that only assume that the / separator is valid.",::NATURE:ChildOf:CWE ID:23:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Windows:OPERATING SYSTEM PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single . character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as / to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering / is insufficient protection if the filesystem also supports the use of as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if ../ sequences are removed from the .../...// string in a sequential fashion, two instances of ../ would be removed from the original string, but the remaining characters would still form the ../ string.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2002-0661:DESCRIPTION:not in denylist for web server, allowing path traversal attacks when the server is run in Windows and other OSes.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0661::REFERENCE:CVE-2002-0946:DESCRIPTION:Arbitrary files may be read files via .. (dot dot) sequences in an HTTP request.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0946::REFERENCE:CVE-2002-1042:DESCRIPTION:Directory traversal vulnerability in search engine for web server allows remote attackers to read arbitrary files via .. sequences in queries.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1042::REFERENCE:CVE-2002-1209:DESCRIPTION:Directory traversal vulnerability in FTP server allows remote attackers to read arbitrary files via .. sequences in a GET request.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1209::REFERENCE:CVE-2002-1178:DESCRIPTION:Directory traversal vulnerability in servlet allows remote attackers to execute arbitrary commands via .. sequences in an HTTP request.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1178::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:'..filename' ('dot dot backslash')::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"",
+29,"Path Traversal: '..filename'",Variant,Incomplete,"The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '..filename' (leading backslash dot dot) sequences that can resolve to a location that is outside of that directory.","This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory. This is similar to CWE-25, except using instead of /. Sometimes a program checks for .. at the beginning of the input, so a .. can bypass that check. It is also useful for bypassing path traversal protection schemes that only assume that the / separator is valid.",::NATURE:ChildOf:CWE ID:23:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Windows:OPERATING SYSTEM PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single . character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as / to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering / is insufficient protection if the filesystem also supports the use of as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if ../ sequences are removed from the .../...// string in a sequential fashion, two instances of ../ would be removed from the original string, but the remaining characters would still form the ../ string.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2002-1987:DESCRIPTION:Protection mechanism checks for /.. but doesn't account for Windows-specific .. allowing read of arbitrary files.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1987::REFERENCE:CVE-2005-2142:DESCRIPTION:Directory traversal vulnerability in FTP server allows remote authenticated attackers to list arbitrary directories via a .. sequence in an LS command.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-2142::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:'..filename' ('leading dot dot backslash')::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"",
+30,"Path Traversal: 'dir..filename'",Variant,Draft,"The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize 'dir..filename' (leading backslash dot dot) sequences that can resolve to a location that is outside of that directory.","This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory. This is similar to CWE-26, except using instead of /. The 'dir..filename' manipulation is useful for bypassing some path traversal protection schemes. Sometimes a program only checks for .. at the beginning of the input, so a .. can bypass that check.",::NATURE:ChildOf:CWE ID:23:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Windows:OPERATING SYSTEM PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single . character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as / to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering / is insufficient protection if the filesystem also supports the use of as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if ../ sequences are removed from the .../...// string in a sequential fashion, two instances of ../ would be removed from the original string, but the remaining characters would still form the ../ string.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2002-1987:DESCRIPTION:Protection mechanism checks for /.. but doesn't account for Windows-specific .. allowing read of arbitrary files.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1987::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:7 - 'directory..filename::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"",
+31,"Path Traversal: 'dir....filename'",Variant,Draft,"The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize 'dir....filename' (multiple internal backslash dot dot) sequences that can resolve to a location that is outside of that directory.","This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory. The 'dir....filename' manipulation is useful for bypassing some path traversal protection schemes. Sometimes a program only removes one .. sequence, so multiple .. can bypass that check. Alternately, this manipulation could be used to bypass a check for .. at the beginning of the pathname, moving up more than one directory level.",::NATURE:ChildOf:CWE ID:23:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Windows:OPERATING SYSTEM PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single . character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as / to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering / is insufficient protection if the filesystem also supports the use of as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if ../ sequences are removed from the .../...// string in a sequential fashion, two instances of ../ would be removed from the original string, but the remaining characters would still form the ../ string.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2002-0160:DESCRIPTION:The administration function in Access Control Server allows remote attackers to read HTML, Java class, and image files outside the web root via a .... sequence in the URL to port 2002.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0160::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:8 - 'directory....filename::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"",
+32,"Path Traversal: '...' (Triple Dot)",Variant,Incomplete,"The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '...' (triple dot) sequences that can resolve to a location that is outside of that directory.","This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory. The '...' manipulation is useful for bypassing some path traversal protection schemes. On some Windows systems, it is equivalent to .... and might bypass checks that assume only two dots are valid. Incomplete filtering, such as removal of ./ sequences, can ultimately produce valid .. sequences due to a collapse into unsafe value (CWE-182).",::NATURE:ChildOf:CWE ID:23:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single . character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as / to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering / is insufficient protection if the filesystem also supports the use of as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if ../ sequences are removed from the .../...// string in a sequential fashion, two instances of ../ would be removed from the original string, but the remaining characters would still form the ../ string.:EFFECTIVENESS:High::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2001-0467:DESCRIPTION:... in web server:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0467::REFERENCE:CVE-2001-0615:DESCRIPTION:... or .... in chat server:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0615::REFERENCE:CVE-2001-0963:DESCRIPTION:... in cd command in FTP server:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0963::REFERENCE:CVE-2001-1193:DESCRIPTION:... in cd command in FTP server:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1193::REFERENCE:CVE-2001-1131:DESCRIPTION:... in cd command in FTP server:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1131::REFERENCE:CVE-2001-0480:DESCRIPTION:read of arbitrary files and directories using GET or CD with ... in Windows-based FTP server.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0480::REFERENCE:CVE-2002-0288:DESCRIPTION:read files using . and Unicode-encoded / or characters in the URL.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0288::REFERENCE:CVE-2003-0313:DESCRIPTION:Directory listing of web server using ...:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0313::REFERENCE:CVE-2005-1658:DESCRIPTION:Triple dot:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1658::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:'...' (triple dot)::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"::TYPE:Maintenance:NOTE:This manipulation-focused entry is currently hiding two distinct weaknesses, so it might need to be split. The manipulation is effective in two different contexts: it is equivalent to .... on Windows, or it can take advantage of incomplete filtering, e.g. if the programmer does a single-pass removal of ./ in a string (collapse of data into unsafe value, CWE-182).::",
+33,"Path Traversal: '....' (Multiple Dot)",Variant,Incomplete,"The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '....' (multiple dot) sequences that can resolve to a location that is outside of that directory.","This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory. The '....' manipulation is useful for bypassing some path traversal protection schemes. On some Windows systems, it is equivalent to ...... and might bypass checks that assume only two dots are valid. Incomplete filtering, such as removal of ./ sequences, can ultimately produce valid .. sequences due to a collapse into unsafe value (CWE-182).",::NATURE:ChildOf:CWE ID:23:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single . character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as / to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering / is insufficient protection if the filesystem also supports the use of as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if ../ sequences are removed from the .../...// string in a sequential fashion, two instances of ../ would be removed from the original string, but the remaining characters would still form the ../ string.:EFFECTIVENESS:High::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2000-0240:DESCRIPTION:read files via /........../ in URL:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0240::REFERENCE:CVE-2000-0773:DESCRIPTION:read files via .... in web server:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0773::REFERENCE:CVE-1999-1082:DESCRIPTION:read files via ...... in web server (doubled triple dot?):LINK:https://www.cve.org/CVERecord?id=CVE-1999-1082::REFERENCE:CVE-2004-2121:DESCRIPTION:read files via ...... in web server (doubled triple dot?):LINK:https://www.cve.org/CVERecord?id=CVE-2004-2121::REFERENCE:CVE-2001-0491:DESCRIPTION:multiple attacks using .., ..., and .... in different commands:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0491::REFERENCE:CVE-2001-0615:DESCRIPTION:... or .... in chat server:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0615::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:'....' (multiple dot)::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"::TYPE:Maintenance:NOTE:Like the triple-dot CWE-32, this manipulation probably hides multiple weaknesses that should be made more explicit.::",
+34,"Path Traversal: '....//'",Variant,Incomplete,"The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '....//' (doubled dot dot slash) sequences that can resolve to a location that is outside of that directory.","This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory. The '....//' manipulation is useful for bypassing some path traversal protection schemes. If ../ is filtered in a sequential fashion, as done by some regular expression engines, then ....// can collapse into the ../ unsafe value (CWE-182). It could also be useful when .. is removed, if the operating system treats // and / as equivalent.",::NATURE:ChildOf:CWE ID:23:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","::METHOD:Automated Static Analysis - Source Code:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer:EFFECTIVENESS:SOAR Partial::METHOD:Architecture or Design Review:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.) Formal Methods / Correct-By-Construction:EFFECTIVENESS:High::","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single . character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as / to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering / is insufficient protection if the filesystem also supports the use of as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if ../ sequences are removed from the .../...// string in a sequential fashion, two instances of ../ would be removed from the original string, but the remaining characters would still form the ../ string.:EFFECTIVENESS:High::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2004-1670:DESCRIPTION:Mail server allows remote attackers to create arbitrary directories via a .. or rename arbitrary files via a ....// in user supplied parameters.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1670::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:'....//' (doubled dot dot slash)::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"::TYPE:Relationship:NOTE:This could occur due to a cleansing error that removes a single ../ from ....//::",
+35,"Path Traversal: '.../...//'",Variant,Incomplete,"The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '.../...//' (doubled triple dot slash) sequences that can resolve to a location that is outside of that directory.","This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory. The '.../...//' manipulation is useful for bypassing some path traversal protection schemes. If ../ is filtered in a sequential fashion, as done by some regular expression engines, then .../...// can collapse into the ../ unsafe value (CWE-182). Removing the first ../ yields ....//; the second removal yields ../. Depending on the algorithm, the product could be susceptible to CWE-34 but not CWE-35, or vice versa.",::NATURE:ChildOf:CWE ID:23:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single . character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as / to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering / is insufficient protection if the filesystem also supports the use of as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if ../ sequences are removed from the .../...// string in a sequential fashion, two instances of ../ would be removed from the original string, but the remaining characters would still form the ../ string.:EFFECTIVENESS:High::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2005-2169:DESCRIPTION:chain: .../...// bypasses protection mechanism using regexp's that remove ../ resulting in collapse into an unsafe value ../ (CWE-182) and resultant path traversal.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-2169::REFERENCE:CVE-2005-0202:DESCRIPTION:.../..../// bypasses regexp's that remove ./ and ../:LINK:https://www.cve.org/CVERecord?id=CVE-2005-0202::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:'.../...//'::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"",
+36,"Absolute Path Traversal",Base,Draft,"The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize absolute path sequences such as /abs/path that can resolve to a location that is outside of that directory.","This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory.",::NATURE:ChildOf:CWE ID:22:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:22:VIEW ID:1305:ORDINAL:Primary::NATURE:ChildOf:CWE ID:22:VIEW ID:1340:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:IMPACT:Execute Unauthorized Code or Commands:NOTE:The attacker may be able to create or overwrite critical files that are used to execute code, such as programs or libraries.::SCOPE:Integrity:IMPACT:Modify Files or Directories:NOTE:The attacker may be able to overwrite or create critical files, such as programs, libraries, or important data. If the targeted file is used for a security mechanism, then the attacker may be able to bypass that mechanism. For example, appending a new account at the end of a password file may allow an attacker to bypass authentication.::SCOPE:Confidentiality:IMPACT:Read Files or Directories:NOTE:The attacker may be able read the contents of unexpected files and expose sensitive data. If the targeted file is used for a security mechanism, then the attacker may be able to bypass that mechanism. For example, by reading a password file, the attacker could conduct brute force password guessing attacks in order to break into an account on the system.::SCOPE:Availability:IMPACT:DoS: Crash, Exit, or Restart:NOTE:The attacker may be able to overwrite, delete, or corrupt unexpected critical files such as programs, libraries, or important data. This may prevent the product from working at all and in the case of a protection mechanisms such as authentication, it has the potential to lockout every user of the product.::","::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","","::REFERENCE:CVE-2022-31503:DESCRIPTION:Python package constructs filenames using an unsafe os.path.join call on untrusted input, allowing absolute path traversal because os.path.join resets the pathname to an absolute path that is specified as part of the input.:LINK:https://www.cve.org/CVERecord?id=CVE-2022-31503::REFERENCE:CVE-2002-1345:DESCRIPTION:Multiple FTP clients write arbitrary files via absolute paths in server responses:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1345::REFERENCE:CVE-2001-1269:DESCRIPTION:ZIP file extractor allows full path:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1269::REFERENCE:CVE-2002-1818:DESCRIPTION:Path traversal using absolute pathname:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1818::REFERENCE:CVE-2002-1913:DESCRIPTION:Path traversal using absolute pathname:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1913::REFERENCE:CVE-2005-2147:DESCRIPTION:Path traversal using absolute pathname:LINK:https://www.cve.org/CVERecord?id=CVE-2005-2147::REFERENCE:CVE-2000-0614:DESCRIPTION:Arbitrary files may be overwritten via compressed attachments that specify absolute path names for the decompressed output.:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0614::REFERENCE:CVE-1999-1263:DESCRIPTION:Mail client allows remote attackers to overwrite arbitrary files via an e-mail message containing a uuencoded attachment that specifies the full pathname for the file to be modified.:LINK:https://www.cve.org/CVERecord?id=CVE-1999-1263::REFERENCE:CVE-2003-0753:DESCRIPTION:Remote attackers can read arbitrary files via a full pathname to the target file in config parameter.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0753::REFERENCE:CVE-2002-1525:DESCRIPTION:Remote attackers can read arbitrary files via an absolute pathname.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1525::REFERENCE:CVE-2001-0038:DESCRIPTION:Remote attackers can read arbitrary files by specifying the drive letter in the requested URL.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0038::REFERENCE:CVE-2001-0255:DESCRIPTION:FTP server allows remote attackers to list arbitrary directories by using the ls command and including the drive letter name (e.g. C:) in the requested pathname.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0255::REFERENCE:CVE-2001-0933:DESCRIPTION:FTP server allows remote attackers to list the contents of arbitrary drives via a ls command that includes the drive letter as an argument.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0933::REFERENCE:CVE-2002-0466:DESCRIPTION:Server allows remote attackers to browse arbitrary directories via a full pathname in the arguments to certain dynamic pages.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0466::REFERENCE:CVE-2002-1483:DESCRIPTION:Remote attackers can read arbitrary files via an HTTP request whose argument is a filename of the form C: (Drive letter), //absolute/path, or .. .:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1483::REFERENCE:CVE-2004-2488:DESCRIPTION:FTP server read/access arbitrary files using C: filenames:LINK:https://www.cve.org/CVERecord?id=CVE-2004-2488::REFERENCE:CVE-2001-0687:DESCRIPTION:FTP server allows a remote attacker to retrieve privileged web server system information by specifying arbitrary paths in the UNC format (computernamesharename).:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0687::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Absolute Path Traversal::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",::597::,"",
+37,"Path Traversal: '/absolute/pathname/here'",Variant,Draft,"The product accepts input in the form of a slash absolute path ('/absolute/pathname/here') without appropriate validation, which can allow an attacker to traverse the file system to unintended locations or access arbitrary files.","",::NATURE:ChildOf:CWE ID:36:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:160:VIEW ID:1000::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single . character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as / to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering / is insufficient protection if the filesystem also supports the use of as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if ../ sequences are removed from the .../...// string in a sequential fashion, two instances of ../ would be removed from the original string, but the remaining characters would still form the ../ string.:EFFECTIVENESS:High::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2002-1345:DESCRIPTION:Multiple FTP clients write arbitrary files via absolute paths in server responses:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1345::REFERENCE:CVE-2001-1269:DESCRIPTION:ZIP file extractor allows full path:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1269::REFERENCE:CVE-2002-1818:DESCRIPTION:Path traversal using absolute pathname:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1818::REFERENCE:CVE-2002-1913:DESCRIPTION:Path traversal using absolute pathname:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1913::REFERENCE:CVE-2005-2147:DESCRIPTION:Path traversal using absolute pathname:LINK:https://www.cve.org/CVERecord?id=CVE-2005-2147::REFERENCE:CVE-2000-0614:DESCRIPTION:Arbitrary files may be overwritten via compressed attachments that specify absolute path names for the decompressed output.:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0614::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:/absolute/pathname/here::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:FIO05-C:ENTRY NAME:Identify files using multiple file attributes::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"",
+38,"Path Traversal: 'absolutepathnamehere'",Variant,Draft,"The product accepts input in the form of a backslash absolute path ('absolutepathnamehere') without appropriate validation, which can allow an attacker to traverse the file system to unintended locations or access arbitrary files.","",::NATURE:ChildOf:CWE ID:36:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single . character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as / to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering / is insufficient protection if the filesystem also supports the use of as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if ../ sequences are removed from the .../...// string in a sequential fashion, two instances of ../ would be removed from the original string, but the remaining characters would still form the ../ string.:EFFECTIVENESS:High::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-1999-1263:DESCRIPTION:Mail client allows remote attackers to overwrite arbitrary files via an e-mail message containing a uuencoded attachment that specifies the full pathname for the file to be modified.:LINK:https://www.cve.org/CVERecord?id=CVE-1999-1263::REFERENCE:CVE-2003-0753:DESCRIPTION:Remote attackers can read arbitrary files via a full pathname to the target file in config parameter.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0753::REFERENCE:CVE-2002-1525:DESCRIPTION:Remote attackers can read arbitrary files via an absolute pathname.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1525::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:absolutepathnamehere ('backslash absolute path')::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:FIO05-C:ENTRY NAME:Identify files using multiple file attributes::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"",
+39,"Path Traversal: 'C:dirname'",Variant,Draft,"The product accepts input that contains a drive letter or Windows volume letter ('C:dirname') that potentially redirects access to an unintended location or arbitrary file.","",::NATURE:ChildOf:CWE ID:36:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:IMPACT:Execute Unauthorized Code or Commands:NOTE:The attacker may be able to create or overwrite critical files that are used to execute code, such as programs or libraries.::SCOPE:Integrity:IMPACT:Modify Files or Directories:NOTE:The attacker may be able to overwrite or create critical files, such as programs, libraries, or important data. If the targeted file is used for a security mechanism, then the attacker may be able to bypass that mechanism. For example, appending a new account at the end of a password file may allow an attacker to bypass authentication.::SCOPE:Confidentiality:IMPACT:Read Files or Directories:NOTE:The attacker may be able read the contents of unexpected files and expose sensitive data. If the targeted file is used for a security mechanism, then the attacker may be able to bypass that mechanism. For example, by reading a password file, the attacker could conduct brute force password guessing attacks in order to break into an account on the system.::SCOPE:Availability:IMPACT:DoS: Crash, Exit, or Restart:NOTE:The attacker may be able to overwrite, delete, or corrupt unexpected critical files such as programs, libraries, or important data. This may prevent the software from working at all and in the case of a protection mechanisms such as authentication, it has the potential to lockout every user of the software.::","","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single . character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as / to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering / is insufficient protection if the filesystem also supports the use of as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if ../ sequences are removed from the .../...// string in a sequential fashion, two instances of ../ would be removed from the original string, but the remaining characters would still form the ../ string.:EFFECTIVENESS:High::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2001-0038:DESCRIPTION:Remote attackers can read arbitrary files by specifying the drive letter in the requested URL.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0038::REFERENCE:CVE-2001-0255:DESCRIPTION:FTP server allows remote attackers to list arbitrary directories by using the ls command and including the drive letter name (e.g. C:) in the requested pathname.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0255::REFERENCE:CVE-2001-0687:DESCRIPTION:FTP server allows a remote attacker to retrieve privileged system information by specifying arbitrary paths.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0687::REFERENCE:CVE-2001-0933:DESCRIPTION:FTP server allows remote attackers to list the contents of arbitrary drives via a ls command that includes the drive letter as an argument.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0933::REFERENCE:CVE-2002-0466:DESCRIPTION:Server allows remote attackers to browse arbitrary directories via a full pathname in the arguments to certain dynamic pages.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0466::REFERENCE:CVE-2002-1483:DESCRIPTION:Remote attackers can read arbitrary files via an HTTP request whose argument is a filename of the form C: (Drive letter), //absolute/path, or .. .:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1483::REFERENCE:CVE-2004-2488:DESCRIPTION:FTP server read/access arbitrary files using C: filenames:LINK:https://www.cve.org/CVERecord?id=CVE-2004-2488::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:'C:dirname' or C: (Windows volume or 'drive letter')::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:FIO05-C:ENTRY NAME:Identify files using multiple file attributes::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"",
+40,"Path Traversal: 'UNCsharename' (Windows UNC Share)",Variant,Draft,"The product accepts input that identifies a Windows UNC share ('UNCsharename') that potentially redirects access to an unintended location or arbitrary file.","",::NATURE:ChildOf:CWE ID:36:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single . character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as / to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering / is insufficient protection if the filesystem also supports the use of as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if ../ sequences are removed from the .../...// string in a sequential fashion, two instances of ../ would be removed from the original string, but the remaining characters would still form the ../ string.:EFFECTIVENESS:High::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2001-0687:DESCRIPTION:FTP server allows a remote attacker to retrieve privileged web server system information by specifying arbitrary paths in the UNC format (computernamesharename).:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0687::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:'UNCsharename' (Windows UNC share)::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"",
+41,"Improper Resolution of Path Equivalence",Base,Incomplete,"The product is vulnerable to file system contents disclosure through path equivalence. Path equivalence involves the use of special characters in file and directory names. The associated manipulations are intended to generate multiple names for the same object.","Path equivalence is usually employed in order to circumvent access controls expressed using an incomplete set of file name or file path representations. This is different from path traversal, wherein the manipulations are performed to generate a name for a different object.",::NATURE:ChildOf:CWE ID:706:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Access Control:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories:IMPACT:Bypass Protection Mechanism:NOTE:An attacker may be able to traverse the file system to unintended locations and read or overwrite the contents of unexpected files. If the files are used for a security mechanism than an attacker may be able to bypass the mechanism.::","::METHOD:Automated Static Analysis - Binary or Bytecode:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Bytecode Weakness Analysis - including disassembler + source code weakness analysis:EFFECTIVENESS:SOAR Partial::METHOD:Manual Static Analysis - Binary or Bytecode:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies:EFFECTIVENESS:SOAR Partial::METHOD:Dynamic Analysis with Automated Results Interpretation:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Web Application Scanner Web Services Scanner Database Scanners:EFFECTIVENESS:SOAR Partial::METHOD:Dynamic Analysis with Manual Results Interpretation:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Fuzz Tester Framework-based Fuzzer:EFFECTIVENESS:SOAR Partial::METHOD:Manual Static Analysis - Source Code:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Focused Manual Spotcheck - Focused manual analysis of source Manual Source Code Review (not inspections):EFFECTIVENESS:High::METHOD:Automated Static Analysis - Source Code:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer:EFFECTIVENESS:SOAR Partial::METHOD:Architecture or Design Review:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Formal Methods / Correct-By-Construction Cost effective for partial coverage: Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.):EFFECTIVENESS:High::","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.::PHASE:Implementation:STRATEGY:Output Encoding:DESCRIPTION:Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2000-1114:DESCRIPTION:Source code disclosure using trailing dot:LINK:https://www.cve.org/CVERecord?id=CVE-2000-1114::REFERENCE:CVE-2002-1986:DESCRIPTION:Source code disclosure using trailing dot:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1986::REFERENCE:CVE-2004-2213:DESCRIPTION:Source code disclosure using trailing dot or trailing encoding space %20:LINK:https://www.cve.org/CVERecord?id=CVE-2004-2213::REFERENCE:CVE-2005-3293:DESCRIPTION:Source code disclosure using trailing dot:LINK:https://www.cve.org/CVERecord?id=CVE-2005-3293::REFERENCE:CVE-2004-0061:DESCRIPTION:Bypass directory access restrictions using trailing dot in URL:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0061::REFERENCE:CVE-2000-1133:DESCRIPTION:Bypass directory access restrictions using trailing dot in URL:LINK:https://www.cve.org/CVERecord?id=CVE-2000-1133::REFERENCE:CVE-2001-1386:DESCRIPTION:Bypass check for .lnk extension using .lnk.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1386::REFERENCE:CVE-2001-0693:DESCRIPTION:Source disclosure via trailing encoded space %20:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0693::REFERENCE:CVE-2001-0778:DESCRIPTION:Source disclosure via trailing encoded space %20:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0778::REFERENCE:CVE-2001-1248:DESCRIPTION:Source disclosure via trailing encoded space %20:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1248::REFERENCE:CVE-2004-0280:DESCRIPTION:Source disclosure via trailing encoded space %20:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0280::REFERENCE:CVE-2005-0622:DESCRIPTION:Source disclosure via trailing encoded space %20:LINK:https://www.cve.org/CVERecord?id=CVE-2005-0622::REFERENCE:CVE-2005-1656:DESCRIPTION:Source disclosure via trailing encoded space %20:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1656::REFERENCE:CVE-2002-1603:DESCRIPTION:Source disclosure via trailing encoded space %20:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1603::REFERENCE:CVE-2001-0054:DESCRIPTION:Multi-Factor Vulnerability (MFV). directory traversal and other issues in FTP server using Web encodings such as %20; certain manipulations have unusual side effects.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0054::REFERENCE:CVE-2002-1451:DESCRIPTION:Trailing space (+ in query string) leads to source code disclosure.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1451::REFERENCE:CVE-2000-0293:DESCRIPTION:Filenames with spaces allow arbitrary file deletion when the product does not properly quote them; some overlap with path traversal.:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0293::REFERENCE:CVE-2001-1567:DESCRIPTION:+ characters in query string converted to spaces before sensitive file/extension (internal space), leading to bypass of access restrictions to the file.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1567::REFERENCE:CVE-2002-0253:DESCRIPTION:Overlaps infoleak:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0253::REFERENCE:CVE-2001-0446:DESCRIPTION:Application server allows remote attackers to read source code for .jsp files by appending a / to the requested URL.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0446::REFERENCE:CVE-2004-0334:DESCRIPTION:Bypass Basic Authentication for files using trailing /:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0334::REFERENCE:CVE-2001-0893:DESCRIPTION:Read sensitive files with trailing /:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0893::REFERENCE:CVE-2001-0892:DESCRIPTION:Web server allows remote attackers to view sensitive files under the document root (such as .htpasswd) via a GET request with a trailing /.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0892::REFERENCE:CVE-2004-1814:DESCRIPTION:Directory traversal vulnerability in server allows remote attackers to read protected files via .. (dot dot) sequences in an HTTP request.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1814::REFERENCE:CVE-2002-1483:DESCRIPTION:Read files with full pathname using multiple internal slash.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1483::REFERENCE:CVE-1999-1456:DESCRIPTION:Server allows remote attackers to read arbitrary files via a GET request with more than one leading / (slash) character in the filename.:LINK:https://www.cve.org/CVERecord?id=CVE-1999-1456::REFERENCE:CVE-2004-0578:DESCRIPTION:Server allows remote attackers to read arbitrary files via leading slash (//) characters in a URL request.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0578::REFERENCE:CVE-2002-0275:DESCRIPTION:Server allows remote attackers to bypass authentication and read restricted files via an extra / (slash) in the requested URL.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0275::REFERENCE:CVE-2004-1032:DESCRIPTION:Product allows local users to delete arbitrary files or create arbitrary empty files via a target filename with a large number of leading slash (/) characters.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1032::REFERENCE:CVE-2002-1238:DESCRIPTION:Server allows remote attackers to bypass access restrictions for files via an HTTP request with a sequence of multiple / (slash) characters such as http://www.example.com///file/.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1238::REFERENCE:CVE-2004-1878:DESCRIPTION:Product allows remote attackers to bypass authentication, obtain sensitive information, or gain access via a direct request to admin/user.pl preceded by // (double leading slash).:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1878::REFERENCE:CVE-2005-1365:DESCRIPTION:Server allows remote attackers to execute arbitrary commands via a URL with multiple leading / (slash) characters and .. sequences.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1365::REFERENCE:CVE-2000-1050:DESCRIPTION:Access directory using multiple leading slash.:LINK:https://www.cve.org/CVERecord?id=CVE-2000-1050::REFERENCE:CVE-2001-1072:DESCRIPTION:Bypass access restrictions via multiple leading slash, which causes a regular expression to fail.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1072::REFERENCE:CVE-2004-0235:DESCRIPTION:Archive extracts to arbitrary files using multiple leading slash in filenames in the archive.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0235::REFERENCE:CVE-2002-1078:DESCRIPTION:Directory listings in web server using multiple trailing slash:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1078::REFERENCE:CVE-2004-0847:DESCRIPTION:ASP.NET allows remote attackers to bypass authentication for .aspx files in restricted directories via a request containing a (1) (backslash) or (2) %5C (encoded backslash), aka Path Validation Vulnerability.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0847::REFERENCE:CVE-2000-0004:DESCRIPTION:Server allows remote attackers to read source code for executable files by inserting a . (dot) into the URL.:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0004::REFERENCE:CVE-2002-0304:DESCRIPTION:Server allows remote attackers to read password-protected files via a /./ in the HTTP request.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0304::REFERENCE:CVE-1999-1083:DESCRIPTION:Possibly (could be a cleansing error):LINK:https://www.cve.org/CVERecord?id=CVE-1999-1083::REFERENCE:CVE-2004-0815:DESCRIPTION:/./////etc cleansed to .///etc then /etc:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0815::REFERENCE:CVE-2002-0112:DESCRIPTION:Server allows remote attackers to view password protected files via /./ in the URL.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0112::REFERENCE:CVE-2004-0696:DESCRIPTION:List directories using desired path and *:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0696::REFERENCE:CVE-2002-0433:DESCRIPTION:List files in web server using *.ext:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0433::REFERENCE:CVE-2001-1152:DESCRIPTION:Proxy allows remote attackers to bypass denylist restrictions and connect to unauthorized web servers by modifying the requested URL, including (1) a // (double slash), (2) a /SUBDIR/.. where the desired file is in the parentdir, (3) a /./, or (4) URL-encoded characters.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1152::REFERENCE:CVE-2000-0191:DESCRIPTION:application check access for restricted URL before canonicalization:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0191::REFERENCE:CVE-2005-1366:DESCRIPTION:CGI source disclosure using dirname/../cgi-bin:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1366::REFERENCE:CVE-1999-0012:DESCRIPTION:Multiple web servers allow restriction bypass using 8.3 names instead of long names:LINK:https://www.cve.org/CVERecord?id=CVE-1999-0012::REFERENCE:CVE-2001-0795:DESCRIPTION:Source code disclosure using 8.3 file name.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0795::REFERENCE:CVE-2005-0471:DESCRIPTION:Multi-Factor Vulnerability. Product generates temporary filenames using long filenames, which become predictable in 8.3 format.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-0471::",,::File or Directory::,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Path Equivalence::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:FIO02-C:ENTRY NAME:Canonicalize path names originating from untrusted sources::",::3::,"::TYPE:Relationship:NOTE:Some of these manipulations could be effective in path traversal issues, too.::",
+42,"Path Equivalence: 'filename.' (Trailing Dot)",Variant,Incomplete,"The product accepts path input in the form of trailing dot ('filedir.') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.","",::NATURE:ChildOf:CWE ID:41:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:162:VIEW ID:1000::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Access Control:IMPACT:Bypass Protection Mechanism::","","","::REFERENCE:CVE-2000-1114:DESCRIPTION:Source code disclosure using trailing dot:LINK:https://www.cve.org/CVERecord?id=CVE-2000-1114::REFERENCE:CVE-2002-1986:DESCRIPTION:Source code disclosure using trailing dot:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1986::REFERENCE:CVE-2004-2213:DESCRIPTION:Source code disclosure using trailing dot:LINK:https://www.cve.org/CVERecord?id=CVE-2004-2213::REFERENCE:CVE-2005-3293:DESCRIPTION:Source code disclosure using trailing dot:LINK:https://www.cve.org/CVERecord?id=CVE-2005-3293::REFERENCE:CVE-2004-0061:DESCRIPTION:Bypass directory access restrictions using trailing dot in URL:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0061::REFERENCE:CVE-2000-1133:DESCRIPTION:Bypass directory access restrictions using trailing dot in URL:LINK:https://www.cve.org/CVERecord?id=CVE-2000-1133::REFERENCE:CVE-2001-1386:DESCRIPTION:Bypass check for .lnk extension using .lnk.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1386::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Trailing Dot - 'filedir.'::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"",
+43,"Path Equivalence: 'filename....' (Multiple Trailing Dot)",Variant,Incomplete,"The product accepts path input in the form of multiple trailing dot ('filedir....') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.","",::NATURE:ChildOf:CWE ID:42:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:163:VIEW ID:1000::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","","::REFERENCE:CVE-2004-0281:DESCRIPTION:Multiple trailing dot allows directory listing:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0281::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Multiple Trailing Dot - 'filedir....'::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"",
+44,"Path Equivalence: 'file.name' (Internal Dot)",Variant,Incomplete,"The product accepts path input in the form of internal dot ('file.ordir') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.","",::NATURE:ChildOf:CWE ID:41:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","","",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Internal Dot - 'file.ordir'::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"::TYPE:Relationship:NOTE:An improper attempt to remove the internal dots from the string could lead to CWE-181 (Incorrect Behavior Order: Validate Before Filter).::",
+45,"Path Equivalence: 'file...name' (Multiple Internal Dot)",Variant,Incomplete,"The product accepts path input in the form of multiple internal dot ('file...dir') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.","",::NATURE:ChildOf:CWE ID:44:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:165:VIEW ID:1000::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","","",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Multiple Internal Dot - 'file...dir'::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"::TYPE:Relationship:NOTE:An improper attempt to remove the internal dots from the string could lead to CWE-181 (Incorrect Behavior Order: Validate Before Filter).::",
+46,"Path Equivalence: 'filename ' (Trailing Space)",Variant,Incomplete,"The product accepts path input in the form of trailing space ('filedir ') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.","",::NATURE:ChildOf:CWE ID:41:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:162:VIEW ID:1000::NATURE:CanPrecede:CWE ID:289:VIEW ID:1000::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","","::REFERENCE:CVE-2001-0693:DESCRIPTION:Source disclosure via trailing encoded space %20:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0693::REFERENCE:CVE-2001-0778:DESCRIPTION:Source disclosure via trailing encoded space %20:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0778::REFERENCE:CVE-2001-1248:DESCRIPTION:Source disclosure via trailing encoded space %20:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1248::REFERENCE:CVE-2004-0280:DESCRIPTION:Source disclosure via trailing encoded space %20:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0280::REFERENCE:CVE-2004-2213:DESCRIPTION:Source disclosure via trailing encoded space %20:LINK:https://www.cve.org/CVERecord?id=CVE-2004-2213::REFERENCE:CVE-2005-0622:DESCRIPTION:Source disclosure via trailing encoded space %20:LINK:https://www.cve.org/CVERecord?id=CVE-2005-0622::REFERENCE:CVE-2005-1656:DESCRIPTION:Source disclosure via trailing encoded space %20:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1656::REFERENCE:CVE-2002-1603:DESCRIPTION:Source disclosure via trailing encoded space %20:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1603::REFERENCE:CVE-2001-0054:DESCRIPTION:Multi-Factor Vulnerability (MFV). directory traversal and other issues in FTP server using Web encodings such as %20; certain manipulations have unusual side effects.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0054::REFERENCE:CVE-2002-1451:DESCRIPTION:Trailing space (+ in query string) leads to source code disclosure.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1451::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Trailing Space - 'filedir '::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",::649::,"",
+47,"Path Equivalence: ' filename' (Leading Space)",Variant,Incomplete,"The product accepts path input in the form of leading space (' filedir') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.","",::NATURE:ChildOf:CWE ID:41:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","","",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Leading Space - ' filedir'::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"",
+48,"Path Equivalence: 'file name' (Internal Whitespace)",Variant,Incomplete,"The product accepts path input in the form of internal space ('file(SPACE)name') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.","",::NATURE:ChildOf:CWE ID:41:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","","::REFERENCE:CVE-2000-0293:DESCRIPTION:Filenames with spaces allow arbitrary file deletion when the product does not properly quote them; some overlap with path traversal.:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0293::REFERENCE:CVE-2001-1567:DESCRIPTION:+ characters in query string converted to spaces before sensitive file/extension (internal space), leading to bypass of access restrictions to the file.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1567::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:file(SPACE)name (internal space)::TAXONOMY NAME:OWASP Top Ten 2004:ENTRY ID:A9:ENTRY NAME:Denial of Service:MAPPING FIT:CWE More Specific::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"::TYPE:Relationship:NOTE:This weakness is likely to overlap quoting problems, e.g. the Program Files unquoted search path (CWE-428). It also could be an equivalence issue if filtering removes all extraneous spaces.::TYPE:Relationship:NOTE:Whitespace can be a factor in other weaknesses not directly related to equivalence. It can also be used to spoof icons or hide files with dangerous names (see icon manipulation and visual truncation in CWE-451).::",
+49,"Path Equivalence: 'filename/' (Trailing Slash)",Variant,Incomplete,"The product accepts path input in the form of trailing slash ('filedir/') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.","",::NATURE:ChildOf:CWE ID:41:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:162:VIEW ID:1000::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::PHASE:Operation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","","::REFERENCE:CVE-2002-0253:DESCRIPTION:Overlaps infoleak:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0253::REFERENCE:CVE-2001-0446:DESCRIPTION:Application server allows remote attackers to read source code for .jsp files by appending a / to the requested URL.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0446::REFERENCE:CVE-2004-0334:DESCRIPTION:Bypass Basic Authentication for files using trailing /:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0334::REFERENCE:CVE-2001-0893:DESCRIPTION:Read sensitive files with trailing /:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0893::REFERENCE:CVE-2001-0892:DESCRIPTION:Web server allows remote attackers to view sensitive files under the document root (such as .htpasswd) via a GET request with a trailing /.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0892::REFERENCE:CVE-2004-1814:DESCRIPTION:Directory traversal vulnerability in server allows remote attackers to read protected files via .. (dot dot) sequences in an HTTP request.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1814::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:filedir/ (trailing slash, trailing /)::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"",
+50,"Path Equivalence: '//multiple/leading/slash'",Variant,Incomplete,"The product accepts path input in the form of multiple leading slash ('//multiple/leading/slash') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.","",::NATURE:ChildOf:CWE ID:41:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:161:VIEW ID:1000::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","","::REFERENCE:CVE-2002-1483:DESCRIPTION:Read files with full pathname using multiple internal slash.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1483::REFERENCE:CVE-1999-1456:DESCRIPTION:Server allows remote attackers to read arbitrary files via a GET request with more than one leading / (slash) character in the filename.:LINK:https://www.cve.org/CVERecord?id=CVE-1999-1456::REFERENCE:CVE-2004-0578:DESCRIPTION:Server allows remote attackers to read arbitrary files via leading slash (//) characters in a URL request.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0578::REFERENCE:CVE-2002-0275:DESCRIPTION:Server allows remote attackers to bypass authentication and read restricted files via an extra / (slash) in the requested URL.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0275::REFERENCE:CVE-2004-1032:DESCRIPTION:Product allows local users to delete arbitrary files or create arbitrary empty files via a target filename with a large number of leading slash (/) characters.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1032::REFERENCE:CVE-2002-1238:DESCRIPTION:Server allows remote attackers to bypass access restrictions for files via an HTTP request with a sequence of multiple / (slash) characters such as http://www.example.com///file/.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1238::REFERENCE:CVE-2004-1878:DESCRIPTION:Product allows remote attackers to bypass authentication, obtain sensitive information, or gain access via a direct request to admin/user.pl preceded by // (double leading slash).:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1878::REFERENCE:CVE-2005-1365:DESCRIPTION:Server allows remote attackers to execute arbitrary commands via a URL with multiple leading / (slash) characters and .. sequences.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1365::REFERENCE:CVE-2000-1050:DESCRIPTION:Access directory using multiple leading slash.:LINK:https://www.cve.org/CVERecord?id=CVE-2000-1050::REFERENCE:CVE-2001-1072:DESCRIPTION:Bypass access restrictions via multiple leading slash, which causes a regular expression to fail.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1072::REFERENCE:CVE-2004-0235:DESCRIPTION:Archive extracts to arbitrary files using multiple leading slash in filenames in the archive.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0235::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME://multiple/leading/slash ('multiple leading slash')::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"",
+51,"Path Equivalence: '/multiple//internal/slash'",Variant,Incomplete,"The product accepts path input in the form of multiple internal slash ('/multiple//internal/slash/') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.","",::NATURE:ChildOf:CWE ID:41:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2002-1483:DESCRIPTION:Read files with full pathname using multiple internal slash.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1483::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:/multiple//internal/slash ('multiple internal slash')::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"",
+52,"Path Equivalence: '/multiple/trailing/slash//'",Variant,Incomplete,"The product accepts path input in the form of multiple trailing slash ('/multiple/trailing/slash//') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.","",::NATURE:ChildOf:CWE ID:41:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:163:VIEW ID:1000::NATURE:CanPrecede:CWE ID:289:VIEW ID:1000::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2002-1078:DESCRIPTION:Directory listings in web server using multiple trailing slash:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1078::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:/multiple/trailing/slash// ('multiple trailing slash')::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"",
+53,"Path Equivalence: 'multipleinternalbackslash'",Variant,Incomplete,"The product accepts path input in the form of multiple internal backslash ('multipletrailingslash') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.","",::NATURE:ChildOf:CWE ID:41:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:165:VIEW ID:1000::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:multipleinternalbackslash::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"",
+54,"Path Equivalence: 'filedir' (Trailing Backslash)",Variant,Incomplete,"The product accepts path input in the form of trailing backslash ('filedir') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.","",::NATURE:ChildOf:CWE ID:41:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:162:VIEW ID:1000::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2004-0847:DESCRIPTION:web framework for .NET allows remote attackers to bypass authentication for .aspx files in restricted directories via a request containing a (1) (backslash) or (2) %5C (encoded backslash):LINK:https://www.cve.org/CVERecord?id=CVE-2004-0847::REFERENCE:CVE-2004-0061:DESCRIPTION:Bypass directory access restrictions using trailing dot in URL:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0061::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:filedir (trailing backslash)::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"",
+55,"Path Equivalence: '/./' (Single Dot Directory)",Variant,Incomplete,"The product accepts path input in the form of single dot directory exploit ('/./') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.","",::NATURE:ChildOf:CWE ID:41:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2000-0004:DESCRIPTION:Server allows remote attackers to read source code for executable files by inserting a . (dot) into the URL.:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0004::REFERENCE:CVE-2002-0304:DESCRIPTION:Server allows remote attackers to read password-protected files via a /./ in the HTTP request.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0304::REFERENCE:CVE-1999-1083:DESCRIPTION:Possibly (could be a cleansing error):LINK:https://www.cve.org/CVERecord?id=CVE-1999-1083::REFERENCE:CVE-2004-0815:DESCRIPTION:/./////etc cleansed to .///etc then /etc:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0815::REFERENCE:CVE-2002-0112:DESCRIPTION:Server allows remote attackers to view password protected files via /./ in the URL.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0112::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:/./ (single dot directory)::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"",
+56,"Path Equivalence: 'filedir*' (Wildcard)",Variant,Incomplete,"The product accepts path input in the form of asterisk wildcard ('filedir*') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.","",::NATURE:ChildOf:CWE ID:41:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:155:VIEW ID:1000::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2004-0696:DESCRIPTION:List directories using desired path and *:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0696::REFERENCE:CVE-2002-0433:DESCRIPTION:List files in web server using *.ext:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0433::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:filedir* (asterisk / wildcard)::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"",
+57,"Path Equivalence: 'fakedir/../realdir/filename'",Variant,Incomplete,"The product contains protection mechanisms to restrict access to 'realdir/filename', but it constructs pathnames using external input in the form of 'fakedir/../realdir/filename' that are not handled by those mechanisms. This allows attackers to perform unauthorized actions against the targeted file.","",::NATURE:ChildOf:CWE ID:41:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2001-1152:DESCRIPTION:Proxy allows remote attackers to bypass denylist restrictions and connect to unauthorized web servers by modifying the requested URL, including (1) a // (double slash), (2) a /SUBDIR/.. where the desired file is in the parentdir, (3) a /./, or (4) URL-encoded characters.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1152::REFERENCE:CVE-2000-0191:DESCRIPTION:application check access for restricted URL before canonicalization:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0191::REFERENCE:CVE-2005-1366:DESCRIPTION:CGI source disclosure using dirname/../cgi-bin:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1366::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:dirname/fakechild/../realchild/filename::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"::TYPE:Theoretical:NOTE:This is a manipulation that uses an injection for one consequence (containment violation using relative path) to achieve a different consequence (equivalence by alternate name).::",
+58,"Path Equivalence: Windows 8.3 Filename",Variant,Incomplete,"The product contains a protection mechanism that restricts access to a long filename on a Windows operating system, but it does not properly restrict access to the equivalent short 8.3 filename.","On later Windows operating systems, a file can have a long name and a short name that is compatible with older Windows file systems, with up to 8 characters in the filename and 3 characters for the extension. These 8.3 filenames, therefore, act as an alternate name for files with long names, so they are useful pathname equivalence manipulations.",::NATURE:ChildOf:CWE ID:41:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Windows:OPERATING SYSTEM PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","::PHASE:System Configuration:DESCRIPTION:Disable Windows from supporting 8.3 filenames by editing the Windows registry. Preventing 8.3 filenames will not remove previously generated 8.3 filenames.::","::REFERENCE:CVE-1999-0012:DESCRIPTION:Multiple web servers allow restriction bypass using 8.3 names instead of long names:LINK:https://www.cve.org/CVERecord?id=CVE-1999-0012::REFERENCE:CVE-2001-0795:DESCRIPTION:Source code disclosure using 8.3 file name.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0795::REFERENCE:CVE-2005-0471:DESCRIPTION:Multi-Factor Vulnerability. Product generates temporary filenames using long filenames, which become predictable in 8.3 format.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-0471::",::File Processing::,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Windows 8.3 Filename::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"::TYPE:Research Gap:NOTE:Probably under-studied.::",
+59,"Improper Link Resolution Before File Access ('Link Following')",Base,Draft,"The product attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.","",::NATURE:ChildOf:CWE ID:706:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:706:VIEW ID:1003:ORDINAL:Primary::,"::ORDINALITY:Resultant::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Windows:OPERATING SYSTEM PREVALENCE:Sometimes::OPERATING SYSTEM CLASS:Unix:OPERATING SYSTEM PREVALENCE:Often::,"::Soft links are a UNIX term that is synonymous with simple shortcuts on Windows-based platforms.::","::TERM:insecure temporary file:DESCRIPTION:Some people use the phrase insecure temporary file when referring to a link following weakness, but other weaknesses can produce insecure temporary files without any symlink involvement at all.::TERM:Zip Slip:DESCRIPTION:Zip slip is an attack that uses file archives (e.g., ZIP, tar, rar, etc.) that contain filenames with path traversal sequences that cause the files to be written outside of the directory under which the archive is expected to be extracted [REF-1282]. It is most commonly used for relative path traversal (CWE-23) and link following (CWE-59).::","::PHASE:Implementation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Access Control:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories:IMPACT:Bypass Protection Mechanism:NOTE:An attacker may be able to traverse the file system to unintended locations and read or overwrite the contents of unexpected files. If the files are used for a security mechanism then an attacker may be able to bypass the mechanism.::SCOPE:Other:IMPACT:Execute Unauthorized Code or Commands:NOTE:Windows simple shortcuts, sometimes referred to as soft links, can be exploited remotely since a .LNK file can be uploaded like a normal file. This can enable remote execution.::","::METHOD:Automated Static Analysis - Binary or Bytecode:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Bytecode Weakness Analysis - including disassembler + source code weakness analysis:EFFECTIVENESS:SOAR Partial::METHOD:Manual Static Analysis - Binary or Bytecode:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies:EFFECTIVENESS:SOAR Partial::METHOD:Dynamic Analysis with Automated Results Interpretation:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Web Application Scanner Web Services Scanner Database Scanners:EFFECTIVENESS:SOAR Partial::METHOD:Dynamic Analysis with Manual Results Interpretation:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Fuzz Tester Framework-based Fuzzer:EFFECTIVENESS:SOAR Partial::METHOD:Manual Static Analysis - Source Code:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Focused Manual Spotcheck - Focused manual analysis of source Manual Source Code Review (not inspections):EFFECTIVENESS:High::METHOD:Automated Static Analysis - Source Code:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer:EFFECTIVENESS:SOAR Partial::METHOD:Architecture or Design Review:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Formal Methods / Correct-By-Construction Cost effective for partial coverage: Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.):EFFECTIVENESS:High::","::PHASE:Architecture and Design:STRATEGY:Separation of Privilege:DESCRIPTION:Follow the principle of least privilege when assigning access rights to entities in a software system. Denying access to a file can prevent an attacker from replacing that file with a link to a sensitive file. Ensure good compartmentalization in the system to provide protected areas that can be trusted.::","::REFERENCE:CVE-1999-1386:DESCRIPTION:Some versions of Perl follow symbolic links when running with the -e option, which allows local users to overwrite arbitrary files via a symlink attack.:LINK:https://www.cve.org/CVERecord?id=CVE-1999-1386::REFERENCE:CVE-2000-1178:DESCRIPTION:Text editor follows symbolic links when creating a rescue copy during an abnormal exit, which allows local users to overwrite the files of other users.:LINK:https://www.cve.org/CVERecord?id=CVE-2000-1178::REFERENCE:CVE-2004-0217:DESCRIPTION:Antivirus update allows local users to create or append to arbitrary files via a symlink attack on a logfile.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0217::REFERENCE:CVE-2003-0517:DESCRIPTION:Symlink attack allows local users to overwrite files.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0517::REFERENCE:CVE-2004-0689:DESCRIPTION:Window manager does not properly handle when certain symbolic links point to stale locations, which could allow local users to create or truncate arbitrary files.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0689::REFERENCE:CVE-2005-1879:DESCRIPTION:Second-order symlink vulnerabilities:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1879::REFERENCE:CVE-2005-1880:DESCRIPTION:Second-order symlink vulnerabilities:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1880::REFERENCE:CVE-2005-1916:DESCRIPTION:Symlink in Python program:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1916::REFERENCE:CVE-2000-0972:DESCRIPTION:Setuid product allows file reading by replacing a file being edited with a symlink to the targeted file, leaking the result in error messages when parsing fails.:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0972::REFERENCE:CVE-2005-0824:DESCRIPTION:Signal causes a dump that follows symlinks.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-0824::REFERENCE:CVE-2001-1494:DESCRIPTION:Hard link attack, file overwrite; interesting because program checks against soft links:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1494::REFERENCE:CVE-2002-0793:DESCRIPTION:Hard link and possibly symbolic link following vulnerabilities in embedded operating system allow local users to overwrite arbitrary files.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0793::REFERENCE:CVE-2003-0578:DESCRIPTION:Server creates hard links and unlinks files as root, which allows local users to gain privileges by deleting and overwriting arbitrary files.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0578::REFERENCE:CVE-1999-0783:DESCRIPTION:Operating system allows local users to conduct a denial of service by creating a hard link from a device special file to a file on an NFS file system.:LINK:https://www.cve.org/CVERecord?id=CVE-1999-0783::REFERENCE:CVE-2004-1603:DESCRIPTION:Web hosting manager follows hard links, which allows local users to read or modify arbitrary files.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1603::REFERENCE:CVE-2004-1901:DESCRIPTION:Package listing system allows local users to overwrite arbitrary files via a hard link attack on the lockfiles.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1901::REFERENCE:CVE-2005-1111:DESCRIPTION:Hard link race condition:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1111::REFERENCE:CVE-2000-0342:DESCRIPTION:Mail client allows remote attackers to bypass the user warning for executable attachments such as .exe, .com, and .bat by using a .lnk file that refers to the attachment, aka Stealth Attachment.:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0342::REFERENCE:CVE-2001-1042:DESCRIPTION:FTP server allows remote attackers to read arbitrary files and directories by uploading a .lnk (link) file that points to the target file.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1042::REFERENCE:CVE-2001-1043:DESCRIPTION:FTP server allows remote attackers to read arbitrary files and directories by uploading a .lnk (link) file that points to the target file.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1043::REFERENCE:CVE-2005-0587:DESCRIPTION:Browser allows remote malicious web sites to overwrite arbitrary files by tricking the user into downloading a .LNK (link) file twice, which overwrites the file that was referenced in the first .LNK file.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-0587::REFERENCE:CVE-2001-1386:DESCRIPTION:.LNK. - .LNK with trailing dot:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1386::REFERENCE:CVE-2003-1233:DESCRIPTION:Rootkits can bypass file access restrictions to Windows kernel directories using NtCreateSymbolicLinkObject function to create symbolic link:LINK:https://www.cve.org/CVERecord?id=CVE-2003-1233::REFERENCE:CVE-2002-0725:DESCRIPTION:File system allows local attackers to hide file usage activities via a hard link to the target file, which causes the link to be recorded in the audit trail instead of the target file.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0725::REFERENCE:CVE-2003-0844:DESCRIPTION:Web server plugin allows local users to overwrite arbitrary files via a symlink attack on predictable temporary filenames.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0844::REFERENCE:CVE-2015-3629:DESCRIPTION:A Libcontainer used in Docker Engine allows local users to escape containerization and write to an arbitrary file on the host system via a symlink attack in an image when respawning a container.:LINK:https://www.cve.org/CVERecord?id=CVE-2015-3629::REFERENCE:CVE-2021-21272:DESCRIPTION:Zip Slip vulnerability in Go-based Open Container Initiative (OCI) registries product allows writing arbitrary files outside intended directory via symbolic links or hard links in a gzipped tarball.:LINK:https://www.cve.org/CVERecord?id=CVE-2021-21272::REFERENCE:CVE-2020-27833:DESCRIPTION:Zip Slip vulnerability in container management product allows writing arbitrary files outside intended directory via a container image (.tar format) with filenames that are symbolic links that point to other files within the same tar file; however, the files being pointed to can also be symbolic links to destinations outside the intended directory, bypassing the initial check.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-27833::",::File Processing::,::File or Directory::,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Link Following::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:FIO02-C:ENTRY NAME:Canonicalize path names originating from untrusted sources::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:POS01-C:ENTRY NAME:Check for the existence of links when dealing with files::TAXONOMY NAME:SEI CERT Perl Coding Standard:ENTRY ID:FIO01-PL:ENTRY NAME:Do not operate on files that can be modified by untrusted users:MAPPING FIT:CWE More Specific::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP18:ENTRY NAME:Link in resource name resolution::",::132::17::35::76::,"::TYPE:Theoretical:NOTE:Link following vulnerabilities are Multi-factor Vulnerabilities (MFV). They are the combination of multiple elements: file or directory permissions, filename predictability, race conditions, and in some cases, a design limitation in which there is no mechanism for performing atomic file creation operations. Some potential factors are race conditions, permissions, and predictability.::",
+61,"UNIX Symbolic Link (Symlink) Following",Compound,Incomplete,"The product, when opening a file or directory, does not sufficiently account for when the file is a symbolic link that resolves to a target outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.","A product that allows UNIX symbolic links (symlink) as part of paths whether in internal code or through user input can allow an attacker to spoof the symbolic link and traverse the file system to unintended locations or access arbitrary files. The symbolic link can permit an attacker to read/write/corrupt a file that they originally did not have permissions to access.",::NATURE:ChildOf:CWE ID:59:VIEW ID:1000:ORDINAL:Primary::NATURE:Requires:CWE ID:362:VIEW ID:1000::NATURE:Requires:CWE ID:340:VIEW ID:1000::NATURE:Requires:CWE ID:386:VIEW ID:1000::NATURE:Requires:CWE ID:732:VIEW ID:1000::,"::ORDINALITY:Resultant::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","::TERM:Symlink following::TERM:symlink vulnerability::","::PHASE:Implementation:NOTE:These are typically reported for temporary files or privileged programs.::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","::PHASE:Implementation:DESCRIPTION:Symbolic link attacks often occur when a program creates a tmp directory that stores files/links. Access to the directory should be restricted to the program as to prevent attackers from manipulating the files.::PHASE:Architecture and Design:STRATEGY:Separation of Privilege:DESCRIPTION:Follow the principle of least privilege when assigning access rights to entities in a software system. Denying access to a file can prevent an attacker from replacing that file with a link to a sensitive file. Ensure good compartmentalization in the system to provide protected areas that can be trusted.::","::REFERENCE:CVE-1999-1386:DESCRIPTION:Some versions of Perl follow symbolic links when running with the -e option, which allows local users to overwrite arbitrary files via a symlink attack.:LINK:https://www.cve.org/CVERecord?id=CVE-1999-1386::REFERENCE:CVE-2000-1178:DESCRIPTION:Text editor follows symbolic links when creating a rescue copy during an abnormal exit, which allows local users to overwrite the files of other users.:LINK:https://www.cve.org/CVERecord?id=CVE-2000-1178::REFERENCE:CVE-2004-0217:DESCRIPTION:Antivirus update allows local users to create or append to arbitrary files via a symlink attack on a logfile.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0217::REFERENCE:CVE-2003-0517:DESCRIPTION:Symlink attack allows local users to overwrite files.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0517::REFERENCE:CVE-2004-0689:DESCRIPTION:Possible interesting example:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0689::REFERENCE:CVE-2005-1879:DESCRIPTION:Second-order symlink vulnerabilities:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1879::REFERENCE:CVE-2005-1880:DESCRIPTION:Second-order symlink vulnerabilities:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1880::REFERENCE:CVE-2005-1916:DESCRIPTION:Symlink in Python program:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1916::REFERENCE:CVE-2000-0972:DESCRIPTION:Setuid product allows file reading by replacing a file being edited with a symlink to the targeted file, leaking the result in error messages when parsing fails.:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0972::REFERENCE:CVE-2005-0824:DESCRIPTION:Signal causes a dump that follows symlinks.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-0824::REFERENCE:CVE-2015-3629:DESCRIPTION:A Libcontainer used in Docker Engine allows local users to escape containerization and write to an arbitrary file on the host system via a symlink attack in an image when respawning a container.:LINK:https://www.cve.org/CVERecord?id=CVE-2015-3629::REFERENCE:CVE-2020-26277:DESCRIPTION:In a MySQL database deployment tool, users may craft a maliciously packaged tarball that contains symlinks to files external to the target and once unpacked, will execute.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-26277::REFERENCE:CVE-2021-21272:DESCRIPTION:Zip Slip vulnerability in Go-based Open Container Initiative (OCI) registries product allows writing arbitrary files outside intended directory via symbolic links or hard links in a gzipped tarball.:LINK:https://www.cve.org/CVERecord?id=CVE-2021-21272::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:UNIX symbolic link following::",::27::,"::TYPE:Research Gap:NOTE:Symlink vulnerabilities are regularly found in C and shell programs, but all programming languages can have this problem. Even shell programs are probably under-reported. Second-order symlink vulnerabilities may exist in programs that invoke other programs that follow symlinks. They are rarely reported but are likely to be fairly common when process invocation is used [REF-493].::",
+62,"UNIX Hard Link",Variant,Incomplete,"The product, when opening a file or directory, does not sufficiently account for when the name is associated with a hard link to a target that is outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.","Failure for a system to check for hard links can result in vulnerability to different types of attacks. For example, an attacker can escalate their privileges if a file used by a privileged program is replaced with a hard link to a sensitive file (e.g. /etc/passwd). When the process opens the file, the attacker can assume the privileges of that process.",::NATURE:ChildOf:CWE ID:59:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Resultant::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Unix:OPERATING SYSTEM PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","::PHASE:Architecture and Design:STRATEGY:Separation of Privilege:DESCRIPTION:Follow the principle of least privilege when assigning access rights to entities in a software system. Denying access to a file can prevent an attacker from replacing that file with a link to a sensitive file. Ensure good compartmentalization in the system to provide protected areas that can be trusted.::","::REFERENCE:CVE-2001-1494:DESCRIPTION:Hard link attack, file overwrite; interesting because program checks against soft links:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1494::REFERENCE:CVE-2002-0793:DESCRIPTION:Hard link and possibly symbolic link following vulnerabilities in embedded operating system allow local users to overwrite arbitrary files.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0793::REFERENCE:CVE-2003-0578:DESCRIPTION:Server creates hard links and unlinks files as root, which allows local users to gain privileges by deleting and overwriting arbitrary files.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0578::REFERENCE:CVE-1999-0783:DESCRIPTION:Operating system allows local users to conduct a denial of service by creating a hard link from a device special file to a file on an NFS file system.:LINK:https://www.cve.org/CVERecord?id=CVE-1999-0783::REFERENCE:CVE-2004-1603:DESCRIPTION:Web hosting manager follows hard links, which allows local users to read or modify arbitrary files.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1603::REFERENCE:CVE-2004-1901:DESCRIPTION:Package listing system allows local users to overwrite arbitrary files via a hard link attack on the lockfiles.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1901::REFERENCE:CVE-2005-0342:DESCRIPTION:The Finder in Mac OS X and earlier allows local users to overwrite arbitrary files and gain privileges by creating a hard link from the .DS_Store file to an arbitrary file.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-0342::REFERENCE:CVE-2005-1111:DESCRIPTION:Hard link race condition:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1111::REFERENCE:CVE-2021-21272:DESCRIPTION:Zip Slip vulnerability in Go-based Open Container Initiative (OCI) registries product allows writing arbitrary files outside intended directory via symbolic links or hard links in a gzipped tarball.:LINK:https://www.cve.org/CVERecord?id=CVE-2021-21272::REFERENCE:BUGTRAQ:20030203 ASA-0001:DESCRIPTION:OpenBSD chpass/chfn/chsh file content leak:LINK:https://seclists.org/bugtraq/2003/Feb/7::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:UNIX hard link::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:FIO05-C:ENTRY NAME:Identify files using multiple file attributes::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP18:ENTRY NAME:Link in resource name resolution::",,"",
+64,"Windows Shortcut Following (.LNK)",Variant,Incomplete,"The product, when opening a file or directory, does not sufficiently handle when the file is a Windows shortcut (.LNK) whose target is outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.","The shortcut (file with the .lnk extension) can permit an attacker to read/write a file that they originally did not have permissions to access.",::NATURE:ChildOf:CWE ID:59:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Resultant::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Windows:OPERATING SYSTEM PREVALENCE:Undetermined::,"","::TERM:Windows symbolic link following::TERM:symlink::","::PHASE:Operation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","::PHASE:Architecture and Design:STRATEGY:Separation of Privilege:DESCRIPTION:Follow the principle of least privilege when assigning access rights to entities in a software system. Denying access to a file can prevent an attacker from replacing that file with a link to a sensitive file. Ensure good compartmentalization in the system to provide protected areas that can be trusted.::","::REFERENCE:CVE-2019-19793:DESCRIPTION:network access control service executes program with high privileges and allows symlink to invoke another executable or perform DLL injection.:LINK:https://www.cve.org/CVERecord?id=CVE-2019-19793::REFERENCE:CVE-2000-0342:DESCRIPTION:Mail client allows remote attackers to bypass the user warning for executable attachments such as .exe, .com, and .bat by using a .lnk file that refers to the attachment, aka Stealth Attachment.:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0342::REFERENCE:CVE-2001-1042:DESCRIPTION:FTP server allows remote attackers to read arbitrary files and directories by uploading a .lnk (link) file that points to the target file.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1042::REFERENCE:CVE-2001-1043:DESCRIPTION:FTP server allows remote attackers to read arbitrary files and directories by uploading a .lnk (link) file that points to the target file.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1043::REFERENCE:CVE-2005-0587:DESCRIPTION:Browser allows remote malicious web sites to overwrite arbitrary files by tricking the user into downloading a .LNK (link) file twice, which overwrites the file that was referenced in the first .LNK file.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-0587::REFERENCE:CVE-2001-1386:DESCRIPTION:.LNK. - .LNK with trailing dot:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1386::REFERENCE:CVE-2003-1233:DESCRIPTION:Rootkits can bypass file access restrictions to Windows kernel directories using NtCreateSymbolicLinkObject function to create symbolic link:LINK:https://www.cve.org/CVERecord?id=CVE-2003-1233::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Windows Shortcut Following (.LNK)::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:FIO05-C:ENTRY NAME:Identify files using multiple file attributes::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP18:ENTRY NAME:Link in resource name resolution::",,"::TYPE:Research Gap:NOTE:Under-studied. Windows .LNK files are more portable than Unix symlinks and have been used in remote exploits. Some Windows API's will access LNK's as if they are regular files, so one would expect that they would be reported more frequently.::",
+65,"Windows Hard Link",Variant,Incomplete,"The product, when opening a file or directory, does not sufficiently handle when the name is associated with a hard link to a target that is outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.","Failure for a system to check for hard links can result in vulnerability to different types of attacks. For example, an attacker can escalate their privileges if a file used by a privileged program is replaced with a hard link to a sensitive file (e.g. AUTOEXEC.BAT). When the process opens the file, the attacker can assume the privileges of that process, or prevent the program from accurately processing data.",::NATURE:ChildOf:CWE ID:59:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Windows:OPERATING SYSTEM PREVALENCE:Undetermined::,"","","::PHASE:Implementation::PHASE:Operation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","::PHASE:Architecture and Design:STRATEGY:Separation of Privilege:DESCRIPTION:Follow the principle of least privilege when assigning access rights to entities in a software system. Denying access to a file can prevent an attacker from replacing that file with a link to a sensitive file. Ensure good compartmentalization in the system to provide protected areas that can be trusted.::","::REFERENCE:CVE-2002-0725:DESCRIPTION:File system allows local attackers to hide file usage activities via a hard link to the target file, which causes the link to be recorded in the audit trail instead of the target file.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0725::REFERENCE:CVE-2003-0844:DESCRIPTION:Web server plugin allows local users to overwrite arbitrary files via a symlink attack on predictable temporary filenames.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0844::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Windows hard link::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:FIO05-C:ENTRY NAME:Identify files using multiple file attributes::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP18:ENTRY NAME:Link in resource name resolution::",,"",
+66,"Improper Handling of File Names that Identify Virtual Resources",Base,Draft,"The product does not handle or incorrectly handles a file name that identifies a virtual resource that is not directly specified within the directory that is associated with the file name, causing the product to perform file-based operations on a resource that is not a file.","Virtual file names are represented like normal file names, but they are effectively aliases for other resources that do not behave like normal files. Depending on their functionality, they could be alternate entities. They are not necessarily listed in directories.",::NATURE:ChildOf:CWE ID:706:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::PHASE:Operation::","",,"::SCOPE:Other:IMPACT:Other::","::METHOD:Automated Static Analysis - Binary or Bytecode:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Bytecode Weakness Analysis - including disassembler + source code weakness analysis:EFFECTIVENESS:SOAR Partial::METHOD:Manual Static Analysis - Binary or Bytecode:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies:EFFECTIVENESS:SOAR Partial::METHOD:Dynamic Analysis with Automated Results Interpretation:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Web Application Scanner Web Services Scanner Database Scanners:EFFECTIVENESS:SOAR Partial::METHOD:Dynamic Analysis with Manual Results Interpretation:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Fuzz Tester Framework-based Fuzzer:EFFECTIVENESS:SOAR Partial::METHOD:Manual Static Analysis - Source Code:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Focused Manual Spotcheck - Focused manual analysis of source Manual Source Code Review (not inspections):EFFECTIVENESS:High::METHOD:Automated Static Analysis - Source Code:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer:EFFECTIVENESS:SOAR Partial::METHOD:Architecture or Design Review:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Formal Methods / Correct-By-Construction Cost effective for partial coverage: Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.):EFFECTIVENESS:High::","","::REFERENCE:CVE-1999-0278:DESCRIPTION:In IIS, remote attackers can obtain source code for ASP files by appending ::$DATA to the URL.:LINK:https://www.cve.org/CVERecord?id=CVE-1999-0278::REFERENCE:CVE-2004-1084:DESCRIPTION:Server allows remote attackers to read files and resource fork content via HTTP requests to certain special file names related to multiple data streams in HFS+.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1084::REFERENCE:CVE-2002-0106:DESCRIPTION:Server allows remote attackers to cause a denial of service via a series of requests to .JSP files that contain an MS-DOS device name.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0106::",::File Processing::,::File or Directory::,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Virtual Files::",,"",
+67,"Improper Handling of Windows Device Names",Variant,Incomplete,"The product constructs pathnames from user input, but it does not handle or incorrectly handles a pathname containing a Windows device name such as AUX or CON. This typically leads to denial of service or an information exposure when the application attempts to process the pathname as a regular file.","Not properly handling virtual filenames (e.g. AUX, CON, PRN, COM1, LPT1) can result in different types of vulnerabilities. In some cases an attacker can request a device via injection of a virtual filename in a URL, which may cause an error that leads to a denial of service or an error page that reveals sensitive information. A product that allows device names to bypass filtering runs the risk of an attacker injecting malicious code in a file with the name of a device.",::NATURE:ChildOf:CWE ID:66:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Resultant::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Windows:OPERATING SYSTEM PREVALENCE:Undetermined::,"::Historically, there was a bug in the Windows operating system that caused a blue screen of death. Even after that issue was fixed DOS device names continue to be a factor.::","","::PHASE:Implementation::PHASE:Operation::","",,"::SCOPE:Availability:SCOPE:Confidentiality:SCOPE:Other:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:Read Application Data:IMPACT:Other::","","::PHASE:Implementation:DESCRIPTION:Be familiar with the device names in the operating system where your system is deployed. Check input for these device names.::","::REFERENCE:CVE-2002-0106:DESCRIPTION:Server allows remote attackers to cause a denial of service via a series of requests to .JSP files that contain an MS-DOS device name.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0106::REFERENCE:CVE-2002-0200:DESCRIPTION:Server allows remote attackers to cause a denial of service via an HTTP request for an MS-DOS device name.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0200::REFERENCE:CVE-2002-1052:DESCRIPTION:Product allows remote attackers to use MS-DOS device names in HTTP requests to cause a denial of service or obtain the physical path of the server.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1052::REFERENCE:CVE-2001-0493:DESCRIPTION:Server allows remote attackers to cause a denial of service via a URL that contains an MS-DOS device name.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0493::REFERENCE:CVE-2001-0558:DESCRIPTION:Server allows a remote attacker to create a denial of service via a URL request which includes a MS-DOS device name.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0558::REFERENCE:CVE-2000-0168:DESCRIPTION:Microsoft Windows 9x operating systems allow an attacker to cause a denial of service via a pathname that includes file device names, aka the DOS Device in Path Name vulnerability.:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0168::REFERENCE:CVE-2001-0492:DESCRIPTION:Server allows remote attackers to determine the physical path of the server via a URL containing MS-DOS device names.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0492::REFERENCE:CVE-2004-0552:DESCRIPTION:Product does not properly handle files whose names contain reserved MS-DOS device names, which can allow malicious code to bypass detection when it is installed, copied, or executed.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0552::REFERENCE:CVE-2005-2195:DESCRIPTION:Server allows remote attackers to cause a denial of service (application crash) via a URL with a filename containing a .cgi extension and an MS-DOS device name.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-2195::",,::File or Directory::,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Windows MS-DOS device names::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:FIO32-C:ENTRY NAME:Do not perform operations on devices that are only appropriate for files:MAPPING FIT:CWE More Specific::TAXONOMY NAME:The CERT Oracle Secure Coding Standard for Java (2011):ENTRY ID:FIO00-J:ENTRY NAME:Do not operate on files in shared directories::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",,"",
+69,"Improper Handling of Windows ::DATA Alternate Data Stream",Variant,Incomplete,"The product does not properly prevent access to, or detect usage of, alternate data streams (ADS).","An attacker can use an ADS to hide information about a file (e.g. size, the name of the process) from a system or file browser tools such as Windows Explorer and 'dir' at the command line utility. Alternately, the attacker might be able to bypass intended access restrictions for the associated data fork.",::NATURE:ChildOf:CWE ID:66:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Windows:OPERATING SYSTEM PREVALENCE:Undetermined::,"::Alternate data streams (ADS) were first implemented in the Windows NT operating system to provide compatibility between NTFS and the Macintosh Hierarchical File System (HFS). In HFS, data and resource forks are used to store information about a file. The data fork provides information about the contents of the file while the resource fork stores metadata such as file type.::","","::PHASE:Implementation::","",,"::SCOPE:Access Control:SCOPE:Non-Repudiation:SCOPE:Other:IMPACT:Bypass Protection Mechanism:IMPACT:Hide Activities:IMPACT:Other::","","::PHASE:Testing:DESCRIPTION:Software tools are capable of finding ADSs on your system.::PHASE:Implementation:DESCRIPTION:Ensure that the source code correctly parses the filename to read or write to the correct stream.::","::REFERENCE:CVE-1999-0278:DESCRIPTION:In IIS, remote attackers can obtain source code for ASP files by appending ::$DATA to the URL.:LINK:https://www.cve.org/CVERecord?id=CVE-1999-0278::REFERENCE:CVE-2000-0927:DESCRIPTION:Product does not properly record file sizes if they are stored in alternative data streams, which allows users to bypass quota restrictions.:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0927::",,::System Process::,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Windows ::DATA alternate data stream::",::168::,"::TYPE:Theoretical:NOTE:This and similar problems exist because the same resource can have multiple identifiers that dictate which behavior can be performed on the resource.::",
+72,"Improper Handling of Apple HFS+ Alternate Data Stream Path",Variant,Incomplete,"The product does not properly handle special paths that may identify the data or resource fork of a file on the HFS+ file system.","If the product chooses actions to take based on the file name, then if an attacker provides the data or resource fork, the product may take unexpected actions. Further, if the product intends to restrict access to a file, then an attacker might still be able to bypass intended access restrictions by requesting the data or resource fork for that file.",::NATURE:ChildOf:CWE ID:66:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:macOS:OPERATING SYSTEM PREVALENCE:Undetermined::,"::The Apple HFS+ file system permits files to have multiple data input streams, accessible through special paths. The Mac OS X operating system provides a way to access the different data input streams through special paths and as an extended attribute: - Resource fork: file/..namedfork/rsrc, file/rsrc (deprecated), xattr:com.apple.ResourceFork - Data fork: file/..namedfork/data (only versions prior to Mac OS X v10.5) Additionally, on filesystems that lack native support for multiple streams, the resource fork and file metadata may be stored in a file with ._ prepended to the name. Forks can also be accessed through non-portable APIs. Forks inherit the file system access controls of the file they belong to. Programs need to control access to these paths, if the processing of a file system object is dependent on the structure of its path.::","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::","","","::REFERENCE:CVE-2004-1084:DESCRIPTION:Server allows remote attackers to read files and resource fork content via HTTP requests to certain special file names related to multiple data streams in HFS+.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1084::",,,"",,"::TYPE:Theoretical:NOTE:This and similar problems exist because the same resource can have multiple identifiers that dictate which behavior can be performed on the resource.::TYPE:Research Gap:NOTE:Under-studied::",
+73,"External Control of File Name or Path",Base,Draft,"The product allows user input to control or influence paths or file names that are used in filesystem operations.","This could allow an attacker to access or modify system files or other files that are critical to the application. Path manipulation errors occur when the following two conditions are met: 1. An attacker can specify a path used in an operation on the filesystem. 2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted. For example, the program may give the attacker the ability to overwrite the specified file or run with a configuration controlled by the attacker.",::NATURE:ChildOf:CWE ID:642:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:610:VIEW ID:1000::NATURE:ChildOf:CWE ID:20:VIEW ID:700:ORDINAL:Primary::NATURE:CanPrecede:CWE ID:22:VIEW ID:1000::NATURE:CanPrecede:CWE ID:41:VIEW ID:1000::NATURE:CanPrecede:CWE ID:98:VIEW ID:1000::NATURE:CanPrecede:CWE ID:434:VIEW ID:1000::NATURE:CanPrecede:CWE ID:59:VIEW ID:1000::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Unix:OPERATING SYSTEM PREVALENCE:Often::OPERATING SYSTEM CLASS:Windows:OPERATING SYSTEM PREVALENCE:Often::OPERATING SYSTEM CLASS:macOS:OPERATING SYSTEM PREVALENCE:Often::,"","","::PHASE:Architecture and Design::PHASE:Implementation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::","",,"::SCOPE:Integrity:SCOPE:Confidentiality:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories:NOTE:The application can operate on unexpected files. Confidentiality is violated when the targeted filename is not directly readable by the attacker.::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:IMPACT:Modify Files or Directories:IMPACT:Execute Unauthorized Code or Commands:NOTE:The application can operate on unexpected files. This may violate integrity if the filename is written to, or if the filename is for a program or other form of executable code.::SCOPE:Availability:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:DoS: Resource Consumption (Other):NOTE:The application can operate on unexpected files. Availability can be violated if the attacker specifies an unexpected file that the application modifies. Availability can also be affected if the attacker specifies a filename for a large file, or points to a special device or a file that does not have the format that the application expects.::","::METHOD:Automated Static Analysis:DESCRIPTION:The external control or influence of filenames can often be detected using automated static analysis that models data flow within the product. Automated static analysis might not be able to recognize when proper input validation is being performed, leading to false positives - i.e., warnings that do not have any security consequences or require any code changes.::","::PHASE:Architecture and Design:DESCRIPTION:When the set of filenames is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames, and reject all other inputs. For example, ID 1 could map to inbox.txt and ID 2 could map to profile.txt. Features such as the ESAPI AccessReferenceMap provide this capability.::PHASE:Architecture and Design Operation:DESCRIPTION:Run your code in a jail or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict all access to files within a particular directory. Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.::PHASE:Architecture and Design:DESCRIPTION:For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single . character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as / to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering / is insufficient protection if the filesystem also supports the use of as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if ../ sequences are removed from the .../...// string in a sequential fashion, two instances of ../ would be removed from the original string, but the remaining characters would still form the ../ string.:EFFECTIVENESS:High::PHASE:Implementation:DESCRIPTION:Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes .. sequences and symbolic links (CWE-23, CWE-59).::PHASE:Installation Operation:DESCRIPTION:Use OS-level permissions and run as a low-privileged user to limit the scope of any successful attack.::PHASE:Operation Implementation:DESCRIPTION:If you are using PHP, configure your application so that it does not use register_globals. During implementation, develop your application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.::PHASE:Testing:DESCRIPTION:Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.::","::REFERENCE:CVE-2022-45918:DESCRIPTION:Chain: a learning management tool debugger uses external input to locate previous session logs (CWE-73) and does not properly validate the given path (CWE-20), allowing for filesystem path traversal using ../ sequences (CWE-24):LINK:https://www.cve.org/CVERecord?id=CVE-2022-45918::REFERENCE:CVE-2008-5748:DESCRIPTION:Chain: external control of values for user's desired language and theme enables path traversal.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-5748::REFERENCE:CVE-2008-5764:DESCRIPTION:Chain: external control of user's target language enables remote file inclusion.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-5764::",,,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:Path Manipulation::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP16:ENTRY NAME:Path Traversal::",::13::267::64::72::76::78::79::80::,"::TYPE:Maintenance:NOTE:CWE-114 is a Class, but it is listed a child of CWE-73 in view 1000. This suggests some abstraction problems that should be resolved in future versions.::TYPE:Relationship:NOTE:The external control of filenames can be the primary link in chains with other file-related weaknesses, as seen in the CanPrecede relationships. This is because software systems use files for many different purposes: to execute programs, load code libraries, to store application data, to store configuration settings, record temporary data, act as signals or semaphores to other processes, etc. However, those weaknesses do not always require external control. For example, link-following weaknesses (CWE-59) often involve pathnames that are not controllable by the attacker at all. The external control can be resultant from other issues. For example, in PHP applications, the register_globals setting can allow an attacker to modify variables that the programmer thought were immutable, enabling file inclusion (CWE-98) and path traversal (CWE-22). Operating with excessive privileges (CWE-250) might allow an attacker to specify an input filename that is not directly readable by the attacker, but is accessible to the privileged program. A buffer overflow (CWE-119) might give an attacker control over nearby memory locations that are related to pathnames, but were not directly modifiable by the attacker.::",
+74,"Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')",Class,Incomplete,"The product constructs all or part of a command, data structure, or record using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify how it is parsed or interpreted when it is sent to a downstream component.","Software or other automated logic has certain assumptions about what constitutes data and control respectively. It is the lack of verification of these assumptions for user-controlled input that leads to injection problems. Injection problems encompass a wide variety of issues -- all mitigated in very different ways and usually attempted in order to alter the control flow of the process. For this reason, the most effective way to discuss these weaknesses is to note the distinct features that classify them as injection weaknesses. The most important issue to note is that all injection problems share one thing in common -- i.e., they allow for the injection of control plane data into the user-controlled data plane. This means that the execution of the process may be altered by sending code in through legitimate data channels, using no other mechanism. While buffer overflows, and many other flaws, involve the use of some further issue to gain execution, injection problems need only for the data to be parsed.",::NATURE:ChildOf:CWE ID:707:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::","",,"::SCOPE:Confidentiality:IMPACT:Read Application Data:NOTE:Many injection attacks involve the disclosure of important information -- in terms of both data sensitivity and usefulness in further exploitation.::SCOPE:Access Control:IMPACT:Bypass Protection Mechanism:NOTE:In some cases, injectable code controls authentication; this may lead to a remote vulnerability.::SCOPE:Other:IMPACT:Alter Execution Logic:NOTE:Injection attacks are characterized by the ability to significantly change the flow of a given process, and in some cases, to the execution of arbitrary code.::SCOPE:Integrity:SCOPE:Other:IMPACT:Other:NOTE:Data injection attacks lead to loss of data integrity in nearly all cases as the control-plane data injected is always incidental to data recall or writing.::SCOPE:Non-Repudiation:IMPACT:Hide Activities:NOTE:Often the actions performed by injected control code are unlogged.::","::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","::PHASE:Requirements:DESCRIPTION:Programming languages and supporting technologies might be chosen which are not subject to these issues.::PHASE:Implementation:DESCRIPTION:Utilize an appropriate mix of allowlist and denylist parsing to filter control-plane syntax from all input.::","::REFERENCE:CVE-2022-36069:DESCRIPTION:Python-based dependency management tool avoids OS command injection when generating Git commands but allows injection of optional arguments with input beginning with a dash, potentially allowing for code execution.:LINK:https://www.cve.org/CVERecord?id=CVE-2022-36069::REFERENCE:CVE-1999-0067:DESCRIPTION:Canonical example of OS command injection. CGI program does not neutralize | metacharacter when invoking a phonebook program.:LINK:https://www.cve.org/CVERecord?id=CVE-1999-0067::REFERENCE:CVE-2022-1509:DESCRIPTION:injection of sed script syntax (sed injection):LINK:https://www.cve.org/CVERecord?id=CVE-2022-1509::REFERENCE:CVE-2020-9054:DESCRIPTION:Chain: improper input validation (CWE-20) in username parameter, leading to OS command injection (CWE-78), as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-9054::REFERENCE:CVE-2021-44228:DESCRIPTION:Product does not neutralize ${xyz} style expressions, allowing remote code execution. (log4shell vulnerability):LINK:https://www.cve.org/CVERecord?id=CVE-2021-44228::",,,"::TAXONOMY NAME:CLASP:ENTRY NAME:Injection problem ('data' used as something else)::TAXONOMY NAME:OWASP Top Ten 2004:ENTRY ID:A6:ENTRY NAME:Injection Flaws:MAPPING FIT:CWE More Specific::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",::10::101::105::108::120::13::135::14::24::250::267::273::28::3::34::42::43::45::46::47::51::52::53::6::64::67::7::71::72::76::78::79::8::80::83::84::9::,"::TYPE:Theoretical:NOTE:Many people treat injection only as an input validation problem (CWE-20) because many people do not distinguish between the consequence/attack (injection) and the protection mechanism that prevents the attack from succeeding. However, input validation is only one potential protection mechanism (output encoding is another), and there is a chaining relationship between improper input validation and the improper enforcement of the structure of messages to other components. Other issues not directly related to input validation, such as race conditions, could similarly impact message structure.::",
+75,"Failure to Sanitize Special Elements into a Different Plane (Special Element Injection)",Class,Draft,"The product does not adequately filter user-controlled input for special elements with control implications.","",::NATURE:ChildOf:CWE ID:74:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::","",,"::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:IMPACT:Modify Application Data:IMPACT:Execute Unauthorized Code or Commands::","","::PHASE:Requirements:DESCRIPTION:Programming languages and supporting technologies might be chosen which are not subject to these issues.::PHASE:Implementation:DESCRIPTION:Utilize an appropriate mix of allowlist and denylist parsing to filter special element syntax from all input.::","",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Special Element Injection::",::81::93::,"",
+76,"Improper Neutralization of Equivalent Special Elements",Base,Draft,"The product correctly neutralizes certain special elements, but it improperly neutralizes equivalent special elements.","The product may have a fixed list of special characters it believes is complete. However, there may be alternate encodings, or representations that also have the same meaning. For example, the product may filter out a leading slash (/) to prevent absolute path names, but does not account for a tilde (~) followed by a user name, which on some *nix systems could be expanded to an absolute pathname. Alternately, the product might filter a dangerous -e command-line switch when calling an external program, but it might not account for --exec or other switches that have the same semantics.",::NATURE:ChildOf:CWE ID:75:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::","",,"::SCOPE:Other:IMPACT:Other::","","::PHASE:Requirements:DESCRIPTION:Programming languages and supporting technologies might be chosen which are not subject to these issues.::PHASE:Implementation:DESCRIPTION:Utilize an appropriate mix of allowlist and denylist parsing to filter equivalent special element syntax from all input.::","",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Equivalent Special Element Injection::",,"",
+77,"Improper Neutralization of Special Elements used in a Command ('Command Injection')",Class,Draft,"The product constructs all or part of a command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended command when it is sent to a downstream component.","Command injection vulnerabilities typically occur when: 1. Data enters the application from an untrusted source. 2. The data is part of a string that is executed as a command by the application. 3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have. Many protocols and products have their own custom command language. While OS or shell command strings are frequently discovered and targeted, developers may not realize that these other command languages might also be vulnerable to attacks. Command injection is a common problem with wrapper programs.",::NATURE:ChildOf:CWE ID:74:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:74:VIEW ID:1003:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::","",,"::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:IMPACT:Execute Unauthorized Code or Commands:NOTE:If a malicious user injects a character (such as a semi-colon) that delimits the end of one command and the beginning of another, it may be possible to then insert an entirely new and unrelated command that was not intended to be executed.::","::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","::PHASE:Architecture and Design:DESCRIPTION:If at all possible, use library calls rather than external processes to recreate the desired functionality.::PHASE:Implementation:DESCRIPTION:If possible, ensure that all external commands called from the program are statically created.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.::PHASE:Operation:DESCRIPTION:Run time: Run time policy enforcement may be used in an allowlist fashion to prevent use of any non-sanctioned commands.::PHASE:System Configuration:DESCRIPTION:Assign permissions that prevent the user from accessing/opening privileged files.::","::REFERENCE:CVE-2022-36069:DESCRIPTION:Python-based dependency management tool avoids OS command injection when generating Git commands but allows injection of optional arguments with input beginning with a dash, potentially allowing for code execution.:LINK:https://www.cve.org/CVERecord?id=CVE-2022-36069::REFERENCE:CVE-1999-0067:DESCRIPTION:Canonical example of OS command injection. CGI program does not neutralize | metacharacter when invoking a phonebook program.:LINK:https://www.cve.org/CVERecord?id=CVE-1999-0067::REFERENCE:CVE-2020-9054:DESCRIPTION:Chain: improper input validation (CWE-20) in username parameter, leading to OS command injection (CWE-78), as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-9054::REFERENCE:CVE-2022-1509:DESCRIPTION:injection of sed script syntax (sed injection):LINK:https://www.cve.org/CVERecord?id=CVE-2022-1509::REFERENCE:CVE-2021-41282:DESCRIPTION:injection of sed script syntax (sed injection):LINK:https://www.cve.org/CVERecord?id=CVE-2021-41282::REFERENCE:CVE-2019-13398:DESCRIPTION:injection of sed script syntax (sed injection):LINK:https://www.cve.org/CVERecord?id=CVE-2019-13398::REFERENCE:CVE-2019-12921:DESCRIPTION:image program allows injection of commands in Magick Vector Graphics (MVG) language.:LINK:https://www.cve.org/CVERecord?id=CVE-2019-12921::REFERENCE:CVE-2020-11698:DESCRIPTION:anti-spam product allows injection of SNMP commands into confiuration file:LINK:https://www.cve.org/CVERecord?id=CVE-2020-11698::",,,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:Command Injection::TAXONOMY NAME:CLASP:ENTRY NAME:Command injection::TAXONOMY NAME:OWASP Top Ten 2007:ENTRY ID:A2:ENTRY NAME:Injection Flaws:MAPPING FIT:CWE More Specific::TAXONOMY NAME:OWASP Top Ten 2004:ENTRY ID:A1:ENTRY NAME:Unvalidated Input:MAPPING FIT:CWE More Specific::TAXONOMY NAME:OWASP Top Ten 2004:ENTRY ID:A6:ENTRY NAME:Injection Flaws:MAPPING FIT:CWE More Specific::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::TAXONOMY NAME:SEI CERT Perl Coding Standard:ENTRY ID:IDS34-PL:ENTRY NAME:Do not pass untrusted, unsanitized data to a command interpreter:MAPPING FIT:CWE More Specific::",::136::15::183::248::40::43::75::76::,"::TYPE:Terminology:NOTE:The command injection phrase carries different meanings to different people. For some people, it refers to any type of attack that can allow the attacker to execute commands of their own choosing, regardless of how those commands are inserted. The command injection could thus be resultant from another weakness. This usage also includes cases in which the functionality allows the user to specify an entire command, which is then executed; within CWE, this situation might be better regarded as an authorization problem (since an attacker should not be able to specify arbitrary commands.) Another common usage, which includes CWE-77 and its descendants, involves cases in which the attacker injects separators into the command being constructed.::",
+78,"Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')",Base,Stable,"The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.","This could allow attackers to execute unexpected, dangerous commands directly on the operating system. This weakness can lead to a vulnerability in environments in which the attacker does not have direct access to the operating system, such as in web applications. Alternately, if the weakness occurs in a privileged program, it could allow the attacker to specify commands that normally would not be accessible, or to call alternate commands with privileges that the attacker does not have. The problem is exacerbated if the compromised process does not follow the principle of least privilege, because the attacker-controlled commands may run with special system privileges that increases the amount of damage. There are at least two subtypes of OS command injection: The application intends to execute a single, fixed program that is under its own control. It intends to use externally-supplied inputs as arguments to that program. For example, the program might use system(nslookup [HOSTNAME]) to run nslookup and allow the user to supply a HOSTNAME, which is used as an argument. Attackers cannot prevent nslookup from executing. However, if the program does not remove command separators from the HOSTNAME argument, attackers could place the separators into the arguments, which allows them to execute their own program after nslookup has finished executing. The application accepts an input that it uses to fully select which program to run, as well as which commands to use. The application simply redirects this entire command to the operating system. For example, the program might use exec([COMMAND]) to execute the [COMMAND] that was supplied by the user. If the COMMAND is under attacker control, then the attacker can execute arbitrary commands or programs. If the command is being executed using functions like exec() and CreateProcess(), the attacker might not be able to combine multiple commands together in the same line. From a weakness standpoint, these variants represent distinct programmer errors. In the first variant, the programmer clearly intends that input from untrusted parties will be part of the arguments in the command to be executed. In the second variant, the programmer does not intend for the command to be accessible to any untrusted party, but the programmer probably has not accounted for alternate ways in which malicious attackers can provide input.",::NATURE:ChildOf:CWE ID:77:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:74:VIEW ID:1003:ORDINAL:Primary::NATURE:ChildOf:CWE ID:77:VIEW ID:1305:ORDINAL:Primary::NATURE:ChildOf:CWE ID:77:VIEW ID:1340:ORDINAL:Primary::NATURE:CanAlsoBe:CWE ID:88:VIEW ID:1000::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","::TERM:Shell injection::TERM:Shell metacharacters::","::PHASE:Implementation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Non-Repudiation:IMPACT:Execute Unauthorized Code or Commands:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories:IMPACT:Read Application Data:IMPACT:Modify Application Data:IMPACT:Hide Activities:NOTE:Attackers could execute unauthorized commands, which could then be used to disable the product, or read and modify data for which the attacker does not have permissions to access directly. Since the targeted application is directly executing the commands instead of the attacker, any malicious activities may appear to come from the application or the application's owner.::","::METHOD:Automated Static Analysis:DESCRIPTION:This weakness can often be detected using automated static analysis tools. Many modern tools use data flow analysis or constraint-based techniques to minimize the number of false positives. Automated static analysis might not be able to recognize when proper input validation is being performed, leading to false positives - i.e., warnings that do not have any security consequences or require any code changes. Automated static analysis might not be able to detect the usage of custom API functions or third-party libraries that indirectly invoke OS commands, leading to false negatives - especially if the API/library code is not available for analysis.::METHOD:Automated Dynamic Analysis:DESCRIPTION:This weakness can be detected using dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.:EFFECTIVENESS:Moderate::METHOD:Manual Static Analysis:DESCRIPTION:Since this weakness does not typically appear frequently within a single software package, manual white box techniques may be able to provide sufficient code coverage and reduction of false positives if all potentially-vulnerable operations can be assessed within limited time constraints.:EFFECTIVENESS:High::METHOD:Automated Static Analysis - Binary or Bytecode:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Bytecode Weakness Analysis - including disassembler + source code weakness analysis Binary Weakness Analysis - including disassembler + source code weakness analysis:EFFECTIVENESS:High::METHOD:Dynamic Analysis with Automated Results Interpretation:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Web Application Scanner Web Services Scanner Database Scanners:EFFECTIVENESS:SOAR Partial::METHOD:Dynamic Analysis with Manual Results Interpretation:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Fuzz Tester Framework-based Fuzzer:EFFECTIVENESS:SOAR Partial::METHOD:Manual Static Analysis - Source Code:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Manual Source Code Review (not inspections) Cost effective for partial coverage: Focused Manual Spotcheck - Focused manual analysis of source:EFFECTIVENESS:High::METHOD:Automated Static Analysis - Source Code:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer:EFFECTIVENESS:High::METHOD:Architecture or Design Review:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Formal Methods / Correct-By-Construction Cost effective for partial coverage: Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.):EFFECTIVENESS:High::","::PHASE:Architecture and Design:DESCRIPTION:If at all possible, use library calls rather than external processes to recreate the desired functionality.::PHASE:Architecture and Design Operation:STRATEGY:Sandbox or Jail:DESCRIPTION:Run the code in a jail or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software. OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.:EFFECTIVENESS:Limited::PHASE:Architecture and Design:STRATEGY:Attack Surface Reduction:DESCRIPTION:For any data that will be used to generate a command to be executed, keep as much of that data out of external control as possible. For example, in web applications, this may require storing the data locally in the session's state instead of sending it out to the client in a hidden form field.::PHASE:Architecture and Design:DESCRIPTION:For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.::PHASE:Architecture and Design:STRATEGY:Libraries or Frameworks:DESCRIPTION:Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using the ESAPI Encoding control [REF-45] or a similar tool, library, or framework. These will help the programmer encode outputs in a manner less prone to error.::PHASE:Implementation:STRATEGY:Output Encoding:DESCRIPTION:While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).::PHASE:Implementation:DESCRIPTION:If the program to be executed allows arguments to be specified within an input file or from standard input, then consider using that mode to pass arguments instead of the command line.::PHASE:Architecture and Design:STRATEGY:Parameterization:DESCRIPTION:If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated. Some languages offer multiple functions that can be used to invoke commands. Where possible, identify any function that invokes a command shell using a single string, and replace it with a function that requires individual arguments. These functions typically perform appropriate quoting and filtering of arguments. For example, in C, the system() function accepts a string that contains the entire command to be executed, whereas execl(), execve(), and others require an array of strings, one for each argument. In Windows, CreateProcess() only accepts one command at a time. In Perl, if system() is provided with an array of arguments, then it will quote each of the arguments.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When constructing OS command strings, use stringent allowlists that limit the character set based on the expected value of the parameter in the request. This will indirectly limit the scope of an attack, but this technique is less important than proper output encoding and escaping. Note that proper output encoding, escaping, and quoting is the most effective solution for preventing OS command injection, although input validation may provide some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will not always prevent OS command injection, especially if you are required to support free-form text fields that could contain arbitrary characters. For example, when invoking a mail program, you might need to allow the subject field to contain otherwise-dangerous inputs like ; and > characters, which would need to be escaped or otherwise handled. In this case, stripping the character might reduce the risk of OS command injection, but it would produce incorrect behavior because the subject field would not be recorded as the user intended. This might seem to be a minor inconvenience, but it could be more important when the program relies on well-structured subject lines in order to pass messages to other components. Even if you make a mistake in your validation (such as forgetting one out of 100 input fields), appropriate encoding is still likely to protect you from injection-based attacks. As long as it is not done in isolation, input validation is still a useful technique, since it may significantly reduce your attack surface, allow you to detect some attacks, and provide other security benefits that proper encoding does not address.::PHASE:Architecture and Design:STRATEGY:Enforcement by Conversion:DESCRIPTION:When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.::PHASE:Operation:STRATEGY:Compilation or Build Hardening:DESCRIPTION:Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's -T switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).::PHASE:Operation:STRATEGY:Environment Hardening:DESCRIPTION:Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's -T switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).::PHASE:Implementation:DESCRIPTION:Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not. In the context of OS Command Injection, error information passed back to the user might reveal whether an OS command is being executed and possibly which command is being used.::PHASE:Operation:STRATEGY:Sandbox or Jail:DESCRIPTION:Use runtime policy enforcement to create an allowlist of allowable commands, then prevent use of any command that does not appear in the allowlist. Technologies such as AppArmor are available to do this.::PHASE:Operation:STRATEGY:Firewall:DESCRIPTION:Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.:EFFECTIVENESS:Moderate::PHASE:Architecture and Design Operation:STRATEGY:Environment Hardening:DESCRIPTION:Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.::PHASE:Operation Implementation:STRATEGY:Environment Hardening:DESCRIPTION:When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.::","::REFERENCE:CVE-2020-10987:DESCRIPTION:OS command injection in Wi-Fi router, as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-10987::REFERENCE:CVE-2020-10221:DESCRIPTION:Template functionality in network configuration management tool allows OS command injection, as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-10221::REFERENCE:CVE-2020-9054:DESCRIPTION:Chain: improper input validation (CWE-20) in username parameter, leading to OS command injection (CWE-78), as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-9054::REFERENCE:CVE-1999-0067:DESCRIPTION:Canonical example of OS command injection. CGI program does not neutralize | metacharacter when invoking a phonebook program.:LINK:https://www.cve.org/CVERecord?id=CVE-1999-0067::REFERENCE:CVE-2001-1246:DESCRIPTION:Language interpreter's mail function accepts another argument that is concatenated to a string used in a dangerous popen() call. Since there is no neutralization of this argument, both OS Command Injection (CWE-78) and Argument Injection (CWE-88) are possible.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1246::REFERENCE:CVE-2002-0061:DESCRIPTION:Web server allows command execution using | (pipe) character.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0061::REFERENCE:CVE-2003-0041:DESCRIPTION:FTP client does not filter | from filenames returned by the server, allowing for OS command injection.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0041::REFERENCE:CVE-2008-2575:DESCRIPTION:Shell metacharacters in a filename in a ZIP archive:LINK:https://www.cve.org/CVERecord?id=CVE-2008-2575::REFERENCE:CVE-2002-1898:DESCRIPTION:Shell metacharacters in a telnet:// link are not properly handled when the launching application processes the link.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1898::REFERENCE:CVE-2008-4304:DESCRIPTION:OS command injection through environment variable.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-4304::REFERENCE:CVE-2008-4796:DESCRIPTION:OS command injection through https:// URLs:LINK:https://www.cve.org/CVERecord?id=CVE-2008-4796::REFERENCE:CVE-2007-3572:DESCRIPTION:Chain: incomplete denylist for OS command injection:LINK:https://www.cve.org/CVERecord?id=CVE-2007-3572::REFERENCE:CVE-2012-1988:DESCRIPTION:Product allows remote users to execute arbitrary commands by creating a file whose pathname contains shell metacharacters.:LINK:https://www.cve.org/CVERecord?id=CVE-2012-1988::",::Program Invocation::,::System Process::,"::TAXONOMY NAME:PLOVER:ENTRY NAME:OS Command Injection::TAXONOMY NAME:OWASP Top Ten 2007:ENTRY ID:A3:ENTRY NAME:Malicious File Execution:MAPPING FIT:CWE More Specific::TAXONOMY NAME:OWASP Top Ten 2004:ENTRY ID:A6:ENTRY NAME:Injection Flaws:MAPPING FIT:CWE More Specific::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:ENV03-C:ENTRY NAME:Sanitize the environment when invoking external programs::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:ENV33-C:ENTRY NAME:Do not call system():MAPPING FIT:CWE More Specific::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:STR02-C:ENTRY NAME:Sanitize data passed to complex subsystems::TAXONOMY NAME:WASC:ENTRY ID:31:ENTRY NAME:OS Commanding::TAXONOMY NAME:The CERT Oracle Secure Coding Standard for Java (2011):ENTRY ID:IDS07-J:ENTRY NAME:Do not pass untrusted, unsanitized data to the Runtime.exec() method::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::TAXONOMY NAME:OMG ASCSM:ENTRY ID:ASCSM-CWE-78::",::108::15::43::6::88::,"::TYPE:Terminology:NOTE:The OS command injection phrase carries different meanings to different people. For some people, it only refers to cases in which the attacker injects command separators into arguments for an application-controlled program that is being invoked. For some people, it refers to any type of attack that can allow the attacker to execute OS commands of their own choosing. This usage could include untrusted search path weaknesses (CWE-426) that cause the application to find and execute an attacker-controlled program. Further complicating the issue is the case when argument injection (CWE-88) allows alternate command-line switches or options to be inserted into the command line, such as an -exec switch whose purpose may be to execute the subsequent argument as a command (this -exec switch exists in the UNIX find command, for example). In this latter case, however, CWE-88 could be regarded as the primary weakness in a chain with CWE-78.::TYPE:Research Gap:NOTE:More investigation is needed into the distinction between the OS command injection variants, including the role with argument injection (CWE-88). Equivalent distinctions may exist in other injection-related problems such as SQL injection.::",
+79,"Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')",Base,Stable,"The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.","Cross-site scripting (XSS) vulnerabilities occur when: Untrusted data enters a web application, typically from a web request. The web application dynamically generates a web page that contains this untrusted data. During page generation, the application does not prevent the data from containing content that is executable by a web browser, such as JavaScript, HTML tags, HTML attributes, mouse events, Flash, ActiveX, etc. A victim visits the generated web page through a web browser, which contains malicious script that was injected using the untrusted data. Since the script comes from a web page that was sent by the web server, the victim's web browser executes the malicious script in the context of the web server's domain. This effectively violates the intention of the web browser's same-origin policy, which states that scripts in one domain should not be able to access resources or run code in a different domain. There are three main kinds of XSS: Type 1: Reflected XSS (or Non-Persistent) - The server reads data directly from the HTTP request and reflects it back in the HTTP response. Reflected XSS exploits occur when an attacker causes a victim to supply dangerous content to a vulnerable web application, which is then reflected back to the victim and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or e-mailed directly to the victim. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces a victim to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the victim, the content is executed by the victim's browser. Type 2: Stored XSS (or Persistent) - The application stores dangerous data in a database, message forum, visitor log, or other trusted data store. At a later time, the dangerous data is subsequently read back into the application and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user. For example, the attacker might inject XSS into a log message, which might not be handled properly when an administrator views the logs. Type 0: DOM-Based XSS - In DOM-based XSS, the client performs the injection of XSS into the page; in the other types, the server performs the injection. DOM-based XSS generally involves server-controlled, trusted script that is sent to the client, such as Javascript that performs sanity checks on a form before the user submits it. If the server-supplied script processes user-supplied data and then injects it back into the web page (such as with dynamic HTML), then DOM-based XSS is possible. Once the malicious script is injected, the attacker can perform a variety of malicious activities. The attacker could transfer private information, such as cookies that may include session information, from the victim's machine to the attacker. The attacker could send malicious requests to a web site on behalf of the victim, which could be especially dangerous to the site if the victim has administrator privileges to manage that site. Phishing attacks could be used to emulate trusted web sites and trick the victim into entering a password, allowing the attacker to compromise the victim's account on that web site. Finally, the script could exploit a vulnerability in the web browser itself possibly taking over the victim's machine, sometimes referred to as drive-by hacking. In many cases, the attack can be launched without the victim even being aware of it. Even with careful users, attackers frequently use a variety of methods to encode the malicious portion of the attack, such as URL encoding or Unicode, so the request looks less suspicious.",::NATURE:ChildOf:CWE ID:74:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:74:VIEW ID:1003:ORDINAL:Primary::NATURE:CanPrecede:CWE ID:494:VIEW ID:1000::NATURE:PeerOf:CWE ID:352:VIEW ID:1000::,"::ORDINALITY:Resultant::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Web Based:TECHNOLOGY PREVALENCE:Often::,"::The Same Origin Policy states that browsers should limit the resources accessible to scripts running on a given web site, or origin, to the resources associated with that web site on the client-side, and not the client-side resources of any other sites or origins. The goal is to prevent one site from being able to modify or read the contents of an unrelated site. Since the World Wide Web involves interactions between many sites, this policy is important for browsers to enforce. When referring to XSS, the Domain of a website is roughly equivalent to the resources associated with that website on the client-side of the connection. That is, the domain can be thought of as all resources the browser is storing for the user's interactions with this particular site.::","::TERM:XSS:DESCRIPTION:A common abbreviation for Cross-Site Scripting.::TERM:HTML Injection:DESCRIPTION:Used as a synonym of stored (Type 2) XSS.::TERM:CSS:DESCRIPTION:In the early years after initial discovery of XSS, CSS was a commonly-used acronym. However, this would cause confusion with Cascading Style Sheets, so usage of this acronym has declined significantly.::","::PHASE:Implementation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::","",,"::SCOPE:Access Control:SCOPE:Confidentiality:IMPACT:Bypass Protection Mechanism:IMPACT:Read Application Data:NOTE:The most common attack performed with cross-site scripting involves the disclosure of information stored in user cookies. Typically, a malicious user will craft a client-side script, which -- when parsed by a web browser -- performs some activity (such as sending all site cookies to a given E-mail address). This script will be loaded and run by each user visiting the web site. Since the site requesting to run the script has access to the cookies in question, the malicious script does also.::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:IMPACT:Execute Unauthorized Code or Commands:NOTE:In some circumstances it may be possible to run arbitrary code on a victim's computer when cross-site scripting is combined with other flaws.::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Access Control:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Bypass Protection Mechanism:IMPACT:Read Application Data:NOTE:The consequence of an XSS attack is the same regardless of whether it is stored or reflected. The difference is in how the payload arrives at the server. XSS can cause a variety of problems for the end user that range in severity from an annoyance to complete account compromise. Some cross-site scripting vulnerabilities can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on the end user systems for a variety of nefarious purposes. Other damaging attacks include the disclosure of end user files, installation of Trojan horse programs, redirecting the user to some other page or site, running Active X controls (under Microsoft Internet Explorer) from sites that a user perceives as trustworthy, and modifying presentation of content.::","::METHOD:Automated Static Analysis:DESCRIPTION:Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible, especially when multiple components are involved.:EFFECTIVENESS:Moderate::METHOD:Black Box:DESCRIPTION:Use the XSS Cheat Sheet [REF-714] or automated test-generation tools to help launch a wide variety of attacks against your web application. The Cheat Sheet contains many subtle XSS variations that are specifically targeted against weak XSS defenses.:EFFECTIVENESS:Moderate::","::PHASE:Architecture and Design:STRATEGY:Libraries or Frameworks:DESCRIPTION:Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.::PHASE:Implementation Architecture and Design:DESCRIPTION:Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies. For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters. Parts of the same output document may require different encodings, which will vary depending on whether the output is in the: HTML body Element attributes (such as src=XYZ) URIs JavaScript sections Cascading Style Sheets and style property etc. Note that HTML Entity Encoding is only appropriate for the HTML body. Consult the XSS Prevention Cheat Sheet [REF-724] for more details on the types of encoding and escaping that are needed.::PHASE:Architecture and Design Implementation:STRATEGY:Attack Surface Reduction:DESCRIPTION:Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.:EFFECTIVENESS:Limited::PHASE:Architecture and Design:DESCRIPTION:For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.::PHASE:Architecture and Design:STRATEGY:Parameterization:DESCRIPTION:If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.::PHASE:Implementation:STRATEGY:Output Encoding:DESCRIPTION:Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component. The problem of inconsistent output encodings often arises in web pages. If an encoding is not specified in an HTTP header, web browsers often guess about which encoding is being used. This can open up the browser to subtle XSS attacks.::PHASE:Implementation:DESCRIPTION:With Struts, write all data from form beans with the bean's filter attribute set to true.::PHASE:Implementation:STRATEGY:Attack Surface Reduction:DESCRIPTION:To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.:EFFECTIVENESS:Defense in Depth::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When dynamically constructing web pages, use stringent allowlists that limit the character set based on the expected value of the parameter in the request. All input should be validated and cleansed, not just parameters that the user is supposed to specify, but all data in the request, including hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. It is common to see data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended. Note that proper output encoding, escaping, and quoting is the most effective solution for preventing XSS, although input validation may provide some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will not always prevent XSS, especially if you are required to support free-form text fields that could contain arbitrary characters. For example, in a chat application, the heart emoticon (<3) would likely pass the validation step, since it is commonly used. However, it cannot be directly inserted into the web page because it contains the < character, which would need to be escaped or otherwise handled. In this case, stripping the < might reduce the risk of XSS, but it would produce incorrect behavior because the emoticon would not be recorded. This might seem to be a minor inconvenience, but it would be more important in a mathematical forum that wants to represent inequalities. Even if you make a mistake in your validation (such as forgetting one out of 100 input fields), appropriate encoding is still likely to protect you from injection-based attacks. As long as it is not done in isolation, input validation is still a useful technique, since it may significantly reduce your attack surface, allow you to detect some attacks, and provide other security benefits that proper encoding does not address. Ensure that you perform input validation at well-defined interfaces within the application. This will help protect the application even if a component is reused or moved elsewhere.::PHASE:Architecture and Design:STRATEGY:Enforcement by Conversion:DESCRIPTION:When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.::PHASE:Operation:STRATEGY:Firewall:DESCRIPTION:Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.:EFFECTIVENESS:Moderate::PHASE:Operation Implementation:STRATEGY:Environment Hardening:DESCRIPTION:When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.::","::REFERENCE:CVE-2021-25926:DESCRIPTION:Python Library Manager did not sufficiently neutralize a user-supplied search term, allowing reflected XSS.:LINK:https://www.cve.org/CVERecord?id=CVE-2021-25926::REFERENCE:CVE-2021-25963:DESCRIPTION:Python-based e-commerce platform did not escape returned content on error pages, allowing for reflected Cross-Site Scripting attacks.:LINK:https://www.cve.org/CVERecord?id=CVE-2021-25963::REFERENCE:CVE-2021-1879:DESCRIPTION:Universal XSS in mobile operating system, as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2021-1879::REFERENCE:CVE-2020-3580:DESCRIPTION:Chain: improper input validation (CWE-20) in firewall product leads to XSS (CWE-79), as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-3580::REFERENCE:CVE-2014-8958:DESCRIPTION:Admin GUI allows XSS through cookie.:LINK:https://www.cve.org/CVERecord?id=CVE-2014-8958::REFERENCE:CVE-2017-9764:DESCRIPTION:Web stats program allows XSS through crafted HTTP header.:LINK:https://www.cve.org/CVERecord?id=CVE-2017-9764::REFERENCE:CVE-2014-5198:DESCRIPTION:Web log analysis product allows XSS through crafted HTTP Referer header.:LINK:https://www.cve.org/CVERecord?id=CVE-2014-5198::REFERENCE:CVE-2008-5080:DESCRIPTION:Chain: protection mechanism failure allows XSS:LINK:https://www.cve.org/CVERecord?id=CVE-2008-5080::REFERENCE:CVE-2006-4308:DESCRIPTION:Chain: incomplete denylist (CWE-184) only checks javascript: tag, allowing XSS (CWE-79) using other tags:LINK:https://www.cve.org/CVERecord?id=CVE-2006-4308::REFERENCE:CVE-2007-5727:DESCRIPTION:Chain: incomplete denylist (CWE-184) only removes SCRIPT tags, enabling XSS (CWE-79):LINK:https://www.cve.org/CVERecord?id=CVE-2007-5727::REFERENCE:CVE-2008-5770:DESCRIPTION:Reflected XSS using the PATH_INFO in a URL:LINK:https://www.cve.org/CVERecord?id=CVE-2008-5770::REFERENCE:CVE-2008-4730:DESCRIPTION:Reflected XSS not properly handled when generating an error message:LINK:https://www.cve.org/CVERecord?id=CVE-2008-4730::REFERENCE:CVE-2008-5734:DESCRIPTION:Reflected XSS sent through email message.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-5734::REFERENCE:CVE-2008-0971:DESCRIPTION:Stored XSS in a security product.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-0971::REFERENCE:CVE-2008-5249:DESCRIPTION:Stored XSS using a wiki page.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-5249::REFERENCE:CVE-2006-3568:DESCRIPTION:Stored XSS in a guestbook application.:LINK:https://www.cve.org/CVERecord?id=CVE-2006-3568::REFERENCE:CVE-2006-3211:DESCRIPTION:Stored XSS in a guestbook application using a javascript: URI in a bbcode img tag.:LINK:https://www.cve.org/CVERecord?id=CVE-2006-3211::REFERENCE:CVE-2006-3295:DESCRIPTION:Chain: library file is not protected against a direct request (CWE-425), leading to reflected XSS (CWE-79).:LINK:https://www.cve.org/CVERecord?id=CVE-2006-3295::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Cross-site scripting (XSS)::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:Cross-site Scripting::TAXONOMY NAME:CLASP:ENTRY NAME:Cross-site scripting::TAXONOMY NAME:OWASP Top Ten 2007:ENTRY ID:A1:ENTRY NAME:Cross Site Scripting (XSS):MAPPING FIT:Exact::TAXONOMY NAME:OWASP Top Ten 2004:ENTRY ID:A1:ENTRY NAME:Unvalidated Input:MAPPING FIT:CWE More Specific::TAXONOMY NAME:OWASP Top Ten 2004:ENTRY ID:A4:ENTRY NAME:Cross-Site Scripting (XSS) Flaws:MAPPING FIT:Exact::TAXONOMY NAME:WASC:ENTRY ID:8:ENTRY NAME:Cross-site Scripting::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::TAXONOMY NAME:OMG ASCSM:ENTRY ID:ASCSM-CWE-79::",::209::588::591::592::63::85::,"::TYPE:Relationship:NOTE:There can be a close relationship between XSS and CSRF (CWE-352). An attacker might use CSRF in order to trick the victim into submitting requests to the server in which the requests contain an XSS payload. A well-known example of this was the Samy worm on MySpace [REF-956]. The worm used XSS to insert malicious HTML sequences into a user's profile and add the attacker as a MySpace friend. MySpace friends of that victim would then execute the payload to modify their own profiles, causing the worm to propagate exponentially. Since the victims did not intentionally insert the malicious script themselves, CSRF was a root cause.::TYPE:Applicable Platform:NOTE:XSS flaws are very common in web applications, since they require a great deal of developer discipline to avoid them.::",
+80,"Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)",Variant,Incomplete,"The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special characters such as <, >, and & that could be interpreted as web-scripting elements when they are sent to a downstream component that processes web pages.","This may allow such characters to be treated as control characters, which are executed client-side in the context of the user's session. Although this can be classified as an injection problem, the more pertinent issue is the improper conversion of such special characters to respective context-appropriate entities before displaying them to the user.",::NATURE:ChildOf:CWE ID:79:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:IMPACT:Read Application Data:IMPACT:Execute Unauthorized Code or Commands::","::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","::PHASE:Implementation:DESCRIPTION:Carefully check each input parameter against a rigorous positive specification (allowlist) defining the specific characters and format allowed. All input should be neutralized, not just parameters that the user is supposed to specify, but all data in the request, including hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. We often encounter data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended.::PHASE:Implementation:STRATEGY:Output Encoding:DESCRIPTION:Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component. The problem of inconsistent output encodings often arises in web pages. If an encoding is not specified in an HTTP header, web browsers often guess about which encoding is being used. This can open up the browser to subtle XSS attacks.::PHASE:Implementation:DESCRIPTION:With Struts, write all data from form beans with the bean's filter attribute set to true.::PHASE:Implementation:STRATEGY:Attack Surface Reduction:DESCRIPTION:To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.:EFFECTIVENESS:Defense in Depth::","::REFERENCE:CVE-2002-0938:DESCRIPTION:XSS in parameter in a link.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0938::REFERENCE:CVE-2002-1495:DESCRIPTION:XSS in web-based email product via attachment filenames.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1495::REFERENCE:CVE-2003-1136:DESCRIPTION:HTML injection in posted message.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-1136::REFERENCE:CVE-2004-2171:DESCRIPTION:XSS not quoted in error page.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-2171::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Basic XSS::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",::18::193::32::86::,"",
+81,"Improper Neutralization of Script in an Error Message Web Page",Variant,Incomplete,"The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special characters that could be interpreted as web-scripting elements when they are sent to an error page.","Error pages may include customized 403 Forbidden or 404 Not Found pages. When an attacker can trigger an error that contains script syntax within the attacker's input, then cross-site scripting attacks may be possible.",::NATURE:ChildOf:CWE ID:79:VIEW ID:1000:ORDINAL:Primary::NATURE:CanAlsoBe:CWE ID:209:VIEW ID:1000::NATURE:CanAlsoBe:CWE ID:390:VIEW ID:1000::,"::ORDINALITY:Resultant::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::PHASE:Operation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:IMPACT:Read Application Data:IMPACT:Execute Unauthorized Code or Commands::","","::PHASE:Implementation:DESCRIPTION:Do not write user-controlled input to error pages.::PHASE:Implementation:DESCRIPTION:Carefully check each input parameter against a rigorous positive specification (allowlist) defining the specific characters and format allowed. All input should be neutralized, not just parameters that the user is supposed to specify, but all data in the request, including hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. We often encounter data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended.::PHASE:Implementation:STRATEGY:Output Encoding:DESCRIPTION:Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component. The problem of inconsistent output encodings often arises in web pages. If an encoding is not specified in an HTTP header, web browsers often guess about which encoding is being used. This can open up the browser to subtle XSS attacks.::PHASE:Implementation:DESCRIPTION:With Struts, write all data from form beans with the bean's filter attribute set to true.::PHASE:Implementation:STRATEGY:Attack Surface Reduction:DESCRIPTION:To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.:EFFECTIVENESS:Defense in Depth::","::REFERENCE:CVE-2002-0840:DESCRIPTION:XSS in default error page from Host: header.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0840::REFERENCE:CVE-2002-1053:DESCRIPTION:XSS in error message.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1053::REFERENCE:CVE-2002-1700:DESCRIPTION:XSS in error page from targeted parameter.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1700::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:XSS in error pages::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",::198::,"",
+82,"Improper Neutralization of Script in Attributes of IMG Tags in a Web Page",Variant,Incomplete,"The web application does not neutralize or incorrectly neutralizes scripting elements within attributes of HTML IMG tags, such as the src attribute.","Attackers can embed XSS exploits into the values for IMG attributes (e.g. SRC) that is streamed and then executed in a victim's browser. Note that when the page is loaded into a user's browsers, the exploit will automatically execute.",::NATURE:ChildOf:CWE ID:83:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:IMPACT:Read Application Data:IMPACT:Execute Unauthorized Code or Commands::","","::PHASE:Implementation:STRATEGY:Output Encoding:DESCRIPTION:Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component. The problem of inconsistent output encodings often arises in web pages. If an encoding is not specified in an HTTP header, web browsers often guess about which encoding is being used. This can open up the browser to subtle XSS attacks.::PHASE:Implementation:STRATEGY:Attack Surface Reduction:DESCRIPTION:To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.:EFFECTIVENESS:Defense in Depth::","::REFERENCE:CVE-2006-3211:DESCRIPTION:Stored XSS in a guestbook application using a javascript: URI in a bbcode img tag.:LINK:https://www.cve.org/CVERecord?id=CVE-2006-3211::REFERENCE:CVE-2002-1649:DESCRIPTION:javascript URI scheme in IMG tag.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1649::REFERENCE:CVE-2002-1803:DESCRIPTION:javascript URI scheme in IMG tag.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1803::REFERENCE:CVE-2002-1804:DESCRIPTION:javascript URI scheme in IMG tag.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1804::REFERENCE:CVE-2002-1805:DESCRIPTION:javascript URI scheme in IMG tag.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1805::REFERENCE:CVE-2002-1806:DESCRIPTION:javascript URI scheme in IMG tag.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1806::REFERENCE:CVE-2002-1807:DESCRIPTION:javascript URI scheme in IMG tag.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1807::REFERENCE:CVE-2002-1808:DESCRIPTION:javascript URI scheme in IMG tag.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1808::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Script in IMG tags::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",,"",
+83,"Improper Neutralization of Script in Attributes in a Web Page",Variant,Draft,"The product does not neutralize or incorrectly neutralizes javascript: or other URIs from dangerous attributes within tags, such as onmouseover, onload, onerror, or style.","",::NATURE:ChildOf:CWE ID:79:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:IMPACT:Read Application Data:IMPACT:Execute Unauthorized Code or Commands::","::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","::PHASE:Implementation:DESCRIPTION:Carefully check each input parameter against a rigorous positive specification (allowlist) defining the specific characters and format allowed. All input should be neutralized, not just parameters that the user is supposed to specify, but all data in the request, including tag attributes, hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. We often encounter data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended.::PHASE:Implementation:STRATEGY:Output Encoding:DESCRIPTION:Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component. The problem of inconsistent output encodings often arises in web pages. If an encoding is not specified in an HTTP header, web browsers often guess about which encoding is being used. This can open up the browser to subtle XSS attacks.::PHASE:Implementation:DESCRIPTION:With Struts, write all data from form beans with the bean's filter attribute set to true.::PHASE:Implementation:STRATEGY:Attack Surface Reduction:DESCRIPTION:To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.:EFFECTIVENESS:Defense in Depth::","::REFERENCE:CVE-2001-0520:DESCRIPTION:Bypass filtering of SCRIPT tags using onload in BODY, href in A, BUTTON, INPUT, and others.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0520::REFERENCE:CVE-2002-1493:DESCRIPTION:guestbook XSS in STYLE or IMG SRC attributes.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1493::REFERENCE:CVE-2002-1965:DESCRIPTION:Javascript in onerror attribute of IMG tag.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1965::REFERENCE:CVE-2002-1495:DESCRIPTION:XSS in web-based email product via onmouseover event.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1495::REFERENCE:CVE-2002-1681:DESCRIPTION:XSS via script in tag.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1681::REFERENCE:CVE-2004-1935:DESCRIPTION:Onload, onmouseover, and other events in an e-mail attachment.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1935::REFERENCE:CVE-2005-0945:DESCRIPTION:Onmouseover and onload events in img, link, and mail tags.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-0945::REFERENCE:CVE-2003-1136:DESCRIPTION:Javascript in onmouseover attribute in e-mail address or URL.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-1136::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:XSS using Script in Attributes::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",::243::244::588::,"",
+84,"Improper Neutralization of Encoded URI Schemes in a Web Page",Variant,Draft,"The web application improperly neutralizes user-controlled input for executable script disguised with URI encodings.","",::NATURE:ChildOf:CWE ID:79:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Integrity:IMPACT:Unexpected State::","","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Resolve all URIs to absolute or canonical representations before processing.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Carefully check each input parameter against a rigorous positive specification (allowlist) defining the specific characters and format allowed. All input should be neutralized, not just parameters that the user is supposed to specify, but all data in the request, including tag attributes, hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. We often encounter data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended.::PHASE:Implementation:STRATEGY:Output Encoding:DESCRIPTION:Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component. The problem of inconsistent output encodings often arises in web pages. If an encoding is not specified in an HTTP header, web browsers often guess about which encoding is being used. This can open up the browser to subtle XSS attacks.::PHASE:Implementation:DESCRIPTION:With Struts, write all data from form beans with the bean's filter attribute set to true.::PHASE:Implementation:STRATEGY:Attack Surface Reduction:DESCRIPTION:To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.:EFFECTIVENESS:Defense in Depth::","::REFERENCE:CVE-2005-0563:DESCRIPTION:Cross-site scripting (XSS) vulnerability in Microsoft Outlook Web Access (OWA) component in Exchange Server 5.5 allows remote attackers to inject arbitrary web script or HTML via an email message with an encoded javascript: URL (javAsc
ript:) in an IMG tag.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-0563::REFERENCE:CVE-2005-2276:DESCRIPTION:Cross-site scripting (XSS) vulnerability in Novell Groupwise WebAccess 6.5 before July 11, 2005 allows remote attackers to inject arbitrary web script or HTML via an e-mail message with an encoded javascript URI (e.g. jAvascript in an IMG tag).:LINK:https://www.cve.org/CVERecord?id=CVE-2005-2276::REFERENCE:CVE-2005-0692:DESCRIPTION:Encoded script within BBcode IMG tag.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-0692::REFERENCE:CVE-2002-0117:DESCRIPTION:Encoded javascript in IMG tag.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0117::REFERENCE:CVE-2002-0118:DESCRIPTION:Encoded javascript in IMG tag.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0118::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:XSS using Script Via Encoded URI Schemes::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",,"",
+85,"Doubled Character XSS Manipulations",Variant,Draft,"The web application does not filter user-controlled input for executable script disguised using doubling of the involved characters.","",::NATURE:ChildOf:CWE ID:79:VIEW ID:1000:ORDINAL:Primary::NATURE:PeerOf:CWE ID:675:VIEW ID:1000::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:IMPACT:Read Application Data:IMPACT:Execute Unauthorized Code or Commands::","","::PHASE:Implementation:DESCRIPTION:Resolve all filtered input to absolute or canonical representations before processing.::PHASE:Implementation:DESCRIPTION:Carefully check each input parameter against a rigorous positive specification (allowlist) defining the specific characters and format allowed. All input should be neutralized, not just parameters that the user is supposed to specify, but all data in the request, including tag attributes, hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. We often encounter data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended.::PHASE:Implementation:STRATEGY:Output Encoding:DESCRIPTION:Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component. The problem of inconsistent output encodings often arises in web pages. If an encoding is not specified in an HTTP header, web browsers often guess about which encoding is being used. This can open up the browser to subtle XSS attacks.::PHASE:Implementation:DESCRIPTION:With Struts, write all data from form beans with the bean's filter attribute set to true.::PHASE:Implementation:STRATEGY:Attack Surface Reduction:DESCRIPTION:To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.:EFFECTIVENESS:Defense in Depth::","::REFERENCE:CVE-2002-2086:DESCRIPTION:XSS using , , and &, which could then be used to add new data or modify XML syntax.",::NATURE:ChildOf:CWE ID:74:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:74:VIEW ID:1003:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Read Application Data:IMPACT:Modify Application Data::","::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.::","",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:XML injection (aka Blind Xpath injection)::TAXONOMY NAME:OWASP Top Ten 2007:ENTRY ID:A2:ENTRY NAME:Injection Flaws:MAPPING FIT:CWE More Specific::TAXONOMY NAME:OWASP Top Ten 2004:ENTRY ID:A6:ENTRY NAME:Injection Flaws:MAPPING FIT:CWE More Specific::TAXONOMY NAME:WASC:ENTRY ID:23:ENTRY NAME:XML Injection::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",::250::83::,"::TYPE:Maintenance:NOTE:The description for this entry is generally applicable to XML, but the name includes blind XPath injection which is more closely associated with CWE-643. Therefore this entry might need to be deprecated or converted to a general category - although injection into raw XML is not covered by CWE-643 or CWE-652.::TYPE:Theoretical:NOTE:In vulnerability theory terms, this is a representation-specific case of a Data/Directive Boundary Error.::TYPE:Research Gap:NOTE:Under-reported. This is likely found regularly by third party code auditors, but there are very few publicly reported examples.::",
+93,"Improper Neutralization of CRLF Sequences ('CRLF Injection')",Base,Draft,"The product uses CRLF (carriage return line feeds) as a special element, e.g. to separate lines or records, but it does not neutralize or incorrectly neutralizes CRLF sequences from inputs.","",::NATURE:ChildOf:CWE ID:74:VIEW ID:1000:ORDINAL:Primary::NATURE:CanPrecede:CWE ID:117:VIEW ID:1000::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::","",,"::SCOPE:Integrity:IMPACT:Modify Application Data::","::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","::PHASE:Implementation:DESCRIPTION:Avoid using CRLF as a special sequence.::PHASE:Implementation:DESCRIPTION:Appropriately filter or quote CRLF sequences in user-controlled input.::","::REFERENCE:CVE-2002-1771:DESCRIPTION:CRLF injection enables spam proxy (add mail headers) using email address or name.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1771::REFERENCE:CVE-2002-1783:DESCRIPTION:CRLF injection in API function arguments modify headers for outgoing requests.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1783::REFERENCE:CVE-2004-1513:DESCRIPTION:Spoofed entries in web server log file via carriage returns:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1513::REFERENCE:CVE-2006-4624:DESCRIPTION:Chain: inject fake log entries with fake timestamps using CRLF injection:LINK:https://www.cve.org/CVERecord?id=CVE-2006-4624::REFERENCE:CVE-2005-1951:DESCRIPTION:Chain: Application accepts CRLF in an object ID, allowing HTTP response splitting.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1951::REFERENCE:CVE-2004-1687:DESCRIPTION:Chain: HTTP response splitting via CRLF in parameter related to URL.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1687::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:CRLF Injection::TAXONOMY NAME:OWASP Top Ten 2007:ENTRY ID:A2:ENTRY NAME:Injection Flaws:MAPPING FIT:CWE More Specific::TAXONOMY NAME:WASC:ENTRY ID:24:ENTRY NAME:HTTP Request Splitting::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",::15::81::,"",
+94,"Improper Control of Generation of Code ('Code Injection')",Base,Draft,"The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.","When a product allows a user's input to contain code syntax, it might be possible for an attacker to craft the code in such a way that it will alter the intended control flow of the product. Such an alteration could lead to arbitrary code execution. Injection problems encompass a wide variety of issues -- all mitigated in very different ways. For this reason, the most effective way to discuss these weaknesses is to note the distinct features which classify them as injection weaknesses. The most important issue to note is that all injection problems share one thing in common -- i.e., they allow for the injection of control plane data into the user-controlled data plane. This means that the execution of the process may be altered by sending code in through legitimate data channels, using no other mechanism. While buffer overflows, and many other flaws, involve the use of some further issue to gain execution, injection problems need only for the data to be parsed. The most classic instantiations of this category of weakness are SQL injection and format string vulnerabilities.",::NATURE:ChildOf:CWE ID:74:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:74:VIEW ID:1003:ORDINAL:Primary::NATURE:ChildOf:CWE ID:913:VIEW ID:1000::,"",::LANGUAGE CLASS:Interpreted:LANGUAGE PREVALENCE:Sometimes::,"","","::PHASE:Implementation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::","",,"::SCOPE:Access Control:IMPACT:Bypass Protection Mechanism:NOTE:In some cases, injectable code controls authentication; this may lead to a remote vulnerability.::SCOPE:Access Control:IMPACT:Gain Privileges or Assume Identity:NOTE:Injected code can access resources that the attacker is directly prevented from accessing.::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:IMPACT:Execute Unauthorized Code or Commands:NOTE:Code injection attacks can lead to loss of data integrity in nearly all cases as the control-plane data injected is always incidental to data recall or writing. Additionally, code injection can often result in the execution of arbitrary code.::SCOPE:Non-Repudiation:IMPACT:Hide Activities:NOTE:Often the actions performed by injected control code are unlogged.::","::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","::PHASE:Architecture and Design:DESCRIPTION:Refactor your program so that you do not have to dynamically generate code.::PHASE:Architecture and Design:DESCRIPTION:Run your code in a jail or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product. Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. To reduce the likelihood of code injection, use stringent allowlists that limit which constructs are allowed. If you are dynamically constructing code that invokes a function, then verifying that the input is alphanumeric might be insufficient. An attacker might still be able to reference a dangerous function that you did not intend to allow, such as system(), exec(), or exit().::PHASE:Testing:DESCRIPTION:Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible.::PHASE:Testing:DESCRIPTION:Use dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.::PHASE:Operation:STRATEGY:Compilation or Build Hardening:DESCRIPTION:Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's -T switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).::PHASE:Operation:STRATEGY:Environment Hardening:DESCRIPTION:Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's -T switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).::PHASE:Implementation:DESCRIPTION:For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].:EFFECTIVENESS:Discouraged Common Practice::","::REFERENCE:CVE-2022-2054:DESCRIPTION:Python compiler uses eval() to execute malicious strings as Python code.:LINK:https://www.cve.org/CVERecord?id=CVE-2022-2054::REFERENCE:CVE-2021-22204:DESCRIPTION:Chain: regex in EXIF processor code does not correctly determine where a string ends (CWE-625), enabling eval injection (CWE-95), as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2021-22204::REFERENCE:CVE-2020-8218:DESCRIPTION:Code injection in VPN product, as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-8218::REFERENCE:CVE-2008-5071:DESCRIPTION:Eval injection in PHP program.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-5071::REFERENCE:CVE-2002-1750:DESCRIPTION:Eval injection in Perl program.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1750::REFERENCE:CVE-2008-5305:DESCRIPTION:Eval injection in Perl program using an ID that should only contain hyphens and numbers.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-5305::REFERENCE:CVE-2002-1752:DESCRIPTION:Direct code injection into Perl eval function.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1752::REFERENCE:CVE-2002-1753:DESCRIPTION:Eval injection in Perl program.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1753::REFERENCE:CVE-2005-1527:DESCRIPTION:Direct code injection into Perl eval function.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1527::REFERENCE:CVE-2005-2837:DESCRIPTION:Direct code injection into Perl eval function.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-2837::REFERENCE:CVE-2005-1921:DESCRIPTION:MFV. code injection into PHP eval statement using nested constructs that should not be nested.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1921::REFERENCE:CVE-2005-2498:DESCRIPTION:MFV. code injection into PHP eval statement using nested constructs that should not be nested.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-2498::REFERENCE:CVE-2005-3302:DESCRIPTION:Code injection into Python eval statement from a field in a formatted file.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-3302::REFERENCE:CVE-2007-1253:DESCRIPTION:Eval injection in Python program.:LINK:https://www.cve.org/CVERecord?id=CVE-2007-1253::REFERENCE:CVE-2001-1471:DESCRIPTION:chain: Resultant eval injection. An invalid value prevents initialization of variables, which can be modified by attacker and later injected into PHP eval statement.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1471::REFERENCE:CVE-2002-0495:DESCRIPTION:Perl code directly injected into CGI library file from parameters to another CGI program.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0495::REFERENCE:CVE-2005-1876:DESCRIPTION:Direct PHP code injection into supporting template file.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1876::REFERENCE:CVE-2005-1894:DESCRIPTION:Direct code injection into PHP script that can be accessed by attacker.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1894::REFERENCE:CVE-2003-0395:DESCRIPTION:PHP code from User-Agent HTTP header directly inserted into log file implemented as PHP script.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0395::",,,"::TAXONOMY NAME:PLOVER:ENTRY ID:CODE:ENTRY NAME:Code Evaluation and Injection::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-2:ENTRY NAME:Req CR 3.5::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 3-3:ENTRY NAME:Req SR 3.5::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-1:ENTRY NAME:Req SVV-1::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-1:ENTRY NAME:Req SVV-3::",::242::35::77::,"",
+95,"Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')",Variant,Incomplete,"The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before using the input in a dynamic evaluation call (e.g. eval).","This may allow an attacker to execute arbitrary code, or at least modify what code can be executed.",::NATURE:ChildOf:CWE ID:94:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE NAME:Java:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:JavaScript:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:Python:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:Perl:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:PHP:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:Ruby:LANGUAGE PREVALENCE:Undetermined::LANGUAGE CLASS:Interpreted:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::PHASE:Implementation:NOTE:This weakness is prevalent in handler/dispatch procedures that might want to invoke a large number of functions, or set a large number of variables.::","",,"::SCOPE:Confidentiality:IMPACT:Read Files or Directories:IMPACT:Read Application Data:NOTE:The injected code could access restricted data / files.::SCOPE:Access Control:IMPACT:Bypass Protection Mechanism:NOTE:In some cases, injectable code controls authentication; this may lead to a remote vulnerability.::SCOPE:Access Control:IMPACT:Gain Privileges or Assume Identity:NOTE:Injected code can access resources that the attacker is directly prevented from accessing.::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:SCOPE:Other:IMPACT:Execute Unauthorized Code or Commands:NOTE:Code injection attacks can lead to loss of data integrity in nearly all cases as the control-plane data injected is always incidental to data recall or writing. Additionally, code injection can often result in the execution of arbitrary code.::SCOPE:Non-Repudiation:IMPACT:Hide Activities:NOTE:Often the actions performed by injected control code are unlogged.::","::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","::PHASE:Architecture and Design Implementation:DESCRIPTION:If possible, refactor your code so that it does not need to use eval() at all.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.::PHASE:Implementation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control. Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.::PHASE:Implementation:DESCRIPTION:For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].:EFFECTIVENESS:Discouraged Common Practice::","::REFERENCE:CVE-2022-2054:DESCRIPTION:Python compiler uses eval() to execute malicious strings as Python code.:LINK:https://www.cve.org/CVERecord?id=CVE-2022-2054::REFERENCE:CVE-2021-22204:DESCRIPTION:Chain: regex in EXIF processor code does not correctly determine where a string ends (CWE-625), enabling eval injection (CWE-95), as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2021-22204::REFERENCE:CVE-2021-22205:DESCRIPTION:Chain: backslash followed by a newline can bypass a validation step (CWE-20), leading to eval injection (CWE-95), as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2021-22205::REFERENCE:CVE-2008-5071:DESCRIPTION:Eval injection in PHP program.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-5071::REFERENCE:CVE-2002-1750:DESCRIPTION:Eval injection in Perl program.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1750::REFERENCE:CVE-2008-5305:DESCRIPTION:Eval injection in Perl program using an ID that should only contain hyphens and numbers.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-5305::REFERENCE:CVE-2002-1752:DESCRIPTION:Direct code injection into Perl eval function.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1752::REFERENCE:CVE-2002-1753:DESCRIPTION:Eval injection in Perl program.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1753::REFERENCE:CVE-2005-1527:DESCRIPTION:Direct code injection into Perl eval function.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1527::REFERENCE:CVE-2005-2837:DESCRIPTION:Direct code injection into Perl eval function.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-2837::REFERENCE:CVE-2005-1921:DESCRIPTION:MFV. code injection into PHP eval statement using nested constructs that should not be nested.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1921::REFERENCE:CVE-2005-2498:DESCRIPTION:MFV. code injection into PHP eval statement using nested constructs that should not be nested.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-2498::REFERENCE:CVE-2005-3302:DESCRIPTION:Code injection into Python eval statement from a field in a formatted file.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-3302::REFERENCE:CVE-2007-1253:DESCRIPTION:Eval injection in Python program.:LINK:https://www.cve.org/CVERecord?id=CVE-2007-1253::REFERENCE:CVE-2001-1471:DESCRIPTION:chain: Resultant eval injection. An invalid value prevents initialization of variables, which can be modified by attacker and later injected into PHP eval statement.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1471::REFERENCE:CVE-2007-2713:DESCRIPTION:Chain: Execution after redirect triggers eval injection.:LINK:https://www.cve.org/CVERecord?id=CVE-2007-2713::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Direct Dynamic Code Evaluation ('Eval Injection')::TAXONOMY NAME:OWASP Top Ten 2007:ENTRY ID:A3:ENTRY NAME:Malicious File Execution:MAPPING FIT:CWE More Specific::TAXONOMY NAME:OWASP Top Ten 2004:ENTRY ID:A6:ENTRY NAME:Injection Flaws:MAPPING FIT:CWE More Specific::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::TAXONOMY NAME:SEI CERT Perl Coding Standard:ENTRY ID:IDS35-PL:ENTRY NAME:Do not invoke the eval form with a string argument:MAPPING FIT:Exact::",::35::,"::TYPE:Other:NOTE:Factors: special character errors can play a role in increasing the variety of code that can be injected, although some vulnerabilities do not require special characters at all, e.g. when a single function without arguments can be referenced and a terminator character is not necessary.::",
+96,"Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection')",Base,Draft,"The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before inserting the input into an executable resource, such as a library, configuration file, or template.","",::NATURE:ChildOf:CWE ID:94:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE NAME:PHP:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:Perl:LANGUAGE PREVALENCE:Undetermined::LANGUAGE CLASS:Interpreted:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::PHASE:Implementation:NOTE:This issue is frequently found in PHP applications that allow users to set configuration variables that are stored within executable PHP files. Technically, this could also be performed in some compiled code (e.g., by byte-patching an executable), although it is highly unlikely.::","",,"::SCOPE:Confidentiality:IMPACT:Read Files or Directories:IMPACT:Read Application Data:NOTE:The injected code could access restricted data / files.::SCOPE:Access Control:IMPACT:Bypass Protection Mechanism:NOTE:In some cases, injectable code controls authentication; this may lead to a remote vulnerability.::SCOPE:Access Control:IMPACT:Gain Privileges or Assume Identity:NOTE:Injected code can access resources that the attacker is directly prevented from accessing.::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:SCOPE:Other:IMPACT:Execute Unauthorized Code or Commands:NOTE:Code injection attacks can lead to loss of data integrity in nearly all cases as the control-plane data injected is always incidental to data recall or writing. Additionally, code injection can often result in the execution of arbitrary code.::SCOPE:Non-Repudiation:IMPACT:Hide Activities:NOTE:Often the actions performed by injected control code are unlogged.::","","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.::PHASE:Implementation:STRATEGY:Output Encoding:DESCRIPTION:Perform proper output validation and escaping to neutralize all code syntax from data written to code files.::","::REFERENCE:CVE-2002-0495:DESCRIPTION:Perl code directly injected into CGI library file from parameters to another CGI program.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0495::REFERENCE:CVE-2005-1876:DESCRIPTION:Direct PHP code injection into supporting template file.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1876::REFERENCE:CVE-2005-1894:DESCRIPTION:Direct code injection into PHP script that can be accessed by attacker.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1894::REFERENCE:CVE-2003-0395:DESCRIPTION:PHP code from User-Agent HTTP header directly inserted into log file implemented as PHP script.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0395::REFERENCE:CVE-2007-6652:DESCRIPTION:chain: execution after redirect allows non-administrator to perform static code injection.:LINK:https://www.cve.org/CVERecord?id=CVE-2007-6652::",,::File or Directory::,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Direct Static Code Injection::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted Input to Command::",::35::73::77::81::85::,"::TYPE:Relationship:NOTE:HTML injection (see CWE-79: XSS) could be thought of as an example of this, but the code is injected and executed on the client side, not the server side. Server-Side Includes (SSI) are an example of direct static code injection.::",
+97,"Improper Neutralization of Server-Side Includes (SSI) Within a Web Page",Variant,Draft,"The product generates a web page, but does not neutralize or incorrectly neutralizes user-controllable input that could be interpreted as a server-side include (SSI) directive.","",::NATURE:ChildOf:CWE ID:96:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:IMPACT:Execute Unauthorized Code or Commands::","","","",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Server-Side Includes (SSI) Injection::TAXONOMY NAME:WASC:ENTRY ID:36:ENTRY NAME:SSI Injection::",::101::35::,"::TYPE:Relationship:NOTE:This can be resultant from XSS/HTML injection because the same special characters can be involved. However, this is server-side code execution, not client-side.::",
+98,"Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')",Variant,Draft,"The PHP application receives input from an upstream component, but it does not restrict or incorrectly restricts the input before its usage in require, include, or similar functions.","In certain versions and configurations of PHP, this can allow an attacker to specify a URL to a remote location from which the product will obtain the code to execute. In other cases in association with path traversal, the attacker can specify a local file that may contain executable statements that can be parsed by PHP.",::NATURE:ChildOf:CWE ID:706:VIEW ID:1000::NATURE:ChildOf:CWE ID:829:VIEW ID:1000:ORDINAL:Primary::NATURE:CanPrecede:CWE ID:94:VIEW ID:1000::NATURE:CanAlsoBe:CWE ID:426:VIEW ID:1000::,"",::LANGUAGE NAME:PHP:LANGUAGE PREVALENCE:Often::,"","::TERM:Remote file include::TERM:RFI:DESCRIPTION:The Remote File Inclusion (RFI) acronym is often used by vulnerability researchers.::TERM:Local file inclusion:DESCRIPTION:This term is frequently used in cases in which remote download is disabled, or when the first part of the filename is not under the attacker's control, which forces use of relative path traversal (CWE-23) attack techniques to access files that may contain previously-injected PHP code, such as web access logs.::","::PHASE:Implementation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::","",,"::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:IMPACT:Execute Unauthorized Code or Commands:NOTE:The attacker may be able to specify arbitrary code to be executed from a remote location. Alternatively, it may be possible to use normal program behavior to insert php code into files on the local machine which can then be included and force the code to execute since php ignores everything in the file except for the content between php specifiers.::","::METHOD:Manual Analysis:DESCRIPTION:Manual white-box analysis can be very effective for finding this issue, since there is typically a relatively small number of include or require statements in each program.:EFFECTIVENESS:High::METHOD:Automated Static Analysis:DESCRIPTION:The external control or influence of filenames can often be detected using automated static analysis that models data flow within the product. Automated static analysis might not be able to recognize when proper input validation is being performed, leading to false positives - i.e., warnings that do not have any security consequences or require any code changes. If the program uses a customized input validation library, then some tools may allow the analyst to create custom signatures to detect usage of those routines.::","::PHASE:Architecture and Design:STRATEGY:Libraries or Frameworks:DESCRIPTION:Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.::PHASE:Architecture and Design:STRATEGY:Enforcement by Conversion:DESCRIPTION:When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs. For example, ID 1 could map to inbox.txt and ID 2 could map to profile.txt. Features such as the ESAPI AccessReferenceMap [REF-185] provide this capability.::PHASE:Architecture and Design:DESCRIPTION:For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.::PHASE:Architecture and Design Operation:STRATEGY:Sandbox or Jail:DESCRIPTION:Run the code in a jail or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software. OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.:EFFECTIVENESS:Limited::PHASE:Architecture and Design Operation:STRATEGY:Environment Hardening:DESCRIPTION:Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When validating filenames, use stringent lists that limit the character set to be used. If feasible, only allow a single . character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as / to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering / is insufficient protection if the filesystem also supports the use of as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if ../ sequences are removed from the .../...// string in a sequential fashion, two instances of ../ would be removed from the original string, but the remaining characters would still form the ../ string.:EFFECTIVENESS:High::PHASE:Architecture and Design Operation:STRATEGY:Attack Surface Reduction:DESCRIPTION:Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server's access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and it can exit immediately. This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include files. It will also reduce the attack surface.::PHASE:Architecture and Design Implementation:STRATEGY:Attack Surface Reduction:DESCRIPTION:Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls. Many file inclusion problems occur because the programmer assumed that certain inputs could not be modified, especially for cookies and URL components.::PHASE:Operation:STRATEGY:Firewall:DESCRIPTION:Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.:EFFECTIVENESS:Moderate::PHASE:Operation Implementation:STRATEGY:Environment Hardening:DESCRIPTION:Develop and run your code in the most recent versions of PHP available, preferably PHP 6 or later. Many of the highly risky features in earlier PHP interpreters have been removed, restricted, or disabled by default.::PHASE:Operation Implementation:STRATEGY:Environment Hardening:DESCRIPTION:When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues. Often, programmers do not protect direct access to files intended only to be included by core programs. These include files may assume that critical variables have already been initialized by the calling program. As a result, the use of register_globals combined with the ability to directly access the include file may allow attackers to conduct file inclusion attacks. This remains an extremely common pattern as of 2009.::PHASE:Operation:STRATEGY:Environment Hardening:DESCRIPTION:Set allow_url_fopen to false, which limits the ability to include files from remote locations.:EFFECTIVENESS:High::","::REFERENCE:CVE-2004-0285:DESCRIPTION:Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0285::REFERENCE:CVE-2004-0030:DESCRIPTION:Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0030::REFERENCE:CVE-2004-0068:DESCRIPTION:Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0068::REFERENCE:CVE-2005-2157:DESCRIPTION:Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-2157::REFERENCE:CVE-2005-2162:DESCRIPTION:Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-2162::REFERENCE:CVE-2005-2198:DESCRIPTION:Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-2198::REFERENCE:CVE-2004-0128:DESCRIPTION:Modification of assumed-immutable variable in configuration script leads to file inclusion.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0128::REFERENCE:CVE-2005-1864:DESCRIPTION:PHP file inclusion.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1864::REFERENCE:CVE-2005-1869:DESCRIPTION:PHP file inclusion.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1869::REFERENCE:CVE-2005-1870:DESCRIPTION:PHP file inclusion.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1870::REFERENCE:CVE-2005-2154:DESCRIPTION:PHP local file inclusion.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-2154::REFERENCE:CVE-2002-1704:DESCRIPTION:PHP remote file include.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1704::REFERENCE:CVE-2002-1707:DESCRIPTION:PHP remote file include.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1707::REFERENCE:CVE-2005-1964:DESCRIPTION:PHP remote file include.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1964::REFERENCE:CVE-2005-1681:DESCRIPTION:PHP remote file include.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1681::REFERENCE:CVE-2005-2086:DESCRIPTION:PHP remote file include.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-2086::REFERENCE:CVE-2004-0127:DESCRIPTION:Directory traversal vulnerability in PHP include statement.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0127::REFERENCE:CVE-2005-1971:DESCRIPTION:Directory traversal vulnerability in PHP include statement.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1971::REFERENCE:CVE-2005-3335:DESCRIPTION:PHP file inclusion issue, both remote and local; local include uses .. and %00 characters as a manipulation, but many remote file inclusion issues probably have this vector.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-3335::REFERENCE:CVE-2009-1936:DESCRIPTION:chain: library file sends a redirect if it is directly requested but continues to execute, allowing remote file inclusion and path traversal.:LINK:https://www.cve.org/CVERecord?id=CVE-2009-1936::",,::File or Directory::,"::TAXONOMY NAME:PLOVER:ENTRY NAME:PHP File Include::TAXONOMY NAME:OWASP Top Ten 2007:ENTRY ID:A3:ENTRY NAME:Malicious File Execution:MAPPING FIT:CWE More Specific::TAXONOMY NAME:WASC:ENTRY ID:5:ENTRY NAME:Remote File Inclusion::",::193::,"::TYPE:Relationship:NOTE:This is frequently a functional consequence of other weaknesses. It is usually multi-factor with other factors (e.g. MAID), although not all inclusion bugs involve assumed-immutable data. Direct request weaknesses frequently play a role. Can overlap directory traversal in local inclusion problems.::",
+99,"Improper Control of Resource Identifiers ('Resource Injection')",Class,Draft,"The product receives input from an upstream component, but it does not restrict or incorrectly restricts the input before it is used as an identifier for a resource that may be outside the intended sphere of control.","A resource injection issue occurs when the following two conditions are met: An attacker can specify the identifier used to access a system resource. For example, an attacker might be able to specify part of the name of a file to be opened or a port number to be used. By specifying the resource, the attacker gains a capability that would not otherwise be permitted. For example, the program may give the attacker the ability to overwrite the specified file, run with a configuration controlled by the attacker, or transmit sensitive information to a third-party server. This may enable an attacker to access or modify otherwise protected system resources.",::NATURE:ChildOf:CWE ID:74:VIEW ID:1000:ORDINAL:Primary::NATURE:PeerOf:CWE ID:706:VIEW ID:1000::NATURE:CanAlsoBe:CWE ID:73:VIEW ID:1000::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","::TERM:Insecure Direct Object Reference:DESCRIPTION:OWASP uses this term, although it is effectively the same as resource injection.::","::PHASE:Architecture and Design::PHASE:Implementation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Application Data:IMPACT:Modify Application Data:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories:NOTE:An attacker could gain access to or modify sensitive data or system resources. This could allow access to protected files or directories including configuration files and files containing sensitive information.::","::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, it can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.::","::REFERENCE:CVE-2013-4787:DESCRIPTION:chain: mobile OS verifies cryptographic signature of file in an archive, but then installs a different file with the same name that is also listed in the archive.:LINK:https://www.cve.org/CVERecord?id=CVE-2013-4787::",,,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:Resource Injection::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::TAXONOMY NAME:OMG ASCSM:ENTRY ID:ASCSM-CWE-99::",::10::240::75::,"::TYPE:Relationship:NOTE:Resource injection that involves resources stored on the filesystem goes by the name path manipulation (CWE-73).::TYPE:Maintenance:NOTE:The relationship between CWE-99 and CWE-610 needs further investigation and clarification. They might be duplicates. CWE-99 Resource Injection, as originally defined in Seven Pernicious Kingdoms taxonomy, emphasizes the identifier used to access a system resource such as a file name or port number, yet it explicitly states that the resource injection term does not apply to path manipulation, which effectively identifies the path at which a resource can be found and could be considered to be one aspect of a resource identifier. Also, CWE-610 effectively covers any type of resource, whether that resource is at the system layer, the application layer, or the code layer.::",
+102,"Struts: Duplicate Validation Forms",Variant,Incomplete,"The product uses multiple validation forms with the same name, which might cause the Struts Validator to validate a form that the programmer does not expect.","If two validation forms have the same name, the Struts Validator arbitrarily chooses one of the forms to use for input validation and discards the other. This decision might not correspond to the programmer's expectations, possibly leading to resultant weaknesses. Moreover, it indicates that the validation logic is not up-to-date, and can indicate that other, more subtle validation errors are present.",::NATURE:ChildOf:CWE ID:694:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:1173:VIEW ID:1000::NATURE:ChildOf:CWE ID:20:VIEW ID:700:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE NAME:Java:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Integrity:IMPACT:Unexpected State::","","::PHASE:Implementation:DESCRIPTION:The DTD or schema validation will not catch the duplicate occurrence of the same form name. To find the issue in the implementation, manual checks or automated static analysis could be applied to the xml configuration files.::","",,,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:Struts: Duplicate Validation Forms::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",,"",
+103,"Struts: Incomplete validate() Method Definition",Variant,Draft,"The product has a validator form that either does not define a validate() method, or defines a validate() method but does not call super.validate().","If the code does not call super.validate(), the Validation Framework cannot check the contents of the form against a validation form. In other words, the validation framework will be disabled for the given form.",::NATURE:ChildOf:CWE ID:573:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:20:VIEW ID:700:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE NAME:Java:LANGUAGE PREVALENCE:Undetermined::,"::The Struts Validator uses a form's validate() method to check the contents of the form properties against the constraints specified in the associated validation form. That means the following classes have a validate() method that is part of the validation framework: ValidatorForm, ValidatorActionForm, DynaValidatorForm, and DynaValidatorActionForm. If the code creates a class that extends one of these classes, and if that class implements custom validation logic by overriding the validate() method, the code must call super.validate() in the validate() implementation.::","","::PHASE:Implementation::","",,"::SCOPE:Other:IMPACT:Other:NOTE:Disabling the validation framework for a form exposes the product to numerous types of attacks. Unchecked input is the root cause of vulnerabilities like cross-site scripting, process control, and SQL injection.::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Other:IMPACT:Other:NOTE:Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.::","::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","::PHASE:Implementation:DESCRIPTION:Implement the validate() method and call super.validate() within that method.::","",,,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:Struts: Erroneous validate() Method::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",,"::TYPE:Relationship:NOTE:This could introduce other weaknesses related to missing input validation.::TYPE:Maintenance:NOTE:The current description implies a loose composite of two separate weaknesses, so this node might need to be split or converted into a low-level category.::",
+104,"Struts: Form Bean Does Not Extend Validation Class",Variant,Draft,"If a form bean does not extend an ActionForm subclass of the Validator framework, it can expose the application to other weaknesses related to insufficient input validation.","",::NATURE:ChildOf:CWE ID:573:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:20:VIEW ID:700:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE NAME:Java:LANGUAGE PREVALENCE:Undetermined::,"::In order to use the Struts Validator, a form must extend one of the following: ValidatorForm, ValidatorActionForm, DynaValidatorActionForm, and DynaValidatorForm. One of these classes must be extended because the Struts Validator ties in to the application by implementing the validate() method in these classes. Forms derived from the ActionForm and DynaActionForm classes cannot use the Struts Validator.::","","::PHASE:Implementation::","",,"::SCOPE:Other:IMPACT:Other:NOTE:Bypassing the validation framework for a form exposes the application to numerous types of attacks. Unchecked input is an important component of vulnerabilities like cross-site scripting, process control, and SQL injection.::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Other:IMPACT:Other:NOTE:Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.::","::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","::PHASE:Implementation:DESCRIPTION:Ensure that all forms extend one of the Validation Classes.::","",,,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:Struts: Form Bean Does Not Extend Validation Class::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",,"",
+105,"Struts: Form Field Without Validator",Variant,Draft,"The product has a form field that is not validated by a corresponding validation form, which can introduce other weaknesses related to insufficient input validation.","Omitting validation for even a single input field may give attackers the leeway they need to compromise the product. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.",::NATURE:ChildOf:CWE ID:1173:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:20:VIEW ID:700:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE NAME:Java:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation:NOTE:Some products use the same ActionForm for more than one purpose. In situations like this, some fields may go unused under some action mappings.::","",,"::SCOPE:Integrity:IMPACT:Unexpected State::SCOPE:Integrity:IMPACT:Bypass Protection Mechanism:NOTE:If unused fields are not validated, shared business logic in an action may allow attackers to bypass the validation checks that are performed for other uses of the form.::","","::PHASE:Implementation:DESCRIPTION:Validate all form fields. If a field is unused, it is still important to constrain it so that it is empty or undefined.::","",,,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:Struts: Form Field Without Validator::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",,"",
+106,"Struts: Plug-in Framework not in Use",Variant,Draft,"When an application does not use an input validation framework such as the Struts Validator, there is a greater risk of introducing weaknesses related to insufficient input validation.","Unchecked input is the leading cause of vulnerabilities in J2EE applications. Unchecked input leads to cross-site scripting, process control, and SQL injection vulnerabilities, among others. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.",::NATURE:ChildOf:CWE ID:1173:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:20:VIEW ID:700:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE NAME:Java:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Integrity:IMPACT:Unexpected State::","","::PHASE:Architecture and Design:STRATEGY:Input Validation:DESCRIPTION:Use an input validation framework such as Struts.::PHASE:Architecture and Design:STRATEGY:Libraries or Frameworks:DESCRIPTION:Use an input validation framework such as Struts.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Use the Struts Validator to validate all program input before it is processed by the application. Ensure that there are no holes in the configuration of the Struts Validator. Example uses of the validator include checking to ensure that: Phone number fields contain only valid characters in phone numbers Boolean values are only T or F Free-form strings are of a reasonable length and composition::PHASE:Implementation:STRATEGY:Libraries or Frameworks:DESCRIPTION:Use the Struts Validator to validate all program input before it is processed by the application. Ensure that there are no holes in the configuration of the Struts Validator. Example uses of the validator include checking to ensure that: Phone number fields contain only valid characters in phone numbers Boolean values are only T or F Free-form strings are of a reasonable length and composition::","",,,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:Struts: Plug-in Framework Not In Use::",,"",
+107,"Struts: Unused Validation Form",Variant,Draft,"An unused validation form indicates that validation logic is not up-to-date.","It is easy for developers to forget to update validation logic when they remove or rename action form mappings. One indication that validation logic is not being properly maintained is the presence of an unused validation form.",::NATURE:ChildOf:CWE ID:1164:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:20:VIEW ID:700:ORDINAL:Primary::,"::ORDINALITY:Resultant::",::LANGUAGE NAME:Java:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::PHASE:Operation::","",,"::SCOPE:Other:IMPACT:Quality Degradation::","","::PHASE:Implementation:DESCRIPTION:Remove the unused Validation Form from the validation.xml file.::","",,,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:Struts: Unused Validation Form::",,"",
+108,"Struts: Unvalidated Action Form",Variant,Incomplete,"Every Action Form must have a corresponding validation form.","If a Struts Action Form Mapping specifies a form, it must have a validation form defined under the Struts Validator.",::NATURE:ChildOf:CWE ID:1173:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:20:VIEW ID:700:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE NAME:Java:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Other:IMPACT:Other:NOTE:If an action form mapping does not have a validation form defined, it may be vulnerable to a number of attacks that rely on unchecked input. Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities all stem from incomplete or absent input validation.::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Other:IMPACT:Other:NOTE:Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.::","","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Map every Action Form to a corresponding validation form. An action or a form may perform validation in other ways, but the Struts Validator provides an excellent way to verify that all input receives at least a basic level of validation. Without this approach, it is difficult, and often impossible, to establish with a high level of confidence that all input is validated.::","",,,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:Struts: Unvalidated Action Form::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",,"",
+109,"Struts: Validator Turned Off",Variant,Draft,"Automatic filtering via a Struts bean has been turned off, which disables the Struts Validator and custom validation logic. This exposes the application to other weaknesses related to insufficient input validation.","",::NATURE:ChildOf:CWE ID:1173:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:20:VIEW ID:700:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE NAME:Java:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Access Control:IMPACT:Bypass Protection Mechanism::","","::PHASE:Implementation:DESCRIPTION:Ensure that an action form mapping enables validation. Set the validate field to true.::","",,,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:Struts: Validator Turned Off::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",,"::TYPE:Other:NOTE:The Action Form mapping in the demonstrative example disables the form's validate() method. The Struts bean: write tag automatically encodes special HTML characters, replacing a < with < and a > with >. This action can be disabled by specifying filter=false as an attribute of the tag to disable specified JSP pages. However, being disabled makes these pages susceptible to cross-site scripting attacks. An attacker may be able to insert malicious scripts as user input to write to these JSP pages.::",
+110,"Struts: Validator Without Form Field",Variant,Draft,"Validation fields that do not appear in forms they are associated with indicate that the validation logic is out of date.","It is easy for developers to forget to update validation logic when they make changes to an ActionForm class. One indication that validation logic is not being properly maintained is inconsistencies between the action form and the validation form. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.",::NATURE:ChildOf:CWE ID:1164:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:20:VIEW ID:700:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE NAME:Java:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::PHASE:Operation::","",,"::SCOPE:Other:IMPACT:Other:NOTE:It is critically important that validation logic be maintained and kept in sync with the rest of the application. Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities all stem from incomplete or absent input validation.::","::METHOD:Automated Static Analysis:DESCRIPTION:To find the issue in the implementation, manual checks or automated static analysis could be applied to the XML configuration files.:EFFECTIVENESS:Moderate::METHOD:Manual Static Analysis:DESCRIPTION:To find the issue in the implementation, manual checks or automated static analysis could be applied to the XML configuration files.:EFFECTIVENESS:Moderate::","","",,,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:Struts: Validator Without Form Field::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",,"",
+111,"Direct Use of Unsafe JNI",Variant,Draft,"When a Java application uses the Java Native Interface (JNI) to call code written in another programming language, it can expose the application to weaknesses in that code, even if those weaknesses cannot occur in Java.","Many safety features that programmers may take for granted do not apply for native code, so you must carefully review all such code for potential problems. The languages used to implement native code may be more susceptible to buffer overflows and other attacks. Native code is unprotected by the security features enforced by the runtime environment, such as strong typing and array bounds checking.",::NATURE:ChildOf:CWE ID:695:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:20:VIEW ID:700:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE NAME:Java:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Access Control:IMPACT:Bypass Protection Mechanism::","::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","::PHASE:Implementation:DESCRIPTION:Implement error handling around the JNI call.::PHASE:Implementation:STRATEGY:Refactoring:DESCRIPTION:Do not use JNI calls if you don't trust the native library.::PHASE:Implementation:STRATEGY:Refactoring:DESCRIPTION:Be reluctant to use JNI calls. A Java API equivalent may exist.::","",,,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:Unsafe JNI::TAXONOMY NAME:The CERT Oracle Secure Coding Standard for Java (2011):ENTRY ID:SEC08-J:ENTRY NAME:Define wrappers around native methods::TAXONOMY NAME:SEI CERT Oracle Coding Standard for Java:ENTRY ID:JNI01-J:ENTRY NAME:Safely invoke standard APIs that perform tasks using the immediate caller's class loader instance (loadLibrary)::TAXONOMY NAME:SEI CERT Oracle Coding Standard for Java:ENTRY ID:JNI00-J:ENTRY NAME:Define wrappers around native methods:MAPPING FIT:Imprecise::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP3:ENTRY NAME:Use of an improper API::",,"",
+112,"Missing XML Validation",Base,Draft,"The product accepts XML from an untrusted source but does not validate the XML against the proper schema.","Most successful attacks begin with a violation of the programmer's assumptions. By accepting an XML document without validating it against a DTD or XML schema, the programmer leaves a door open for attackers to provide unexpected, unreasonable, or malicious input.",::NATURE:ChildOf:CWE ID:1286:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:20:VIEW ID:700:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Integrity:IMPACT:Unexpected State::","::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","::PHASE:Architecture and Design:STRATEGY:Input Validation:DESCRIPTION:Always validate XML input against a known XML Schema or DTD. It is not possible for an XML parser to validate all aspects of a document's content because a parser cannot understand the complete semantics of the data. However, a parser can do a complete and thorough job of checking the document's structure and therefore guarantee to the code that processes the document that the content is well-formed.::","",,,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:Missing XML Validation::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",::230::231::,"",
+113,"Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')",Variant,Incomplete,"The product receives data from an HTTP agent/component (e.g., web server, proxy, browser, etc.), but it does not neutralize or incorrectly neutralizes CR and LF characters before the data is included in outgoing HTTP headers.","HTTP agents or components may include a web server, load balancer, reverse proxy, web caching proxy, application firewall, web browser, etc. Regardless of the role, they are expected to maintain coherent, consistent HTTP communication state across all components. However, including unexpected data in an HTTP header allows an attacker to specify the entirety of the HTTP message that is rendered by the client HTTP agent (e.g., web browser) or back-end HTTP agent (e.g., web server), whether the message is part of a request or a response. When an HTTP request contains unexpected CR and LF characters, the server may respond with an output stream that is interpreted as splitting the stream into two different HTTP messages instead of one. CR is carriage return, also given by %0d or r, and LF is line feed, also given by %0a or n. In addition to CR and LF characters, other valid/RFC compliant special characters and unique character encodings can be utilized, such as HT (horizontal tab, also given by %09 or t) and SP (space, also given as + sign or %20). These types of unvalidated and unexpected data in HTTP message headers allow an attacker to control the second split message to mount attacks such as server-side request forgery, cross-site scripting, and cache poisoning attacks. HTTP response splitting weaknesses may be present when: Data enters a web application through an untrusted source, most frequently an HTTP request. The data is included in an HTTP response header sent to a web user without neutralizing malicious characters that can be interpreted as separator characters for headers.",::NATURE:ChildOf:CWE ID:93:VIEW ID:1000:ORDINAL:Primary::NATURE:CanPrecede:CWE ID:79:VIEW ID:1000::NATURE:ChildOf:CWE ID:20:VIEW ID:700:ORDINAL:Primary::NATURE:ChildOf:CWE ID:436:VIEW ID:1000::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Web Based:TECHNOLOGY PREVALENCE:Undetermined::,"","::TERM:HTTP Request Splitting::TERM:HTTP Response Splitting::","::PHASE:Implementation::","",,"::SCOPE:Integrity:SCOPE:Access Control:IMPACT:Modify Application Data:IMPACT:Gain Privileges or Assume Identity:NOTE:CR and LF characters in an HTTP header may give attackers control of the remaining headers and body of the message that the application intends to send/receive, as well as allowing them to create additional messages entirely under their control.::","::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Construct HTTP headers very carefully, avoiding the use of non-validated input data.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. If an input does not strictly conform to specifications, reject it or transform it into something that conforms. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.::PHASE:Implementation:STRATEGY:Output Encoding:DESCRIPTION:Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2020-15811:DESCRIPTION:Chain: Proxy uses a substring search instead of parsing the Transfer-Encoding header (CWE-697), allowing request splitting (CWE-113) and cache poisoning:LINK:https://www.cve.org/CVERecord?id=CVE-2020-15811::REFERENCE:CVE-2021-41084:DESCRIPTION:Scala-based HTTP interface allows request splitting and response splitting through header names, header values, status reasons, and URIs:LINK:https://www.cve.org/CVERecord?id=CVE-2021-41084::REFERENCE:CVE-2018-12116:DESCRIPTION:Javascript-based framework allows request splitting through a path option of an HTTP request:LINK:https://www.cve.org/CVERecord?id=CVE-2018-12116::REFERENCE:CVE-2004-2146:DESCRIPTION:Application accepts CRLF in an object ID, allowing HTTP response splitting.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-2146::REFERENCE:CVE-2004-1656:DESCRIPTION:Shopping cart allows HTTP response splitting to perform HTML injection via CRLF in a parameter for a url:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1656::REFERENCE:CVE-2005-2060:DESCRIPTION:Bulletin board allows response splitting via CRLF in parameter.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-2060::REFERENCE:CVE-2004-2512:DESCRIPTION:Response splitting via CRLF in PHPSESSID.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-2512::REFERENCE:CVE-2005-1951:DESCRIPTION:e-commerce app allows HTTP response splitting using CRLF in object id parameters:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1951::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:HTTP response splitting::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:HTTP Response Splitting::TAXONOMY NAME:WASC:ENTRY ID:25:ENTRY NAME:HTTP Response Splitting::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",::105::31::34::85::,"",
+114,"Process Control",Class,Incomplete,"Executing commands or loading libraries from an untrusted source or in an untrusted environment can cause an application to execute malicious commands (and payloads) on behalf of an attacker.","Process control vulnerabilities take two forms: An attacker can change the command that the program executes: the attacker explicitly controls what the command is. An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means. Process control vulnerabilities of the first type occur when either data enters the application from an untrusted source and the data is used as part of a string representing a command that is executed by the application. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.",::NATURE:ChildOf:CWE ID:73:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:20:VIEW ID:700:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:IMPACT:Execute Unauthorized Code or Commands::","::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","::PHASE:Architecture and Design:STRATEGY:Libraries or Frameworks:DESCRIPTION:Libraries that are loaded should be well understood and come from a trusted source. The application can execute code contained in the native libraries, which often contain calls that are susceptible to other security problems, such as buffer overflows or command injection. All native libraries should be validated to determine if the application requires the use of the library. It is very difficult to determine what these native libraries actually do, and the potential for malicious code is high. In addition, the potential for an inadvertent mistake in these native libraries is also high, as many are written in C or C++ and may be susceptible to buffer overflow or race condition problems. To help prevent buffer overflow attacks, validate all input to native calls for content and length. If the native library does not come from a trusted source, review the source code of the library. The library should be built from the reviewed source before using it.::","",,::System Process::,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:Process Control::",::108::640::,"::TYPE:Maintenance:NOTE:CWE-114 is a Class, but it is listed a child of CWE-73 in view 1000. This suggests some abstraction problems that should be resolved in future versions.::TYPE:Maintenance:NOTE:This entry seems to have close relationships with CWE-426/CWE-427. It seems more attack-oriented.::",
+115,"Misinterpretation of Input",Base,Incomplete,"The product misinterprets an input, whether from an attacker or another product, in a security-relevant fashion.","",::NATURE:ChildOf:CWE ID:436:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Architecture and Design::PHASE:Implementation::","",,"::SCOPE:Integrity:IMPACT:Unexpected State::","::METHOD:Fuzzing:DESCRIPTION:Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.:EFFECTIVENESS:High::","","::REFERENCE:CVE-2005-2225:DESCRIPTION:Product sees dangerous file extension in free text of a group discussion, disconnects all users.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-2225::REFERENCE:CVE-2001-0003:DESCRIPTION:Product does not correctly import and process security settings from another product.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0003::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Misinterpretation Error::",,"::TYPE:Research Gap:NOTE:This concept needs further study. It is likely a factor in several weaknesses, possibly resultant as well. Overlaps Multiple Interpretation Errors (MIE).::",
+116,"Improper Encoding or Escaping of Output",Class,Draft,"The product prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly. As a result, the intended structure of the message is not preserved.","Improper encoding or escaping can allow attackers to change the commands that are sent to another component, inserting malicious commands instead. Most products follow a certain protocol that uses structured messages for communication between components, such as queries or commands. These structured messages can contain raw data interspersed with metadata or control information. For example, GET /index.html HTTP/1.1 is a structured message containing a command (GET) with a single argument (/index.html) and metadata about which protocol version is being used (HTTP/1.1). If an application uses attacker-supplied inputs to construct a structured message without properly encoding or escaping, then the attacker could insert special characters that will cause the data to be interpreted as control information or metadata. Consequently, the component that receives the output will perform the wrong operations, or otherwise interpret the data incorrectly.",::NATURE:ChildOf:CWE ID:707:VIEW ID:1000:ORDINAL:Primary::NATURE:CanPrecede:CWE ID:74:VIEW ID:1000::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Often::TECHNOLOGY NAME:Database Server:TECHNOLOGY PREVALENCE:Often::TECHNOLOGY NAME:Web Server:TECHNOLOGY PREVALENCE:Often::,"","::TERM:Output Sanitization::TERM:Output Validation::TERM:Output Encoding::","::PHASE:Implementation::PHASE:Operation::","",,"::SCOPE:Integrity:IMPACT:Modify Application Data:NOTE:The communications between components can be modified in unexpected ways. Unexpected commands can be executed, bypassing other security mechanisms. Incoming data can be misinterpreted.::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:SCOPE:Access Control:IMPACT:Execute Unauthorized Code or Commands:NOTE:The communications between components can be modified in unexpected ways. Unexpected commands can be executed, bypassing other security mechanisms. Incoming data can be misinterpreted.::SCOPE:Confidentiality:IMPACT:Bypass Protection Mechanism:NOTE:The communications between components can be modified in unexpected ways. Unexpected commands can be executed, bypassing other security mechanisms. Incoming data can be misinterpreted.::","::METHOD:Automated Static Analysis:DESCRIPTION:This weakness can often be detected using automated static analysis tools. Many modern tools use data flow analysis or constraint-based techniques to minimize the number of false positives.:EFFECTIVENESS:Moderate::METHOD:Automated Dynamic Analysis:DESCRIPTION:This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.::","::PHASE:Architecture and Design:STRATEGY:Libraries or Frameworks:DESCRIPTION:Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using the ESAPI Encoding control [REF-45] or a similar tool, library, or framework. These will help the programmer encode outputs in a manner less prone to error. Alternately, use built-in functions, but consider using wrappers in case those functions are discovered to have a vulnerability.::PHASE:Architecture and Design:STRATEGY:Parameterization:DESCRIPTION:If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated. For example, stored procedures can enforce database query structure and reduce the likelihood of SQL injection.::PHASE:Architecture and Design Implementation:DESCRIPTION:Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.::PHASE:Architecture and Design:DESCRIPTION:In some cases, input validation may be an important strategy when output encoding is not a complete solution. For example, you may be providing the same output that will be processed by multiple consumers that use different encodings or representations. In other cases, you may be required to allow user-supplied input to contain control information, such as limited HTML tags that support formatting in a wiki or bulletin board. When this type of requirement must be met, use an extremely strict allowlist to limit which control sequences can be used. Verify that the resulting syntactic structure is what you expect. Use your normal encoding methods for the remainder of the input.::PHASE:Architecture and Design:DESCRIPTION:Use input validation as a defense-in-depth measure to reduce the likelihood of output encoding errors (see CWE-20).::PHASE:Requirements:DESCRIPTION:Fully specify which encodings are required by components that will be communicating with each other.::PHASE:Implementation:DESCRIPTION:When exchanging data between components, ensure that both components are using the same character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set the encoding you are using whenever the protocol allows you to do so.::","::REFERENCE:CVE-2021-41232:DESCRIPTION:Chain: authentication routine in Go-based agile development product does not escape user name (CWE-116), allowing LDAP injection (CWE-90):LINK:https://www.cve.org/CVERecord?id=CVE-2021-41232::REFERENCE:CVE-2008-4636:DESCRIPTION:OS command injection in backup software using shell metacharacters in a filename; correct behavior would require that this filename could not be changed.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-4636::REFERENCE:CVE-2008-0769:DESCRIPTION:Web application does not set the charset when sending a page to a browser, allowing for XSS exploitation when a browser chooses an unexpected encoding.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-0769::REFERENCE:CVE-2008-0005:DESCRIPTION:Program does not set the charset when sending a page to a browser, allowing for XSS exploitation when a browser chooses an unexpected encoding.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-0005::REFERENCE:CVE-2008-5573:DESCRIPTION:SQL injection via password parameter; a strong password might contain &:LINK:https://www.cve.org/CVERecord?id=CVE-2008-5573::REFERENCE:CVE-2008-3773:DESCRIPTION:Cross-site scripting in chat application via a message subject, which normally might contain & and other XSS-related characters.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-3773::REFERENCE:CVE-2008-0757:DESCRIPTION:Cross-site scripting in chat application via a message, which normally might be allowed to contain arbitrary content.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-0757::",,,"::TAXONOMY NAME:WASC:ENTRY ID:22:ENTRY NAME:Improper Output Handling::TAXONOMY NAME:The CERT Oracle Secure Coding Standard for Java (2011):ENTRY ID:IDS00-J:ENTRY NAME:Sanitize untrusted data passed across a trust boundary:MAPPING FIT:Exact::TAXONOMY NAME:The CERT Oracle Secure Coding Standard for Java (2011):ENTRY ID:IDS05-J:ENTRY NAME:Use a subset of ASCII for file and path names::TAXONOMY NAME:SEI CERT Oracle Coding Standard for Java:ENTRY ID:IDS00-J:ENTRY NAME:Prevent SQL injection:MAPPING FIT:Imprecise::TAXONOMY NAME:SEI CERT Perl Coding Standard:ENTRY ID:IDS33-PL:ENTRY NAME:Sanitize untrusted data passed across a trust boundary:MAPPING FIT:Exact::",::104::73::81::85::,"::TYPE:Relationship:NOTE:This weakness is primary to all weaknesses related to injection (CWE-74) since the inherent nature of injection involves the violation of structured messages.::TYPE:Relationship:NOTE:CWE-116 and CWE-20 have a close association because, depending on the nature of the structured message, proper input validation can indirectly prevent special characters from changing the meaning of a structured message. For example, by validating that a numeric ID field should only contain the 0-9 characters, the programmer effectively prevents injection attacks. However, input validation is not always sufficient, especially when less stringent data types must be supported, such as free-form text. Consider a SQL injection scenario in which a last name is inserted into a query. The name O'Reilly would likely pass the validation step since it is a common last name in the English language. However, it cannot be directly inserted into the database because it contains the ' apostrophe character, which would need to be escaped or otherwise neutralized. In this case, stripping the apostrophe might reduce the risk of SQL injection, but it would produce incorrect behavior because the wrong name would be recorded.::TYPE:Terminology:NOTE:The usage of the encoding and escaping terms varies widely. For example, in some programming languages, the terms are used interchangeably, while other languages provide APIs that use both terms for different tasks. This overlapping usage extends to the Web, such as the escape JavaScript function whose purpose is stated to be encoding. The concepts of encoding and escaping predate the Web by decades. Given such a context, it is difficult for CWE to adopt a consistent vocabulary that will not be misinterpreted by some constituency.::TYPE:Theoretical:NOTE:This is a data/directive boundary error in which data boundaries are not sufficiently enforced before it is sent to a different control sphere.::TYPE:Research Gap:NOTE:While many published vulnerabilities are related to insufficient output encoding, there is such an emphasis on input validation as a protection mechanism that the underlying causes are rarely described. Within CVE, the focus is primarily on well-understood issues like cross-site scripting and SQL injection. It is likely that this weakness frequently occurs in custom protocols that support multiple encodings, which are not necessarily detectable with automated techniques.::",
+117,"Improper Output Neutralization for Logs",Base,Draft,"The product does not neutralize or incorrectly neutralizes output that is written to logs.","This can allow an attacker to forge log entries or inject malicious content into logs. Log forging vulnerabilities occur when: Data enters an application from an untrusted source. The data is written to an application or system log file.",::NATURE:ChildOf:CWE ID:116:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:20:VIEW ID:700:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"::Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.::","","::PHASE:Implementation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::","",,"::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:SCOPE:Non-Repudiation:IMPACT:Modify Application Data:IMPACT:Hide Activities:IMPACT:Execute Unauthorized Code or Commands:NOTE:Interpretation of the log files may be hindered or misdirected if an attacker can supply data to the application that is subsequently logged verbatim. In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. Forged or otherwise corrupted log files can be used to cover an attacker's tracks, possibly by skewing statistics, or even to implicate another party in the commission of a malicious act. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility.::","::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.::PHASE:Implementation:STRATEGY:Output Encoding:DESCRIPTION:Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2006-4624:DESCRIPTION:Chain: inject fake log entries with fake timestamps using CRLF injection:LINK:https://www.cve.org/CVERecord?id=CVE-2006-4624::",,,"::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:Log Forging::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP23:ENTRY NAME:Exposed Data::TAXONOMY NAME:The CERT Oracle Secure Coding Standard for Java (2011):ENTRY ID:IDS03-J:ENTRY NAME:Do not log unsanitized user input:MAPPING FIT:Exact::TAXONOMY NAME:SEI CERT Oracle Coding Standard for Java:ENTRY ID:IDS03-J:ENTRY NAME:Do not log unsanitized user input:MAPPING FIT:Exact::",::268::81::93::,"",
+118,"Incorrect Access of Indexable Resource ('Range Error')",Class,Incomplete,"The product does not restrict or incorrectly restricts operations within the boundaries of a resource that is accessed using an index or pointer, such as memory or files.","",::NATURE:ChildOf:CWE ID:664:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Other:IMPACT:Varies by Context::","","","",,,"::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP8:ENTRY NAME:Faulty Buffer Access::",::10::14::24::45::46::47::8::9::,"",
+119,"Improper Restriction of Operations within the Bounds of a Memory Buffer",Class,Stable,"The product performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.","Certain languages allow direct addressing of memory locations and do not automatically ensure that these locations are valid for the memory buffer that is being referenced. This can cause read or write operations to be performed on memory locations that may be associated with other variables, data structures, or internal program data. As a result, an attacker may be able to execute arbitrary code, alter the intended control flow, read sensitive information, or cause the system to crash.",::NATURE:ChildOf:CWE ID:118:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:20:VIEW ID:700:ORDINAL:Primary::,"",::LANGUAGE NAME:C:LANGUAGE PREVALENCE:Often::LANGUAGE NAME:C++:LANGUAGE PREVALENCE:Often::LANGUAGE CLASS:Assembly:LANGUAGE PREVALENCE:Undetermined::,"","::TERM:Buffer Overflow:DESCRIPTION:This term has many different meanings to different audiences. From a CWE mapping perspective, this term should be avoided where possible. Some researchers, developers, and tools intend for it to mean write past the end of a buffer, whereas others use the same term to mean any read or write outside the boundaries of a buffer, whether before the beginning of the buffer or after the end of the buffer. Still others using the same term could mean any action after the end of a buffer, whether it is a read or write. Since the term is commonly used for exploitation and for vulnerabilities, it further confuses things.::TERM:buffer overrun:DESCRIPTION:Some prominent vendors and researchers use the term buffer overrun, but most people use buffer overflow. See the alternate term for buffer overflow for context.::TERM:memory safety:DESCRIPTION:Generally used for techniques that avoid weaknesses related to memory access, such as those identified by CWE-119 and its descendants. However, the term is not formal, and there is likely disagreement between practitioners as to which weaknesses are implicitly covered by the memory safety term.::","::PHASE:Implementation::","",,"::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Modify Memory:NOTE:If the memory accessible by the attacker can be effectively controlled, it may be possible to execute arbitrary code, as with a standard buffer overflow. If the attacker can overwrite a pointer's worth of memory (usually 32 or 64 bits), they can redirect a function pointer to their own malicious code. Even when the attacker can only modify a single byte arbitrary code execution can be possible. Sometimes this is because the same problem can be exploited repeatedly to the same effect. Other times it is because the attacker can overwrite security-critical application-specific data -- such as a flag indicating whether the user is an administrator.::SCOPE:Availability:SCOPE:Confidentiality:IMPACT:Read Memory:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:DoS: Resource Consumption (CPU):IMPACT:DoS: Resource Consumption (Memory):NOTE:Out of bounds memory access will very likely result in the corruption of relevant memory, and perhaps instructions, possibly leading to a crash. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.::SCOPE:Confidentiality:IMPACT:Read Memory:NOTE:In the case of an out-of-bounds read, the attacker may have access to sensitive information. If the sensitive information contains system details, such as the current buffers position in memory, this knowledge can be used to craft further attacks, possibly with more severe consequences.::","::METHOD:Automated Static Analysis:DESCRIPTION:This weakness can often be detected using automated static analysis tools. Many modern tools use data flow analysis or constraint-based techniques to minimize the number of false positives. Automated static analysis generally does not account for environmental considerations when reporting out-of-bounds memory operations. This can make it difficult for users to determine which warnings should be investigated first. For example, an analysis tool might report buffer overflows that originate from command line arguments in a program that is not expected to run with setuid or other special privileges.:EFFECTIVENESS:High::METHOD:Automated Dynamic Analysis:DESCRIPTION:This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.::METHOD:Automated Static Analysis - Binary or Bytecode:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Binary / Bytecode Quality Analysis Bytecode Weakness Analysis - including disassembler + source code weakness analysis Binary Weakness Analysis - including disassembler + source code weakness analysis:EFFECTIVENESS:SOAR Partial::METHOD:Manual Static Analysis - Binary or Bytecode:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies:EFFECTIVENESS:SOAR Partial::METHOD:Dynamic Analysis with Automated Results Interpretation:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Web Application Scanner Web Services Scanner Database Scanners:EFFECTIVENESS:SOAR Partial::METHOD:Dynamic Analysis with Manual Results Interpretation:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Fuzz Tester Framework-based Fuzzer:EFFECTIVENESS:SOAR Partial::METHOD:Manual Static Analysis - Source Code:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Focused Manual Spotcheck - Focused manual analysis of source Manual Source Code Review (not inspections):EFFECTIVENESS:SOAR Partial::METHOD:Automated Static Analysis - Source Code:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer Cost effective for partial coverage: Source Code Quality Analyzer:EFFECTIVENESS:High::METHOD:Architecture or Design Review:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Formal Methods / Correct-By-Construction Cost effective for partial coverage: Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.):EFFECTIVENESS:High::","::PHASE:Requirements:STRATEGY:Language Selection:DESCRIPTION:Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer. Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.::PHASE:Architecture and Design:STRATEGY:Libraries or Frameworks:DESCRIPTION:Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Examples include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions.::PHASE:Operation Build and Compilation:STRATEGY:Environment Hardening:DESCRIPTION:Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking. D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.:EFFECTIVENESS:Defense in Depth::PHASE:Implementation:DESCRIPTION:Consider adhering to the following rules when allocating and managing an application's memory: Double check that the buffer is as large as specified. When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string. Check buffer boundaries if accessing the buffer in a loop and make sure there is no danger of writing past the allocated space. If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.::PHASE:Operation Build and Compilation:STRATEGY:Environment Hardening:DESCRIPTION:Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code. Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as rebasing (for Windows) and prelinking (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking. For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].:EFFECTIVENESS:Defense in Depth::PHASE:Operation:STRATEGY:Environment Hardening:DESCRIPTION:Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment. For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336].:EFFECTIVENESS:Defense in Depth::PHASE:Implementation:DESCRIPTION:Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available.:EFFECTIVENESS:Moderate::","::REFERENCE:CVE-2021-22991:DESCRIPTION:Incorrect URI normalization in application traffic product leads to buffer overflow, as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2021-22991::REFERENCE:CVE-2020-29557:DESCRIPTION:Buffer overflow in Wi-Fi router web interface, as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-29557::REFERENCE:CVE-2009-2550:DESCRIPTION:Classic stack-based buffer overflow in media player using a long entry in a playlist:LINK:https://www.cve.org/CVERecord?id=CVE-2009-2550::REFERENCE:CVE-2009-2403:DESCRIPTION:Heap-based buffer overflow in media player using a long entry in a playlist:LINK:https://www.cve.org/CVERecord?id=CVE-2009-2403::REFERENCE:CVE-2009-0689:DESCRIPTION:large precision value in a format string triggers overflow:LINK:https://www.cve.org/CVERecord?id=CVE-2009-0689::REFERENCE:CVE-2009-0690:DESCRIPTION:negative offset value leads to out-of-bounds read:LINK:https://www.cve.org/CVERecord?id=CVE-2009-0690::REFERENCE:CVE-2009-1532:DESCRIPTION:malformed inputs cause accesses of uninitialized or previously-deleted objects, leading to memory corruption:LINK:https://www.cve.org/CVERecord?id=CVE-2009-1532::REFERENCE:CVE-2009-1528:DESCRIPTION:chain: lack of synchronization leads to memory corruption:LINK:https://www.cve.org/CVERecord?id=CVE-2009-1528::REFERENCE:CVE-2021-29529:DESCRIPTION:Chain: machine-learning product can have a heap-based buffer overflow (CWE-122) when some integer-oriented bounds are calculated by using ceiling() and floor() on floating point values (CWE-1339):LINK:https://www.cve.org/CVERecord?id=CVE-2021-29529::REFERENCE:CVE-2009-0558:DESCRIPTION:attacker-controlled array index leads to code execution:LINK:https://www.cve.org/CVERecord?id=CVE-2009-0558::REFERENCE:CVE-2009-0269:DESCRIPTION:chain: -1 value from a function call was intended to indicate an error, but is used as an array index instead.:LINK:https://www.cve.org/CVERecord?id=CVE-2009-0269::REFERENCE:CVE-2009-0566:DESCRIPTION:chain: incorrect calculations lead to incorrect pointer dereference and memory corruption:LINK:https://www.cve.org/CVERecord?id=CVE-2009-0566::REFERENCE:CVE-2009-1350:DESCRIPTION:product accepts crafted messages that lead to a dereference of an arbitrary pointer:LINK:https://www.cve.org/CVERecord?id=CVE-2009-1350::REFERENCE:CVE-2009-0191:DESCRIPTION:chain: malformed input causes dereference of uninitialized memory:LINK:https://www.cve.org/CVERecord?id=CVE-2009-0191::REFERENCE:CVE-2008-4113:DESCRIPTION:OS kernel trusts userland-supplied length value, allowing reading of sensitive information:LINK:https://www.cve.org/CVERecord?id=CVE-2008-4113::REFERENCE:CVE-2005-1513:DESCRIPTION:Chain: integer overflow in securely-coded mail program leads to buffer overflow. In 2005, this was regarded as unrealistic to exploit, but in 2020, it was rediscovered to be easier to exploit due to evolutions of the technology.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1513::REFERENCE:CVE-2003-0542:DESCRIPTION:buffer overflow involving a regular expression with a large number of captures:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0542::REFERENCE:CVE-2017-1000121:DESCRIPTION:chain: unchecked message size metadata allows integer overflow (CWE-190) leading to buffer overflow (CWE-119).:LINK:https://www.cve.org/CVERecord?id=CVE-2017-1000121::",,::Memory::,"::TAXONOMY NAME:OWASP Top Ten 2004:ENTRY ID:A5:ENTRY NAME:Buffer Overflows:MAPPING FIT:Exact::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:ARR00-C:ENTRY NAME:Understand how arrays work::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:ARR30-C:ENTRY NAME:Do not form or use out-of-bounds pointers or array subscripts:MAPPING FIT:CWE More Abstract::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:ARR38-C:ENTRY NAME:Guarantee that library functions do not form invalid pointers:MAPPING FIT:CWE More Abstract::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:ENV01-C:ENTRY NAME:Do not make assumptions about the size of an environment variable::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:EXP39-C:ENTRY NAME:Do not access a variable through a pointer of an incompatible type:MAPPING FIT:Imprecise::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:FIO37-C:ENTRY NAME:Do not assume character data has been read::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:STR31-C:ENTRY NAME:Guarantee that storage for strings has sufficient space for character data and the null terminator:MAPPING FIT:CWE More Abstract::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:STR32-C:ENTRY NAME:Do not pass a non-null-terminated character sequence to a library function that expects a string:MAPPING FIT:CWE More Abstract::TAXONOMY NAME:WASC:ENTRY ID:7:ENTRY NAME:Buffer Overflow::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP8:ENTRY NAME:Faulty Buffer Access::",::10::100::123::14::24::42::44::45::46::47::8::9::,"::TYPE:Applicable Platform:NOTE:It is possible in any programming languages without memory management support to attempt an operation outside of the bounds of a memory buffer, but the consequences will vary widely depending on the language, platform, and chip architecture.::",
+120,"Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')",Base,Incomplete,"The product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.","A buffer overflow condition exists when a product attempts to put more data in a buffer than it can hold, or when it attempts to put data in a memory area outside of the boundaries of a buffer. The simplest type of error, and the most common cause of buffer overflows, is the classic case in which the product copies the buffer without restricting how much is copied. Other variants exist, but the existence of a classic overflow strongly suggests that the programmer is not considering even the most basic of security protections.",::NATURE:ChildOf:CWE ID:119:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:119:VIEW ID:1003:ORDINAL:Primary::NATURE:ChildOf:CWE ID:119:VIEW ID:1305:ORDINAL:Primary::NATURE:ChildOf:CWE ID:119:VIEW ID:1340:ORDINAL:Primary::NATURE:CanPrecede:CWE ID:123:VIEW ID:1000::NATURE:ChildOf:CWE ID:20:VIEW ID:700:ORDINAL:Primary::,"::ORDINALITY:Resultant::ORDINALITY:Primary::",::LANGUAGE NAME:C:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:C++:LANGUAGE PREVALENCE:Undetermined::LANGUAGE CLASS:Assembly:LANGUAGE PREVALENCE:Undetermined::,"","::TERM:Classic Buffer Overflow:DESCRIPTION:This term was frequently used by vulnerability researchers during approximately 1995 to 2005 to differentiate buffer copies without length checks (which had been known about for decades) from other emerging weaknesses that still involved invalid accesses of buffers, as vulnerability researchers began to develop advanced exploitation techniques.::TERM:Unbounded Transfer::","::PHASE:Implementation::","",,"::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:IMPACT:Modify Memory:IMPACT:Execute Unauthorized Code or Commands:NOTE:Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of the product's implicit security policy. This can often be used to subvert any other security service.::SCOPE:Availability:IMPACT:Modify Memory:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:DoS: Resource Consumption (CPU):NOTE:Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the product into an infinite loop.::","::METHOD:Automated Static Analysis:DESCRIPTION:This weakness can often be detected using automated static analysis tools. Many modern tools use data flow analysis or constraint-based techniques to minimize the number of false positives. Automated static analysis generally does not account for environmental considerations when reporting out-of-bounds memory operations. This can make it difficult for users to determine which warnings should be investigated first. For example, an analysis tool might report buffer overflows that originate from command line arguments in a program that is not expected to run with setuid or other special privileges.:EFFECTIVENESS:High::METHOD:Automated Dynamic Analysis:DESCRIPTION:This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.::METHOD:Manual Analysis:DESCRIPTION:Manual analysis can be useful for finding this weakness, but it might not achieve desired code coverage within limited time constraints. This becomes difficult for weaknesses that must be considered for all inputs, since the attack surface can be too large.::METHOD:Automated Static Analysis - Binary or Bytecode:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Bytecode Weakness Analysis - including disassembler + source code weakness analysis Binary Weakness Analysis - including disassembler + source code weakness analysis:EFFECTIVENESS:High::METHOD:Manual Static Analysis - Binary or Bytecode:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies:EFFECTIVENESS:SOAR Partial::METHOD:Dynamic Analysis with Automated Results Interpretation:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Web Application Scanner Web Services Scanner Database Scanners:EFFECTIVENESS:SOAR Partial::METHOD:Dynamic Analysis with Manual Results Interpretation:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Fuzz Tester Framework-based Fuzzer:EFFECTIVENESS:SOAR Partial::METHOD:Manual Static Analysis - Source Code:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Focused Manual Spotcheck - Focused manual analysis of source Manual Source Code Review (not inspections):EFFECTIVENESS:SOAR Partial::METHOD:Automated Static Analysis - Source Code:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer:EFFECTIVENESS:High::METHOD:Architecture or Design Review:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Formal Methods / Correct-By-Construction Cost effective for partial coverage: Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.):EFFECTIVENESS:High::","::PHASE:Requirements:STRATEGY:Language Selection:DESCRIPTION:Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer. Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.::PHASE:Architecture and Design:STRATEGY:Libraries or Frameworks:DESCRIPTION:Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Examples include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions.::PHASE:Operation Build and Compilation:STRATEGY:Environment Hardening:DESCRIPTION:Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking. D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.:EFFECTIVENESS:Defense in Depth::PHASE:Implementation:DESCRIPTION:Consider adhering to the following rules when allocating and managing an application's memory: Double check that your buffer is as large as you specify. When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string. Check buffer boundaries if accessing the buffer in a loop and make sure there is no danger of writing past the allocated space. If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.::PHASE:Architecture and Design:DESCRIPTION:For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.::PHASE:Operation Build and Compilation:STRATEGY:Environment Hardening:DESCRIPTION:Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code. Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as rebasing (for Windows) and prelinking (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking. For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].:EFFECTIVENESS:Defense in Depth::PHASE:Operation:STRATEGY:Environment Hardening:DESCRIPTION:Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment. For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336].:EFFECTIVENESS:Defense in Depth::PHASE:Build and Compilation Operation:DESCRIPTION:Most mitigating technologies at the compiler or OS level to date address only a subset of buffer overflow problems and rarely provide complete protection against even that subset. It is good practice to implement strategies to increase the workload of an attacker, such as leaving the attacker to guess an unknown value that changes every program execution.::PHASE:Implementation:DESCRIPTION:Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available.:EFFECTIVENESS:Moderate::PHASE:Architecture and Design:STRATEGY:Enforcement by Conversion:DESCRIPTION:When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.::PHASE:Architecture and Design Operation:STRATEGY:Environment Hardening:DESCRIPTION:Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.::PHASE:Architecture and Design Operation:STRATEGY:Sandbox or Jail:DESCRIPTION:Run the code in a jail or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software. OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.:EFFECTIVENESS:Limited::","::REFERENCE:CVE-2000-1094:DESCRIPTION:buffer overflow using command with long argument:LINK:https://www.cve.org/CVERecord?id=CVE-2000-1094::REFERENCE:CVE-1999-0046:DESCRIPTION:buffer overflow in local program using long environment variable:LINK:https://www.cve.org/CVERecord?id=CVE-1999-0046::REFERENCE:CVE-2002-1337:DESCRIPTION:buffer overflow in comment characters, when product increments a counter for a > but does not decrement for <:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1337::REFERENCE:CVE-2003-0595:DESCRIPTION:By replacing a valid cookie value with an extremely long string of characters, an attacker may overflow the application's buffers.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0595::REFERENCE:CVE-2001-0191:DESCRIPTION:By replacing a valid cookie value with an extremely long string of characters, an attacker may overflow the application's buffers.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0191::",::Memory Management::,::Memory::,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Unbounded Transfer ('classic overflow')::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:Buffer Overflow::TAXONOMY NAME:CLASP:ENTRY NAME:Buffer overflow::TAXONOMY NAME:OWASP Top Ten 2004:ENTRY ID:A1:ENTRY NAME:Unvalidated Input:MAPPING FIT:CWE More Specific::TAXONOMY NAME:OWASP Top Ten 2004:ENTRY ID:A5:ENTRY NAME:Buffer Overflows:MAPPING FIT:CWE More Specific::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:STR31-C:ENTRY NAME:Guarantee that storage for strings has sufficient space for character data and the null terminator:MAPPING FIT:Exact::TAXONOMY NAME:WASC:ENTRY ID:7:ENTRY NAME:Buffer Overflow::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP8:ENTRY NAME:Faulty Buffer Access::TAXONOMY NAME:OMG ASCSM:ENTRY ID:ASCSM-CWE-120::TAXONOMY NAME:OMG ASCRM:ENTRY ID:ASCRM-CWE-120::",::10::100::14::24::42::44::45::46::47::67::8::9::92::,"::TYPE:Relationship:NOTE:At the code level, stack-based and heap-based overflows do not differ significantly, so there usually is not a need to distinguish them. From the attacker perspective, they can be quite different, since different techniques are required to exploit them.::TYPE:Terminology:NOTE:Many issues that are now called buffer overflows are substantively different than the classic overflow, including entirely different bug types that rely on overflow exploit techniques, such as integer signedness errors, integer overflows, and format string bugs. This imprecise terminology can make it difficult to determine which variant is being reported.::",
+121,"Stack-based Buffer Overflow",Variant,Draft,"A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).","",::NATURE:ChildOf:CWE ID:788:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:787:VIEW ID:1000::,"::ORDINALITY:Primary::",::LANGUAGE NAME:C:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:C++:LANGUAGE PREVALENCE:Undetermined::,"::There are generally several security-critical data on an execution stack that can lead to arbitrary code execution. The most prominent is the stored return address, the memory address at which execution should continue once the current function is finished executing. The attacker can overwrite this value with some memory address to which the attacker also has write access, into which they place arbitrary code to be run with the full privileges of the vulnerable program. Alternately, the attacker can supply the address of an important call, for instance the POSIX system() call, leaving arguments to the call on the stack. This is often called a return into libc exploit, since the attacker generally forces the program to jump at return time into an interesting routine in the C standard library (libc). Other important data commonly on the stack include the stack pointer and frame pointer, two values that indicate offsets for computing memory addresses. Modifying those values can often be leveraged into a write-what-where condition.::","::TERM:Stack Overflow:DESCRIPTION:Stack Overflow is often used to mean the same thing as stack-based buffer overflow, however it is also used on occasion to mean stack exhaustion, usually a result from an excessively recursive function call. Due to the ambiguity of the term, use of stack overflow to describe either circumstance is discouraged.::","::PHASE:Implementation::","",,"::SCOPE:Availability:IMPACT:Modify Memory:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:DoS: Resource Consumption (CPU):IMPACT:DoS: Resource Consumption (Memory):NOTE:Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:SCOPE:Access Control:IMPACT:Modify Memory:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Bypass Protection Mechanism:NOTE:Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy.::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:SCOPE:Access Control:SCOPE:Other:IMPACT:Modify Memory:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Bypass Protection Mechanism:IMPACT:Other:NOTE:When the consequence is arbitrary code execution, this can often be used to subvert any other security service.::","::METHOD:Fuzzing:DESCRIPTION:Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.:EFFECTIVENESS:High::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","::PHASE:Operation Build and Compilation:STRATEGY:Environment Hardening:DESCRIPTION:Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking. D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.:EFFECTIVENESS:Defense in Depth::PHASE:Architecture and Design:DESCRIPTION:Use an abstraction library to abstract away risky APIs. Not a complete solution.::PHASE:Implementation:DESCRIPTION:Implement and perform bounds checking on input.::PHASE:Implementation:DESCRIPTION:Do not use dangerous functions such as gets. Use safer, equivalent functions which check for boundary errors.::PHASE:Operation Build and Compilation:STRATEGY:Environment Hardening:DESCRIPTION:Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code. Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as rebasing (for Windows) and prelinking (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking. For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].:EFFECTIVENESS:Defense in Depth::","::REFERENCE:CVE-2021-35395:DESCRIPTION:Stack-based buffer overflows in SFK for wifi chipset used for IoT/embedded devices, as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2021-35395::",,,"::TAXONOMY NAME:CLASP:ENTRY NAME:Stack overflow::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP8:ENTRY NAME:Faulty Buffer Access::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:ARR38-C:ENTRY NAME:Guarantee that library functions do not form invalid pointers:MAPPING FIT:Imprecise::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:STR31-C:ENTRY NAME:Guarantee that storage for strings has sufficient space for character data and the null terminator:MAPPING FIT:CWE More Specific::",,"::TYPE:Other:NOTE:Stack-based buffer overflows can instantiate in return address overwrites, stack pointer overwrites or frame pointer overwrites. They can also be considered function pointer overwrites, array indexer overwrites or write-what-where condition, etc.::",
+122,"Heap-based Buffer Overflow",Variant,Draft,"A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc().","",::NATURE:ChildOf:CWE ID:788:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:787:VIEW ID:1000::,"::ORDINALITY:Primary::",::LANGUAGE NAME:C:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:C++:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Availability:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:DoS: Resource Consumption (CPU):IMPACT:DoS: Resource Consumption (Memory):NOTE:Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:SCOPE:Access Control:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Bypass Protection Mechanism:IMPACT:Modify Memory:NOTE:Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy. Besides important user data, heap-based overflows can be used to overwrite function pointers that may be living in memory, pointing it to the attacker's code. Even in applications that do not explicitly use function pointers, the run-time will usually leave many in memory. For example, object methods in C++ are generally implemented using function pointers. Even in C programs, there is often a global offset table used by the underlying runtime.::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:SCOPE:Access Control:SCOPE:Other:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Bypass Protection Mechanism:IMPACT:Other:NOTE:When the consequence is arbitrary code execution, this can often be used to subvert any other security service.::","::METHOD:Fuzzing:DESCRIPTION:Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.:EFFECTIVENESS:High::","::PHASE::DESCRIPTION:Pre-design: Use a language or compiler that performs automatic bounds checking.::PHASE:Architecture and Design:DESCRIPTION:Use an abstraction library to abstract away risky APIs. Not a complete solution.::PHASE:Operation Build and Compilation:STRATEGY:Environment Hardening:DESCRIPTION:Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking. D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.:EFFECTIVENESS:Defense in Depth::PHASE:Operation Build and Compilation:STRATEGY:Environment Hardening:DESCRIPTION:Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code. Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as rebasing (for Windows) and prelinking (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking. For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].:EFFECTIVENESS:Defense in Depth::PHASE:Implementation:DESCRIPTION:Implement and perform bounds checking on input.::PHASE:Implementation:STRATEGY:Libraries or Frameworks:DESCRIPTION:Do not use dangerous functions such as gets. Look for their safe equivalent, which checks for the boundary.::PHASE:Operation:DESCRIPTION:Use OS-level preventative functionality. This is not a complete solution, but it provides some defense in depth.::","::REFERENCE:CVE-2021-43537:DESCRIPTION:Chain: in a web browser, an unsigned 64-bit integer is forcibly cast to a 32-bit integer (CWE-681) and potentially leading to an integer overflow (CWE-190). If an integer overflow occurs, this can cause heap memory corruption (CWE-122):LINK:https://www.cve.org/CVERecord?id=CVE-2021-43537::REFERENCE:CVE-2007-4268:DESCRIPTION:Chain: integer signedness error (CWE-195) passes signed comparison, leading to heap overflow (CWE-122):LINK:https://www.cve.org/CVERecord?id=CVE-2007-4268::REFERENCE:CVE-2009-2523:DESCRIPTION:Chain: product does not handle when an input string is not NULL terminated (CWE-170), leading to buffer over-read (CWE-125) or heap-based buffer overflow (CWE-122).:LINK:https://www.cve.org/CVERecord?id=CVE-2009-2523::REFERENCE:CVE-2021-29529:DESCRIPTION:Chain: machine-learning product can have a heap-based buffer overflow (CWE-122) when some integer-oriented bounds are calculated by using ceiling() and floor() on floating point values (CWE-1339):LINK:https://www.cve.org/CVERecord?id=CVE-2021-29529::REFERENCE:CVE-2010-1866:DESCRIPTION:Chain: integer overflow (CWE-190) causes a negative signed value, which later bypasses a maximum-only check (CWE-839), leading to heap-based buffer overflow (CWE-122).:LINK:https://www.cve.org/CVERecord?id=CVE-2010-1866::",,::Memory::,"::TAXONOMY NAME:CLASP:ENTRY NAME:Heap overflow::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP8:ENTRY NAME:Faulty Buffer Access::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:STR31-C:ENTRY NAME:Guarantee that storage for strings has sufficient space for character data and the null terminator:MAPPING FIT:CWE More Specific::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-2:ENTRY NAME:Req CR 3.5::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 3-3:ENTRY NAME:Req SR 3.5::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-1:ENTRY NAME:Req SI-1::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-1:ENTRY NAME:Req SI-2::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-1:ENTRY NAME:Req SVV-1::TAXONOMY NAME:ISA/IEC 62443:ENTRY ID:Part 4-1:ENTRY NAME:Req SVV-3::",::92::,"::TYPE:Relationship:NOTE:Heap-based buffer overflows are usually just as dangerous as stack-based buffer overflows.::",
+123,"Write-what-where Condition",Base,Draft,"Any condition where the attacker has the ability to write an arbitrary value to an arbitrary location, often as the result of a buffer overflow.","",::NATURE:ChildOf:CWE ID:787:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:119:VIEW ID:1305:ORDINAL:Primary::NATURE:ChildOf:CWE ID:119:VIEW ID:1340:ORDINAL:Primary::,"::ORDINALITY:Resultant::",::LANGUAGE NAME:C:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:C++:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:SCOPE:Access Control:IMPACT:Modify Memory:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Gain Privileges or Assume Identity:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:Bypass Protection Mechanism:NOTE:Clearly, write-what-where conditions can be used to write data to areas of memory outside the scope of a policy. Also, they almost invariably can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy. If the attacker can overwrite a pointer's worth of memory (usually 32 or 64 bits), they can redirect a function pointer to their own malicious code. Even when the attacker can only modify a single byte arbitrary code execution can be possible. Sometimes this is because the same problem can be exploited repeatedly to the same effect. Other times it is because the attacker can overwrite security-critical application-specific data -- such as a flag indicating whether the user is an administrator.::SCOPE:Integrity:SCOPE:Availability:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:Modify Memory:NOTE:Many memory accesses can lead to program termination, such as when writing to addresses that are invalid for the current process.::SCOPE:Access Control:SCOPE:Other:IMPACT:Bypass Protection Mechanism:IMPACT:Other:NOTE:When the consequence is arbitrary code execution, this can often be used to subvert any other security service.::","","::PHASE:Architecture and Design:STRATEGY:Language Selection:DESCRIPTION:Use a language that provides appropriate memory abstractions.::PHASE:Operation:DESCRIPTION:Use OS-level preventative functionality integrated after the fact. Not a complete solution.::","::REFERENCE:CVE-2022-21668:DESCRIPTION:Chain: Python library does not limit the resources used to process images that specify a very large number of bands (CWE-1284), leading to excessive memory consumption (CWE-789) or an integer overflow (CWE-190).:LINK:https://www.cve.org/CVERecord?id=CVE-2022-21668::REFERENCE:CVE-2022-0545:DESCRIPTION:Chain: 3D renderer has an integer overflow (CWE-190) leading to write-what-where condition (CWE-123) using a crafted image.:LINK:https://www.cve.org/CVERecord?id=CVE-2022-0545::",,,"::TAXONOMY NAME:CLASP:ENTRY NAME:Write-what-where condition::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:ARR30-C:ENTRY NAME:Do not form or use out-of-bounds pointers or array subscripts:MAPPING FIT:Imprecise::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:ARR38-C:ENTRY NAME:Guarantee that library functions do not form invalid pointers:MAPPING FIT:Imprecise::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:STR31-C:ENTRY NAME:Guarantee that storage for strings has sufficient space for character data and the null terminator:MAPPING FIT:Imprecise::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:STR32-C:ENTRY NAME:Do not pass a non-null-terminated character sequence to a library function that expects a string:MAPPING FIT:Imprecise::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP8:ENTRY NAME:Faulty Buffer Access::",,"",
+124,"Buffer Underwrite ('Buffer Underflow')",Base,Incomplete,"The product writes to a buffer using an index or pointer that references a memory location prior to the beginning of the buffer.","This typically occurs when a pointer or its index is decremented to a position before the buffer, when pointer arithmetic results in a position before the beginning of the valid memory location, or when a negative index is used.",::NATURE:ChildOf:CWE ID:786:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:787:VIEW ID:1000::,"::ORDINALITY:Primary::",::LANGUAGE NAME:C:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:C++:LANGUAGE PREVALENCE:Undetermined::,"","::TERM:buffer underrun:DESCRIPTION:Some prominent vendors and researchers use the term buffer underrun. Buffer underflow is more commonly used, although both terms are also sometimes used to describe a buffer under-read (CWE-127).::","::PHASE:Implementation::","",,"::SCOPE:Integrity:SCOPE:Availability:IMPACT:Modify Memory:IMPACT:DoS: Crash, Exit, or Restart:NOTE:Out of bounds memory access will very likely result in the corruption of relevant memory, and perhaps instructions, possibly leading to a crash.::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:SCOPE:Access Control:SCOPE:Other:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Modify Memory:IMPACT:Bypass Protection Mechanism:IMPACT:Other:NOTE:If the corrupted memory can be effectively controlled, it may be possible to execute arbitrary code. If the corrupted memory is data rather than instructions, the system will continue to function with improper changes, possibly in violation of an implicit or explicit policy. The consequences would only be limited by how the affected data is used, such as an adjacent memory location that is used to specify whether the user has special privileges.::SCOPE:Access Control:SCOPE:Other:IMPACT:Bypass Protection Mechanism:IMPACT:Other:NOTE:When the consequence is arbitrary code execution, this can often be used to subvert any other security service.::","","::PHASE:Requirements:DESCRIPTION:Choose a language that is not susceptible to these issues.::PHASE:Implementation:DESCRIPTION:All calculated values that are used as index or for pointer arithmetic should be validated to ensure that they are within an expected range.::","::REFERENCE:CVE-2021-24018:DESCRIPTION:buffer underwrite in firmware verification routine allows code execution via a crafted firmware image:LINK:https://www.cve.org/CVERecord?id=CVE-2021-24018::REFERENCE:CVE-2002-2227:DESCRIPTION:Unchecked length of SSLv2 challenge value leads to buffer underflow.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-2227::REFERENCE:CVE-2007-4580:DESCRIPTION:Buffer underflow from a small size value with a large buffer (length parameter inconsistency, CWE-130):LINK:https://www.cve.org/CVERecord?id=CVE-2007-4580::REFERENCE:CVE-2007-1584:DESCRIPTION:Buffer underflow from an all-whitespace string, which causes a counter to be decremented before the buffer while looking for a non-whitespace character.:LINK:https://www.cve.org/CVERecord?id=CVE-2007-1584::REFERENCE:CVE-2007-0886:DESCRIPTION:Buffer underflow resultant from encoded data that triggers an integer overflow.:LINK:https://www.cve.org/CVERecord?id=CVE-2007-0886::REFERENCE:CVE-2006-6171:DESCRIPTION:Product sets an incorrect buffer size limit, leading to off-by-two buffer underflow.:LINK:https://www.cve.org/CVERecord?id=CVE-2006-6171::REFERENCE:CVE-2006-4024:DESCRIPTION:Negative value is used in a memcpy() operation, leading to buffer underflow.:LINK:https://www.cve.org/CVERecord?id=CVE-2006-4024::REFERENCE:CVE-2004-2620:DESCRIPTION:Buffer underflow due to mishandled special characters:LINK:https://www.cve.org/CVERecord?id=CVE-2004-2620::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:UNDER - Boundary beginning violation ('buffer underflow'?)::TAXONOMY NAME:CLASP:ENTRY NAME:Buffer underwrite::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP8:ENTRY NAME:Faulty Buffer Access::",,"::TYPE:Relationship:NOTE:This could be resultant from several errors, including a bad offset or an array index that decrements before the beginning of the buffer (see CWE-129).::",
+125,"Out-of-bounds Read",Base,Draft,"The product reads data past the end, or before the beginning, of the intended buffer.","Typically, this can allow attackers to read sensitive information from other memory locations or cause a crash. A crash can occur when the code reads a variable amount of data and assumes that a sentinel exists to stop the read operation, such as a NUL in a string. The expected sentinel might not be located in the out-of-bounds memory, causing excessive data to be read, leading to a segmentation fault or a buffer overflow. The product may modify an index or perform pointer arithmetic that references a memory location that is outside of the boundaries of the buffer. A subsequent read operation then produces undefined or unexpected results.",::NATURE:ChildOf:CWE ID:119:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:119:VIEW ID:1003:ORDINAL:Primary::NATURE:ChildOf:CWE ID:119:VIEW ID:1305:ORDINAL:Primary::NATURE:ChildOf:CWE ID:119:VIEW ID:1340:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE NAME:C:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:C++:LANGUAGE PREVALENCE:Undetermined::TECHNOLOGY CLASS:ICS/OT:TECHNOLOGY PREVALENCE:Often::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:IMPACT:Read Memory::SCOPE:Confidentiality:IMPACT:Bypass Protection Mechanism:NOTE:By reading out-of-bounds memory, an attacker might be able to get secret values, such as memory addresses, which can be bypass protection mechanisms such as ASLR in order to improve the reliability and likelihood of exploiting a separate weakness to achieve code execution instead of just denial of service.::","::METHOD:Fuzzing:DESCRIPTION:Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.:EFFECTIVENESS:High::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. To reduce the likelihood of introducing an out-of-bounds read, ensure that you validate and ensure correct calculations for any length argument, buffer size calculation, or offset. Be especially careful of relying on a sentinel (i.e. special character such as NUL) in untrusted inputs.::PHASE:Architecture and Design:STRATEGY:Language Selection:DESCRIPTION:Use a language that provides appropriate memory abstractions.::","::REFERENCE:CVE-2020-11899:DESCRIPTION:Out-of-bounds read in IP stack used in embedded systems, as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-11899::REFERENCE:CVE-2014-0160:DESCRIPTION:Chain: Heartbleed bug receives an inconsistent length parameter (CWE-130) enabling an out-of-bounds read (CWE-126), returning memory that could include private cryptographic keys and other sensitive data.:LINK:https://www.cve.org/CVERecord?id=CVE-2014-0160::REFERENCE:CVE-2021-40985:DESCRIPTION:HTML conversion package has a buffer under-read, allowing a crash:LINK:https://www.cve.org/CVERecord?id=CVE-2021-40985::REFERENCE:CVE-2018-10887:DESCRIPTION:Chain: unexpected sign extension (CWE-194) leads to integer overflow (CWE-190), causing an out-of-bounds read (CWE-125):LINK:https://www.cve.org/CVERecord?id=CVE-2018-10887::REFERENCE:CVE-2009-2523:DESCRIPTION:Chain: product does not handle when an input string is not NULL terminated (CWE-170), leading to buffer over-read (CWE-125) or heap-based buffer overflow (CWE-122).:LINK:https://www.cve.org/CVERecord?id=CVE-2009-2523::REFERENCE:CVE-2018-16069:DESCRIPTION:Chain: series of floating-point precision errors (CWE-1339) in a web browser rendering engine causes out-of-bounds read (CWE-125), giving access to cross-origin data:LINK:https://www.cve.org/CVERecord?id=CVE-2018-16069::REFERENCE:CVE-2004-0112:DESCRIPTION:out-of-bounds read due to improper length check:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0112::REFERENCE:CVE-2004-0183:DESCRIPTION:packet with large number of specified elements cause out-of-bounds read.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0183::REFERENCE:CVE-2004-0221:DESCRIPTION:packet with large number of specified elements cause out-of-bounds read.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0221::REFERENCE:CVE-2004-0184:DESCRIPTION:out-of-bounds read, resultant from integer underflow:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0184::REFERENCE:CVE-2004-1940:DESCRIPTION:large length value causes out-of-bounds read:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1940::REFERENCE:CVE-2004-0421:DESCRIPTION:malformed image causes out-of-bounds read:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0421::REFERENCE:CVE-2008-4113:DESCRIPTION:OS kernel trusts userland-supplied length value, allowing reading of sensitive information:LINK:https://www.cve.org/CVERecord?id=CVE-2008-4113::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Out-of-bounds Read::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:ARR30-C:ENTRY NAME:Do not form or use out-of-bounds pointers or array subscripts:MAPPING FIT:Imprecise::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:ARR38-C:ENTRY NAME:Guarantee that library functions do not form invalid pointers:MAPPING FIT:Imprecise::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:EXP39-C:ENTRY NAME:Do not access a variable through a pointer of an incompatible type:MAPPING FIT:Imprecise::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:STR31-C:ENTRY NAME:Guarantee that storage for strings has sufficient space for character data and the null terminator:MAPPING FIT:Imprecise::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:STR32-C:ENTRY NAME:Do not pass a non-null-terminated character sequence to a library function that expects a string:MAPPING FIT:CWE More Abstract::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP8:ENTRY NAME:Faulty Buffer Access::",::540::,"",
+126,"Buffer Over-read",Variant,Draft,"The product reads from a buffer using buffer access mechanisms such as indexes or pointers that reference memory locations after the targeted buffer.","This typically occurs when the pointer or its index is incremented to a position beyond the bounds of the buffer or when pointer arithmetic results in a position outside of the valid memory location to name a few. This may result in exposure of sensitive information or possibly a crash.",::NATURE:ChildOf:CWE ID:125:VIEW ID:1000::NATURE:ChildOf:CWE ID:788:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE NAME:C:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:C++:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:IMPACT:Read Memory::SCOPE:Confidentiality:IMPACT:Bypass Protection Mechanism:NOTE:By reading out-of-bounds memory, an attacker might be able to get secret values, such as memory addresses, which can be bypass protection mechanisms such as ASLR in order to improve the reliability and likelihood of exploiting a separate weakness to achieve code execution instead of just denial of service.::","::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","","::REFERENCE:CVE-2022-1733:DESCRIPTION:Text editor has out-of-bounds read past end of line while indenting C code:LINK:https://www.cve.org/CVERecord?id=CVE-2022-1733::REFERENCE:CVE-2014-0160:DESCRIPTION:Chain: Heartbleed bug receives an inconsistent length parameter (CWE-130) enabling an out-of-bounds read (CWE-126), returning memory that could include private cryptographic keys and other sensitive data.:LINK:https://www.cve.org/CVERecord?id=CVE-2014-0160::REFERENCE:CVE-2009-2523:DESCRIPTION:Chain: product does not handle when an input string is not NULL terminated, leading to buffer over-read or heap-based buffer overflow.:LINK:https://www.cve.org/CVERecord?id=CVE-2009-2523::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Buffer over-read::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP8:ENTRY NAME:Faulty Buffer Access::",,"::TYPE:Relationship:NOTE:These problems may be resultant from missing sentinel values (CWE-463) or trusting a user-influenced input length variable.::",
+127,"Buffer Under-read",Variant,Draft,"The product reads from a buffer using buffer access mechanisms such as indexes or pointers that reference memory locations prior to the targeted buffer.","This typically occurs when the pointer or its index is decremented to a position before the buffer, when pointer arithmetic results in a position before the beginning of the valid memory location, or when a negative index is used. This may result in exposure of sensitive information or possibly a crash.",::NATURE:ChildOf:CWE ID:125:VIEW ID:1000::NATURE:ChildOf:CWE ID:786:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE NAME:C:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:C++:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:IMPACT:Read Memory::SCOPE:Confidentiality:IMPACT:Bypass Protection Mechanism:NOTE:By reading out-of-bounds memory, an attacker might be able to get secret values, such as memory addresses, which can be bypass protection mechanisms such as ASLR in order to improve the reliability and likelihood of exploiting a separate weakness to achieve code execution instead of just denial of service.::","","","::REFERENCE:CVE-2021-40985:DESCRIPTION:HTML conversion package has a buffer under-read, allowing a crash:LINK:https://www.cve.org/CVERecord?id=CVE-2021-40985::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Buffer under-read::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP8:ENTRY NAME:Faulty Buffer Access::",,"::TYPE:Research Gap:NOTE:Under-studied.::",
+128,"Wrap-around Error",Base,Incomplete,"Wrap around errors occur whenever a value is incremented past the maximum value for its type and therefore wraps around to a very small, negative, or undefined value.","",::NATURE:ChildOf:CWE ID:682:VIEW ID:1000:ORDINAL:Primary::NATURE:CanPrecede:CWE ID:119:VIEW ID:1000::NATURE:PeerOf:CWE ID:190:VIEW ID:1000::,"::ORDINALITY:Primary::",::LANGUAGE NAME:C:LANGUAGE PREVALENCE:Often::LANGUAGE NAME:C++:LANGUAGE PREVALENCE:Often::,"::Due to how addition is performed by computers, if a primitive is incremented past the maximum value possible for its storage space, the system will not recognize this, and therefore increment each bit as if it still had extra space. Because of how negative numbers are represented in binary, primitives interpreted as signed may wrap to very large negative values.::","","::PHASE:Implementation::","",,"::SCOPE:Availability:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:DoS: Resource Consumption (CPU):IMPACT:DoS: Resource Consumption (Memory):IMPACT:DoS: Instability:NOTE:This weakness will generally lead to undefined behavior and therefore crashes. In the case of overflows involving loop index variables, the likelihood of infinite loops is also high.::SCOPE:Integrity:IMPACT:Modify Memory:NOTE:If the value in question is important to data (as opposed to flow), simple data corruption has occurred. Also, if the wrap around results in other conditions such as buffer overflows, further memory corruption may occur.::SCOPE:Confidentiality:SCOPE:Availability:SCOPE:Access Control:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Bypass Protection Mechanism:NOTE:This weakness can sometimes trigger buffer overflows which can be used to execute arbitrary code. This is usually outside the scope of a program's implicit security policy.::","","::PHASE::DESCRIPTION:Requirements specification: The choice could be made to use a language that is not susceptible to these issues.::PHASE:Architecture and Design:DESCRIPTION:Provide clear upper and lower bounds on the scale of any protocols designed.::PHASE:Implementation:DESCRIPTION:Perform validation on all incremented variables to ensure that they remain within reasonable bounds.::","",,,"::TAXONOMY NAME:CLASP:ENTRY NAME:Wrap-around error::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:MEM07-C:ENTRY NAME:Ensure that the arguments to calloc(), when multiplied, can be represented as a size_t::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP1:ENTRY NAME:Glitch in computation::",::92::,"::TYPE:Relationship:NOTE:The relationship between overflow and wrap-around needs to be examined more closely, since several entries (including CWE-190) are closely related.::",
+129,"Improper Validation of Array Index",Variant,Draft,"The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.","",::NATURE:ChildOf:CWE ID:1285:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:20:VIEW ID:1003:ORDINAL:Primary::NATURE:CanPrecede:CWE ID:119:VIEW ID:1000::NATURE:CanPrecede:CWE ID:823:VIEW ID:1000::NATURE:CanPrecede:CWE ID:789:VIEW ID:1000::,"::ORDINALITY:Resultant:DESCRIPTION:The most common condition situation leading to an out-of-bounds array index is the use of loop index variables as buffer indexes. If the end condition for the loop is subject to a flaw, the index can grow or shrink unbounded, therefore causing a buffer overflow or underflow. Another common situation leading to this condition is the use of a function's return value, or the resulting value of a calculation directly as an index in to a buffer.::",::LANGUAGE NAME:C:LANGUAGE PREVALENCE:Often::LANGUAGE NAME:C++:LANGUAGE PREVALENCE:Often::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","::TERM:out-of-bounds array index::TERM:index-out-of-range::TERM:array index underflow::","::PHASE:Implementation::","",,"::SCOPE:Integrity:SCOPE:Availability:IMPACT:DoS: Crash, Exit, or Restart:NOTE:Use of an index that is outside the bounds of an array will very likely result in the corruption of relevant memory and perhaps instructions, leading to a crash, if the values are outside of the valid memory area.::SCOPE:Integrity:IMPACT:Modify Memory:NOTE:If the memory corrupted is data, rather than instructions, the system will continue to function with improper values.::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Modify Memory:IMPACT:Read Memory:NOTE:Use of an index that is outside the bounds of an array can also trigger out-of-bounds read or write operations, or operations on the wrong objects; i.e., buffer overflows are not always the result. This may result in the exposure or modification of sensitive data.::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:IMPACT:Execute Unauthorized Code or Commands:NOTE:If the memory accessible by the attacker can be effectively controlled, it may be possible to execute arbitrary code, as with a standard buffer overflow and possibly without the use of large inputs if a precise index can be controlled.::SCOPE:Integrity:SCOPE:Availability:SCOPE:Confidentiality:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Read Memory:IMPACT:Modify Memory:NOTE:A single fault could allow either an overflow (CWE-788) or underflow (CWE-786) of the array index. What happens next will depend on the type of operation being performed out of bounds, but can expose sensitive information, cause a system crash, or possibly lead to arbitrary code execution.::","::METHOD:Automated Static Analysis:DESCRIPTION:This weakness can often be detected using automated static analysis tools. Many modern tools use data flow analysis or constraint-based techniques to minimize the number of false positives. Automated static analysis generally does not account for environmental considerations when reporting out-of-bounds memory operations. This can make it difficult for users to determine which warnings should be investigated first. For example, an analysis tool might report array index errors that originate from command line arguments in a program that is not expected to run with setuid or other special privileges.:EFFECTIVENESS:High::METHOD:Automated Dynamic Analysis:DESCRIPTION:This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.::METHOD:Black Box:DESCRIPTION:Black box methods might not get the needed code coverage within limited time constraints, and a dynamic test might not produce any noticeable side effects even if it is successful.::","::PHASE:Architecture and Design:STRATEGY:Input Validation:DESCRIPTION:Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).::PHASE:Architecture and Design:DESCRIPTION:For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server. Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.::PHASE:Requirements:STRATEGY:Language Selection:DESCRIPTION:Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, Ada allows the programmer to constrain the values of a variable and languages such as Java and Ruby will allow the programmer to handle exceptions when an out-of-bounds index is accessed.::PHASE:Operation Build and Compilation:STRATEGY:Environment Hardening:DESCRIPTION:Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code. Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as rebasing (for Windows) and prelinking (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking. For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].:EFFECTIVENESS:Defense in Depth::PHASE:Operation:STRATEGY:Environment Hardening:DESCRIPTION:Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment. For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336].:EFFECTIVENESS:Defense in Depth::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When accessing a user-controlled array index, use a stringent range of values that are within the target array. Make sure that you do not allow negative values to be used. That is, verify the minimum as well as the maximum of the range of acceptable values.::PHASE:Implementation:DESCRIPTION:Be especially careful to validate all input when invoking code that crosses language boundaries, such as from an interpreted language to native code. This could create an unexpected interaction between the language boundaries. Ensure that you are not violating any of the expectations of the language with which you are interfacing. For example, even though Java may not be susceptible to buffer overflows, providing a large argument in a call to native code might trigger an overflow.::PHASE:Architecture and Design Operation:STRATEGY:Environment Hardening:DESCRIPTION:Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.::PHASE:Architecture and Design Operation:STRATEGY:Sandbox or Jail:DESCRIPTION:Run the code in a jail or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software. OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.:EFFECTIVENESS:Limited::","::REFERENCE:CVE-2005-0369:DESCRIPTION:large ID in packet used as array index:LINK:https://www.cve.org/CVERecord?id=CVE-2005-0369::REFERENCE:CVE-2001-1009:DESCRIPTION:negative array index as argument to POP LIST command:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1009::REFERENCE:CVE-2003-0721:DESCRIPTION:Integer signedness error leads to negative array index:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0721::REFERENCE:CVE-2004-1189:DESCRIPTION:product does not properly track a count and a maximum number, which can lead to resultant array index overflow.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1189::REFERENCE:CVE-2007-5756:DESCRIPTION:Chain: device driver for packet-capturing software allows access to an unintended IOCTL with resultant array index error.:LINK:https://www.cve.org/CVERecord?id=CVE-2007-5756::REFERENCE:CVE-2005-2456:DESCRIPTION:Chain: array index error (CWE-129) leads to deadlock (CWE-833):LINK:https://www.cve.org/CVERecord?id=CVE-2005-2456::",,::Memory::,"::TAXONOMY NAME:CLASP:ENTRY NAME:Unchecked array indexing::TAXONOMY NAME:PLOVER:ENTRY NAME:INDEX - Array index overflow::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:ARR00-C:ENTRY NAME:Understand how arrays work::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:ARR30-C:ENTRY NAME:Do not form or use out-of-bounds pointers or array subscripts:MAPPING FIT:CWE More Specific::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:ARR38-C:ENTRY NAME:Do not add or subtract an integer to a pointer if the resulting value does not refer to a valid array element::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:INT32-C:ENTRY NAME:Ensure that operations on signed integers do not result in overflow::TAXONOMY NAME:SEI CERT Perl Coding Standard:ENTRY ID:IDS32-PL:ENTRY NAME:Validate any integer that is used as an array index:MAPPING FIT:Imprecise::TAXONOMY NAME:OMG ASCSM:ENTRY ID:ASCSM-CWE-129::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP8:ENTRY NAME:Faulty Buffer Access::",::100::,"::TYPE:Relationship:NOTE:This weakness can precede uncontrolled memory allocation (CWE-789) in languages that automatically expand an array when an index is used that is larger than the size of the array, such as JavaScript.::TYPE:Theoretical:NOTE:An improperly validated array index might lead directly to the always-incorrect behavior of access of array using out-of-bounds index.::",
+130,"Improper Handling of Length Parameter Inconsistency",Base,Incomplete,"The product parses a formatted message or structure, but it does not handle or incorrectly handles a length field that is inconsistent with the actual length of the associated data.","If an attacker can manipulate the length parameter associated with an input such that it is inconsistent with the actual length of the input, this can be leveraged to cause the target application to behave in unexpected, and possibly, malicious ways. One of the possible motives for doing so is to pass in arbitrarily large input to the application. Another possible motivation is the modification of application state by including invalid data for subsequent properties of the application. Such weaknesses commonly lead to attacks such as buffer overflows and execution of arbitrary code.",::NATURE:ChildOf:CWE ID:240:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:119:VIEW ID:1305:ORDINAL:Primary::NATURE:ChildOf:CWE ID:119:VIEW ID:1340:ORDINAL:Primary::NATURE:CanPrecede:CWE ID:805:VIEW ID:1000::,"::ORDINALITY:Primary::",::LANGUAGE NAME:C:LANGUAGE PREVALENCE:Sometimes::LANGUAGE NAME:C++:LANGUAGE PREVALENCE:Sometimes::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","::TERM:length manipulation::TERM:length tampering::","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Memory:IMPACT:Modify Memory:IMPACT:Varies by Context::","","::PHASE:Implementation:DESCRIPTION:When processing structured incoming data containing a size field followed by raw data, ensure that you identify and resolve any inconsistencies between the size field and the actual size of the data.::PHASE:Implementation:DESCRIPTION:Do not let the user control the size of the buffer.::PHASE:Implementation:DESCRIPTION:Validate that the length of the user-supplied data is consistent with the buffer size.::","::REFERENCE:CVE-2014-0160:DESCRIPTION:Chain: Heartbleed bug receives an inconsistent length parameter (CWE-130) enabling an out-of-bounds read (CWE-126), returning memory that could include private cryptographic keys and other sensitive data.:LINK:https://www.cve.org/CVERecord?id=CVE-2014-0160::REFERENCE:CVE-2009-2299:DESCRIPTION:Web application firewall consumes excessive memory when an HTTP request contains a large Content-Length value but no POST data.:LINK:https://www.cve.org/CVERecord?id=CVE-2009-2299::REFERENCE:CVE-2001-0825:DESCRIPTION:Buffer overflow in internal string handling routine allows remote attackers to execute arbitrary commands via a length argument of zero or less, which disables the length check.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0825::REFERENCE:CVE-2001-1186:DESCRIPTION:Web server allows remote attackers to cause a denial of service via an HTTP request with a content-length value that is larger than the size of the request, which prevents server from timing out the connection.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1186::REFERENCE:CVE-2001-0191:DESCRIPTION:Service does not properly check the specified length of a cookie, which allows remote attackers to execute arbitrary commands via a buffer overflow, or brute force authentication by using a short cookie length.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0191::REFERENCE:CVE-2003-0429:DESCRIPTION:Traffic analyzer allows remote attackers to cause a denial of service and possibly execute arbitrary code via invalid IPv4 or IPv6 prefix lengths, possibly triggering a buffer overflow.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0429::REFERENCE:CVE-2000-0655:DESCRIPTION:Chat client allows remote attackers to cause a denial of service or execute arbitrary commands via a JPEG image containing a comment with an illegal field length of 1.:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0655::REFERENCE:CVE-2004-0492:DESCRIPTION:Server allows remote attackers to cause a denial of service and possibly execute arbitrary code via a negative Content-Length HTTP header field causing a heap-based buffer overflow.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0492::REFERENCE:CVE-2004-0201:DESCRIPTION:Help program allows remote attackers to execute arbitrary commands via a heap-based buffer overflow caused by a .CHM file with a large length field:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0201::REFERENCE:CVE-2003-0825:DESCRIPTION:Name services does not properly validate the length of certain packets, which allows attackers to cause a denial of service and possibly execute arbitrary code. Can overlap zero-length issues:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0825::REFERENCE:CVE-2004-0095:DESCRIPTION:Policy manager allows remote attackers to cause a denial of service (memory consumption and crash) and possibly execute arbitrary code via an HTTP POST request with an invalid Content-Length value.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0095::REFERENCE:CVE-2004-0826:DESCRIPTION:Heap-based buffer overflow in library allows remote attackers to execute arbitrary code via a modified record length field in an SSLv2 client hello message.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0826::REFERENCE:CVE-2004-0808:DESCRIPTION:When domain logons are enabled, server allows remote attackers to cause a denial of service via a SAM_UAS_CHANGE request with a length value that is larger than the number of structures that are provided.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0808::REFERENCE:CVE-2002-1357:DESCRIPTION:Multiple SSH2 servers and clients do not properly handle packets or data elements with incorrect length specifiers, which may allow remote attackers to cause a denial of service or possibly execute arbitrary code.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1357::REFERENCE:CVE-2004-0774:DESCRIPTION:Server allows remote attackers to cause a denial of service (CPU and memory exhaustion) via a POST request with a Content-Length header set to -1.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0774::REFERENCE:CVE-2004-0989:DESCRIPTION:Multiple buffer overflows in xml library that may allow remote attackers to execute arbitrary code via long URLs.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0989::REFERENCE:CVE-2004-0568:DESCRIPTION:Application does not properly validate the length of a value that is saved in a session file, which allows remote attackers to execute arbitrary code via a malicious session file (.ht), web site, or Telnet URL contained in an e-mail message, triggering a buffer overflow.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0568::REFERENCE:CVE-2003-0327:DESCRIPTION:Server allows remote attackers to cause a denial of service via a remote password array with an invalid length, which triggers a heap-based buffer overflow.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0327::REFERENCE:CVE-2003-0345:DESCRIPTION:Product allows remote attackers to cause a denial of service and possibly execute arbitrary code via an SMB packet that specifies a smaller buffer length than is required.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0345::REFERENCE:CVE-2004-0430:DESCRIPTION:Server allows remote attackers to execute arbitrary code via a LoginExt packet for a Cleartext Password User Authentication Method (UAM) request with a PathName argument that includes an AFPName type string that is longer than the associated length field.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0430::REFERENCE:CVE-2005-0064:DESCRIPTION:PDF viewer allows remote attackers to execute arbitrary code via a PDF file with a large /Encrypt /Length keyLength value.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-0064::REFERENCE:CVE-2004-0413:DESCRIPTION:SVN client trusts the length field of SVN protocol URL strings, which allows remote attackers to cause a denial of service and possibly execute arbitrary code via an integer overflow that leads to a heap-based buffer overflow.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0413::REFERENCE:CVE-2004-0940:DESCRIPTION:Is effectively an accidental double increment of a counter that prevents a length check conditional from exiting a loop.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0940::REFERENCE:CVE-2002-1235:DESCRIPTION:Length field of a request not verified.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1235::REFERENCE:CVE-2005-3184:DESCRIPTION:Buffer overflow by modifying a length value.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-3184::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Length Parameter Inconsistency::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted Input to Command::",::47::,"::TYPE:Relationship:NOTE:This probably overlaps other categories including zero-length issues.::",
+131,"Incorrect Calculation of Buffer Size",Base,Draft,"The product does not correctly calculate the size to be used when allocating a buffer, which could lead to a buffer overflow.","",::NATURE:ChildOf:CWE ID:682:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:682:VIEW ID:1003:ORDINAL:Primary::NATURE:ChildOf:CWE ID:682:VIEW ID:1305:ORDINAL:Primary::NATURE:ChildOf:CWE ID:682:VIEW ID:1340:ORDINAL:Primary::NATURE:CanPrecede:CWE ID:119:VIEW ID:1000::,"",::LANGUAGE NAME:C:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:C++:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Integrity:SCOPE:Availability:SCOPE:Confidentiality:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Read Memory:IMPACT:Modify Memory:NOTE:If the incorrect calculation is used in the context of memory allocation, then the software may create a buffer that is smaller or larger than expected. If the allocated buffer is smaller than expected, this could lead to an out-of-bounds read or write (CWE-119), possibly causing a crash, allowing arbitrary code execution, or exposing sensitive data.::","::METHOD:Automated Static Analysis:DESCRIPTION:This weakness can often be detected using automated static analysis tools. Many modern tools use data flow analysis or constraint-based techniques to minimize the number of false positives. Automated static analysis generally does not account for environmental considerations when reporting potential errors in buffer calculations. This can make it difficult for users to determine which warnings should be investigated first. For example, an analysis tool might report buffer overflows that originate from command line arguments in a program that is not expected to run with setuid or other special privileges.:EFFECTIVENESS:High::METHOD:Automated Dynamic Analysis:DESCRIPTION:This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.:EFFECTIVENESS:Moderate::METHOD:Manual Analysis:DESCRIPTION:Manual analysis can be useful for finding this weakness, but it might not achieve desired code coverage within limited time constraints. This becomes difficult for weaknesses that must be considered for all inputs, since the attack surface can be too large.::METHOD:Manual Analysis:DESCRIPTION:This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. Specifically, manual static analysis is useful for evaluating the correctness of allocation calculations. This can be useful for detecting overflow conditions (CWE-190) or similar weaknesses that might have serious security impacts on the program.:EFFECTIVENESS:High::METHOD:Automated Static Analysis - Binary or Bytecode:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Bytecode Weakness Analysis - including disassembler + source code weakness analysis Binary Weakness Analysis - including disassembler + source code weakness analysis:EFFECTIVENESS:High::METHOD:Manual Static Analysis - Binary or Bytecode:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies:EFFECTIVENESS:SOAR Partial::METHOD:Manual Static Analysis - Source Code:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Focused Manual Spotcheck - Focused manual analysis of source Manual Source Code Review (not inspections):EFFECTIVENESS:SOAR Partial::METHOD:Automated Static Analysis - Source Code:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer Cost effective for partial coverage: Source Code Quality Analyzer:EFFECTIVENESS:High::METHOD:Architecture or Design Review:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Formal Methods / Correct-By-Construction Cost effective for partial coverage: Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.):EFFECTIVENESS:High::","::PHASE:Implementation:DESCRIPTION:When allocating a buffer for the purpose of transforming, converting, or encoding an input, allocate enough memory to handle the largest possible encoding. For example, in a routine that converts & characters to & for HTML entity encoding, the output buffer needs to be at least 5 times as large as the input buffer.::PHASE:Implementation:DESCRIPTION:Understand the programming language's underlying representation and how it interacts with numeric calculation (CWE-681). Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, not-a-number calculations, and how the language handles numbers that are too large or too small for its underlying representation. [REF-7] Also be careful to account for 32-bit, 64-bit, and other potential differences that may affect the numeric representation.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Perform input validation on any numeric input by ensuring that it is within the expected range. Enforce that the input meets both the minimum and maximum requirements for the expected range.::PHASE:Architecture and Design:DESCRIPTION:For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.::PHASE:Implementation:DESCRIPTION:When processing structured incoming data containing a size field followed by raw data, identify and resolve any inconsistencies between the size field and the actual size of the data (CWE-130).::PHASE:Implementation:DESCRIPTION:When allocating memory that uses sentinels to mark the end of a data structure - such as NUL bytes in strings - make sure you also include the sentinel in your calculation of the total amount of memory that must be allocated.::PHASE:Implementation:DESCRIPTION:Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available.:EFFECTIVENESS:Moderate::PHASE:Implementation:DESCRIPTION:Use sizeof() on the appropriate data type to avoid CWE-467.::PHASE:Implementation:DESCRIPTION:Use the appropriate type for the desired action. For example, in C/C++, only use unsigned types for values that could never be negative, such as height, width, or other numbers related to quantity. This will simplify validation and will reduce surprises related to unexpected casting.::PHASE:Architecture and Design:STRATEGY:Libraries or Frameworks:DESCRIPTION:Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Use libraries or frameworks that make it easier to handle numbers without unexpected consequences, or buffer allocation routines that automatically track buffer size. Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++). [REF-106]::PHASE:Operation Build and Compilation:STRATEGY:Environment Hardening:DESCRIPTION:Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking. D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.:EFFECTIVENESS:Defense in Depth::PHASE:Operation Build and Compilation:STRATEGY:Environment Hardening:DESCRIPTION:Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code. Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as rebasing (for Windows) and prelinking (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking. For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].:EFFECTIVENESS:Defense in Depth::PHASE:Operation:STRATEGY:Environment Hardening:DESCRIPTION:Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment. For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336].:EFFECTIVENESS:Defense in Depth::PHASE:Implementation:STRATEGY:Compilation or Build Hardening:DESCRIPTION:Examine compiler warnings closely and eliminate problems with potential security implications, such as signed / unsigned mismatch in memory operations, or use of uninitialized variables. Even if the weakness is rarely exploitable, a single failure may lead to the compromise of the entire system.::PHASE:Architecture and Design Operation:STRATEGY:Environment Hardening:DESCRIPTION:Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.::PHASE:Architecture and Design Operation:STRATEGY:Sandbox or Jail:DESCRIPTION:Run the code in a jail or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software. OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.:EFFECTIVENESS:Limited::","::REFERENCE:CVE-2020-17087:DESCRIPTION:Chain: integer truncation (CWE-197) causes small buffer allocation (CWE-131) leading to out-of-bounds write (CWE-787) in kernel pool, as exploited in the wild per CISA KEV.:LINK:https://www.cve.org/CVERecord?id=CVE-2020-17087::REFERENCE:CVE-2004-1363:DESCRIPTION:substitution overflow: buffer overflow using environment variables that are expanded after the length check is performed:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1363::REFERENCE:CVE-2004-0747:DESCRIPTION:substitution overflow: buffer overflow using expansion of environment variables:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0747::REFERENCE:CVE-2005-2103:DESCRIPTION:substitution overflow: buffer overflow using a large number of substitution strings:LINK:https://www.cve.org/CVERecord?id=CVE-2005-2103::REFERENCE:CVE-2005-3120:DESCRIPTION:transformation overflow: product adds extra escape characters to incoming data, but does not account for them in the buffer length:LINK:https://www.cve.org/CVERecord?id=CVE-2005-3120::REFERENCE:CVE-2003-0899:DESCRIPTION:transformation overflow: buffer overflow when expanding > to >, etc.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0899::REFERENCE:CVE-2001-0334:DESCRIPTION:expansion overflow: buffer overflow using wildcards:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0334::REFERENCE:CVE-2001-0248:DESCRIPTION:expansion overflow: long pathname + glob = overflow:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0248::REFERENCE:CVE-2001-0249:DESCRIPTION:expansion overflow: long pathname + glob = overflow:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0249::REFERENCE:CVE-2002-0184:DESCRIPTION:special characters in argument are not properly expanded:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0184::REFERENCE:CVE-2004-0434:DESCRIPTION:small length value leads to heap overflow:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0434::REFERENCE:CVE-2002-1347:DESCRIPTION:multiple variants:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1347::REFERENCE:CVE-2005-0490:DESCRIPTION:needs closer investigation, but probably expansion-based:LINK:https://www.cve.org/CVERecord?id=CVE-2005-0490::REFERENCE:CVE-2004-0940:DESCRIPTION:needs closer investigation, but probably expansion-based:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0940::REFERENCE:CVE-2008-0599:DESCRIPTION:Chain: Language interpreter calculates wrong buffer size (CWE-131) by using size = ptr ? X : Y instead of size = (ptr ? X : Y) expression.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-0599::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Other length calculation error::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:INT30-C:ENTRY NAME:Ensure that unsigned integer operations do not wrap:MAPPING FIT:Imprecise::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:MEM35-C:ENTRY NAME:Allocate sufficient memory for an object:MAPPING FIT:CWE More Abstract::",::100::47::,"::TYPE:Maintenance:NOTE:This is a broad category. Some examples include: simple math errors, incorrectly updating parallel counters, not accounting for size differences when transforming one input to another format (e.g. URL canonicalization or other transformation that can generate a result that's larger than the original input, i.e. expansion). This level of detail is rarely available in public reports, so it is difficult to find good examples.::TYPE:Maintenance:NOTE:This weakness may be a composite or a chain. It also may contain layering or perspective differences. This issue may be associated with many different types of incorrect calculations (CWE-682), although the integer overflow (CWE-190) is probably the most prevalent. This can be primary to resource consumption problems (CWE-400), including uncontrolled memory allocation (CWE-789). However, its relationship with out-of-bounds buffer access (CWE-119) must also be considered.::",
+134,"Use of Externally-Controlled Format String",Base,Draft,"The product uses a function that accepts a format string as an argument, but the format string originates from an external source.","When an attacker can modify an externally-controlled format string, this can lead to buffer overflows, denial of service, or data representation problems. It should be noted that in some circumstances, such as internationalization, the set of format strings is externally controlled by design. If the source of these format strings is trusted (e.g. only contained in library files that are only modifiable by the system administrator), then the external control might not itself pose a vulnerability.",::NATURE:ChildOf:CWE ID:668:VIEW ID:1000:ORDINAL:Primary::NATURE:ChildOf:CWE ID:668:VIEW ID:1003:ORDINAL:Primary::NATURE:CanPrecede:CWE ID:123:VIEW ID:1000::NATURE:ChildOf:CWE ID:20:VIEW ID:700:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE NAME:C:LANGUAGE PREVALENCE:Often::LANGUAGE NAME:C++:LANGUAGE PREVALENCE:Often::LANGUAGE NAME:Perl:LANGUAGE PREVALENCE:Rarely::,"","","::PHASE:Implementation:NOTE:The programmer rarely intends for a format string to be externally-controlled at all. This weakness is frequently introduced in code that constructs log messages, where a constant format string is omitted.::PHASE:Implementation:NOTE:In cases such as localization and internationalization, the language-specific message repositories could be an avenue for exploitation, but the format string issue would be resultant, since attacker control of those repositories would also allow modification of message length, format, and content.::","",,"::SCOPE:Confidentiality:IMPACT:Read Memory:NOTE:Format string problems allow for information disclosure which can severely simplify exploitation of the program.::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:IMPACT:Modify Memory:IMPACT:Execute Unauthorized Code or Commands:NOTE:Format string problems can result in the execution of arbitrary code.::","::METHOD:Automated Static Analysis:DESCRIPTION:This weakness can often be detected using automated static analysis tools. Many modern tools use data flow analysis or constraint-based techniques to minimize the number of false positives.::METHOD:Black Box:DESCRIPTION:Since format strings often occur in rarely-occurring erroneous conditions (e.g. for error message logging), they can be difficult to detect using black box methods. It is highly likely that many latent issues exist in executables that do not have associated source code (or equivalent source.:EFFECTIVENESS:Limited::METHOD:Automated Static Analysis - Binary or Bytecode:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Bytecode Weakness Analysis - including disassembler + source code weakness analysis Binary Weakness Analysis - including disassembler + source code weakness analysis Cost effective for partial coverage: Binary / Bytecode simple extractor - strings, ELF readers, etc.:EFFECTIVENESS:High::METHOD:Manual Static Analysis - Binary or Bytecode:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies:EFFECTIVENESS:SOAR Partial::METHOD:Dynamic Analysis with Automated Results Interpretation:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Web Application Scanner Web Services Scanner Database Scanners:EFFECTIVENESS:SOAR Partial::METHOD:Dynamic Analysis with Manual Results Interpretation:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Fuzz Tester Framework-based Fuzzer:EFFECTIVENESS:SOAR Partial::METHOD:Manual Static Analysis - Source Code:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Manual Source Code Review (not inspections) Cost effective for partial coverage: Focused Manual Spotcheck - Focused manual analysis of source:EFFECTIVENESS:High::METHOD:Automated Static Analysis - Source Code:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer Cost effective for partial coverage: Warning Flags:EFFECTIVENESS:High::METHOD:Architecture or Design Review:DESCRIPTION:According to SOAR, the following detection techniques may be useful: Highly cost effective: Formal Methods / Correct-By-Construction Cost effective for partial coverage: Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.):EFFECTIVENESS:High::","::PHASE:Requirements:DESCRIPTION:Choose a language that is not subject to this flaw.::PHASE:Implementation:DESCRIPTION:Ensure that all format string functions are passed a static string which cannot be controlled by the user, and that the proper number of arguments are always sent to that function as well. If at all possible, use functions that do not support the %n operator in format strings. [REF-116] [REF-117]::PHASE:Build and Compilation:DESCRIPTION:Run compilers and linkers with high warning levels, since they may detect incorrect usage.::","::REFERENCE:CVE-2002-1825:DESCRIPTION:format string in Perl program:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1825::REFERENCE:CVE-2001-0717:DESCRIPTION:format string in bad call to syslog function:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0717::REFERENCE:CVE-2002-0573:DESCRIPTION:format string in bad call to syslog function:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0573::REFERENCE:CVE-2002-1788:DESCRIPTION:format strings in NNTP server responses:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1788::REFERENCE:CVE-2006-2480:DESCRIPTION:Format string vulnerability exploited by triggering errors or warnings, as demonstrated via format string specifiers in a .bmp filename.:LINK:https://www.cve.org/CVERecord?id=CVE-2006-2480::REFERENCE:CVE-2007-2027:DESCRIPTION:Chain: untrusted search path enabling resultant format string by loading malicious internationalization messages:LINK:https://www.cve.org/CVERecord?id=CVE-2007-2027::",::Logging::Error Handling::String Processing::,::Memory::,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Format string vulnerability::TAXONOMY NAME:7 Pernicious Kingdoms:ENTRY NAME:Format String::TAXONOMY NAME:CLASP:ENTRY NAME:Format string problem::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:FIO30-C:ENTRY NAME:Exclude user input from format strings:MAPPING FIT:Exact::TAXONOMY NAME:CERT C Secure Coding:ENTRY ID:FIO47-C:ENTRY NAME:Use valid format strings:MAPPING FIT:CWE More Specific::TAXONOMY NAME:OWASP Top Ten 2004:ENTRY ID:A1:ENTRY NAME:Unvalidated Input:MAPPING FIT:CWE More Specific::TAXONOMY NAME:WASC:ENTRY ID:6:ENTRY NAME:Format String::TAXONOMY NAME:The CERT Oracle Secure Coding Standard for Java (2011):ENTRY ID:IDS06-J:ENTRY NAME:Exclude user input from format strings::TAXONOMY NAME:SEI CERT Perl Coding Standard:ENTRY ID:IDS30-PL:ENTRY NAME:Exclude user input from format strings:MAPPING FIT:Exact::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::TAXONOMY NAME:OMG ASCSM:ENTRY ID:ASCSM-CWE-134::",::135::67::,"::TYPE:Applicable Platform:NOTE:This weakness is possible in any programming language that support format strings.::TYPE:Other:NOTE:While Format String vulnerabilities typically fall under the Buffer Overflow category, technically they are not overflowed buffers. The Format String vulnerability is fairly new (circa 1999) and stems from the fact that there is no realistic way for a function that takes a variable number of arguments to determine just how many arguments were passed in. The most common functions that take a variable number of arguments, including C-runtime functions, are the printf() family of calls. The Format String problem appears in a number of ways. A *printf() call without a format specifier is dangerous and can be exploited. For example, printf(input); is exploitable, while printf(y, input); is not exploitable in that context. The result of the first call, used incorrectly, allows for an attacker to be able to peek at stack memory since the input string will be used as the format specifier. The attacker can stuff the input string with format specifiers and begin reading stack values, since the remaining parameters will be pulled from the stack. Worst case, this improper use may give away enough control to allow an arbitrary value (or values in the case of an exploit program) to be written into the memory of the running program. Frequently targeted entities are file names, process names, identifiers. Format string problems are a classic C/C++ issue that are now rare due to the ease of discovery. One main reason format string vulnerabilities can be exploited is due to the %n operator. The %n operator will write the number of characters, which have been printed by the format string therefore far, to the memory pointed to by its argument. Through skilled creation of a format string, a malicious user may use values on the stack to create a write-what-where condition. Once this is achieved, they can execute arbitrary code. Other operators can be used as well; for example, a %9999s operator could also trigger a buffer overflow, or when used in file-formatting functions like fprintf, it can generate a much larger output than intended.::TYPE:Research Gap:NOTE:Format string issues are under-studied for languages other than C. Memory or disk consumption, control flow or variable alteration, and data corruption may result from format string exploitation in applications written in other languages such as Perl, PHP, Python, etc.::",
+135,"Incorrect Calculation of Multi-Byte String Length",Base,Draft,"The product does not correctly calculate the length of strings that can contain wide or multi-byte characters.","",::NATURE:ChildOf:CWE ID:682:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE NAME:C:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:C++:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation:NOTE:There are several ways in which improper string length checking may result in an exploitable condition. All of these, however, involve the introduction of buffer overflow conditions in order to reach an exploitable state. The first of these issues takes place when the output of a wide or multi-byte character string, string-length function is used as a size for the allocation of memory. While this will result in an output of the number of characters in the string, note that the characters are most likely not a single byte, as they are with standard character strings. So, using the size returned as the size sent to new or malloc and copying the string to this newly allocated memory will result in a buffer overflow. Another common way these strings are misused involves the mixing of standard string and wide or multi-byte string functions on a single string. Invariably, this mismatched information will result in the creation of a possibly exploitable buffer overflow condition.::","",,"::SCOPE:Integrity:SCOPE:Confidentiality:SCOPE:Availability:IMPACT:Execute Unauthorized Code or Commands:NOTE:This weakness may lead to a buffer overflow. Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy. This can often be used to subvert any other security service.::SCOPE:Availability:SCOPE:Confidentiality:IMPACT:Read Memory:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:DoS: Resource Consumption (CPU):IMPACT:DoS: Resource Consumption (Memory):NOTE:Out of bounds memory access will very likely result in the corruption of relevant memory, and perhaps instructions, possibly leading to a crash. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.::SCOPE:Confidentiality:IMPACT:Read Memory:NOTE:In the case of an out-of-bounds read, the attacker may have access to sensitive information. If the sensitive information contains system details, such as the current buffers position in memory, this knowledge can be used to craft further attacks, possibly with more severe consequences.::","::METHOD:Automated Static Analysis:DESCRIPTION:Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Always verify the length of the string unit character.::PHASE:Implementation:STRATEGY:Libraries or Frameworks:DESCRIPTION:Use length computing functions (e.g. strlen, wcslen, etc.) appropriately with their equivalent type (e.g.: byte, wchar_t, etc.)::","",,,"::TAXONOMY NAME:CLASP:ENTRY NAME:Improper string length checking::TAXONOMY NAME:The CERT Oracle Secure Coding Standard for Java (2011):ENTRY ID:FIO10-J:ENTRY NAME:Ensure the array is filled when using read() to fill an array::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP10:ENTRY NAME:Incorrect Buffer Length Computation::",,"",
+138,"Improper Neutralization of Special Elements",Class,Draft,"The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as control elements or syntactic markers when they are sent to a downstream component.","Most languages and protocols have their own special elements such as characters and reserved words. These special elements can carry control implications. If product does not prevent external control or influence over the inclusion of such special elements, the control flow of the program may be altered from what was intended. For example, both Unix and Windows interpret the symbol < (less than) as meaning read input from a file.",::NATURE:ChildOf:CWE ID:707:VIEW ID:1000:ORDINAL:Primary::,"::ORDINALITY:Primary::",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Other:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Alter Execution Logic:IMPACT:DoS: Crash, Exit, or Restart::","","::PHASE:Implementation:DESCRIPTION:Developers should anticipate that special elements (e.g. delimiters, symbols) will be injected into input vectors of their product. One defense is to create an allowlist (e.g. a regular expression) that defines valid input according to the requirements specifications. Strictly filter any input that does not match against the allowlist. Properly encode your output, and quote any elements that have special meaning to the component with which you are communicating.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.::PHASE:Implementation:DESCRIPTION:Use and specify an appropriate output encoding to ensure that the special elements are well-defined. A normal byte sequence in one encoding could be a special element in another.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::PHASE:Implementation:STRATEGY:Output Encoding:DESCRIPTION:While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).::","::REFERENCE:CVE-2001-0677:DESCRIPTION:Read arbitrary files from mail client by providing a special MIME header that is internally used to store pathnames for attachments.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0677::REFERENCE:CVE-2000-0703:DESCRIPTION:Setuid program does not cleanse special escape sequence before sending data to a mail program, causing the mail program to process those sequences.:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0703::REFERENCE:CVE-2003-0020:DESCRIPTION:Multi-channel issue. Terminal escape sequences not filtered from log files.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0020::REFERENCE:CVE-2003-0083:DESCRIPTION:Multi-channel issue. Terminal escape sequences not filtered from log files.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0083::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Special Elements (Characters or Reserved Words)::TAXONOMY NAME:PLOVER:ENTRY NAME:Custom Special Character Injection::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",::105::15::34::,"::TYPE:Relationship:NOTE:This weakness can be related to interpretation conflicts or interaction errors in intermediaries (such as proxies or application firewalls) when the intermediary's model of an endpoint does not account for protocol-specific special elements.::TYPE:Relationship:NOTE:See this entry's children for different types of special elements that have been observed at one point or another. However, it can be difficult to find suitable CVE examples. In an attempt to be complete, CWE includes some types that do not have any associated observed example.::TYPE:Research Gap:NOTE:This weakness is probably under-studied for proprietary or custom formats. It is likely that these issues are fairly common in applications that use their own custom format for configuration files, logs, meta-data, messaging, etc. They would only be found by accident or with a focused effort based on an understanding of the format.::",
+140,"Improper Neutralization of Delimiters",Base,Draft,"The product does not neutralize or incorrectly neutralizes delimiters.","",::NATURE:ChildOf:CWE ID:138:VIEW ID:1000:ORDINAL:Primary::,"",,"","","::PHASE:Implementation::","",,"::SCOPE:Integrity:IMPACT:Unexpected State::","","::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Developers should anticipate that delimiters will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.::PHASE:Implementation:STRATEGY:Output Encoding:DESCRIPTION:While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2003-0307:DESCRIPTION:Attacker inserts field separator into input to specify admin privileges.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0307::REFERENCE:CVE-2000-0293:DESCRIPTION:Multiple internal space, insufficient quoting - program does not use proper delimiter between values.:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0293::REFERENCE:CVE-2001-0527:DESCRIPTION:Attacker inserts carriage returns and | field separator characters to add new user/privileges.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0527::REFERENCE:CVE-2002-0267:DESCRIPTION:Linebreak in field of PHP script allows admin privileges when written to data file.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0267::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Delimiter Problems::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",::15::,"",
+141,"Improper Neutralization of Parameter/Argument Delimiters",Variant,Draft,"The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as parameter or argument delimiters when they are sent to a downstream component.","As data is parsed, an injected/absent/malformed delimiter may cause the process to take unexpected actions.",::NATURE:ChildOf:CWE ID:140:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Integrity:IMPACT:Unexpected State::","","::PHASE::DESCRIPTION:Developers should anticipate that parameter/argument delimiters will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.::PHASE:Implementation:STRATEGY:Output Encoding:DESCRIPTION:While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2003-0307:DESCRIPTION:Attacker inserts field separator into input to specify admin privileges.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0307::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Parameter Delimiter::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",,"",
+142,"Improper Neutralization of Value Delimiters",Variant,Draft,"The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as value delimiters when they are sent to a downstream component.","As data is parsed, an injected/absent/malformed delimiter may cause the process to take unexpected actions.",::NATURE:ChildOf:CWE ID:140:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Integrity:IMPACT:Unexpected State::","","::PHASE::DESCRIPTION:Developers should anticipate that value delimiters will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.::PHASE:Implementation:STRATEGY:Output Encoding:DESCRIPTION:While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2000-0293:DESCRIPTION:Multiple internal space, insufficient quoting - program does not use proper delimiter between values.:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0293::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Value Delimiter::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",,"",
+143,"Improper Neutralization of Record Delimiters",Variant,Draft,"The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as record delimiters when they are sent to a downstream component.","As data is parsed, an injected/absent/malformed delimiter may cause the process to take unexpected actions.",::NATURE:ChildOf:CWE ID:140:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Integrity:IMPACT:Unexpected State::","","::PHASE::DESCRIPTION:Developers should anticipate that record delimiters will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.::PHASE:Implementation:STRATEGY:Output Encoding:DESCRIPTION:While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2004-1982:DESCRIPTION:Carriage returns in subject field allow adding new records to data file.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1982::REFERENCE:CVE-2001-0527:DESCRIPTION:Attacker inserts carriage returns and | field separator characters to add new user/privileges.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0527::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Record Delimiter::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",,"",
+144,"Improper Neutralization of Line Delimiters",Variant,Draft,"The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as line delimiters when they are sent to a downstream component.","As data is parsed, an injected/absent/malformed delimiter may cause the process to take unexpected actions.",::NATURE:ChildOf:CWE ID:140:VIEW ID:1000:ORDINAL:Primary::NATURE:CanAlsoBe:CWE ID:93:VIEW ID:1000::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Integrity:IMPACT:Unexpected State::","","::PHASE::DESCRIPTION:Developers should anticipate that line delimiters will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.::PHASE:Implementation:STRATEGY:Output Encoding:DESCRIPTION:While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2002-0267:DESCRIPTION:Linebreak in field of PHP script allows admin privileges when written to data file.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0267::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Line Delimiter::TAXONOMY NAME:The CERT Oracle Secure Coding Standard for Java (2011):ENTRY ID:IDS03-J:ENTRY NAME:Do not log unsanitized user input::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",,"::TYPE:Relationship:NOTE:Depending on the language and syntax being used, this could be the same as the record delimiter (CWE-143).::",
+145,"Improper Neutralization of Section Delimiters",Variant,Incomplete,"The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as section delimiters when they are sent to a downstream component.","As data is parsed, an injected/absent/malformed delimiter may cause the process to take unexpected actions. One example of a section delimiter is the boundary string in a multipart MIME message. In many cases, doubled line delimiters can serve as a section delimiter.",::NATURE:ChildOf:CWE ID:140:VIEW ID:1000:ORDINAL:Primary::NATURE:CanAlsoBe:CWE ID:93:VIEW ID:1000::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Integrity:IMPACT:Unexpected State::","","::PHASE::DESCRIPTION:Developers should anticipate that section delimiters will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.::PHASE:Implementation:STRATEGY:Output Encoding:DESCRIPTION:While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Section Delimiter::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",,"::TYPE:Relationship:NOTE:Depending on the language and syntax being used, this could be the same as the record delimiter (CWE-143).::",
+146,"Improper Neutralization of Expression/Command Delimiters",Variant,Incomplete,"The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as expression or command delimiters when they are sent to a downstream component.","As data is parsed, an injected/absent/malformed delimiter may cause the process to take unexpected actions.",::NATURE:ChildOf:CWE ID:140:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Confidentiality:SCOPE:Integrity:SCOPE:Availability:SCOPE:Other:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Alter Execution Logic::","","::PHASE::DESCRIPTION:Developers should anticipate that inter-expression and inter-command delimiters will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.::PHASE:Implementation:STRATEGY:Output Encoding:DESCRIPTION:While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Delimiter between Expressions or Commands::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",::15::6::,"::TYPE:Relationship:NOTE:A shell metacharacter (covered in CWE-150) is one example of a potential delimiter that may need to be neutralized.::",
+147,"Improper Neutralization of Input Terminators",Variant,Draft,"The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as input terminators when they are sent to a downstream component.","For example, a . in SMTP signifies the end of mail message data, whereas a null character can be used for the end of a string.",::NATURE:ChildOf:CWE ID:138:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Integrity:IMPACT:Unexpected State::","","::PHASE::DESCRIPTION:Developers should anticipate that terminators will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.::PHASE:Implementation:STRATEGY:Output Encoding:DESCRIPTION:While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2000-0319:DESCRIPTION:MFV. mail server does not properly identify terminator string to signify end of message, causing corruption, possibly in conjunction with off-by-one error.:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0319::REFERENCE:CVE-2000-0320:DESCRIPTION:MFV. mail server does not properly identify terminator string to signify end of message, causing corruption, possibly in conjunction with off-by-one error.:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0320::REFERENCE:CVE-2001-0996:DESCRIPTION:Mail server does not quote end-of-input terminator if it appears in the middle of a message.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0996::REFERENCE:CVE-2002-0001:DESCRIPTION:Improperly terminated comment or phrase allows commands.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0001::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Input Terminator::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",::460::,"",
+148,"Improper Neutralization of Input Leaders",Variant,Draft,"The product does not properly handle when a leading character or sequence (leader) is missing or malformed, or if multiple leaders are used when only one should be allowed.","",::NATURE:ChildOf:CWE ID:138:VIEW ID:1000:ORDINAL:Primary::,"",,"","","::PHASE:Implementation::","",,"::SCOPE:Integrity:IMPACT:Unexpected State::","","::PHASE::DESCRIPTION:Developers should anticipate that leading characters will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.::PHASE:Implementation:STRATEGY:Output Encoding:DESCRIPTION:While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Input Leader::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",,"",
+149,"Improper Neutralization of Quoting Syntax",Variant,Draft,"Quotes injected into a product can be used to compromise a system. As data are parsed, an injected/absent/duplicate/malformed use of quotes may cause the process to take unexpected actions.","",::NATURE:ChildOf:CWE ID:138:VIEW ID:1000:ORDINAL:Primary::,"",,"","","::PHASE:Implementation::","",,"::SCOPE:Integrity:IMPACT:Unexpected State::","","::PHASE::DESCRIPTION:Developers should anticipate that quotes will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.::PHASE:Implementation:STRATEGY:Output Encoding:DESCRIPTION:While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2004-0956:DESCRIPTION:Database allows remote attackers to cause a denial of service (application crash) via a MATCH AGAINST query with an opening double quote but no closing double quote.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0956::REFERENCE:CVE-2003-1016:DESCRIPTION:MIE. MFV too? bypass AV/security with fields that should not be quoted, duplicate quotes, missing leading/trailing quotes.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-1016::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Quoting Element::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",::468::,"",
+150,"Improper Neutralization of Escape, Meta, or Control Sequences",Variant,Incomplete,"The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as escape, meta, or control character sequences when they are sent to a downstream component.","As data is parsed, an injected/absent/malformed delimiter may cause the process to take unexpected actions.",::NATURE:ChildOf:CWE ID:138:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::","",,"::SCOPE:Integrity:IMPACT:Unexpected State::","","::PHASE::DESCRIPTION:Developers should anticipate that escape, meta and control characters/sequences will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.::PHASE:Implementation:STRATEGY:Output Encoding:DESCRIPTION:While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2002-0542:DESCRIPTION:The mail program processes special ~ escape sequence even when not in interactive mode.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0542::REFERENCE:CVE-2000-0703:DESCRIPTION:Setuid program does not filter escape sequences before calling mail program.:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0703::REFERENCE:CVE-2002-0986:DESCRIPTION:Mail function does not filter control characters from arguments, allowing mail message content to be modified.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0986::REFERENCE:CVE-2003-0020:DESCRIPTION:Multi-channel issue. Terminal escape sequences not filtered from log files.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0020::REFERENCE:CVE-2003-0083:DESCRIPTION:Multi-channel issue. Terminal escape sequences not filtered from log files.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0083::REFERENCE:CVE-2003-0021:DESCRIPTION:Terminal escape sequences not filtered by terminals when displaying files.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0021::REFERENCE:CVE-2003-0022:DESCRIPTION:Terminal escape sequences not filtered by terminals when displaying files.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0022::REFERENCE:CVE-2003-0023:DESCRIPTION:Terminal escape sequences not filtered by terminals when displaying files.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0023::REFERENCE:CVE-2003-0063:DESCRIPTION:Terminal escape sequences not filtered by terminals when displaying files.:LINK:https://www.cve.org/CVERecord?id=CVE-2003-0063::REFERENCE:CVE-2000-0476:DESCRIPTION:Terminal escape sequences not filtered by terminals when displaying files.:LINK:https://www.cve.org/CVERecord?id=CVE-2000-0476::REFERENCE:CVE-2001-1556:DESCRIPTION:MFV. (multi-channel). Injection of control characters into log files that allow information hiding when using raw Unix programs to read the files.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1556::",,,"::TAXONOMY NAME:PLOVER:ENTRY NAME:Escape, Meta, or Control Character / Sequence::TAXONOMY NAME:The CERT Oracle Secure Coding Standard for Java (2011):ENTRY ID:IDS03-J:ENTRY NAME:Do not log unsanitized user input::TAXONOMY NAME:Software Fault Patterns:ENTRY ID:SFP24:ENTRY NAME:Tainted input to command::",::134::41::81::93::,"",
+151,"Improper Neutralization of Comment Delimiters",Variant,Draft,"The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as comment delimiters when they are sent to a downstream component.","",::NATURE:ChildOf:CWE ID:138:VIEW ID:1000:ORDINAL:Primary::,"",::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::,"","","::PHASE:Implementation::","",,"::SCOPE:Integrity:IMPACT:Unexpected State::","","::PHASE::DESCRIPTION:Developers should anticipate that comments will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.::PHASE:Implementation:STRATEGY:Output Encoding:DESCRIPTION:While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.::","::REFERENCE:CVE-2002-0001:DESCRIPTION:Mail client command execution due to improperly terminated comment in address list.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0001::REFERENCE:CVE-2004-0162:DESCRIPTION:MIE. RFC822 comment fields may be processed as other fields by clients.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-0162::REFERENCE:CVE-2004-1686:DESCRIPTION:Well-placed comment bypasses security warning.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1686::REFERENCE:CVE-2005-1909:DESCRIPTION:Information hiding using a manipulation involving injection of comment code into product. Note: these vulnerabilities are likely vulnerable to more general XSS problems, although a regexp might allow >!-- while denying most other tags.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1909::REFERENCE:CVE-2005-1969:DESCRIPTION:Information hiding using a manipulation involving injection of comment code into product. Note: these vulnerabilities are likely vulnerable to more general XSS problems, although a regexp might allow