gsd-2021-47128
Vulnerability from gsd
Modified
2024-03-05 06:03
Details
In the Linux kernel, the following vulnerability has been resolved:
bpf, lockdown, audit: Fix buggy SELinux lockdown permission checks
Commit 59438b46471a ("security,lockdown,selinux: implement SELinux lockdown")
added an implementation of the locked_down LSM hook to SELinux, with the aim
to restrict which domains are allowed to perform operations that would breach
lockdown. This is indirectly also getting audit subsystem involved to report
events. The latter is problematic, as reported by Ondrej and Serhei, since it
can bring down the whole system via audit:
1) The audit events that are triggered due to calls to security_locked_down()
can OOM kill a machine, see below details [0].
2) It also seems to be causing a deadlock via avc_has_perm()/slow_avc_audit()
when trying to wake up kauditd, for example, when using trace_sched_switch()
tracepoint, see details in [1]. Triggering this was not via some hypothetical
corner case, but with existing tools like runqlat & runqslower from bcc, for
example, which make use of this tracepoint. Rough call sequence goes like:
rq_lock(rq) -> -------------------------+
trace_sched_switch() -> |
bpf_prog_xyz() -> +-> deadlock
selinux_lockdown() -> |
audit_log_end() -> |
wake_up_interruptible() -> |
try_to_wake_up() -> |
rq_lock(rq) --------------+
What's worse is that the intention of 59438b46471a to further restrict lockdown
settings for specific applications in respect to the global lockdown policy is
completely broken for BPF. The SELinux policy rule for the current lockdown check
looks something like this:
allow <who> <who> : lockdown { <reason> };
However, this doesn't match with the 'current' task where the security_locked_down()
is executed, example: httpd does a syscall. There is a tracing program attached
to the syscall which triggers a BPF program to run, which ends up doing a
bpf_probe_read_kernel{,_str}() helper call. The selinux_lockdown() hook does
the permission check against 'current', that is, httpd in this example. httpd
has literally zero relation to this tracing program, and it would be nonsensical
having to write an SELinux policy rule against httpd to let the tracing helper
pass. The policy in this case needs to be against the entity that is installing
the BPF program. For example, if bpftrace would generate a histogram of syscall
counts by user space application:
bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'
bpftrace would then go and generate a BPF program from this internally. One way
of doing it [for the sake of the example] could be to call bpf_get_current_task()
helper and then access current->comm via one of bpf_probe_read_kernel{,_str}()
helpers. So the program itself has nothing to do with httpd or any other random
app doing a syscall here. The BPF program _explicitly initiated_ the lockdown
check. The allow/deny policy belongs in the context of bpftrace: meaning, you
want to grant bpftrace access to use these helpers, but other tracers on the
system like my_random_tracer _not_.
Therefore fix all three issues at the same time by taking a completely different
approach for the security_locked_down() hook, that is, move the check into the
program verification phase where we actually retrieve the BPF func proto. This
also reliably gets the task (current) that is trying to install the BPF tracing
program, e.g. bpftrace/bcc/perf/systemtap/etc, and it also fixes the OOM since
we're moving this out of the BPF helper's fast-path which can be called several
millions of times per second.
The check is then also in line with other security_locked_down() hooks in the
system where the enforcement is performed at open/load time, for example,
open_kcore() for /proc/kcore access or module_sig_check() for module signatures
just to pick f
---truncated---
Aliases
{
"gsd": {
"metadata": {
"exploitCode": "unknown",
"remediation": "unknown",
"reportConfidence": "confirmed",
"type": "vulnerability"
},
"osvSchema": {
"aliases": [
"CVE-2021-47128"
],
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, lockdown, audit: Fix buggy SELinux lockdown permission checks\n\nCommit 59438b46471a (\"security,lockdown,selinux: implement SELinux lockdown\")\nadded an implementation of the locked_down LSM hook to SELinux, with the aim\nto restrict which domains are allowed to perform operations that would breach\nlockdown. This is indirectly also getting audit subsystem involved to report\nevents. The latter is problematic, as reported by Ondrej and Serhei, since it\ncan bring down the whole system via audit:\n\n 1) The audit events that are triggered due to calls to security_locked_down()\n can OOM kill a machine, see below details [0].\n\n 2) It also seems to be causing a deadlock via avc_has_perm()/slow_avc_audit()\n when trying to wake up kauditd, for example, when using trace_sched_switch()\n tracepoint, see details in [1]. Triggering this was not via some hypothetical\n corner case, but with existing tools like runqlat \u0026 runqslower from bcc, for\n example, which make use of this tracepoint. Rough call sequence goes like:\n\n rq_lock(rq) -\u003e -------------------------+\n trace_sched_switch() -\u003e |\n bpf_prog_xyz() -\u003e +-\u003e deadlock\n selinux_lockdown() -\u003e |\n audit_log_end() -\u003e |\n wake_up_interruptible() -\u003e |\n try_to_wake_up() -\u003e |\n rq_lock(rq) --------------+\n\nWhat\u0027s worse is that the intention of 59438b46471a to further restrict lockdown\nsettings for specific applications in respect to the global lockdown policy is\ncompletely broken for BPF. The SELinux policy rule for the current lockdown check\nlooks something like this:\n\n allow \u003cwho\u003e \u003cwho\u003e : lockdown { \u003creason\u003e };\n\nHowever, this doesn\u0027t match with the \u0027current\u0027 task where the security_locked_down()\nis executed, example: httpd does a syscall. There is a tracing program attached\nto the syscall which triggers a BPF program to run, which ends up doing a\nbpf_probe_read_kernel{,_str}() helper call. The selinux_lockdown() hook does\nthe permission check against \u0027current\u0027, that is, httpd in this example. httpd\nhas literally zero relation to this tracing program, and it would be nonsensical\nhaving to write an SELinux policy rule against httpd to let the tracing helper\npass. The policy in this case needs to be against the entity that is installing\nthe BPF program. For example, if bpftrace would generate a histogram of syscall\ncounts by user space application:\n\n bpftrace -e \u0027tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }\u0027\n\nbpftrace would then go and generate a BPF program from this internally. One way\nof doing it [for the sake of the example] could be to call bpf_get_current_task()\nhelper and then access current-\u003ecomm via one of bpf_probe_read_kernel{,_str}()\nhelpers. So the program itself has nothing to do with httpd or any other random\napp doing a syscall here. The BPF program _explicitly initiated_ the lockdown\ncheck. The allow/deny policy belongs in the context of bpftrace: meaning, you\nwant to grant bpftrace access to use these helpers, but other tracers on the\nsystem like my_random_tracer _not_.\n\nTherefore fix all three issues at the same time by taking a completely different\napproach for the security_locked_down() hook, that is, move the check into the\nprogram verification phase where we actually retrieve the BPF func proto. This\nalso reliably gets the task (current) that is trying to install the BPF tracing\nprogram, e.g. bpftrace/bcc/perf/systemtap/etc, and it also fixes the OOM since\nwe\u0027re moving this out of the BPF helper\u0027s fast-path which can be called several\nmillions of times per second.\n\nThe check is then also in line with other security_locked_down() hooks in the\nsystem where the enforcement is performed at open/load time, for example,\nopen_kcore() for /proc/kcore access or module_sig_check() for module signatures\njust to pick f\n---truncated---",
"id": "GSD-2021-47128",
"modified": "2024-03-05T06:03:55.167748Z",
"schema_version": "1.4.0"
}
},
"namespaces": {
"cve.org": {
"CVE_data_meta": {
"ASSIGNER": "cve@kernel.org",
"ID": "CVE-2021-47128",
"STATE": "PUBLIC"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "Linux",
"version": {
"version_data": [
{
"version_affected": "\u003c",
"version_name": "59438b46471a",
"version_value": "ff5039ec75c8"
},
{
"version_value": "not down converted",
"x_cve_json_5_version_data": {
"defaultStatus": "affected",
"versions": [
{
"status": "affected",
"version": "5.6"
},
{
"lessThan": "5.6",
"status": "unaffected",
"version": "0",
"versionType": "custom"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.43",
"versionType": "custom"
},
{
"lessThanOrEqual": "5.12.*",
"status": "unaffected",
"version": "5.12.10",
"versionType": "custom"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "5.13",
"versionType": "original_commit_for_fix"
}
]
}
}
]
}
}
]
},
"vendor_name": "Linux"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, lockdown, audit: Fix buggy SELinux lockdown permission checks\n\nCommit 59438b46471a (\"security,lockdown,selinux: implement SELinux lockdown\")\nadded an implementation of the locked_down LSM hook to SELinux, with the aim\nto restrict which domains are allowed to perform operations that would breach\nlockdown. This is indirectly also getting audit subsystem involved to report\nevents. The latter is problematic, as reported by Ondrej and Serhei, since it\ncan bring down the whole system via audit:\n\n 1) The audit events that are triggered due to calls to security_locked_down()\n can OOM kill a machine, see below details [0].\n\n 2) It also seems to be causing a deadlock via avc_has_perm()/slow_avc_audit()\n when trying to wake up kauditd, for example, when using trace_sched_switch()\n tracepoint, see details in [1]. Triggering this was not via some hypothetical\n corner case, but with existing tools like runqlat \u0026 runqslower from bcc, for\n example, which make use of this tracepoint. Rough call sequence goes like:\n\n rq_lock(rq) -\u003e -------------------------+\n trace_sched_switch() -\u003e |\n bpf_prog_xyz() -\u003e +-\u003e deadlock\n selinux_lockdown() -\u003e |\n audit_log_end() -\u003e |\n wake_up_interruptible() -\u003e |\n try_to_wake_up() -\u003e |\n rq_lock(rq) --------------+\n\nWhat\u0027s worse is that the intention of 59438b46471a to further restrict lockdown\nsettings for specific applications in respect to the global lockdown policy is\ncompletely broken for BPF. The SELinux policy rule for the current lockdown check\nlooks something like this:\n\n allow \u003cwho\u003e \u003cwho\u003e : lockdown { \u003creason\u003e };\n\nHowever, this doesn\u0027t match with the \u0027current\u0027 task where the security_locked_down()\nis executed, example: httpd does a syscall. There is a tracing program attached\nto the syscall which triggers a BPF program to run, which ends up doing a\nbpf_probe_read_kernel{,_str}() helper call. The selinux_lockdown() hook does\nthe permission check against \u0027current\u0027, that is, httpd in this example. httpd\nhas literally zero relation to this tracing program, and it would be nonsensical\nhaving to write an SELinux policy rule against httpd to let the tracing helper\npass. The policy in this case needs to be against the entity that is installing\nthe BPF program. For example, if bpftrace would generate a histogram of syscall\ncounts by user space application:\n\n bpftrace -e \u0027tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }\u0027\n\nbpftrace would then go and generate a BPF program from this internally. One way\nof doing it [for the sake of the example] could be to call bpf_get_current_task()\nhelper and then access current-\u003ecomm via one of bpf_probe_read_kernel{,_str}()\nhelpers. So the program itself has nothing to do with httpd or any other random\napp doing a syscall here. The BPF program _explicitly initiated_ the lockdown\ncheck. The allow/deny policy belongs in the context of bpftrace: meaning, you\nwant to grant bpftrace access to use these helpers, but other tracers on the\nsystem like my_random_tracer _not_.\n\nTherefore fix all three issues at the same time by taking a completely different\napproach for the security_locked_down() hook, that is, move the check into the\nprogram verification phase where we actually retrieve the BPF func proto. This\nalso reliably gets the task (current) that is trying to install the BPF tracing\nprogram, e.g. bpftrace/bcc/perf/systemtap/etc, and it also fixes the OOM since\nwe\u0027re moving this out of the BPF helper\u0027s fast-path which can be called several\nmillions of times per second.\n\nThe check is then also in line with other security_locked_down() hooks in the\nsystem where the enforcement is performed at open/load time, for example,\nopen_kcore() for /proc/kcore access or module_sig_check() for module signatures\njust to pick f\n---truncated---"
}
]
},
"generator": {
"engine": "bippy-8df59b4913de"
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "n/a"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://git.kernel.org/stable/c/ff5039ec75c83d2ed5b781dc7733420ee8c985fc",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/ff5039ec75c83d2ed5b781dc7733420ee8c985fc"
},
{
"name": "https://git.kernel.org/stable/c/acc43fc6cf0d50612193813c5906a1ab9d433e1e",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/acc43fc6cf0d50612193813c5906a1ab9d433e1e"
},
{
"name": "https://git.kernel.org/stable/c/ff40e51043af63715ab413995ff46996ecf9583f",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/ff40e51043af63715ab413995ff46996ecf9583f"
}
]
}
},
"nvd.nist.gov": {
"cve": {
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, lockdown, audit: Fix buggy SELinux lockdown permission checks\n\nCommit 59438b46471a (\"security,lockdown,selinux: implement SELinux lockdown\")\nadded an implementation of the locked_down LSM hook to SELinux, with the aim\nto restrict which domains are allowed to perform operations that would breach\nlockdown. This is indirectly also getting audit subsystem involved to report\nevents. The latter is problematic, as reported by Ondrej and Serhei, since it\ncan bring down the whole system via audit:\n\n 1) The audit events that are triggered due to calls to security_locked_down()\n can OOM kill a machine, see below details [0].\n\n 2) It also seems to be causing a deadlock via avc_has_perm()/slow_avc_audit()\n when trying to wake up kauditd, for example, when using trace_sched_switch()\n tracepoint, see details in [1]. Triggering this was not via some hypothetical\n corner case, but with existing tools like runqlat \u0026 runqslower from bcc, for\n example, which make use of this tracepoint. Rough call sequence goes like:\n\n rq_lock(rq) -\u003e -------------------------+\n trace_sched_switch() -\u003e |\n bpf_prog_xyz() -\u003e +-\u003e deadlock\n selinux_lockdown() -\u003e |\n audit_log_end() -\u003e |\n wake_up_interruptible() -\u003e |\n try_to_wake_up() -\u003e |\n rq_lock(rq) --------------+\n\nWhat\u0027s worse is that the intention of 59438b46471a to further restrict lockdown\nsettings for specific applications in respect to the global lockdown policy is\ncompletely broken for BPF. The SELinux policy rule for the current lockdown check\nlooks something like this:\n\n allow \u003cwho\u003e \u003cwho\u003e : lockdown { \u003creason\u003e };\n\nHowever, this doesn\u0027t match with the \u0027current\u0027 task where the security_locked_down()\nis executed, example: httpd does a syscall. There is a tracing program attached\nto the syscall which triggers a BPF program to run, which ends up doing a\nbpf_probe_read_kernel{,_str}() helper call. The selinux_lockdown() hook does\nthe permission check against \u0027current\u0027, that is, httpd in this example. httpd\nhas literally zero relation to this tracing program, and it would be nonsensical\nhaving to write an SELinux policy rule against httpd to let the tracing helper\npass. The policy in this case needs to be against the entity that is installing\nthe BPF program. For example, if bpftrace would generate a histogram of syscall\ncounts by user space application:\n\n bpftrace -e \u0027tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }\u0027\n\nbpftrace would then go and generate a BPF program from this internally. One way\nof doing it [for the sake of the example] could be to call bpf_get_current_task()\nhelper and then access current-\u003ecomm via one of bpf_probe_read_kernel{,_str}()\nhelpers. So the program itself has nothing to do with httpd or any other random\napp doing a syscall here. The BPF program _explicitly initiated_ the lockdown\ncheck. The allow/deny policy belongs in the context of bpftrace: meaning, you\nwant to grant bpftrace access to use these helpers, but other tracers on the\nsystem like my_random_tracer _not_.\n\nTherefore fix all three issues at the same time by taking a completely different\napproach for the security_locked_down() hook, that is, move the check into the\nprogram verification phase where we actually retrieve the BPF func proto. This\nalso reliably gets the task (current) that is trying to install the BPF tracing\nprogram, e.g. bpftrace/bcc/perf/systemtap/etc, and it also fixes the OOM since\nwe\u0027re moving this out of the BPF helper\u0027s fast-path which can be called several\nmillions of times per second.\n\nThe check is then also in line with other security_locked_down() hooks in the\nsystem where the enforcement is performed at open/load time, for example,\nopen_kcore() for /proc/kcore access or module_sig_check() for module signatures\njust to pick f\n---truncated---"
}
],
"id": "CVE-2021-47128",
"lastModified": "2024-03-17T22:38:29.433",
"metrics": {},
"published": "2024-03-15T21:15:07.470",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/acc43fc6cf0d50612193813c5906a1ab9d433e1e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/ff40e51043af63715ab413995ff46996ecf9583f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/ff5039ec75c83d2ed5b781dc7733420ee8c985fc"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
}
}
}
}
Loading...
Loading...
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.