LibreWolf, un Firefox preparado para ser más privado nada más iniciarlo

LibreWolf

El navegador web más usado del mundo en estos momentos es Chrome. En parte, creo que eso es debido a que la mayoría de la gente tira por lo más conocido sin importarle cosas como la privacidad. Los que usamos Linux si pensamos en ello, y por ese motivo terminamos con algún navegador que use Chromium, pero diferente a Chrome, o Firefox. Hay navegadores que se basan en el de Mozilla, como LibreWolf, para ofrecernos diferentes experiencias.

No vamos a decir que Firefox sea un navegador que espíe a los usuarios, las cosas como son. Pero LibreWolf incluye por defecto algunas herramientas que lo hacen aún más privado. Para empezar, no recoge datos de telemetría. Estos datos suelen ayudar a los desarrolladores a mejorar su software, pero  tienen que recoger cierta información que algunos pueden preferir no compartir. Además, los motores de búsqueda son muy diferentes: por defecto usa DuckDuckGo, pero el resto de opciones que ofrece tras la instalación de cero son, además de la Wikipedia, DuckDuckGo Lite, que es la versión móvil, Searx, StartPage, Qwant y MetaGear.

LibreWolf no recoge datos de telemetría y bloquea publicidad por defecto

Hay usuarios que, tras instalar un navegador, lo primero que buscan es un bloqueador de publicidad. Esto no es necesario en algunas distribuciones Linux que incluyen una versión de Firefox con uno incluido, y LibreWolf tiene instalada por defecto una extensión: uBlock Origin. Como el ETP de Firefox, los bloqueadores pueden hacer que algún componente de una página web deje de funcionar, algo que hay que tener en cuenta si alguna funciona de manera errática, pero merece la pena en el 99% de los casos.

LibreWolf, como Firefox, es de código abierto y se actualiza justo después que el navegador en el que se basan. Hay que verlo como el navegador del zorro, pero ya preparado para centrarse en la privacidad. De hecho, mejora la ETP de Mozilla incluyendo un cortafuegos y otras mejoras de seguridad, todo ello sin sacrificar rendimiento ni usabilidad.

Instalación en Linux

Para instalarlo en Linux, tenemos que hacerlo de la siguiente manera:

  • Arch Linux: está en AUR, por lo que hay que compilarlo o usar la herramienta yay, tal y como explicamos en este artículo. El paquete librewolf compila Firefox y añade los parches, mientras que librewolf-bin proporciona un binario. Si se usan distribuciones como Manjaro, se puede instalar desde Pamac.
  • Debian: se añade el repositorio y se instala con estos comandos:
echo 'deb http://download.opensuse.org/repositories/home:/bgstack15:/aftermozilla/Debian_Unstable/ /' | sudo tee /etc/apt/sources.list.d/home:bgstack15:aftermozilla.list
curl -fsSL https://download.opensuse.org/repositories/home:bgstack15:aftermozilla/Debian_Unstable/Release.key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/home_bgstack15_aftermozilla.gpg > /dev/null
sudo apt update
sudo apt install librewolf
  • Gentoo: se crea el archivo /etc/portage/repos.conf/librewolf.conf con esto (cambiando «ubicación del repo» por la ubicación en donde quiera ponerse):
[librewolf]
priority = 50
location = "ubicación-del-repo"/librewolf
sync-type = git
sync-uri = https://gitlab.com/librewolf-community/browser/gentoo.git
auto-sync = Yes

Posteriormente, hay que ejecutar emaint -r librewolf sync.

También está disponible en AppImage y como paquete Flatpak en este enlace.

Está claro que cuando nos acostumbramos a algo es difícil cambiar, pero una alternativa al zorro de fuego es el lobo libre.

from Linux Adictos https://ift.tt/31ZTq32
via IFTTT

Mantenedores de PHP culpan a la filtración de la base de datos de master.php.net

A finales del mes pasado se dio a conocer la noticia de que un hacker comprometió el servidor utilizado para distribuir el lenguaje de programación PHP y agregó un backdoor al código fuente que habría dejado a los sitios web vulnerables a una adquisición completa, dijeron miembros del proyecto de código abierto.

