Go es un lenguaje de programación concurrente y compilado con tipado estático inspirado en la sintaxis de C, pero con seguridad de memoria y recolección de basura.

Russ Cox, un ingeniero de software de Google que lidera el desarrollo del lenguaje de programación de código abierto Go, presentó un posible plan para implementar la telemetría en la cadena de herramientas de Go. Sin embargo, muchos miembros de la comunidad de Go se oponen porque el plan llama a la telemetría de manera predeterminada.

Estos desarrolladores alarmados preferirían un régimen de participación en lugar de un régimen de exclusión, una posición que el equipo de Go rechaza porque garantizaría una baja adopción y reduciría la cantidad de datos de telemetría recibidos hasta el punto en que sería de poco valor.

Para quienes desconocen de Go, deben saber que este es un lenguaje de programación desarrollado en Google. Aunque es similar al lenguaje C, trae una serie de adiciones importantes y modernas. Russ Cox es el ingeniero de Google que actualmente lidera el desarrollo de Go, y ha presentado una propuesta controvertida, que implicaría habilitar la telemetría en Go de forma predeterminada.

La telemetría cubrirá las utilidades de línea de comandos desarrolladas por el equipo de desarrollo del lenguaje Go, como la utilidad «go», el compilador, las aplicaciones gopls y govulncheck. La recopilación de información se limitará solo a la acumulación de información sobre las características de los servicios públicos, es decir la telemetría no se agregará a las aplicaciones creadas.

La telemetría, como la describe Cox, implica que el software envíe datos desde el software Go a un servidor para proporcionar información sobre las funciones que se utilizan y cómo se está desempeñando el software. Argumenta que es beneficioso para los proyectos de código abierto tener esta información para guiar el desarrollo.

Creo que los proyectos de software de código abierto deben explorar nuevos diseños de telemetría que ayuden a los desarrolladores a obtener la información que necesitan para trabajar de manera eficaz y eficiente, sin recopilar rastros invasivos de la actividad detallada del usuario.

He escrito una breve serie de publicaciones de blog sobre un diseño de este tipo, al que llamo telemetría transparente, porque recopila la menor cantidad posible (kilobytes por año de cada instalación) y luego publica cada elemento que recopila, para inspección pública y análisis.

Me gustaría explorar el uso de la telemetría transparente, o un sistema similar, en la cadena de herramientas de Go, que espero ayude a los desarrolladores y usuarios de proyectos de Go. Para ser claros, solo sugiero que se agregue instrumentación a las herramientas de línea de comandos de Go escritas y distribuidas por el equipo de Go, como el comando go, el compilador Go, gopls y govulncheck. No estoy sugiriendo que el compilador Go agregue instrumentación a todos los programas Go del mundo: eso es claramente inapropiado.
La telemetría transparente tiene las siguientes propiedades clave*:

Aunque la idea detrás de la propuesta puede no ser mala, la idea planeada actualmente puede asustar a los desarrolladores actuales o potenciales del lenguaje de programación Go en cualquier proyecto futuro. Debe recordarse que la mayoría de los desarrolladores y usuarios de código abierto se oponen notoriamente a la mayoría de las formas de telemetría.

El motivo para recopilar telemetría, es el deseo de obtener la información faltante sobre las necesidades y características del trabajo de los desarrolladores que no se puede detectar mediante mensajes de error y encuestas como método de retroalimentación.

Russ tiene como objetivo introducir un concepto de «telemetría transparente» para ayudar a los proyectos de código abierto a comprender mejor el software, teniendo en cuenta la privacidad. En las publicaciones de su blog (una serie de 3 artículos), menciona que las encuestas y los informes de errores son insuficientes. Por lo tanto, es necesario introducir la forma más fácil de recopilar datos sobre el uso de una aplicación (es decir, la telemetría) manteniendo las cosas abiertas para todos.

Esto significa que todo el proceso de recopilación de datos, cómo se procesan y qué resulta de ellos, está abierto a todos.

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

from Linux Adictos https://ift.tt/VExXgT7
via IFTTT

Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

Hace poco se dio a conocer la publicación de diversas versiones correctivas del sistema de control de código fuente distribuido Git que abarcan desde la versión 2.38.4 a la versión 2.30.8, en los que se encuentran dos correcciones que eliminan las vulnerabilidades detectadas que afecta las optimizaciones de clones locales y el comando «git apply».

