В ядре Linux устранена следующая уязвимость:
ptrace: немного более разумная логика get_dumpable()
«Сбрасываемость» задачи в основном связана с образом памяти о ней.
задача - концепция исходит из того, может ли он дать дамп ядра или нет - и
не имеет смысла, если у вас нет связанного мм. И почти все пользователи фактически используют его только в том случае, если задача
имеет указатель мм. Но у нас есть один странный особый случай: ptrace_may_access() использует 'dumpable' для
проверять различные другие вещи совершенно независимо от ММ (обычно
явно используя такие флаги, как PTRACE_MODE_READ_FSCREDS).
В том числе для потоки, у которых больше нет виртуальной машины (и, возможно, никогда не было, как и у большинства ядерных нити). Этот флаг был создан не для того, но он такой, какой он есть. Код ptrace проверяет совпадение uid/gid, поэтому вам необходимо быть uid-0, чтобы увидеть детали потока ядра, но это означает, что традиционная модель «отбрасывания возможностей» не имеет никакого значения для это все.
Придайте всему этому *немного* больше смысла, сказав, что если у вас нет
указатель MM, мы будем использовать кэшированный флаг «последней возможности сброса», если поток
когда-либо имел MM (для потоков ядра он будет равен нулю, поскольку он никогда не бывает
set) и требуют наличия соответствующей возможности CAP_SYS_PTRACE для переопределения.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional "drop capabilities" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached "last dumpability" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.
Характеристики атаки
Последствия
Строка CVSS v3.1
Тип уязвимости (CWE)
Уязвимые продукты 14
| Конфигурация | От (включительно) | До (исключительно) |
|---|---|---|
|
Linux Linux_Kernel
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
|
3.16.52
|
3.17
|
|
Linux Linux_Kernel
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
|
4.4.40
|
4.5
|
|
Linux Linux_Kernel
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
|
4.8.16
|
4.9
|
|
Linux Linux_Kernel
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
|
4.9.1
|
5.10.256
|
|
Linux Linux_Kernel
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
|
5.11
|
5.15.207
|
|
Linux Linux_Kernel
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
|
5.16
|
6.1.173
|
|
Linux Linux_Kernel
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
|
6.2
|
6.6.139
|
|
Linux Linux_Kernel
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
|
6.7
|
6.12.89
|
|
Linux Linux_Kernel
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
|
6.13
|
6.18.31
|
|
Linux Linux_Kernel
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
|
6.19
|
7.0.8
|
|
Linux Linux_Kernel
cpe:2.3:o:linux:linux_kernel:7.1:rc1:*:*:*:*:*:*
|
— | — |
|
Linux Linux_Kernel
cpe:2.3:o:linux:linux_kernel:7.1:rc2:*:*:*:*:*:*
|
— | — |
|
Linux Linux_Kernel
cpe:2.3:o:linux:linux_kernel:7.1:rc3:*:*:*:*:*:*
|
— | — |
|
Debian Debian_Linux
cpe:2.3:o:debian:debian_linux:11.0:*:*:*:*:*:*:*
|
— | — |