Vulnerabilidades

WonderCMS 3.5.0 es vulnerable a falsificación de petición del lado del servidor (SSRF) en la funcionalidad de instalación de módulos personalizados. Un administrador autenticado puede proporcionar una URL maliciosa a través del parámetro POST pluginThemeUrl. El servidor obtiene la URL proporcionada utilizando curl_exec() sin validación suficiente, permitiendo al atacante forzar peticiones HTTP internas o externas.

Una vulnerabilidad de falsificación de petición del lado del servidor (SSRF) en Ghost permite a un atacante acceder a recursos internos. Este problema afecta a Ghost: desde la versión 6.0.0 hasta la 6.0.8, y desde la 5.99.0 hasta la 5.130.3.

*** Pendiente de traducción *** A vulnerability was found in SourceCodester Online Exam Form Submission 1.0. This affects an unknown part of the file /index.php. The manipulation of the argument usn results in sql injection. The attack can be launched remotely. The exploit has been made public and could be used.

*** Pendiente de traducción *** Apache::AuthAny::Cookie v0.201 or earlier for Perl generates session ids insecurely.<br /> <br /> Session ids are generated using an MD5 hash of the epoch time and a call to the built-in rand function. The epoch time may be guessed, if it is not leaked from the HTTP Date header. The built-in rand function is unsuitable for cryptographic usage.<br /> <br /> Predicable session ids could allow an attacker to gain access to systems.

*** Pendiente de traducción *** A vulnerability has been found in SourceCodester Online Student File Management System 1.0. Affected by this issue is some unknown functionality of the file /admin/delete_user.php. The manipulation of the argument user_id leads to sql injection. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.

*** Pendiente de traducción *** Use of Hard-coded Credentials vulnerability in ABB FLXEON.This issue affects FLXEON: through 9.3.5 and newer versions