El problema se suscitó en dos actualizaciones enviadas al servidor PHP Git durante el fin de semana del 27 de marzo en el cual agregaron una línea que, si fuera ejecutada por un sitio web impulsado por esta versión secuestrada de PHP, habría permitido a los visitantes no autorizados ejecutar el código de su elección.

Las confirmaciones maliciosas le dieron al código la capacidad de inyectar código en los visitantes que tenían la palabra «zerodium» en un encabezado HTTP. Las confirmaciones se realizaron en el repositorio php-src bajo los nombres de cuenta de dos conocidos desarrolladores de PHP, Rasmus Lerdorf y Nikita Popov.

Tras el compromiso, Popov explicó que los funcionarios de PHP concluyeron que su infraestructura Git independiente representaba un riesgo de seguridad innecesario.

Como resultado, decidieron cerrar el servidor git.php.net y hacer de GitHub la fuente oficial de repositorios PHP. En el futuro, todos los cambios en el código fuente de PHP se realizarán directamente en GitHub en lugar de en git.php.net.

El mantenedor de PHP, Nikita Popov, lanzó una actualización sobre cómo se comprometió el código fuente y se insertó el código malicioso, culpando a una fuga de la base de datos del usuario en lugar de un problema con el servidor en sí.

El equipo originalmente creía que el servidor que alojaba el repositorio había sido asaltado, pero en una nueva publicación, Popov dijo:

“Ya no creemos que el servidor git.php.net haya sido comprometido. Sin embargo, es posible que se haya filtrado la base de datos del usuario master.php.net ”. Además, master.php.net se ha migrado a un nuevo sistema main.php.net.

Aquí hay detalles que Popov dio sobre el progreso de la investigación:

“Cuando se realizó la primera confirmación maliciosa bajo el nombre de Rasmus, mi reacción inicial fue revertir el cambio y revocar el acceso a la confirmación de la cuenta de Rasmus, asumiendo que era un individuo hack de cuenta. En retrospectiva, esta acción realmente no tenía sentido, porque noEl empujón estaba sucediendo a través de la cuenta de Rasmus en particular. Cualquier cuenta con acceso al repositorio php-src podría haber realizado el envío con un nombre falso.

“Cuando se realizó la segunda confirmación maliciosa bajo mi propio nombre, miré los registros de nuestra instalación de gitolite para determinar qué cuenta se estaba utilizando realmente para enviar . Sin embargo, aunque se tuvieron en cuenta todas las confirmaciones adyacentes, no había entradas git-receive-pack para las dos confirmaciones maliciosas, lo que significa que estas dos confirmaciones omitieron por completo la infraestructura de gitolite. Esto se interpretó como prueba probable de un compromiso del servidor.

Las acciones que se han tomado ahora incluyen restablecer todas las contraseñas y modificar el código para usar consultas parametrizadas para protegerse contra ataques de inyección SQL.

El uso de consultas parametrizadas ha sido la mejor práctica recomendada durante muchos años, y el hecho de que el código que no se ha estado ejecutando durante tanto tiempo en el corazón de la infraestructura del código fuente de PHP muestra cuán inseguro es el código heredado en una organización si está funcionando y no está causando problemas obvios.

El sistema master.php.net, que se utiliza para la autenticación y varias tareas de administración, estaba ejecutando un código muy antiguo en un sistema operativo/versión PHP muy antiguo, por lo que algún tipo de vulnerabilidad no sería muy sorprendente. Los encargados del mantenimiento han realizado una serie de cambios para aumentar la seguridad de este sistema:

  • master.php.net se ha migrado a un nuevo sistema (que ejecuta PHP 8) y se ha cambiado el nombre de main.php.net al mismo tiempo. Entre otras cosas, el nuevo sistema es compatible con TLS 1.2, lo que significa que ya no debería ver las advertencias de la versión TLS al acceder a este sitio.
  • La implementación se ha trasladado al uso de consultas parametrizadas, para asegurarse de que no se puedan producir inyecciones de SQL.
  • Las contraseñas ahora se almacenan usando bcrypt.
  • Las contraseñas existentes se han restablecido (use main.php.net/forgot.php para generar una nueva).

Fuente: https://externals.io

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

Rust ya es uno de los favoritos para desarrollo de Android

