Vulnerabilidades

*** Pendiente de traducción *** User-controlled inputs are improperly escaped in:<br /> <br /> <br /> <br /> <br /> * <br /> VotePage.php (poll option input)<br /> <br /> <br /> <br /> * <br /> ResultPage::getPagesTab() and getErrorsTab() (user-controllable page names)<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> This allows attackers to inject JavaScript and compromise user sessions under certain conditions.<br /> <br /> <br /> <br /> <br /> This issue affects Mediawiki - SecurePoll extension: from 1.39.X before 1.39.13, from 1.42.X before 1.42.7, from 1.43.X before 1.43.2.

*** Pendiente de traducción *** SetTranslationHandler.php does not validate that the user is an election admin, allowing any (even unauthenticated) user to change election-related translation text. While partially broken in newer MediaWiki versions, the check is still missing.<br /> <br /> <br /> <br /> <br /> This issue affects Mediawiki - SecurePoll extension: from 1.39.X before 1.39.13, from 1.42.X before 1.42.7, from 1.43.X before 1.43.2.

*** Pendiente de traducción *** A vulnerability classified as problematic was found in HDF5 1.14.6. This vulnerability affects the function H5FS__sinfo_serialize_node_cb of the file src/H5FScache.c. The manipulation leads to heap-based buffer overflow. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used.

*** Pendiente de traducción *** ArchivePage.php, UnarchivePage.php, and VoterEligibilityPage#executeClear() do not validate request methods or CSRF tokens, allowing attackers to trigger sensitive actions if an admin visits a malicious site.<br /> <br /> <br /> <br /> <br /> This issue affects Mediawiki - SecurePoll extension: from 1.39.X before 1.39.13, from 1.42.X before 1.42.7, from 1.43.X before 1.43.2.

*** Pendiente de traducción *** Uncontrolled Resource Consumption vulnerability in Wikimedia Foundation Mediawiki - IPInfo Extension allows Excessive Allocation.This issue affects Mediawiki - IPInfo Extension: from 1.39.X before 1.39.13, from 1.42.X before 1.42.7, from 1.43.X before 1.43.2.