*** Pendiente de traducción *** Use of a One-Way Hash with a Predictable Salt vulnerability in ABB FLXEON.This issue affects FLXEON: through 9.3.5. and newer versions

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/habanalabs: fix mem leak in capture user mappings<br /> <br /> This commit fixes a memory leak caused when clearing the user_mappings<br /> info when a new context is opened immediately after user_mapping is<br /> captured and a hard reset is performed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix race issue between cpu buffer write and swap<br /> <br /> Warning happened in rb_end_commit() at code:<br /> if (RB_WARN_ON(cpu_buffer, !local_read(&amp;cpu_buffer-&gt;committing)))<br /> <br /> WARNING: CPU: 0 PID: 139 at kernel/trace/ring_buffer.c:3142<br /> rb_commit+0x402/0x4a0<br /> Call Trace:<br /> ring_buffer_unlock_commit+0x42/0x250<br /> trace_buffer_unlock_commit_regs+0x3b/0x250<br /> trace_event_buffer_commit+0xe5/0x440<br /> trace_event_buffer_reserve+0x11c/0x150<br /> trace_event_raw_event_sched_switch+0x23c/0x2c0<br /> __traceiter_sched_switch+0x59/0x80<br /> __schedule+0x72b/0x1580<br /> schedule+0x92/0x120<br /> worker_thread+0xa0/0x6f0<br /> <br /> It is because the race between writing event into cpu buffer and swapping<br /> cpu buffer through file per_cpu/cpu0/snapshot:<br /> <br /> Write on CPU 0 Swap buffer by per_cpu/cpu0/snapshot on CPU 1<br /> -------- --------<br /> tracing_snapshot_write()<br /> [...]<br /> <br /> ring_buffer_lock_reserve()<br /> cpu_buffer = buffer-&gt;buffers[cpu]; // 1. Suppose find &amp;#39;cpu_buffer_a&amp;#39;;<br /> [...]<br /> rb_reserve_next_event()<br /> [...]<br /> <br /> ring_buffer_swap_cpu()<br /> if (local_read(&amp;cpu_buffer_a-&gt;committing))<br /> goto out_dec;<br /> if (local_read(&amp;cpu_buffer_b-&gt;committing))<br /> goto out_dec;<br /> buffer_a-&gt;buffers[cpu] = cpu_buffer_b;<br /> buffer_b-&gt;buffers[cpu] = cpu_buffer_a;<br /> // 2. cpu_buffer has swapped here.<br /> <br /> rb_start_commit(cpu_buffer);<br /> if (unlikely(READ_ONCE(cpu_buffer-&gt;buffer)<br /> != buffer)) { // 3. This check passed due to &amp;#39;cpu_buffer-&gt;buffer&amp;#39;<br /> [...] // has not changed here.<br /> return NULL;<br /> }<br /> cpu_buffer_b-&gt;buffer = buffer_a;<br /> cpu_buffer_a-&gt;buffer = buffer_b;<br /> [...]<br /> <br /> // 4. Reserve event from &amp;#39;cpu_buffer_a&amp;#39;.<br /> <br /> ring_buffer_unlock_commit()<br /> [...]<br /> cpu_buffer = buffer-&gt;buffers[cpu]; // 5. Now find &amp;#39;cpu_buffer_b&amp;#39; !!!<br /> rb_commit(cpu_buffer)<br /> rb_end_commit() // 6. WARN for the wrong &amp;#39;committing&amp;#39; state !!!<br /> <br /> Based on above analysis, we can easily reproduce by following testcase:<br /> ``` bash<br /> #!/bin/bash<br /> <br /> dmesg -n 7<br /> sysctl -w kernel.panic_on_warn=1<br /> TR=/sys/kernel/tracing<br /> echo 7 &gt; ${TR}/buffer_size_kb<br /> echo "sched:sched_switch" &gt; ${TR}/set_event<br /> while [ true ]; do<br /> echo 1 &gt; ${TR}/per_cpu/cpu0/snapshot<br /> done &amp;<br /> while [ true ]; do<br /> echo 1 &gt; ${TR}/per_cpu/cpu0/snapshot<br /> done &amp;<br /> while [ true ]; do<br /> echo 1 &gt; ${TR}/per_cpu/cpu0/snapshot<br /> done &amp;<br /> ```<br /> <br /> To fix it, IIUC, we can use smp_call_function_single() to do the swap on<br /> the target cpu where the buffer is located, so that above race would be<br /> avoided.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: fix memory leak with using debugfs_lookup()<br /> <br /> When calling debugfs_lookup() the result must have dput() called on it,<br /> otherwise the memory will leak over time. To make things simpler, just<br /> call debugfs_lookup_and_remove() instead which handles all of the logic at<br /> once.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSv4.2: Rework scratch handling for READ_PLUS (again)<br /> <br /> I found that the read code might send multiple requests using the same<br /> nfs_pgio_header, but nfs4_proc_read_setup() is only called once. This is<br /> how we ended up occasionally double-freeing the scratch buffer, but also<br /> means we set a NULL pointer but non-zero length to the xdr scratch<br /> buffer. This results in an oops the first time decoding needs to copy<br /> something to scratch, which frequently happens when decoding READ_PLUS<br /> hole segments.<br /> <br /> I fix this by moving scratch handling into the pageio read code. I<br /> provide a function to allocate scratch space for decoding read replies,<br /> and free the scratch buffer when the nfs_pgio_header is freed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: mm: Add p?d_leaf() definitions<br /> <br /> When I do LTP test, LTP test case ksm06 caused panic at<br /> break_ksm_pmd_entry<br /> -&gt; pmd_leaf (Huge page table but False)<br /> -&gt; pte_present (panic)<br /> <br /> The reason is pmd_leaf() is not defined, So like commit 501b81046701<br /> ("mips: mm: add p?d_leaf() definitions") add p?d_leaf() definition for<br /> LoongArch.