Google dio a conocer hace poco la inclusión del lenguaje de programación Rust entre los lenguajes permitidos para el desarrollo de Android.

Ya que el compilador de Rust se incluyó en el árbol de fuentes de Android en 2019, pero la compatibilidad con el lenguaje siguió siendo experimental. Algunos de los primeros componentes de Rust que se envían a Android son nuevas implementaciones del mecanismo de comunicación entre procesos de Binder y la pila de Bluetooth.

La implementación de Rust se llevó a cabo como parte de un proyecto para fortalecer la seguridad, promover técnicas de codificación segura y mejorar la eficiencia de identificación de problemas al trabajar con memoria en Android. Se observa que alrededor del 70% de todas las vulnerabilidades peligrosas identificadas en Android son causadas por errores al trabajar con memoria.

El uso del lenguaje Rust, que se centra en el manejo seguro de la memoria y proporciona administración automática de la memoria, reducirá el riesgo de vulnerabilidades causadas por errores durante el manejo de la memoria, como acceder a un área de memoria después de que se haya liberado y desbordar los límites del búfer.

El manejo seguro de la memoria está garantizado en Rust en el momento de la compilación mediante la verificación de referencias, el seguimiento de la propiedad del objeto y la vida útil del objeto (alcance), así como mediante la evaluación de la corrección del acceso a la memoria en el tiempo de ejecución.

Rust también proporciona medios para protegerse contra desbordamientos de enteros, requiere la inicialización obligatoria de los valores de las variables antes de su uso, maneja mejor los errores en la biblioteca estándar, adopta el concepto de referencias y variables inmutables de forma predeterminada y ofrece una fuerte escritura estática para minimizar los errores lógicos.

En Android, la gestión segura de la memoria se proporciona en los lenguajes Kotlin y Java ya compatibles, pero no son adecuados para desarrollar componentes del sistema debido a la gran sobrecarga.

Rust permite lograr un rendimiento cercano a los lenguajes C y C ++, lo que permite que se utilice para desarrollar partes de bajo nivel de la plataforma y componentes para interactuar con el hardware.

Para garantizar la seguridad del código C y C ++, Android usa aislamiento de espacio aislado, análisis estático y pruebas de fuzzing. Las capacidades del aislamiento de sandbox son limitadas y han alcanzado el límite de sus capacidades (una mayor fragmentación en los procesos no es práctica desde el punto de vista del consumo de recursos).

Entre las limitaciones de usar sandbox, mencionan la alta sobrecarga y el mayor consumo de memoria causado por la necesidad de generar nuevos procesos, así como la latencia adicional asociada con el uso de IPC.

Al mismo tiempo, el sandbox no elimina vulnerabilidades en el código, sino que solo reduce los riesgos y complica el ataque, ya que la explotación requiere la identificación no de una, sino de varias vulnerabilidades.

Los métodos de prueba de código están limitados porque, para detectar errores, es necesario crear condiciones para la manifestación del problema. No es posible abarcar todas las opciones posibles, por lo que muchos errores pasan desapercibidos.

Para los procesos del sistema en Android, Google se adhiere a la «regla de dos», según la cual cualquier código agregado no debe cumplir más de dos de tres condiciones: trabajar con datos de entrada no verificados, usar un lenguaje de programación inseguro (C/C++) y ejecutarse sin aislamiento de espacio aislado rígido (con privilegios elevados).

De esta regla se deduce que el código para procesar datos externos debe reducirse a privilegios mínimos (aislado) o escribirse en un lenguaje de programación seguro.

Google no tiene como objetivo reescribir el código C/C ++ existente en Rust, pero planea usar este lenguaje para desarrollar código nuevo.

Tiene sentido usar Rust para código nuevo, ya que estadísticamente la mayoría de los errores aparecen en código nuevo o recientemente modificado. En particular, alrededor del 50% de los errores de memoria detectados en Android se detectan en código escrito hace menos de un año.

Fuente: https://security.googleblog.com

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

Lanzamiento de prueba de Rocky Linux fue pospuesto hasta finales de abril

