Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: logitech-hidpp: soluciona el fallo del kernel en la desconexión del USB del receptor hidpp_connect_event() tiene *cuatro* carreras de tiempo de verificación versus tiempo de uso (TOCTOU) cuando corre consigo mismo. hidpp_connect_event() se ejecuta principalmente desde una cola de trabajo, pero también se ejecuta en probe() y si el hw recibe un paquete "dispositivo conectado" cuando el subproceso que ejecuta hidpp_connect_event() desde probe() está esperando en el hw, entonces se ejecuta un segundo El hilo que ejecuta hidpp_connect_event() se iniciará desde la cola de trabajo. Esto abre las siguientes carreras (tenga en cuenta que el código siguiente está simplificado):1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; } We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968: [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them: 2. Updating the name to the HIDPP name (harmless race): if (hidpp->name == hdev->name) { ... hidpp->name = new_name; } 3. Initializing the power_supply class for the battery (problematic!): hidpp_initialize_battery() { if (hidpp->battery.ps) return 0; probe_battery(); /* Blocks, threads take turns executing this */ hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); } 4. Creating delayed input_device (potentially problematic): if (hidpp->delayed_input) return; hidpp->delayed_input = hidpp_allocate_input(hdev); The really big problem here is 3. Hitting the race leads to the following sequence: hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); ... hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); So now we have registered 2 power supplies for the same battery, which looks a bit weird from userspace's pov but this is not even the really big problem. Notice how: 1. This is all devm-maganaged 2. The hidpp->battery.desc struct is shared between the 2 power supplies 3. hidpp->battery.desc.properties points to the result from the second devm_kmemdup() This causes a use after free scenario on USB disconnect of the receiver: 1. The last registered power supply class device gets unregistered 2. The memory from the last devm_kmemdup() call gets freed, hidpp->battery.desc.properties now points to freed memory 3. The first registered power supply class device gets unregistered, this involves sending a remove uevent to userspace which invokes power_supply_uevent() to fill the uevent data 4. power_supply_uevent() uses hidpp->battery.desc.properties which now points to freed memory leading to backtraces like this one: Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 ... Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0 ... Sep 22 20:01:35 eric kernel: ? asm_exc_page_fault+0x26/0x30 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel: dev_uevent+0x10f/0x2d0 Sep 22 20:01:35 eric kernel: kobject_uevent_env+0x291/0x680 Sep 22 20:01:35 eric kernel: ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: corrige uaf en smb20_oplock_break_ack elimina la referencia después de usar opinfo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: perf/x86/lbr: Filtrar direcciones vsyscall Descubrimos que puede ocurrir un pánico cuando se realiza una vsyscall mientras el muestreo LBR está activo. Si el VSYSCALL se interrumpe (NMI) para el muestreo de Perf, esta secuencia de llamadas puede ocurrir (más reciente en la parte superior): __insn_get_emulate_prefix () insn_get_emulate_prefix () insn_get_prefixes () insn_get_opcode () decode_branch_type () get_branch_type () _pmu_handle_irq () perf_event_nmi_handler ( ) Dentro de __insn_get_emulate_prefix() en el cuadro 0, se llama una macro: peek_nbyte_next(insn_byte_t, insn, i) Dentro de esta macro, se produce esta desreferencia: (insn)->next_byte Inspeccionando registros en este punto, el valor del campo next_byte es el dirección de vsyscall realizada, por ejemplo, la ubicación de la versión vsyscall de gettimeofday() en 0xffffffffff600000. El acceso a una dirección en la región vsyscall provocará un error debido a un error de página no controlado. Para corregir el error, se puede filtrar por vsyscalls al determinar el tipo de rama. Este parche devolverá una rama "ninguna" si se encuentra que una dirección del kernel se encuentra en la región vsyscall.

Vulnerabilidad de Cross-Site Request Forgery (CSRF) en Thrive Themes Thrive Automator. Este problema afecta a Thrive Automator: desde n/a hasta 1.17.

Vulnerabilidad de Cross-Site Request Forgery (CSRF) en ?leanTalk - Anti-Spam Protection Spam protection, Anti-Spam, FireWall by CleanTalk. Este problema afecta a la protección contra spam, Anti-Spam, FireWall de CleanTalk: desde n/a hasta 6.20.

El complemento Advanced iFrame para WordPress es vulnerable a Cross-Site Scripting Almacenado a través del código corto advanced_iframe del complemento en todas las versiones hasta la 2024.1 incluida, debido a que el complemento permite a los usuarios incluir archivos JS de fuentes externas a través del atributo adicional_js. Esto hace posible que atacantes autenticados con permisos de nivel de colaborador y superiores inyecten scripts web arbitrarios en páginas que se ejecutarán cada vez que un usuario acceda a una página inyectada.

Exposición de información confidencial a una vulnerabilidad de actor no autorizado en Tainacan.Org Tainacan. Este problema afecta a Tainacan: desde n/a hasta 0.20.6.

Vulnerabilidad de Cross-Site Request Forgery (CSRF) en Senol Sahin AI Power: Complete AI Pack – Desarrollado por GPT-4. Este problema afecta a AI Power: Complete AI Pack – Desarrollado por GPT-4: desde n/a hasta 1.8.12.

Vulnerabilidad de Cross-Site Request Forgery (CSRF) en HasThemes HT Mega – Absolute Addons For Elementor. Este problema afecta a HT Mega – Absolute Addons For Elementor: desde n/a hasta 2.3.3.

Vulnerabilidad de Cross-Site Request Forgery (CSRF) en GS Plugins Logo Slider – Logo Showcase, Logo Carousel, Logo Gallery and Client Logo Presentation. Este problema afecta a Logo Slider – Logo Showcase, Logo Carousel, Logo Gallery and Client Logo Presentation: desde n/ a hasta 3.5.1.

El Avada | El tema Website Builder para WordPress y WooCommerce para WordPress es vulnerable a la carga de archivos arbitrarios debido a la falta de validación del tipo de archivo en la función ajax_import_options() en todas las versiones hasta la 7.11.4 incluida. Esto hace posible que atacantes autenticados, con acceso de nivel de colaborador y superior, carguen archivos arbitrarios en el servidor del sitio afectado, lo que puede hacer posible la ejecución remota de código.

IBM Cloud Pak for Security (CP4S) 1.10.0.0 a 1.10.6.0 podría permitir que un atacante remoto obtenga información confidencial, causada por no habilitar correctamente HTTP Strict Transport Security. Un atacante podría aprovechar esta vulnerabilidad para obtener información confidencial utilizando técnicas de intermediario. ID de IBM X-Force: 216388.