Vulnerabilidades

*** Pendiente de traducción *** picoclaw

*** Pendiente de traducción *** @pensar/apex

*** Pendiente de traducción *** Netis AC1200 Router NC21 V4.0.1.4296 contains a hard-coded root credential stored in /etc/shadow.sample. The password for the root account is set to the trivially weak value root, allowing an attacker with access to the device to authenticate as root and gain full control of the underlying operating system.

*** Pendiente de traducción *** Netis AC1200 Router NC21 V4.0.1.4296 is vulnerable to unauthenticated command injection via the /cgi-bin/skk_set.cgi endpoint. The password and new_pwd_confirm POST parameters are passed directly to the underlying OS shell without sanitization. An attacker can inject arbitrary shell commands by wrapping them in backticks (`) and encoding them in base64. Because the endpoint requires no authentication, any device on the LAN can achieve full Remote Code Execution on the router's operating system with a single HTTP POST request.

*** Pendiente de traducción *** Slican telephone exchanges allow administrative protocol authentication bypass. An attacker can bypass the need to enter login credentials by executing the appropriate command.<br /> <br /> <br /> This issue was fixed in versions below:<br /> - NCP: version 1.24.0250<br /> - IPx series: version 6.61.0040<br /> - CCT-1668: version 6.56.0430<br /> - MAC-6400: version 6.56.0430<br /> - CXS-0424: version 6.30.0510<br /> <br /> The issue STILL EXISTS in End-Of-Life telephone exchanges in versions 4.xx and below:<br /> - CCT-1668 (CCT1CPU)<br /> - MAC-6400<br /> - CXS-0424<br /> These products were discontinued in 2011 and 2012 and and will not receive updates. These products require a hardware update in order to receive a software update. The vendor recommends that users of these devices contact the their service department directly to determine the options for upgrading.

*** Pendiente de traducción *** In Slican telephone exchanges secure key is generated in a predictable manner using properties of the telephone exchange which can be obtained without authentication. An unauthenticated attacker can deduce the secure key and obtain admin credentials.<br /> <br /> This issue was fixed in versions below:<br /> - IPx series: version 6.61.0040<br /> - CCT-1668: version 6.56.0430<br /> - MAC-6400: version 6.56.0430<br /> - CXS-0424: version 6.30.0510<br /> <br /> The issue STILL EXISTS in End-Of-Life telephone exchanges in versions 4.xx and below:<br /> - CCT-1668 (CCT1CPU)<br /> - MAC-6400<br /> - CXS-0424<br /> These products were discontinued in 2011 and 2012 and and will not receive updates. These products require a hardware update in order to receive a software update. The vendor recommends that users of these devices contact the their service department directly to determine the options for upgrading.

*** Pendiente de traducción *** IBM MQ Operator SC2: v3.2.0 through 3.2.23CD:  v3.3.0, v3.4.0, v3.4.1, v3.5.0, v3.5.1 - v3.5.3, v3.6.0 - v3.6.4, v3.7.0 - v3.7.2, v3.8.0, v3.8.1, v3.9.0, v3.9.1LTS: v2.0.0 - 2.0.29 and IBM supplied MQ Advanced container images SC2: 9.4.0.6 through r1, 9.4.0.6-r2, 9.4.0.7-r1, 9.4.0.10-r1, 9.4.0.10-r2, 9.4.0.11-r1, 9.4.0.11-r2, 9.4.0.11-r3, 9.4.0.12-r1, 9.4.0.15-r1 - 9.4.0.15-r4, 9.4.0.16-r1, 9.4.0.16-r2, 9.4.0.17-r1, 9.4.0.17-r2, 9.4.0.20-r1CD: 9.4.1.0-r1, 9.4.1.0-r2, 9.4.1.1-r1, 9.4.2.0-r1, 9.4.2.0-r2, 9.4.2.1-r1, 9.4.2.1-r2, 9.4.3.0-r1, 9.4.3.0-r2, 9.4.3.1-r1 - 9.4.3.1-r3, 9.4.4.0-r1 - 9.4.4.0-r4, 9.4.4.1-r1, 9.4.5.0-r1, 9.4.5.0-r2LTS: 9.3.0.0-r1, 9.3.0.0-r2, 9.3.0.0-r3, 9.3.0.1-r1, 9.3.0.1-r2, 9.3.0.1-r3, 9.3.0.1-r4, 9.3.0.3-r1, 9.3.0.4-r1, 9.3.0.4-r2, 9.3.0.5-r1, 9.3.0.5-r2, 9.3.0.5-r3, 9.3.0.6-r1, 9.3.0.10-r1, 9.3.0.10-r2, 9.3.0.11-r1,9.3.0.11-r2, 9.3.0.15-r1, 9.3.0.16-r1, 9.3.0.16-r2, 9.3.0.17-r1, 9.3.0.17-r2, 9.3.0.17-r3, 9.3.0.20-r1, 9.3.0.20-r2, 9.3.0.21-r1, 9.3.0.21-r2, 9.3.0.21-r3, 9.3.0.25-r1, 9.4.0.0-r1, 9.4.0.0-r2, 9.4.0.0-r3, 9.4.0.5-r1, 9.4.0.5-r2 IBM MQ stores potentially sensitive information in log files that could be read by a local user.

*** Pendiente de traducción *** libusb before version 1.0.30 contains a NULL pointer dereference vulnerability that allows attackers to crash applications by supplying a malformed USB configuration descriptor where an interface claims bNumEndpoints greater than zero but is followed by a class-specific descriptor whose bLength exceeds the remaining buffer size, causing parse_interface() to return early without allocating the endpoint array. Attackers can exploit this flaw through libusb_get_active_config_descriptor or libusb_get_config_descriptor by providing crafted descriptors via virtualized USB passthrough, file-based descriptor parsing, or network sources, causing any application iterating over endpoints to dereference a NULL endpoint pointer and crash.

*** Pendiente de traducción *** A flaw was found in Samba’s vfs_worm module. The module is intended to provide write-once, read-many (WORM) protections by preventing modification of files after a configurable grace period. Due to insufficient validation during rename operations, an authenticated user with write access to a share could overwrite a protected file by renaming a newly created file over the existing WORM-protected file.

*** Pendiente de traducción *** A flaw was found in Samba’s handling of NTFS-style reparse points on shares configured with read only = yes. Due to missing SMB-layer access checks, authenticated users with underlying filesystem write permissions may create or delete reparse point metadata through SMB operations even on read-only exports. This could allow modification of SMB-visible file behavior, including converting files into symbolic links or other reparse point types.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/display/dp_mst: Add protection against 0 vcpi<br /> <br /> When releasing a timeslot there is a slight chance we may end up<br /> with the wrong payload mask due to overflow if the delayed_destroy_work<br /> ends up coming into play after a DP 2.1 monitor gets disconnected<br /> which causes vcpi to become 0 then we try to make the payload =<br /> ~BIT(vcpi - 1) which is a negative shift. VCPI id should never<br /> really be 0 hence skip changing the payload mask if VCPI is 0.<br /> <br /> Otherwise it leads to<br /> [515.287237] xe 0000:03:00.0: [drm:drm_dp_mst_get_port_malloc<br /> [drm_display_helper]] port ffff888126ce9000 (3)<br /> [515.287267] -----------[ cut here ]-----------<br /> [515.287268] UBSAN: shift-out-of-bounds in<br /> ../drivers/gpu/drm/display/drm_dp_mst_topology.c:4575:36<br /> [515.287271] shift exponent -1 is negative<br /> [515.287275] CPU: 7 UID: 0 PID: 3108 Comm: kworker/u64:33 Tainted: G<br /> S U 6.17.0-rc6-lgci-xe-xe-3795-3e79699fa1b216e92+ #1 PREEMPT(voluntary)<br /> [515.287279] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER<br /> [515.287279] Hardware name: ASUS System Product Name/PRIME Z790-P<br /> WIFI, BIOS 1645 03/15/2024<br /> [515.287281] Workqueue: drm_dp_mst_wq drm_dp_delayed_destroy_work<br /> [drm_display_helper]<br /> [515.287303] Call Trace:<br /> [515.287304] <br /> [515.287306] dump_stack_lvl+0xc1/0xf0<br /> [515.287313] dump_stack+0x10/0x20<br /> [515.287316] __ubsan_handle_shift_out_of_bounds+0x133/0x2e0<br /> [515.287324] ? drm_atomic_get_private_obj_state+0x186/0x1d0<br /> [515.287333] drm_dp_atomic_release_time_slots.cold+0x17/0x3d<br /> [drm_display_helper]<br /> [515.287355] mst_connector_atomic_check+0x159/0x180 [xe]<br /> [515.287546] drm_atomic_helper_check_modeset+0x4d9/0xfa0<br /> [515.287550] ? __ww_mutex_lock.constprop.0+0x6f/0x1a60<br /> [515.287562] intel_atomic_check+0x119/0x2b80 [xe]<br /> [515.287740] ? find_held_lock+0x31/0x90<br /> [515.287747] ? lock_release+0xce/0x2a0<br /> [515.287754] drm_atomic_check_only+0x6a2/0xb40<br /> [515.287758] ? drm_atomic_add_affected_connectors+0x12b/0x140<br /> [515.287765] drm_atomic_commit+0x6e/0xf0<br /> [515.287766] ? _pfx__drm_printfn_info+0x10/0x10<br /> [515.287774] drm_client_modeset_commit_atomic+0x25c/0x2b0<br /> [515.287794] drm_client_modeset_commit_locked+0x60/0x1b0<br /> [515.287795] ? mutex_lock_nested+0x1b/0x30<br /> [515.287801] drm_client_modeset_commit+0x26/0x50<br /> [515.287804] __drm_fb_helper_restore_fbdev_mode_unlocked+0xdc/0x110<br /> [515.287810] drm_fb_helper_hotplug_event+0x120/0x140<br /> [515.287814] drm_fbdev_client_hotplug+0x28/0xd0<br /> [515.287819] drm_client_hotplug+0x6c/0xf0<br /> [515.287824] drm_client_dev_hotplug+0x9e/0xd0<br /> [515.287829] drm_kms_helper_hotplug_event+0x1a/0x30<br /> [515.287834] drm_dp_delayed_destroy_work+0x3df/0x410<br /> [drm_display_helper]<br /> [515.287861] process_one_work+0x22b/0x6f0<br /> [515.287874] worker_thread+0x1e8/0x3d0<br /> [515.287879] ? __pfx_worker_thread+0x10/0x10<br /> [515.287882] kthread+0x11c/0x250<br /> [515.287886] ? __pfx_kthread+0x10/0x10<br /> [515.287890] ret_from_fork+0x2d7/0x310<br /> [515.287894] ? __pfx_kthread+0x10/0x10<br /> [515.287897] ret_from_fork_asm+0x1a/0x30

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ima: Fix stack-out-of-bounds in is_bprm_creds_for_exec()<br /> <br /> KASAN reported a stack-out-of-bounds access in ima_appraise_measurement<br /> from is_bprm_creds_for_exec:<br /> <br /> BUG: KASAN: stack-out-of-bounds in ima_appraise_measurement+0x12dc/0x16a0<br /> Read of size 1 at addr ffffc9000160f940 by task sudo/550<br /> The buggy address belongs to stack of task sudo/550<br /> and is located at offset 24 in frame:<br /> ima_appraise_measurement+0x0/0x16a0<br /> This frame has 2 objects:<br /> [48, 56) &amp;#39;file&amp;#39;<br /> [80, 148) &amp;#39;hash&amp;#39;<br /> <br /> This is caused by using container_of on the *file pointer. This offset<br /> calculation is what triggers the stack-out-of-bounds error.<br /> <br /> In order to fix this, pass in a bprm_is_check boolean which can be set<br /> depending on how process_measurement is called. If the caller has a<br /> linux_binprm pointer and the function is BPRM_CHECK we can determine<br /> is_check and set it then. Otherwise set it to false.