Los desarrolladores del proyecto Rocky Linux (entre ellos Gregory Kurtzer, fundador de CentOS) cuyo objetivo es crear una nueva compilación RHEL gratuita que pueda tomar el lugar del clásico CentOS, hace pocos dias dieron a conocer un informe en marzo en el cual anuncian el aplazamiento del primer lanzamiento de prueba de la distribución hasta el 30 de abril, previamente programado para 31 de marzo.

Aún no se ha determinado la hora de inicio para probar el instalador de Anaconda, cuya publicación estaba programada para el 28 de febrero.

De los trabajos ya realizados, se destacó la preparación de la infraestructura de montaje, el sistema de montaje y la plataforma para el montaje automático de paquetes, además de que se ha puesto en funcionamiento un repositorio público de prueba de paquetes.

El repositorio de BaseOS se ha construido con éxito y el trabajo continúa en los repositorios de AppStream y PowerTools y se está trabajando para crear la Rocky Enterprise Software Foundation (RESF) para supervisar el proyecto.

También se menciona que se ha comenzado la preparación de la infraestructura para los espejos primarios, ademas de que se lanzó su propio canal de YouTube y se ha elaborado un acuerdo con los desarrolladores, que debe ser firmado por todos los involucrados en el desarrollo del kit de distribución.

Cabe señalar que la distribución de Rocky Linux se desarrollará independientemente de la empresa Ctrl IQ bajo el control de la comunidad.

Ctrl IQ no controlará el proyecto, solo actuará como uno de los patrocinadores, cubriendo los costos y brindando apoyo legal.

Los componentes subyacentes a la pila tecnológica Ctrl IQ se desarrollaron originalmente para su uso con CentOS, pero un cambio en la política de Red Hat con respecto a esta distribución obligó a buscar una alternativa, que fue la creación de la distribución Rocky Linux.

La pila de software que se está desarrollando en Ctrl IQ tendrá como objetivo proporcionar herramientas para orquestar elementos de infraestructura empresarial que abarcan diferentes sistemas, clústeres y arquitecturas en la nube. La pila consta de los siguientes componentes:

  • Distribución de Rocky Linux.
  • Warewulf Systems Management Toolkit, desarrollado originalmente para administrar grandes clústeres de cómputo basados ​​en Linux.
  • Computing Stacks Ctrl Computing Stacks, diseñado para su uso en áreas que requieren alta potencia informática, como el aprendizaje automático, la informática científica y la informática de alto rendimiento.
  • Plataforma Fuzzball para orquestar flujos de trabajo y datos en infraestructuras de servidores locales.
  • Ctrl IQ Plataforma en la nube para lanzar y orquestar flujos de trabajo y servicios en varios sistemas en la nube

Recordemos que el proyecto Rocky Linux se está desarrollando bajo el liderazgo de Gregory Kurtzer, fundador de CentOS, con el objetivo de crear una alternativa que pueda tomar el lugar del clásico CentOS.

Paralelamente, se creó una empresa comercial Ctrl IQ para desarrollar productos avanzados basados ​​en Rocky Linux y para apoyar a la comunidad de desarrolladores de esta distribución, que recibió una inversión de $ 4 millones.

Se promete que la distribución de Rocky Linux en sí se desarrollará independientemente de la compañía Ctrl IQ bajo el control de la comunidad. MontaVista también se unió al desarrollo y financiamiento del proyecto. El proveedor FossHost proporcionó equipo para implementar una infraestructura de compilacion alternativa.

De momento para aquellos que buscan una alternativa a CentOS, pueden optar por otra de las nuevas alternativas que se destacan para CentOS, es AlmaLinux y la cual ya cuenta con una versión estable que fue liberada después de 4 meses de arduo trabajo.

La versión se basa en Red Hat Enterprise Linux 8.3 y es completamente idéntica en funcionalidad con la excepción de los cambios relacionados con el cambio de marca y la eliminación de paquetes específicos de RHEL como redhat- *, insights-client y subscription-manager-migration *. Todos los desarrollos se publican bajo licencias gratuitas.

En cuanto a las actualizaciones para AlmaLinux, la rama de distribución esta basada en la base del paquete RHEL 8 y se promete lanzarse hasta 2029. La distribución es gratuita para todas las categorías de usuarios y es desarrollada con la participación de la comunidad y utilizando un modelo de gestión similar a la organización del proyecto Fedora.

