Es lo que tiene esta distribución. Lo mismo se pasa casi un mes sin lanzar una versión estable que nos entrega una actualización seis días después de la anterior. Esta mañana han lanzado Manjaro 2021-12-16, una actualización sin muchas novedades destacadas, pero sí dos dignas de mención. Una de ellas es que la edición KDE ha recibido KDE Gear 21.12.0, la actualización de diciembre del set de aplicaciones del proyecto. La otra no es muy grande, pero sí importante.

Y es que el pasado día 6 The Document Foundation lanzó las actualizaciones LibreOffice 7.2.4 y 7.1.8 que sólo introducían una corrección de seguridad. TDF creyó que era lo suficientemente importante como para lanzar una nueva versión de su suite, y probablemente esto haya tenido algo que ver en que Manjaro 2021-12-16 se haya lanzado tan pronto. De hecho, al lanzar la actualización del día 10 hubo usuarios que mencionaban que la versión de LibreOffice incluida llegaba con el fallo de seguridad.

Novedades más destacadas de Manjaro 2021-12-16

• Se actualizaron algunos de los Kernels. 5.13 y 5.14 ya han llegado al final de su ciclo de vida, y Linux 5.13 ni siquiera está disponible.
• Se realizaron más cambios en el tema Breath.
• KDE Gear está ahora en 21.12.0.
• Thunderbird se renovó a 91.4.0.
• @Yochanan trabajó en la racionalización de las anulaciones de Manjaro en las extensiones y ajustes de GNOME. Los usuarios de esta edición deben asegurarse de reiniciar Gnome Shell o cerrar la sesión antes de informar de cualquier problema.
• LibreOffice se renovó a 7.1.8 y 7.2.4, que incluyen importantes correcciones de seguridad.
• Algunas actualizaciones a Deepin.
• Otras actualizaciones regulares de Upstream.

Manjaro 2021-12-16 es una actualización estable, lo que significa que está disponible para actualizar desde el mismo sistema operativo, bien desde el centro de software Pamac o con el comando sudo pacman -Syu. La próxima imagen ISO, de hecho ya está disponible la primera Release Candiate, ya será Manjaro 21.2 Qo’nos.

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

Durante los últimos dias en la red se ha estado hablando bastante sobre la vulnerabilidad de Log4j en la cual se han descubierto diversos vectores de ataque y que ademas se han filtrado diversos exploits funcionales para poder explotar la vulnerabilidad.

La gravedad el asunto radica que este es un marco popular para organizar el registro en aplicaciones Java, que permite la ejecución de código arbitrario cuando se escribe un valor con formato especial en el registro en el formato «{jndi: URL}». El ataque se puede llevar a cabo en aplicaciones Java que registran valores obtenidos de fuentes externas, por ejemplo, al mostrar valores problemáticos en mensajes de error.

Y es que un atacante realiza una solicitud HTTP en un sistema de destino, que genera un registro usando Log4j 2 que usa JNDI para realizar una solicitud en el sitio controlado por el atacante. Luego, la vulnerabilidad hace que el proceso explotado llegue al sitio y ejecute la carga útil. En muchos ataques observados, el parámetro que pertenece al atacante es un sistema de registro de DNS, destinado a registrar una solicitud en el sitio para identificar sistemas vulnerables.

Tal y como ya compartio nuestro compañero Isaac:

Esta vulnerabilidad de Log4j permite explotar una validación de entrada incorrecta a LDAP, permitiendo ejecución remota de código (RCE), y comprometiendo el servidor (confidencialidad, integridad de datos y disponibilidad del sistema). Además, el problema o importancia de esta vulnerabilidad reside en la cantidad de aplicaciones y servidores que la usan, incluyendo software empresarial y servicios en la nube como Apple iCloud, Steam, o videojuegos tan populares como Minecraft: Java Edition, Twitter, Cloudflare, Tencent, ElasticSearch, Redis, Elastic Logstash, y un largo etc.

Hablando sobre el asunto, hace poco la Apache Software Foundation dio a conocer mediante una publicación un resumen de los proyectos que abordan una vulnerabilidad crítica en Log4j 2 que permite que se ejecute código arbitrario en el servidor.

Los siguientes proyectos de Apache se ven afectados: Archiva, Druid, EventMesh, Flink, Fortress, Geode, Hive, JMeter, Jena, JSPWiki, OFBiz, Ozone, SkyWalking, Solr, Struts, TrafficControl y Calcite Avatica. La vulnerabilidad también afectó a los productos de GitHub, incluidos GitHub.com, GitHub Enterprise Cloud y GitHub Enterprise Server.

En los últimos días se ha producido un aumento significativo de la actividad relacionada con la explotación de la vulnerabilidad. Por ejemplo, Check Point registró alrededor de 100 intentos de explotación por minuto en sus servidores ficticios en su punto máximo, y Sophos anunció el descubrimiento de una nueva botnet para la minería de criptomonedas, formada a partir de sistemas con una vulnerabilidad sin parchear en Log4j 2.

En cuanto a la informacion que se ha estado dando a conocer sobre el problema:

• La vulnerabilidad se ha confirmado en muchas imágenes oficiales de Docker, incluidas couchbase, elasticsearch, flink, solr, imágenes de tormenta, etc.
• La vulnerabilidad está presente en el producto MongoDB Atlas Search.
• El problema aparece en una variedad de productos de Cisco, incluidos Cisco Webex Meetings Server, Cisco CX Cloud Agent, Cisco
• Advanced Web Security Reporting, Cisco Firepower Threat Defense (FTD), Cisco Identity Services Engine (ISE), Cisco CloudCenter, Cisco DNA Center, Cisco. BroadWorks, etc.
• El problema está presente en IBM WebSphere Application Server y en los siguientes productos de Red Hat : OpenShift, OpenShift Logging, OpenStack Platform, Integration Camel, CodeReady Studio, Data Grid, Fuse y AMQ Streams.
• Problema confirmado en Junos Space Network Management Platform, Northstar Controller / Planner, Paragon Insights / Pathfinder / Planner.
• Muchos productos de Oracle , vmWare , Broadcom y Amazon también se ven afectados .

Los proyectos de Apache que no se ven afectados por la vulnerabilidad Log4j 2: Apache Iceberg, Guacamole, Hadoop, Log4Net, Spark, Tomcat, ZooKeeper y CloudStack.

Se recomienda a los usuarios de paquetes problemáticos que instalen urgentemente las actualizaciones publicadas para ellos, actualicen por separado la versión de Log4j 2 o establezcan el parámetro Log4j2.formatMsgNoLookups en verdadero (por ejemplo, agregando la clave «-DLog4j2.formatMsgNoLookup=True» al inicio ).

Para bloquear el sistema es vulnerable al que no hay acceso directo, se sugirió explotar la vacuna Logout4Shell, que, a través de la comisión de un ataque, expone el ajuste de Java «log4j2.formatMsgNoLookups=true», «com.sun.jndi.rmi.object. trustURLCodebase=false » y» com.sun.jndi.cosnaming.object.trustURLCodebase=false «para bloquear más manifestaciones de la vulnerabilidad en sistemas no controlados.

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