*** Pendiente de traducción *** Improper Neutralization of Input During Web Page Generation (XSS or &amp;#39;Cross-site Scripting&amp;#39;) vulnerability in Wikimedia Foundation Mediawiki - IPInfo Extension allows Cross-Site Scripting (XSS).This issue affects Mediawiki - IPInfo Extension: from 1.39.X before 1.39.13, from 1.42.X before 1.42.7, from 1.43.X before 1.43.2.

*** Pendiente de traducción *** In MbedTLS 3.3.0 before 3.6.4, mbedtls_lms_verify may accept invalid signatures if hash computation fails and internal errors go unchecked, enabling LMS (Leighton-Micali Signature) forgery in a fault scenario. Specifically, unchecked return values in mbedtls_lms_verify allow an attacker (who can induce a hardware hash accelerator fault) to bypass LMS signature verification by reusing stale stack data, resulting in acceptance of an invalid signature. In mbedtls_lms_verify, the return values of the internal Merkle tree functions create_merkle_leaf_value and create_merkle_internal_value are not checked. These functions return an integer that indicates whether the call succeeded or not. If a failure occurs, the output buffer (Tc_candidate_root_node) may remain uninitialized, and the result of the signature verification is unpredictable. When the software implementation of SHA-256 is used, these functions will not fail. However, with hardware-accelerated hashing, an attacker could use fault injection against the accelerator to bypass verification.

*** Pendiente de traducción *** In MbedTLS 3.3.0 before 3.6.4, mbedtls_lms_import_public_key does not check that the input buffer is at least 4 bytes before reading a 32-bit field, allowing a possible out-of-bounds read on truncated input. Specifically, an out-of-bounds read in mbedtls_lms_import_public_key allows context-dependent attackers to trigger a crash or limited adjacent-memory disclosure by supplying a truncated LMS (Leighton-Micali Signature) public-key buffer under four bytes. An LMS public key starts with a 4-byte type indicator. The function mbedtls_lms_import_public_key reads this type indicator before validating the size of its input.

*** Pendiente de traducción *** Mbed TLS before 3.6.4 has a race condition in AESNI detection if certain compiler optimizations occur. An attacker may be able to extract an AES key from a multithreaded program, or perform a GCM forgery.

*** Pendiente de traducción *** Mbed TLS before 3.6.4 has a PEM parsing one-byte heap-based buffer underflow, in mbedtls_pem_read_buffer and two mbedtls_pk_parse functions, via untrusted PEM input.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/rt: Fix race in push_rt_task<br /> <br /> Overview<br /> ========<br /> When a CPU chooses to call push_rt_task and picks a task to push to<br /> another CPU&amp;#39;s runqueue then it will call find_lock_lowest_rq method<br /> which would take a double lock on both CPUs&amp;#39; runqueues. If one of the<br /> locks aren&amp;#39;t readily available, it may lead to dropping the current<br /> runqueue lock and reacquiring both the locks at once. During this window<br /> it is possible that the task is already migrated and is running on some<br /> other CPU. These cases are already handled. However, if the task is<br /> migrated and has already been executed and another CPU is now trying to<br /> wake it up (ttwu) such that it is queued again on the runqeue<br /> (on_rq is 1) and also if the task was run by the same CPU, then the<br /> current checks will pass even though the task was migrated out and is no<br /> longer in the pushable tasks list.<br /> <br /> Crashes<br /> =======<br /> This bug resulted in quite a few flavors of crashes triggering kernel<br /> panics with various crash signatures such as assert failures, page<br /> faults, null pointer dereferences, and queue corruption errors all<br /> coming from scheduler itself.<br /> <br /> Some of the crashes:<br /> -&gt; kernel BUG at kernel/sched/rt.c:1616! BUG_ON(idx &gt;= MAX_RT_PRIO)<br /> Call Trace:<br /> ? __die_body+0x1a/0x60<br /> ? die+0x2a/0x50<br /> ? do_trap+0x85/0x100<br /> ? pick_next_task_rt+0x6e/0x1d0<br /> ? do_error_trap+0x64/0xa0<br /> ? pick_next_task_rt+0x6e/0x1d0<br /> ? exc_invalid_op+0x4c/0x60<br /> ? pick_next_task_rt+0x6e/0x1d0<br /> ? asm_exc_invalid_op+0x12/0x20<br /> ? pick_next_task_rt+0x6e/0x1d0<br /> __schedule+0x5cb/0x790<br /> ? update_ts_time_stats+0x55/0x70<br /> schedule_idle+0x1e/0x40<br /> do_idle+0x15e/0x200<br /> cpu_startup_entry+0x19/0x20<br /> start_secondary+0x117/0x160<br /> secondary_startup_64_no_verify+0xb0/0xbb<br /> <br /> -&gt; BUG: kernel NULL pointer dereference, address: 00000000000000c0<br /> Call Trace:<br /> ? __die_body+0x1a/0x60<br /> ? no_context+0x183/0x350<br /> ? __warn+0x8a/0xe0<br /> ? exc_page_fault+0x3d6/0x520<br /> ? asm_exc_page_fault+0x1e/0x30<br /> ? pick_next_task_rt+0xb5/0x1d0<br /> ? pick_next_task_rt+0x8c/0x1d0<br /> __schedule+0x583/0x7e0<br /> ? update_ts_time_stats+0x55/0x70<br /> schedule_idle+0x1e/0x40<br /> do_idle+0x15e/0x200<br /> cpu_startup_entry+0x19/0x20<br /> start_secondary+0x117/0x160<br /> secondary_startup_64_no_verify+0xb0/0xbb<br /> <br /> -&gt; BUG: unable to handle page fault for address: ffff9464daea5900<br /> kernel BUG at kernel/sched/rt.c:1861! BUG_ON(rq-&gt;cpu != task_cpu(p))<br /> <br /> -&gt; kernel BUG at kernel/sched/rt.c:1055! BUG_ON(!rq-&gt;nr_running)<br /> Call Trace:<br /> ? __die_body+0x1a/0x60<br /> ? die+0x2a/0x50<br /> ? do_trap+0x85/0x100<br /> ? dequeue_top_rt_rq+0xa2/0xb0<br /> ? do_error_trap+0x64/0xa0<br /> ? dequeue_top_rt_rq+0xa2/0xb0<br /> ? exc_invalid_op+0x4c/0x60<br /> ? dequeue_top_rt_rq+0xa2/0xb0<br /> ? asm_exc_invalid_op+0x12/0x20<br /> ? dequeue_top_rt_rq+0xa2/0xb0<br /> dequeue_rt_entity+0x1f/0x70<br /> dequeue_task_rt+0x2d/0x70<br /> __schedule+0x1a8/0x7e0<br /> ? blk_finish_plug+0x25/0x40<br /> schedule+0x3c/0xb0<br /> futex_wait_queue_me+0xb6/0x120<br /> futex_wait+0xd9/0x240<br /> do_futex+0x344/0xa90<br /> ? get_mm_exe_file+0x30/0x60<br /> ? audit_exe_compare+0x58/0x70<br /> ? audit_filter_rules.constprop.26+0x65e/0x1220<br /> __x64_sys_futex+0x148/0x1f0<br /> do_syscall_64+0x30/0x80<br /> entry_SYSCALL_64_after_hwframe+0x62/0xc7<br /> <br /> -&gt; BUG: unable to handle page fault for address: ffff8cf3608bc2c0<br /> Call Trace:<br /> ? __die_body+0x1a/0x60<br /> ? no_context+0x183/0x350<br /> ? spurious_kernel_fault+0x171/0x1c0<br /> ? exc_page_fault+0x3b6/0x520<br /> ? plist_check_list+0x15/0x40<br /> ? plist_check_list+0x2e/0x40<br /> ? asm_exc_page_fault+0x1e/0x30<br /> ? _cond_resched+0x15/0x30<br /> ? futex_wait_queue_me+0xc8/0x120<br /> ? futex_wait+0xd9/0x240<br /> ? try_to_wake_up+0x1b8/0x490<br /> ? futex_wake+0x78/0x160<br /> ? do_futex+0xcd/0xa90<br /> ? plist_check_list+0x15/0x40<br /> ? plist_check_list+0x2e/0x40<br /> ? plist_del+0x6a/0xd0<br /> ? plist_check_list+0x15/0x40<br /> ? plist_check_list+0x2e/0x40<br /> ? dequeue_pushable_task+0x20/0x70<br /> ? __schedule+0x382/0x7e0<br /> ? asm_sysvec_reschedule_i<br /> ---truncated---

*** Pendiente de traducción *** OP-TEE is a Trusted Execution Environment (TEE) designed as companion to a non-secure Linux kernel running on Arm; Cortex-A cores using the TrustZone technology. In version 4.5.0, using a specially crafted tee-supplicant binary running in REE userspace, an attacker can trigger a panic in a TA that uses the libutee Secure Storage API. Many functions in libutee, specifically those which make up the Secure Storage API, will panic if a system call returns an unexpected return code. This behavior is mandated by the TEE Internal Core API specification. However, in OP-TEE’s implementation, return codes of secure storage operations are passed through unsanitized from the REE tee-supplicant, through the Linux kernel tee-driver, through the OP-TEE kernel, back to libutee. Thus, an attacker with access to REE userspace, and the ability to stop tee-supplicant and replace it with their own process (generally trivial for a root user, and depending on the way permissions are set up, potentially available even to less privileged users) can run a malicious tee-supplicant process that responds to storage requests with unexpected response codes, triggering a panic in the requesting TA. This is particularly dangerous for TAs built with `TA_FLAG_SINGLE_INSTANCE` (corresponding to `gpd.ta.singleInstance` and `TA_FLAG_INSTANCE_KEEP_ALIVE` (corresponding to `gpd.ta.keepAlive`). The behavior of these TAs may depend on memory that is preserved between sessions, and the ability of an attacker to panic the TA and reload it with a clean memory space can compromise the behavior of those TAs. A critical example of this is the optee_ftpm TA. It uses the kept alive memory to hold PCR values, which crucially must be non-resettable. An attacker who can trigger a panic in the fTPM TA can reset the PCRs, and then extend them PCRs with whatever they choose, falsifying boot measurements, accessing sealed data, and potentially more. The impact of this issue depends significantly on the behavior of affected TAs. For some, it could manifest as a denial of service, while for others, like the fTPM TA, it can result in the disclosure of sensitive data. Anyone running the fTPM TA is affected, but similar attacks may be possible on other TAs that leverage the Secure Storage API. A fix is available in commit 941a58d78c99c4754fbd4ec3079ec9e1d596af8f.