Como tal, se menciona que estas versiones de mantenimiento son para abordar dos problemas de seguridad identificados bajoCVE-2023-22490 y CVE-2023-23946. Ambas vulnerabilidades afectan gamas de versiones existentes y se recomienda encarecidamente a los usuarios que realicen la actualización correspondiente.

Un atacante puede explotar de forma remota una vulnerabilidad para detectar información. Además, un atacante puede
explotar una vulnerabilidad localmente para manipular archivos.

Se requieren privilegios normales para explotar las vulnerabilidades. Ambas vulnerabilidades requieren la interacción del usuario.

La primer vulnerabilidad identificada es CVE-2023-22490, la cual permite que un atacante que controla el contenido de un repositorio clonado obtenga acceso a datos confidenciales en el sistema de un usuario. Dos defectos contribuyen a la aparición de la vulnerabilidad:

• La primera falla permite, cuando se trabaja con un repositorio especialmente diseñado, lograr el uso de optimizaciones de clonación local incluso cuando se usa un transporte que interactúa con sistemas externos.
• La segunda falla permite colocar un enlace simbólico en lugar del directorio $GIT_DIR/objects, similar a la vulnerabilidad CVE-2022-39253, en la que se bloqueó la ubicación de enlaces simbólicos en el directorio $GIT_DIR/objects, pero el hecho que el directorio $GIT_DIR/objects en sí mismo no se verificó puede ser un enlace simbólico.

En el modo de clonación local, git mueve $GIT_DIR/objects al directorio de destino eliminando las referencias de los enlaces simbólicos, lo que hace que los archivos a los que se hace referencia se copien directamente en el directorio de destino. Cambiar al uso de optimizaciones de clones locales para el transporte no local permite explotar una vulnerabilidad cuando se trabaja con repositorios externos (por ejemplo, la inclusión recursiva de submódulos con el comando «git clone –recurse-submodules» puede conducir a la clonación de un repositorio malicioso empaquetado como un submódulo en otro repositorio).

Usando un repositorio especialmente diseñado, se puede engañar a Git para que use su optimización de clones locales incluso cuando se utiliza un transporte no local.
Aunque Git cancelará los clones locales cuya fuente $GIT_DIR/objects directorio contiene enlaces simbólicos (cf, CVE-2022-39253), los objetos del directorio en sí puede seguir siendo un enlace simbólico.

Estos dos pueden combinarse para incluir archivos arbitrarios basados ​​en rutas en el sistema de archivos de la víctima dentro del repositorio malicioso y la copia de trabajo, lo que permite la exfiltración de datos de manera similar a
CVE-2022-39253.

La segunda vulnerabilidad detectada es CVE-2023-23946 y esta permite sobrescribir el contenido de los archivos fuera del directorio de trabajo al pasar una entrada con formato especial al comando «git apply».

Por ejemplo, se puede realizar un ataque cuando los parches preparados por un atacante se procesan en «git apply». Para evitar que los parches creen archivos fuera de la copia de trabajo, «git apply» bloquea el procesamiento de parches que intentan escribir un archivo usando enlaces simbólicos. Pero esta protección resultó ser eludida al crear un enlace simbólico en primer lugar.

Fedora 36 y 37 tienen actualizaciones de seguridad en estado ‘testing’ que actualizan ‘git’ a la versión 2.39.2.

Las vulnerabilidades también se abordan con GitLab 15.8.2, 15.7.7 y 15.6.8 en Community Edition (CE) y Enterprise Edition (EE).

GitLab clasifica las vulnerabilidades como críticas porque CVE-2023-23946 permite la ejecución de código de programa arbitrario en el entorno Gitaly (servicio Git RPC) .
Al mismo tiempo, Python incorporado se actualiza a la versión 3.9.16 para corregir más vulnerabilidades.

Finalmente para los interesados en conocer más al respecto, pueden seguir el lanzamiento de actualizaciones de paquetes en distribuciones en las páginas de Debian, Ubuntu, RHEL, SUSE/openSUSE, Fedora, Arch y FreeBSD.

Si no es posible instalar una actualización, se recomienda como solución evitar ejecutar «git clone» con la opción «–recurse-submodules» en repositorios que no son de confianza, y no usar «git apply» y «git am «comandos con código no verificado.

from Linux Adictos https://ift.tt/XetU0lz
via IFTTT