Si quieres conocer más al respecto sobre AlmaLinux, puedes consultar la publicación al respecto en el siguiente enlace.

Fuente: https://forums.rockylinux.org

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

Signal reanudó labores en el código del servidor y su criptomoneda integrada

La Signal Technology Foundation, que desarrolla el sistema de comunicaciones seguras Signal dio a conocer hace poco que ha reanudado labores sobre la publicación del código para las partes del servidor del mensajero.

Después de que la publicación de cambios en el repositorio público se detuvo sin explicación el 22 de abril del año pasado (2020) y que la actualización del repositorio se detuvo después del anuncio de la intención de integrar el sistema de pago en Signal.

Ahora (un año después de eso) comenzaron las pruebas del sistema de pago integrado en Signal, basado en la propia criptomoneda MobileCoin (MOB), desarrollada por Moxie Marlinspike, el autor del protocolo Signal y casi al mismo tiempo, el repositorio publicó cambios en los componentes del servidor que se habían acumulado durante el año, incluida la implementación del sistema de pago.

Para quienes desconocen de la criptomoneda MobileCoin, deben saber que está diseñada para construir una red de pago móvil que garantice la privacidad del usuario.

Los datos del usuario permanecen solo en sus manos, y los desarrolladores de Signal o los administradores de elementos de infraestructura no tienen la capacidad de acceder al dinero, los datos del saldo del usuario y el historial de transacciones. La red de pago no tiene un único punto de control y se basa en la idea de propiedad fraccionada, cuya esencia es que todos los fondos de la red se forman como un conjunto de acciones individuales que se pueden canjear. La cantidad total de fondos en la red se fija en 250 millones de MOB.

MobileCoin se basa en blockchain, que almacena el historial de todos los pagos exitosos. Para confirmar la propiedad de los fondos, debe tener dos claves: una clave para transferir fondos y una clave para ver el estado. Para la mayoría de los usuarios, estas claves pueden derivarse de una clave base común.

Las transacciones se forman en la computadora o teléfono del usuario, luego de lo cual se transfieren a uno de los nodos con el estado de validador para su procesamiento en un enclave aislado.

Los datos solo se pueden transferir a nodos criptográficos que hayan confirmado el uso del código MobileCoin sin modificar en el enclave. Cada enclave aislado replica una máquina de estado que agrega transacciones válidas a la cadena de bloques utilizando el Protocolo de consenso de MobileCoin para validar los pagos.

Para garantizar la integridad de los datos y la protección contra la corrupción retroactiva, se utiliza una estructura de árbol Merkle Tree, en la que cada rama verifica todas las ramas y nodos subyacentes a través de hash de conjunto (árbol). Al tener el hash final, el usuario puede verificar la corrección de todo el historial de operaciones, así como la corrección de los estados pasados ​​de la base de datos.

El creador de Signal explicó la idea de integrar la criptomoneda en el mensajero con el deseo de brindar a los usuarios un sistema de pago fácil de usar que proteja la privacidad, similar a cómo el mensajero de Signal garantiza la seguridad de la comunicación. Bruce Schneier, un reconocido experto en criptografía y seguridad informática, criticó las acciones de los desarrolladores de Signal. Schneier cree que poner todos los huevos en una canasta no es la mejor solución, y el punto no es en absoluto que esto lleve a la hinchazón y complicación del programa, y ​​ni siquiera a la duda del uso de blockchain, y no en un Intente vincular Signal a una criptomoneda.

El problema clave, según Schneier, es que agregar un sistema de pago a una aplicación de cifrado de extremo a extremo crea amenazas adicionales asociadas con un mayor interés de varias agencias de inteligencia y reguladores gubernamentales. Las comunicaciones seguras y las transacciones seguras bien podrían haberse implementado en aplicaciones separadas.

Las aplicaciones con implementaciones de cifrado confiable de extremo a extremo ya están bajo ataque y es peligroso aumentar aún más el grado de oposición: cuando se combina la funcionalidad, el impacto en el sistema de pago arrastrará la funcionalidad de cifrado de extremo a extremo con eso, si una parte muere, todo el sistema muere.

Fuente: https://signal.org

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