Hi,These bug fix releases of the LTTng kernel and user-space tracers contain security fixes which address memory disclosure and denial of service issues. Those are of relatively low severity mainly because they involve specific uses of the tracer by users that belong to the `tracing` group.
Here is the explanation of the impact for each issue corrected. The issues that have a security impact are tagged with [security].
The issues that were corrected in LTTng 2.12 were likely present in older versions, which are not maintained anymore. All users of LTTng-modules and LTTng-UST should upgrade.
* Kernel tracer (LTTng-modules) 2.13.7:[security] A user belonging to the `tracing` group can use the event notification capture or the filtering features to target a userspace string (e.g. pathname input field of the openat system call) while any user on the system feeds an invalid pointer or a pointer to kernel memory to the instrumented system call. This results in a kernel OOPS in case of an invalid pointer, or disclosure of kernel memory to the tracing group if the pointer targets a kernel memory address. This is corrected by properly keeping track of user pointers and using the appropriate methods to access userspace memory.
[security] A user belonging to the `tracing` group can use the event notification capture or the filtering features to target a userspace array of integers (e.g. fildes output field of the pipe2 system call) while any user on the system feeds an invalid pointer or a pointer to kernel memory to the instrumented system call. This results in a kernel OOPS in case of an invalid pointer, or disclosure of kernel memory to the tracing group if the pointer targets a kernel memory address. This is corrected by properly keeping track of user pointers and using the appropriate methods to access userspace memory.
[security] A `tracing` group user crafting an ill-intended event notification capture or filter bytecode can emit load and load-field-ref instructions which are already specialized for the wrong field type, thus bypassing the instruction selection performed by the bytecode linker and bytecode specialization phases. When combined with passing invalid or kernel memory pointers to userspace memory arguments (e.g. pathname input field of openat or fildes output field of pipe2), this can result in a kernel OOPS in case of an invalid pointer, or a disclosure of kernel memory to the tracing group if the pointer targets a kernel memory address. This is corrected by rejecting specialized load and load-field-ref instructions in the bytecode validation phase.
Event notification capture fields that end up using more than 512 bytes of msgpack buffer space for a single event notification emit warnings in the kernel console and result in a corrupted msgpack buffer. This is fixed by emitting a "NIL" msgpack field rather than the field that would require too much space.
When an event notification capture for a userspace string or a userspace integer triggers a page fault, emit a "NIL" msgpack field rather than an empty string or a zero-value integer.
Fix a kernel OOPS on powerpc64 when the lttng_tracer module initializes, because the do_get_kallsyms LTTng wrapper returns the address of the local entry point rather than the global entry point. This is corrected by adjusting the offset (+4 and then -4) to get the global entry point on PPC64_ELF_ABI_v2.
* Kernel tracer (LTTng-modules) 2.12.11:[security] A user belonging to the `tracing` group can use the filtering feature to target a userspace array of integers (e.g. fildes output field of the pipe2 system call) while any user on the system feeds an invalid pointer or a pointer to kernel memory to the instrumented system call. This results in a kernel OOPS in case of an invalid pointer, or disclosure of kernel memory to the tracing group if the pointer targets a kernel memory address. This is corrected by properly keeping track of user pointers and using the appropriate methods to access userspace memory.
[security] A `tracing` group user crafting an ill-intended filter bytecode can emit load and load-field-ref instructions which are already specialized for the wrong field type, thus bypassing the instruction selection performed by the bytecode linker and bytecode specialization phases. When combined with passing invalid or kernel memory pointers to userspace memory arguments (e.g. pathname input field of openat or fildes output field of pipe2), this can result in a kernel OOPS in case of an invalid pointer, or a disclosure of kernel memory to the tracing group if the pointer targets a kernel memory address. This is corrected by rejecting specialized load and load-field-ref instructions in the bytecode validation phase.
Fix a kernel OOPS on powerpc64 when the lttng_tracer module initializes, because the do_get_kallsyms LTTng wrapper returns the address of the local entry point rather than the global entry point. This is corrected by adjusting the offset (+4 and then -4) to get the global entry point on PPC64_ELF_ABI_v2.
The filter bytecode interpreter leaves context field byte order uninitialized, which can cause erratic filtering behavior when targeting context fields. This is not currently observable because current lttng-tools do not currently emit BYTECODE_OP_GET_SYMBOL instructions to load the context value for filtering. Fix this by initializing the byte order field.
* Application tracer (LTTng-UST) 2.13.5:[security] A `tracing` group user crafting an ill-intended event notification capture or filter bytecode can emit load and load-field-ref instructions which are already specialized for the wrong field type, thus bypassing the instruction selection performed by the bytecode linker and bytecode specialization phases. This can result in a disclosure of application memory to the tracing group if the type expected by the instrumentation is larger than the instrumented type, or application crash if a string is expected but the top of interpreter stack does not point to a valid address. This is corrected by rejecting specialized load and load-field-ref instructions in the bytecode validation phase.
Event notification capture fields that end up using more than the number of bytes allocated for the msgpack buffer space for a single event notification can cause the resulting msgpack buffer to be corrupted. This is fixed by emitting a "NIL" msgpack field rather than the field that would require too much space.
When getting the shared memory area at initialization time, wait(3) is used to wait on the forked child process to exit, which can cause the library to wait on any child process of the application. Use waitpid(3) instead to make sure the right child is waited for, and therefore don't wait for unrelated, unreaped, child processes.
* Application tracer (LTTng-UST) 2.12.7:[security] A `tracing` group user crafting an ill-intended event notification capture or filter bytecode can emit load and load-field-ref instructions which are already specialized for the wrong field type, thus bypassing the instruction selection performed by the bytecode linker and bytecode specialization phases. This can result in a disclosure of application memory to the tracing group if the type expected by the instrumentation is larger than the instrumented type, or application crash if a string is expected but the top of interpreter stack does not point to a valid address. This is corrected by rejecting specialized load and load-field-ref instructions in the bytecode validation phase.
When getting the shared memory area at initialization time, wait(3) is used to wait on the forked child process to exit, which can cause the library to wait on any child process of the application. Use waitpid(3) instead to make sure the right child is waited for, and therefore don't wait for unrelated, unreaped, child processes.
Project website: https://lttng.org Documentation: https://lttng.org/docs Download link: https://lttng.org/download -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com
|