CWE-129
AllowedImproper Validation of Array Index
Abstraction: Variant · Status: 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.
746 vulnerabilities reference this CWE, most recent first.
GHSA-37H8-X7J6-5J7X
Vulnerability from github – Published: 2025-07-09 12:31 – Updated: 2025-12-18 18:30In the Linux kernel, the following vulnerability has been resolved:
scsi: megaraid_sas: Fix invalid node index
On a system with DRAM interleave enabled, out-of-bound access is detected:
megaraid_sas 0000:3f:00.0: requested/available msix 128/128 poll_queue 0 ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x46/0x4b megasas_alloc_irq_vectors+0x149/0x190 [megaraid_sas] megasas_probe_one.cold+0xa4d/0x189c [megaraid_sas] local_pci_probe+0x42/0x90 pci_device_probe+0xdc/0x290 really_probe+0xdb/0x340 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8b/0xe0 bus_add_driver+0x142/0x220 driver_register+0x72/0xd0 megasas_init+0xdf/0xff0 [megaraid_sas] do_one_initcall+0x57/0x310 do_init_module+0x90/0x250 init_module_from_file+0x85/0xc0 idempotent_init_module+0x114/0x310 __x64_sys_finit_module+0x65/0xc0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Fix it accordingly.
{
"affected": [],
"aliases": [
"CVE-2025-38239"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-09T11:15:25Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: megaraid_sas: Fix invalid node index\n\nOn a system with DRAM interleave enabled, out-of-bound access is\ndetected:\n\nmegaraid_sas 0000:3f:00.0: requested/available msix 128/128 poll_queue 0\n------------[ cut here ]------------\nUBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28\nindex -1 is out of range for type \u0027cpumask *[1024]\u0027\ndump_stack_lvl+0x5d/0x80\nubsan_epilogue+0x5/0x2b\n__ubsan_handle_out_of_bounds.cold+0x46/0x4b\nmegasas_alloc_irq_vectors+0x149/0x190 [megaraid_sas]\nmegasas_probe_one.cold+0xa4d/0x189c [megaraid_sas]\nlocal_pci_probe+0x42/0x90\npci_device_probe+0xdc/0x290\nreally_probe+0xdb/0x340\n__driver_probe_device+0x78/0x110\ndriver_probe_device+0x1f/0xa0\n__driver_attach+0xba/0x1c0\nbus_for_each_dev+0x8b/0xe0\nbus_add_driver+0x142/0x220\ndriver_register+0x72/0xd0\nmegasas_init+0xdf/0xff0 [megaraid_sas]\ndo_one_initcall+0x57/0x310\ndo_init_module+0x90/0x250\ninit_module_from_file+0x85/0xc0\nidempotent_init_module+0x114/0x310\n__x64_sys_finit_module+0x65/0xc0\ndo_syscall_64+0x82/0x170\nentry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFix it accordingly.",
"id": "GHSA-37h8-x7j6-5j7x",
"modified": "2025-12-18T18:30:28Z",
"published": "2025-07-09T12:31:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38239"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/074efb35552556a4b3b25eedab076d5dc24a8199"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/19a47c966deb36624843b7301f0373a3dc541a05"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/752eb816b55adb0673727ba0ed96609a17895654"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bf2c1643abc3b2507d56bb6c22bf9897272f8a35"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f1064b3532192e987ab17be7281d5fee36fd25e1"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-39CV-HX7C-VJCQ
Vulnerability from github – Published: 2025-05-01 15:31 – Updated: 2025-11-04 18:31In the Linux kernel, the following vulnerability has been resolved:
net_sched: sch_sfq: move the limit validation
It is not sufficient to directly validate the limit on the data that the user passes as it can be updated based on how the other parameters are changed.
Move the check at the end of the configuration update process to also catch scenarios where the limit is indirectly updated, for example with the following configurations:
tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 depth 1 tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 divisor 1
This fixes the following syzkaller reported crash:
------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:203:6 index 65535 is out of range for type 'struct sfq_head[128]' CPU: 1 UID: 0 PID: 3037 Comm: syz.2.16 Not tainted 6.14.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x201/0x300 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_out_of_bounds+0xf5/0x120 lib/ubsan.c:429 sfq_link net/sched/sch_sfq.c:203 [inline] sfq_dec+0x53c/0x610 net/sched/sch_sfq.c:231 sfq_dequeue+0x34e/0x8c0 net/sched/sch_sfq.c:493 sfq_reset+0x17/0x60 net/sched/sch_sfq.c:518 qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035 tbf_reset+0x41/0x110 net/sched/sch_tbf.c:339 qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035 dev_reset_queue+0x100/0x1b0 net/sched/sch_generic.c:1311 netdev_for_each_tx_queue include/linux/netdevice.h:2590 [inline] dev_deactivate_many+0x7e5/0xe70 net/sched/sch_generic.c:1375
{
"affected": [],
"aliases": [
"CVE-2025-37752"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-01T13:15:53Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: sch_sfq: move the limit validation\n\nIt is not sufficient to directly validate the limit on the data that\nthe user passes as it can be updated based on how the other parameters\nare changed.\n\nMove the check at the end of the configuration update process to also\ncatch scenarios where the limit is indirectly updated, for example\nwith the following configurations:\n\ntc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 depth 1\ntc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 divisor 1\n\nThis fixes the following syzkaller reported crash:\n\n------------[ cut here ]------------\nUBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:203:6\nindex 65535 is out of range for type \u0027struct sfq_head[128]\u0027\nCPU: 1 UID: 0 PID: 3037 Comm: syz.2.16 Not tainted 6.14.0-rc2-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024\nCall Trace:\n \u003cTASK\u003e\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x201/0x300 lib/dump_stack.c:120\n ubsan_epilogue lib/ubsan.c:231 [inline]\n __ubsan_handle_out_of_bounds+0xf5/0x120 lib/ubsan.c:429\n sfq_link net/sched/sch_sfq.c:203 [inline]\n sfq_dec+0x53c/0x610 net/sched/sch_sfq.c:231\n sfq_dequeue+0x34e/0x8c0 net/sched/sch_sfq.c:493\n sfq_reset+0x17/0x60 net/sched/sch_sfq.c:518\n qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035\n tbf_reset+0x41/0x110 net/sched/sch_tbf.c:339\n qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035\n dev_reset_queue+0x100/0x1b0 net/sched/sch_generic.c:1311\n netdev_for_each_tx_queue include/linux/netdevice.h:2590 [inline]\n dev_deactivate_many+0x7e5/0xe70 net/sched/sch_generic.c:1375",
"id": "GHSA-39cv-hx7c-vjcq",
"modified": "2025-11-04T18:31:33Z",
"published": "2025-05-01T15:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37752"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1348214fa042a71406964097e743c87a42c85a49"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5e5e1fcc1b8ed57f902c424c5d9b328a3a19073d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6c589aa318023690f1606c666a7fb5f4c1c9c219"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7d62ded97db6b7c94c891f704151f372b1ba4688"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8fadc871a42933aacb7f1ce9ed9a96485e2c9cf4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b36a68192037d1614317a09b0d78c7814e2eecf9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b3bf8f63e6179076b57c9de660c9f80b5abefe70"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d2718324f9e329b10ddc091fba5a0ba2b9d4d96a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f86293adce0c201cfabb283ef9d6f21292089bb8"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3CCM-4QQ2-5WRP
Vulnerability from github – Published: 2026-07-01 18:47 – Updated: 2026-07-01 18:47Summary
ciphertextContainer.UnmarshalJSON decodes the third :-separated component of a vault:vX:base64... ciphertext and then unconditionally takes a 12-byte prefix slice for the AES-GCM nonce: c.nonce = fullCiphertext[:aesGCMNonceSize]. If the decoded blob is shorter than 12 bytes, the slice expression panics. The panic happens before any cryptographic operation, while the JSON body of the request is still being parsed inside the request handler. Because the handler is invoked from net/http's standard handler goroutine, the panic is recovered to a 500 response, but the request handler aborts mid-execution and the recovered panic appears in the Coordinator's logs. An authenticated workload that holds a valid mesh certificate for any WorkloadSecretID can trigger the panic at will, producing log spam, request-failure metrics, and a slow but cheap denial of service against the transit-engine endpoint.
Details
the panicking slice
coordinator/internal/transitengineapi/crypto.go:64-88:
// UnmarshalJSON umarshalls a json string to a ciphertextContainer holding the version prefix,
// decoded base64 nonce and ciphertext.
func (c *ciphertextContainer) UnmarshalJSON(data []byte) error {
var encoded string
if err := json.Unmarshal(data, &encoded); err != nil {
return err
}
// Split "vault:vX:base64" format
parts := strings.SplitN(encoded, ":", 3)
if len(parts) < 3 {
return fmt.Errorf("invalid ciphertext format")
}
version, err := extractVersion(parts[1])
if err != nil {
return fmt.Errorf("ciphertext version: %w", err)
}
c.keyVersion = version
fullCiphertext, err := base64.StdEncoding.DecodeString(parts[2])
if err != nil {
return fmt.Errorf("decoding ciphertext: %w", err)
}
c.nonce = fullCiphertext[:aesGCMNonceSize] // PANIC when len(fullCiphertext) < 12
c.ciphertext = fullCiphertext[aesGCMNonceSize:]
return nil
}
aesGCMNonceSize = 12 (defined at line 33). There is no length check on fullCiphertext. If parts[2] decodes to fewer than 12 bytes (which happens for any base64 string shorter than ~16 characters), the slice expression fullCiphertext[:aesGCMNonceSize] triggers Go's runtime panic runtime error: slice bounds out of range [:12] with length N.
UnmarshalJSON is reached from parseRequest:
// coordinator/internal/transitengineapi/transitengineapi.go:292-302
func parseRequest(r *http.Request, into any) error {
defer r.Body.Close()
if err := validateContentType(r); err != nil {
return err
}
if err := json.NewDecoder(r.Body).Decode(into); err != nil {
return err
}
return nil
}
which is called inside getDecryptHandler (line 178-237) before any other processing.
auth requirement is real but trivial to satisfy for any registered workload
The transit-engine HTTP server (transitengineapi.go:74-100) configures tls.RequireAndVerifyClientCert with the Coordinator's mesh CA pool. The handler is wrapped by authorizationMiddleware (line 348-357) which calls authorizeWorkloadSecret (line 241-254). That function reads the WorkloadSecretOID extension from the peer cert and requires it to match the URL path's {name} segment.
Any workload that has gone through the normal initializer / meshapi flow (coordinator/internal/meshapi/meshapi.go:71-119) and has a non-empty WorkloadSecretID in its PolicyEntry is issued a mesh cert with the matching extension, so the path-name authorisation is automatically satisfied for whichever workloadSecretID the manifest assigned to that workload. There is no rate limiting, no proof-of-work, and no audit log on triggering the panic.
what happens after the panic
net/http wraps each handler in a recovered goroutine, so the panic does not crash the Coordinator process. Instead:
- The Go runtime captures the panic, logs
http: panic serving <peer>: runtime error: slice bounds out of rangeto stderr together with a goroutine stack trace. - The connection is hung up without a response body (
http.Server.servecallsc.close()in the recovery path). - The grpc-prometheus / handler metrics (registered via
promRegistry) record the request as failed. - The recovered panic appears in the Coordinator's logs / journald, creating noise that an operator monitoring a real attack would have to filter out.
A workload that wants to amplify the impact can:
- Loop the request to fill the journal with stack traces (cheap operation per request, expensive log volume).
- Combine with a second valid workload identity to bypass any per-cert rate limiting added later.
- Use the panic stack trace (which contains internal source paths) as a fingerprint to determine the exact Coordinator version in lieu of a
/versionendpoint.
The panic also avoids returning a JSON error body to the caller, so callers that depend on a structured error are forced into a less informative failure mode (HTTP-level connection close).
PoC
The bug is deterministic. Drop the following test into coordinator/internal/transitengineapi/crypto_test.go:
func TestCiphertextContainer_UnmarshalJSON_ShortBlobPanics(t *testing.T) {
// "AAAA" base64-decodes to 3 bytes, well under aesGCMNonceSize=12.
body := []byte(`"vault:v1:AAAA"`)
defer func() {
if r := recover(); r == nil {
t.Fatalf("expected panic, got nil")
}
}()
var c ciphertextContainer
_ = c.UnmarshalJSON(body) // panics: slice bounds out of range [:12] with length 3
}
End-to-end against a running Coordinator (omitted for static review; would require a Contrast cluster and a mesh-certificate-holding workload):
$ curl -k --cert workload.crt --key workload.key \
-H 'Content-Type: application/json' \
-d '{"ciphertext":"vault:v1:AAAA","associated_data":""}' \
https://coordinator:8200/v1/transit/decrypt/<my-workload-secret-id>
# Connection: closed without HTTP response body.
# Coordinator log:
# http: panic serving 10.0.0.5:54321: runtime error: slice bounds out of range [:12] with length 3
# goroutine 4711 [running]:
# net/http.(*conn).serve.func1(...)
# net/http/server.go:1883 +0xb0
# panic({0x...?, 0x...?})
# runtime/panic.go:770 +0x132
# github.com/edgelesssys/contrast/coordinator/internal/transitengineapi.(*ciphertextContainer).UnmarshalJSON(...)
# coordinator/internal/transitengineapi/crypto.go:85 +0x...
Impact
- Soft denial of service against the transit-engine endpoint per workload identity. The Coordinator process survives because of
net/http's panic recovery, but each panicked request consumes CPU for the recovery / stack dump and floods the operator's logs. - Information disclosure via stack trace in the Coordinator log. The trace pins the Coordinator binary version, the build path of the
transitengineapipackage, and exact line numbers of internal source. This is a low-grade fingerprint, but it is leaked even to operators who would normally only see the binary version through controlled means. - Loss of structured error reporting: legitimate decrypt requests sharing the panicked log lines may be harder to attribute, and the API consumer sees a connection-close instead of a 4xx response, masking the cause.
CVSS rationale: AV:N, AC:L, PR:L (any workload with a transit-engine permission can do this), UI:N, S:U, C:N / I:N / A:L (low availability impact: log noise + per-request CPU cost; no full DoS because Go's HTTP panic recovery keeps the process up). Score 3.1.
Recommended Fix
Validate the decoded length before slicing. The minimal change at coordinator/internal/transitengineapi/crypto.go:81-87:
fullCiphertext, err := base64.StdEncoding.DecodeString(parts[2])
if err != nil {
return fmt.Errorf("decoding ciphertext: %w", err)
}
if len(fullCiphertext) < aesGCMNonceSize {
return fmt.Errorf("ciphertext is too short: got %d bytes, expected at least %d for the nonce", len(fullCiphertext), aesGCMNonceSize)
}
c.nonce = fullCiphertext[:aesGCMNonceSize]
c.ciphertext = fullCiphertext[aesGCMNonceSize:]
return nil
A defence-in-depth tightening would also reject ciphertexts with len(fullCiphertext) <= aesGCMNonceSize (which would yield an empty actual ciphertext that AES-GCM open would later reject anyway, but a sharper boundary fails earlier with a clearer error). Add a unit test along the lines of the PoC that asserts a clean error rather than a panic.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.20.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/edgelesssys/contrast"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.21.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-01T18:47:53Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\n`ciphertextContainer.UnmarshalJSON` decodes the third `:`-separated component of a `vault:vX:base64...` ciphertext and then unconditionally takes a 12-byte prefix slice for the AES-GCM nonce: `c.nonce = fullCiphertext[:aesGCMNonceSize]`. If the decoded blob is shorter than 12 bytes, the slice expression panics. The panic happens before any cryptographic operation, while the JSON body of the request is still being parsed inside the request handler. Because the handler is invoked from `net/http`\u0027s standard handler goroutine, the panic is recovered to a 500 response, but the request handler aborts mid-execution and the recovered panic appears in the Coordinator\u0027s logs. An authenticated workload that holds a valid mesh certificate for any `WorkloadSecretID` can trigger the panic at will, producing log spam, request-failure metrics, and a slow but cheap denial of service against the transit-engine endpoint.\n\n## Details\n\n### the panicking slice\n\n`coordinator/internal/transitengineapi/crypto.go:64-88`:\n\n```go\n// UnmarshalJSON umarshalls a json string to a ciphertextContainer holding the version prefix,\n// decoded base64 nonce and ciphertext.\nfunc (c *ciphertextContainer) UnmarshalJSON(data []byte) error {\n\tvar encoded string\n\tif err := json.Unmarshal(data, \u0026encoded); err != nil {\n\t\treturn err\n\t}\n\t// Split \"vault:vX:base64\" format\n\tparts := strings.SplitN(encoded, \":\", 3)\n\tif len(parts) \u003c 3 {\n\t\treturn fmt.Errorf(\"invalid ciphertext format\")\n\t}\n\tversion, err := extractVersion(parts[1])\n\tif err != nil {\n\t\treturn fmt.Errorf(\"ciphertext version: %w\", err)\n\t}\n\tc.keyVersion = version\n\tfullCiphertext, err := base64.StdEncoding.DecodeString(parts[2])\n\tif err != nil {\n\t\treturn fmt.Errorf(\"decoding ciphertext: %w\", err)\n\t}\n\tc.nonce = fullCiphertext[:aesGCMNonceSize] // PANIC when len(fullCiphertext) \u003c 12\n\tc.ciphertext = fullCiphertext[aesGCMNonceSize:]\n\treturn nil\n}\n```\n\n`aesGCMNonceSize = 12` (defined at line 33). There is no length check on `fullCiphertext`. If `parts[2]` decodes to fewer than 12 bytes (which happens for any base64 string shorter than ~16 characters), the slice expression `fullCiphertext[:aesGCMNonceSize]` triggers Go\u0027s runtime panic `runtime error: slice bounds out of range [:12] with length N`.\n\n`UnmarshalJSON` is reached from `parseRequest`:\n\n```go\n// coordinator/internal/transitengineapi/transitengineapi.go:292-302\nfunc parseRequest(r *http.Request, into any) error {\n\tdefer r.Body.Close()\n\tif err := validateContentType(r); err != nil {\n\t\treturn err\n\t}\n\tif err := json.NewDecoder(r.Body).Decode(into); err != nil {\n\t\treturn err\n\t}\n\treturn nil\n}\n```\n\nwhich is called inside `getDecryptHandler` (line 178-237) before any other processing.\n\n### auth requirement is real but trivial to satisfy for any registered workload\n\nThe transit-engine HTTP server (`transitengineapi.go:74-100`) configures `tls.RequireAndVerifyClientCert` with the Coordinator\u0027s mesh CA pool. The handler is wrapped by `authorizationMiddleware` (line 348-357) which calls `authorizeWorkloadSecret` (line 241-254). That function reads the `WorkloadSecretOID` extension from the peer cert and requires it to match the URL path\u0027s `{name}` segment.\n\nAny workload that has gone through the normal initializer / meshapi flow (`coordinator/internal/meshapi/meshapi.go:71-119`) and has a non-empty `WorkloadSecretID` in its `PolicyEntry` is issued a mesh cert with the matching extension, so the path-name authorisation is automatically satisfied for whichever `workloadSecretID` the manifest assigned to that workload. There is no rate limiting, no proof-of-work, and no audit log on triggering the panic.\n\n### what happens after the panic\n\n`net/http` wraps each handler in a recovered goroutine, so the panic does not crash the Coordinator process. Instead:\n\n1. The Go runtime captures the panic, logs `http: panic serving \u003cpeer\u003e: runtime error: slice bounds out of range` to stderr together with a goroutine stack trace.\n2. The connection is hung up without a response body (`http.Server.serve` calls `c.close()` in the recovery path).\n3. The grpc-prometheus / handler metrics (registered via `promRegistry`) record the request as failed.\n4. The recovered panic appears in the Coordinator\u0027s logs / journald, creating noise that an operator monitoring a real attack would have to filter out.\n\nA workload that wants to amplify the impact can:\n\n* Loop the request to fill the journal with stack traces (cheap operation per request, expensive log volume).\n* Combine with a second valid workload identity to bypass any per-cert rate limiting added later.\n* Use the panic stack trace (which contains internal source paths) as a fingerprint to determine the exact Coordinator version in lieu of a `/version` endpoint.\n\nThe panic also avoids returning a JSON error body to the caller, so callers that depend on a structured error are forced into a less informative failure mode (HTTP-level connection close).\n\n## PoC\n\nThe bug is deterministic. Drop the following test into `coordinator/internal/transitengineapi/crypto_test.go`:\n\n```go\nfunc TestCiphertextContainer_UnmarshalJSON_ShortBlobPanics(t *testing.T) {\n\t// \"AAAA\" base64-decodes to 3 bytes, well under aesGCMNonceSize=12.\n\tbody := []byte(`\"vault:v1:AAAA\"`)\n\tdefer func() {\n\t\tif r := recover(); r == nil {\n\t\t\tt.Fatalf(\"expected panic, got nil\")\n\t\t}\n\t}()\n\tvar c ciphertextContainer\n\t_ = c.UnmarshalJSON(body) // panics: slice bounds out of range [:12] with length 3\n}\n```\n\nEnd-to-end against a running Coordinator (omitted for static review; would require a Contrast cluster and a mesh-certificate-holding workload):\n\n```bash\n$ curl -k --cert workload.crt --key workload.key \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"ciphertext\":\"vault:v1:AAAA\",\"associated_data\":\"\"}\u0027 \\\n https://coordinator:8200/v1/transit/decrypt/\u003cmy-workload-secret-id\u003e\n\n# Connection: closed without HTTP response body.\n# Coordinator log:\n# http: panic serving 10.0.0.5:54321: runtime error: slice bounds out of range [:12] with length 3\n# goroutine 4711 [running]:\n# net/http.(*conn).serve.func1(...)\n# net/http/server.go:1883 +0xb0\n# panic({0x...?, 0x...?})\n# runtime/panic.go:770 +0x132\n# github.com/edgelesssys/contrast/coordinator/internal/transitengineapi.(*ciphertextContainer).UnmarshalJSON(...)\n# coordinator/internal/transitengineapi/crypto.go:85 +0x...\n```\n\n## Impact\n\n* **Soft denial of service** against the transit-engine endpoint per workload identity. The Coordinator process survives because of `net/http`\u0027s panic recovery, but each panicked request consumes CPU for the recovery / stack dump and floods the operator\u0027s logs.\n* **Information disclosure via stack trace** in the Coordinator log. The trace pins the Coordinator binary version, the build path of the `transitengineapi` package, and exact line numbers of internal source. This is a low-grade fingerprint, but it is leaked even to operators who would normally only see the binary version through controlled means.\n* **Loss of structured error reporting**: legitimate decrypt requests sharing the panicked log lines may be harder to attribute, and the API consumer sees a connection-close instead of a 4xx response, masking the cause.\n\nCVSS rationale: `AV:N`, `AC:L`, `PR:L` (any workload with a transit-engine permission can do this), `UI:N`, `S:U`, `C:N` / `I:N` / `A:L` (low availability impact: log noise + per-request CPU cost; no full DoS because Go\u0027s HTTP panic recovery keeps the process up). Score `3.1`.\n\n## Recommended Fix\n\nValidate the decoded length before slicing. The minimal change at `coordinator/internal/transitengineapi/crypto.go:81-87`:\n\n```go\nfullCiphertext, err := base64.StdEncoding.DecodeString(parts[2])\nif err != nil {\n\treturn fmt.Errorf(\"decoding ciphertext: %w\", err)\n}\nif len(fullCiphertext) \u003c aesGCMNonceSize {\n\treturn fmt.Errorf(\"ciphertext is too short: got %d bytes, expected at least %d for the nonce\", len(fullCiphertext), aesGCMNonceSize)\n}\nc.nonce = fullCiphertext[:aesGCMNonceSize]\nc.ciphertext = fullCiphertext[aesGCMNonceSize:]\nreturn nil\n```\n\nA defence-in-depth tightening would also reject ciphertexts with `len(fullCiphertext) \u003c= aesGCMNonceSize` (which would yield an empty actual ciphertext that AES-GCM open would later reject anyway, but a sharper boundary fails earlier with a clearer error). Add a unit test along the lines of the PoC that asserts a clean error rather than a panic.",
"id": "GHSA-3ccm-4qq2-5wrp",
"modified": "2026-07-01T18:47:53Z",
"published": "2026-07-01T18:47:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/edgelesssys/contrast/security/advisories/GHSA-3ccm-4qq2-5wrp"
},
{
"type": "WEB",
"url": "https://github.com/edgelesssys/contrast/commit/d6584fbff816037472034f7ad6e08cdbab1d870d"
},
{
"type": "PACKAGE",
"url": "https://github.com/edgelesssys/contrast"
},
{
"type": "WEB",
"url": "https://github.com/edgelesssys/contrast/releases/tag/v1.21.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "Constrata\u0027s coordinator transit engine `ciphertextContainer.UnmarshalJSON` panics on attacker-controlled short ciphertexts"
}
GHSA-3CPP-8F88-6JXP
Vulnerability from github – Published: 2022-05-24 17:33 – Updated: 2022-05-24 17:33u'Buffer overflow can happen as part of SIP message packet processing while storing values in array due to lack of check to validate the index length' in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Wearables in Agatti, APQ8053, APQ8096AU, APQ8098, Bitra, Kamorta, MSM8905, MSM8909W, MSM8917, MSM8940, MSM8953, MSM8996AU, Nicobar, QCA6390, QCA6574AU, QCM2150, QCS605, QM215, Rennell, SA6155P, SA8155P, Saipan, SDA660, SDM429, SDM429W, SDM439, SDM450, SDM630, SDM632, SDM636, SDM660, SDM670, SDM710, SDM845, SM6150, SM7150, SM8150, SM8250, SXR1130, SXR2130
{
"affected": [],
"aliases": [
"CVE-2020-3673"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-11-02T07:15:00Z",
"severity": "CRITICAL"
},
"details": "u\u0027Buffer overflow can happen as part of SIP message packet processing while storing values in array due to lack of check to validate the index length\u0027 in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Wearables in Agatti, APQ8053, APQ8096AU, APQ8098, Bitra, Kamorta, MSM8905, MSM8909W, MSM8917, MSM8940, MSM8953, MSM8996AU, Nicobar, QCA6390, QCA6574AU, QCM2150, QCS605, QM215, Rennell, SA6155P, SA8155P, Saipan, SDA660, SDM429, SDM429W, SDM439, SDM450, SDM630, SDM632, SDM636, SDM660, SDM670, SDM710, SDM845, SM6150, SM7150, SM8150, SM8250, SXR1130, SXR2130",
"id": "GHSA-3cpp-8f88-6jxp",
"modified": "2022-05-24T17:33:03Z",
"published": "2022-05-24T17:33:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-3673"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins/october-2020-bulletin"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins/october-2020-security-bulletin"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-3F2J-PP6Q-8HP5
Vulnerability from github – Published: 2022-04-19 00:00 – Updated: 2022-04-24 00:00Multiple code execution vulnerabilities exists in the Nef polygon-parsing functionality of CGAL libcgal CGAL-5.1.1. A specially crafted malformed file can lead to an out-of-bounds read and type confusion, which could lead to code execution. An attacker can provide malicious input to trigger any of these vulnerabilities. An oob read vulnerability exists in Nef_S2/SNC_io_parser.h SNC_io_parser::read_vertex() vh->svertices_begin().
{
"affected": [],
"aliases": [
"CVE-2020-28612"
],
"database_specific": {
"cwe_ids": [
"CWE-125",
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-18T17:15:00Z",
"severity": "HIGH"
},
"details": "Multiple code execution vulnerabilities exists in the Nef polygon-parsing functionality of CGAL libcgal CGAL-5.1.1. A specially crafted malformed file can lead to an out-of-bounds read and type confusion, which could lead to code execution. An attacker can provide malicious input to trigger any of these vulnerabilities. An oob read vulnerability exists in Nef_S2/SNC_io_parser.h SNC_io_parser\u003cEW\u003e::read_vertex() vh-\u003esvertices_begin().",
"id": "GHSA-3f2j-pp6q-8hp5",
"modified": "2022-04-24T00:00:32Z",
"published": "2022-04-19T00:00:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28612"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/12/msg00011.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202305-34"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2020-1225"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3F3W-4RVJ-J62G
Vulnerability from github – Published: 2023-09-05 09:30 – Updated: 2024-04-04 07:26Memory Corruption due to improper validation of array index in Linux while updating adn record.
{
"affected": [],
"aliases": [
"CVE-2023-21636"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-09-05T07:15:12Z",
"severity": "HIGH"
},
"details": "Memory Corruption due to improper validation of array index in Linux while updating adn record.",
"id": "GHSA-3f3w-4rvj-j62g",
"modified": "2024-04-04T07:26:46Z",
"published": "2023-09-05T09:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21636"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins/september-2023-bulletin"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3FXG-PQX6-JXM3
Vulnerability from github – Published: 2022-05-24 16:51 – Updated: 2024-04-04 01:22Firmware is getting into loop of overwriting memory when scan command is given from host because of improper validation. in Snapdragon Compute, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wired Infrastructure and Networking in IPQ8074, QCA8081, QCS404, QCS405, QCS605, SD 425, SD 427, SD 430, SD 435, SD 450, SD 625, SD 636, SD 712 / SD 710 / SD 670, SD 820, SD 835, SD 845 / SD 850, SD 855, SD 8CX, SDA660, SDM630, SDM660
{
"affected": [],
"aliases": [
"CVE-2019-2346"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-07-25T17:15:00Z",
"severity": "HIGH"
},
"details": "Firmware is getting into loop of overwriting memory when scan command is given from host because of improper validation. in Snapdragon Compute, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice \u0026 Music, Snapdragon Wired Infrastructure and Networking in IPQ8074, QCA8081, QCS404, QCS405, QCS605, SD 425, SD 427, SD 430, SD 435, SD 450, SD 625, SD 636, SD 712 / SD 710 / SD 670, SD 820, SD 835, SD 845 / SD 850, SD 855, SD 8CX, SDA660, SDM630, SDM660",
"id": "GHSA-3fxg-pqx6-jxm3",
"modified": "2024-04-04T01:22:54Z",
"published": "2022-05-24T16:51:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-2346"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3G28-V7G2-X3C3
Vulnerability from github – Published: 2022-05-14 03:28 – Updated: 2022-05-14 03:28In Android before 2018-04-05 or earlier security patch level on Qualcomm Snapdragon Mobile SD 425, SD 430, SD 450, and SD 625, in a QTEE API function, an array out-of-bounds index can occur.
{
"affected": [],
"aliases": [
"CVE-2016-10454"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-04-18T14:29:00Z",
"severity": "CRITICAL"
},
"details": "In Android before 2018-04-05 or earlier security patch level on Qualcomm Snapdragon Mobile SD 425, SD 430, SD 450, and SD 625, in a QTEE API function, an array out-of-bounds index can occur.",
"id": "GHSA-3g28-v7g2-x3c3",
"modified": "2022-05-14T03:28:16Z",
"published": "2022-05-14T03:28:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-10454"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2018-04-01"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/103671"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3G2P-5Q22-H774
Vulnerability from github – Published: 2022-10-10 19:00 – Updated: 2025-06-09 15:31An issue was discovered in D-Bus before 1.12.24, 1.13.x and 1.14.x before 1.14.4, and 1.15.x before 1.15.2. An authenticated attacker can cause dbus-daemon and other programs that use libdbus to crash when receiving a message where an array length is inconsistent with the size of the element type.
{
"affected": [],
"aliases": [
"CVE-2022-42011"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-10T00:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in D-Bus before 1.12.24, 1.13.x and 1.14.x before 1.14.4, and 1.15.x before 1.15.2. An authenticated attacker can cause dbus-daemon and other programs that use libdbus to crash when receiving a message where an array length is inconsistent with the size of the element type.",
"id": "GHSA-3g2p-5q22-h774",
"modified": "2025-06-09T15:31:34Z",
"published": "2022-10-10T19:00:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42011"
},
{
"type": "WEB",
"url": "https://gitlab.freedesktop.org/dbus/dbus/-/issues/413"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/E4CO7N226I3X5FNBR2MACCH6TS764VJP"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ND74SKN56BCYL3QLEAAB6E64UUBRA5UG"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/SQCSLMCK2XGX23R2DKW2MSAICQAK6MT2"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/E4CO7N226I3X5FNBR2MACCH6TS764VJP"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ND74SKN56BCYL3QLEAAB6E64UUBRA5UG"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/SQCSLMCK2XGX23R2DKW2MSAICQAK6MT2"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202305-08"
},
{
"type": "WEB",
"url": "https://www.openwall.com/lists/oss-security/2022/10/06/1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3G98-4F8C-VH63
Vulnerability from github – Published: 2023-11-27 00:30 – Updated: 2023-11-27 00:30A vulnerability classified as problematic was found in Apryse iText 8.0.2. This vulnerability affects the function main of the file PdfDocument.java. The manipulation leads to improper validation of array index. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-246124. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2023-6298"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-26T23:15:07Z",
"severity": "MODERATE"
},
"details": "A vulnerability classified as problematic was found in Apryse iText 8.0.2. This vulnerability affects the function main of the file PdfDocument.java. The manipulation leads to improper validation of array index. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-246124. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-3g98-4f8c-vh63",
"modified": "2023-11-27T00:30:31Z",
"published": "2023-11-27T00:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6298"
},
{
"type": "WEB",
"url": "https://drive.google.com/drive/folders/1OBAeGH_rNfa1os6g6QlIt4pL-2NKHZm_?usp=sharing"
},
{
"type": "WEB",
"url": "https://kb.itextpdf.com/itext/statement-regarding-cve-2022-24198-and-2023-6298"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.246124"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.246124"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-7
Strategy: Input Validation
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).
Mitigation MIT-15
- 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.
Mitigation MIT-3
Strategy: Language Selection
- Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, 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.
Mitigation MIT-11
Strategy: Environment Hardening
- 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].
Mitigation MIT-12
Strategy: Environment Hardening
- 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].
Mitigation MIT-5
Strategy: Input Validation
- 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.
Mitigation MIT-35
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.
Mitigation MIT-17
Strategy: Environment Hardening
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.
Mitigation MIT-22
Strategy: Sandbox or Jail
- 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.
CAPEC-100: Overflow Buffers
Buffer Overflow attacks target improper or missing bounds checking on buffer operations, typically triggered by input injected by an adversary. As a consequence, an adversary is able to write past the boundaries of allocated buffer regions in memory, causing a program crash or potentially redirection of execution as per the adversaries' choice.