Azure ya no permitirá los servicios de mineria de criptos

Se dio a conocer la noticia de que hace pocos días Microsoft actualizó sus Términos de servicio y dentro de los cambios realizados, podremos encontrar la imposibilidad minar criptomonedas a través de servicios en línea, sin autorización emitida por la empresa.

La decisión se indicó a través de una actualización de sus Términos de licencia universal para servicios en línea que entró en vigencia el 1 de diciembre. Este documento cubre cualquier «servicio alojado por Microsoft al que el cliente se suscriba en virtud de un contrato de licencias por volumen de Microsoft», principalmente relacionado con Azure.

Desde el 1Diciembre de 2022, los usuarios de Microsoft ya no pueden minar a través de plataformas en la nube sin obtener primero el permiso de la empresa. Fue en una actualización de su «Política de uso aceptable» que la compañía aclaró que «la minería de criptomonedas está prohibida sin la aprobación previa de Microsoft».

Las nuevas restricciones tienen como objetivo aumentar la estabilidad de sus servicios en la nube. De hecho, cuando se le preguntó acerca de este cambio, el editor de Windows dijo que la minería de criptomonedas podría:

Interrumpir o incluso dañar los servicios en línea y sus usuarios…

La minería de criptomonedas a menudo se puede vincular con el fraude cibernético y los ataques abusivos, como el acceso y el uso no autorizados de los recursos del cliente. Hicimos este cambio para proteger aún más a nuestros clientes y mitigar el riesgo de interrupción o deterioro de los servicios de Microsoft Cloud. Se puede considerar el permiso para extraer criptografía para pruebas e investigaciones de detecciones de seguridad”, explicó un portavoz de Microsoft.

Esta actualización, vigente desde principios de mes, concierne a todos los usuarios de Microsoft, incluidos los clientes que pagan:

«Ni el cliente, ni aquellos que acceden a un servicio en línea a través del cliente, pueden usar un servicio en línea para extraer criptomonedas sin la aprobación previa por escrito de Microsoft».

Microsoft no parece haber hecho pública esta decisión más allá de la página resumen de cambios y, en las últimas horas, en un Aviso para socios titulado: «Medidas importantes que los socios deben tomar para asegurar el ecosistema de socios».

Este documento establece que la política de uso aceptable se ha actualizado para prohibir explícitamente la minería de criptomonedas en todos los servicios en línea de Microsoft, a menos que Microsoft otorgue una aprobación previa por escrito.

Luego dice:

«Sugerimos buscar la aprobación previa por escrito de Microsoft antes de usar Microsoft Online Services para la minería de criptomonedas, independientemente de la duración de la suscripción».

Aunque la empresa ha introducido restricciones en la minería de criptomonedas a través de Microsoft Online Services, la empresa también señaló que puede considerar permitir la minería de criptomonedas con fines de investigación y prueba.

Microsoft Online Services es una parte clave de la estrategia de software como servicio de la empresa. Los servicios en línea incluyen la red informática en la nube de Microsoft Azure, que los usuarios utilizan para la minería de criptomonedas. Microsoft había experimentado previamente con el lanzamiento de Ethereum Blockchain como un servicio en Azure en 2015 antes de finalizar silenciosamente el servicio Azure Blockchain en septiembre del año pasado.

Con esta actualización, Microsoft se ancla en línea con otras importantes marcas tecnológicas que prohíben la minería de criptomonedas en sus plataformas en la nube. Mismo caso en Amazon Web Services, que no permite la minería de criptomonedas que se aprovecha de sus servidores asi como tambien que Oracle ha prohibido por completo la minería de criptomonedas en su nube.

Antes de la declaración del portavoz de Microsoft, algunos habían especulado que a Microsoft podría preocuparle que los mineros no pagaran sus facturas en la nube.

Con la industria de las criptomonedas plagada de escándalos de todo tipo (como FTX), junto con los valores de muchos tokens muy por debajo de los máximos históricos, las posiciones de los mineros pueden ser… digamos precarias. El hecho de que Microsoft recordara a los socios que no permitieran la criptominería respaldaba esta suposición, ya que Microsoft no trata directamente con la mayoría de sus clientes.

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

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

Jack Patrick Dorsey ​ es un desarrollador de software y empresario estadounidense. Se le conoce por ser uno de los cofundadores de Twitter

Hace poco Jack Dorsey, cofundador de Twitter, dijo que otorgaría una subvención de un millón de dólares al año a la aplicación de mensajería encriptada Signal, la primera de una serie de subvenciones que planea otorgar para apoyar el «desarrollo de la Internet abierta».

Dorsey dijo que su esperanza de construir un Twitter de acuerdo con sus deseos murió en 2020 con la entrada de un inversionista activista anónimo.

“Planeé mi salida en ese momento, sabiendo que ya no era el adecuado para la empresa”, escribió.

Los principios sobre los que esperaba construir un medio de resistencia al control corporativo y gubernamental, contenido controlado por el usuario sin excepción y moderación algorítmica, no están presentes en el Twitter de hoy ni en el que dirigía, admitió. Aun así, escribió que, contrariamente a las insinuaciones que acompañan a los llamados Archivos de Twitter, «no hubo malas intenciones ni motivos ocultos, y todos actuaron con la mejor información que teníamos en ese momento».

Así dice Dorsey:

“En cuanto a los archivos, me gustaría que se publicaran a la manera de Wikileaks, con muchos más ojos e interpretaciones a tener en cuenta. Y con ello, compromisos de transparencia para las acciones presentes y futuras. Tengo la esperanza de que todo esto suceda. No hay nada que esconder… solo mucho que aprender. Los ataques actuales contra mis antiguos compañeros podrían ser peligrosos y no resolver nada. Si quieres culpar, dirígeme a mí y a mis acciones, o a la falta de ellas”.

Las redes sociales no deben ser «propiedad de una sola empresa o grupo de empresas» y deben ser «resistentes a la influencia corporativa y gubernamental», escribió Dorsey en una publicación en Revue, un servicio de información propiedad de Twitter. La publicación se ha trasladado a Pastebin ya que Revue cerrará sus puertas a principios del próximo año.

Pero las conversaciones en sí mismas son en realidad una mirada muy interesante a la dificultad de la moderación en circunstancias sin precedentes. La discusión franca y abierta sobre cómo interpretar una regla o qué hacer o no hacer es exactamente lo que uno esperaría que sucediera detrás de escena de tal proceso. Las imputaciones de parcialidad tienen poco o ningún peso documental detrás de ellas, más allá de lo que presta una presentación cuidadosamente elegida con la intención abierta de promover esta narrativa.

Jack Dorsey quiere apoyar el «desarrollo de una Internet más abierta», dijo que planea otorgar subvenciones para financiar proyectos en este sentido. Inicialmente, el empresario estadounidense quiere apoyar a los equipos de ingeniería que trabajan en redes sociales, protocolos de comunicación privada o bitcoin. Es un esfuerzo enfocado y urgente hacia un estándar de tecnología básica para hacer de las redes sociales una parte integral de Internet.

Convirtiendo la acción a la palabra, anunció que comenzará financiando a Signal (que definitivamente se resiste a los gobiernos) hasta por un millón de dólares al año.

Vienen más subvenciones, dijo, y pidió recomendaciones. 

Signal, que recibirá $ 1 millón por año, fue fundada por Matthew Rosenfeld (también conocido como Moxie Marlinspike), la aplicación tiene que ver con la seguridad y ofrece opciones como la destrucción automática de mensajes después de un período determinado.

Hace casi dos años, Signal se había distinguido por aprovechar al máximo los tropiezos de WhatsApp, cuando la aplicación Meta quiso imponer a sus usuarios una modificación de sus condiciones generales que permitía transferir datos personales con Facebook. Objetivo, hacer de WhatsApp un intermediario entre los internautas y los comerciantes. Recomendado por Edward Snowden y Elon Musk, Signal ganó varios millones de usuarios en pocos días.

Dorsey llama a Mastodon y Matrix otras vías interesantes de desarrollo porque, en lo que respecta a las soluciones reales, por supuesto, está en funcionamiento (o al menos presente) en Bluesky:

“Habrá muchas más. Uno de ellos tendrá la oportunidad de convertirse en un estándar como HTTP o SMTP. No es un «Twitter descentralizado». Esta es una acción específica y urgente para un estándar tecnológico fundamental para hacer de las redes sociales una parte integral de Internet”.

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

OSV-Scanner funciona como una interfaz para la base de datos OSV.dev

Google dio a conocer hace poco OSV-Scanner, una herramienta que brinda a los desarrolladores de código abierto un fácil acceso para verificar vulnerabilidades sin parchear en el código y las aplicaciones, teniendo en cuenta toda la cadena de dependencias asociadas con el código.

OSV-Scanner permite detectar situaciones en las que una aplicación se vuelve vulnerable debido a problemas en una de las bibliotecas utilizadas como dependencia. En este caso, la biblioteca vulnerable se puede usar indirectamente, es decir invocado a través de otra dependencia.

El año pasado, emprendimos un esfuerzo para mejorar la clasificación de vulnerabilidades para desarrolladores y consumidores de software de código abierto. Esto implicó la publicación del esquema de vulnerabilidad de código abierto (OSV) y el lanzamiento del servicio OSV.dev , la primera base de datos de vulnerabilidad de código abierto distribuida. OSV permite que todos los diferentes ecosistemas de código abierto y bases de datos de vulnerabilidades publiquen y consuman información en un formato simple, preciso y legible por máquina.

Los proyectos de software generalmente se construyen sobre una montaña de dependencias: en lugar de comenzar desde cero, los desarrolladores incorporan bibliotecas de software externas en los proyectos y agregan funcionalidades adicionales. Sin embargo, los paquetes de código abierto a menudo contienen fragmentos de código no documentados que se extraen de otras bibliotecas. Esta práctica crea lo que se conoce como «dependencias transitivas» en el software y significa que puede contener múltiples capas de vulnerabilidad que son difíciles de rastrear manualmente.

Las dependencias transitivas se han convertido en una fuente creciente de riesgo de seguridad de código abierto durante el último año. Un informe reciente de Endor Labs encontró que el 95 % de las vulnerabilidades de código abierto se encuentran en dependencias transitivas o indirectas, y otro informe separado de Sonatype también destacó que las dependencias transitivas representan seis de cada siete vulnerabilidades que afectan al código abierto.

Según Google, la nueva herramienta comenzará con la búsqueda de estas dependencias transitivas mediante el análisis de manifiestos, listas de materiales de software (SBOM) donde estén disponibles y hashes de confirmación. Luego se conectará con la base de datos de vulnerabilidades de código abierto (OSV) para mostrar las vulnerabilidades relevantes.

OSV-Scanner puede escanear automáticamente de forma recursiva un árbol de directorios, identificando proyectos y aplicaciones por la presencia de directorios git (la información sobre vulnerabilidades se determina a través del análisis de hashes de confirmación), archivos SBOM (Software Bill Of Material en formatos SPDX y CycloneDX), manifiestos o bloquear administradores de paquetes de archivos como Yarn, NPM, GEM, PIP y Cargo. También admite escanear el relleno de imágenes de contenedores docker creadas en base a paquetes de los repositorios de Debian.

El OSV-Scanner es el siguiente paso en este esfuerzo, ya que proporciona una interfaz con soporte oficial para la base de datos OSV que conecta la lista de dependencias de un proyecto con las vulnerabilidades que las afectan.

La información sobre vulnerabilidades se toma de la base de datos OSV (vulnerabilidades de código abierto), que cubre información sobre problemas de seguridad en Сrates.io (Rust), Go, Maven, NPM (JavaScript), NuGet (C#), Packagist (PHP), PyPI (Python), RubyGems, Android, Debian y Alpine, así como datos de vulnerabilidad del kernel de Linux e informes de vulnerabilidad del proyecto alojados en GitHub.

La base de datos OSV refleja el estado de corrección del problema, las confirmaciones con la aparición y corrección de la vulnerabilidad, el rango de versiones afectadas por la vulnerabilidad, enlaces al repositorio del proyecto con el código y la notificación del problema. La API proporcionada le permite rastrear la manifestación de una vulnerabilidad a nivel de confirmaciones y etiquetas y analizar la exposición al problema de los productos derivados y las dependencias.

Finalmente cabe mencionar que el código del proyecto está escrito en Go y se distribuye bajo la licencia Apache 2.0. Puedes consultar más detalles al respecto en el siguiente enlace.

Los desarrolladores pueden descargar y probar OSV-Scanner desde el sitio web osv.dev o usar la verificación de vulnerabilidades de OpenSSF Scorecard  para ejecutar automáticamente el escáner en un proyecto de GitHub.

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

Hace ya más de dos años que los early adopters nos hicimos con una tablet de PINE64 con la esperanza de tener una tablet algo usable que funcionara con Linux. En estos momentos, ese proyecto/versión está casi muerto, y más que lo estará después de que la compañía haya anunciado que pronto lanzará la PineTab2. Lo ha hecho en un boletín mensual que no siempre cubrimos, en parte porque pocas veces publican algo tan relevante como lo de esta nueva tablet.

Como poseedor de la PineTab 1, Early Adopter o como quiera que la vayan a llamar a partir de ahora, no puedo decir que esté encantado con esta noticia. No lo estoy porque la PineTab2 parece una tablet de verdad, lo que debería haber sido la primera y no lo fue. No lo estoy porque esta noticia lleva implícito que mi tablet va a dejar de recibir cariño. PINE64 explica lo de la primera versión resumiendo diciendo que la culpa fue de la pandemia (y del chachacha, ya de paso…), pero ahora ya están centrados en esta nueva versión que cambia hasta los materiales de fabricación.

Cómo es la PineTab2 (y comparación con la primera)

• Carcasa de metal fácil de quitar para facilitar reparaciones. La de 2020 es de plástico.
• SoC RK3566, que aseguran que es una gran opción para una tablet por su bajo consumo y baja temperatura. La de 2020 usa un Allwinner A64.
• Dos puertos USB-C, uno con velocidad de USB 3.0 y el otro de 2.0, que también carga. Además, tiene una salida micro HDMI, tarjeta de MicroSD y un jack para auriculares. Muy parecido todo esto a la de 2020, pero ésta no tiene puertos USB-C.
• Cámaras de 5MPx y 2MPx, que sin más información parece que no han cambiado.
• Habrá dos versiones: una con 8GB de RAM y 128GB de almacenamiento y una con 4GB de RAM y 64GB. La de 2020 tenía sólo 64GB, y 2GB de RAM.
• Precio: desconocido.
• Pronto habrá algunas para desarrolladores.

PINE64 vuelve a avisar de que está todo en una fase muy temprana… y esta película ya la he visto.

Me mojo: ¿La recomiendo?

Lógicamente, aún no se sabe mucho de esta tablet porque es la primera vez que nos hablan de ella y nadie ha hecho ninguna demostración, pero yo sencillamente diría que hay que contenerse. ¿Tiene buena pinta? Sí, pero si algo hemos aprendido de la PineTab Early Adopter es que el software es casi más importante que el hardware.

Si usa Manjaro, que es lo que eligieron para el PinePhone, las veces que lo he probado me han dejado muy buen sabor de boca, pero también ha quedado claro que no hay nada que podamos etiquetar de «estable». Por lo tanto, lo mejor es esperar a un posible día/versión en el que tanto software como hardware se puedan usar de verdad.

Por otra parte, no han mencionado o no he visto yo nada sobre el WiFi, y no se puede descartar que la PineTab2 sea sólo compatible con la frecuencia de 2.4GHz. En la versión de 2020, el WiFi es muy lento, un dolor diría yo, y sería una gran decepción si finalmente no soporta la frecuencia de 5GHz, o por lo menos mejoraran mucho lo que hay en la PineTab Early Adopter.

Para quién va dirigida la PineTab2

Esto no lo dice PINE64, pero sí lo digo yo. La PineTab2 no será una tablet para el público general, ese que lo que quiere es usar algo para navegar, comunicarse con sus conocidos y jugar a los títulos móviles más populares. Como casi todo lo que fabrica esta compañía, el punto más exclusivo de la PineTab2 será que es hackeable, es decir, se le podrán instalar todo tipo de sistemas operativos de la comunidad y nosotros mismos podremos hacerle algunos cambios, pero no será algo que compita con las tablet Android o el iPad.

Aunque lo cierto es que PINE64 no tiene ese objetivo. En cuanto a tablets, parece que lo que busca es lanzar el equivalente a un portátil con Linux, pero en una tablet, algo que conseguirá si no se rinden. Y si no somos desarrolladores, (mucha) paciencia.

from Linux Adictos https://ift.tt/y4H2MGf
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 noticia de que se identificaron dos vulnerabilidades en el kernel de Linux (ya catalogada bajo CVE-2022-42896), que potencialmente se puede usar para organizar la ejecución remota de código a nivel del kernel mediante el envío de un paquete L2CAP especialmente diseñado a través de Bluetooth.

Se menciona que la primera vulnerabilidad (CVE-2022-42896) se produce al acceder a un área de memoria ya liberada (use-after-free) en la implementación de las funciones l2cap_connect y l2cap_le_connect_req.

El fallo se aprovecha después de crear un canal a través de la llamada de devolución de llamada new_connection, el cual no se bloquea la configuración para ello, pero se configura un temporizador (__set_chan_timer), después de un tiempo de espera, llamando a la función l2cap_chan_timeout y limpiando el canal sin verificar la terminación del trabajo con el canal en las funciones l2cap_le_connect*.

El tiempo de espera predeterminado es de 40 segundos y se asumió que una condición de carrera no podía ocurrir con tanto retraso, pero resultó que debido a otro error en el controlador SMP, fue posible llamar instantáneamente al temporizador y alcanzar la condición de carrera.

Un problema en l2cap_le_connect_req puede provocar una fuga de memoria del kernel, y en l2cap_connect puede sobrescribir el contenido de la memoria y ejecutar su código. La primera variante del ataque se puede llevar a cabo usando Bluetooth LE 4.0 (desde 2009), la segunda usando Bluetooth BR/EDR 5.2 (desde 2020).

Existen vulnerabilidades de uso posterior a la liberación en las funciones l2cap_connect y l2cap_le_connect_req del kernel de Linux net/bluetooth/l2cap_core.c que pueden permitir la ejecución de código y la pérdida de memoria del kernel (respectivamente) de forma remota a través de Bluetooth. Un atacante remoto podría ejecutar código que filtra la memoria del kernel a través de Bluetooth si se encuentra cerca de la víctima. Recomendamos actualizar la confirmación pasada https://ift.tt/ejioua3 https://ift.tt/L6iKMQ9

La segunda vulnerabilidad que fue detectada (ya catalogada bajo CVE-2022-42895) está provocada por una fuga de memoria residual en la función l2cap_parse_conf_req, que se puede utilizar para obtener información de forma remota sobre punteros a estructuras del kernel mediante el envío de solicitudes de configuración especialmente diseñadas.

Sobre esta vulnerabilidad se menciona que en la función l2cap_parse_conf_req, se usó la estructura l2cap_conf_efs, para la cual la memoria asignada no fue inicializada previamente, y mediante manipulaciones con el indicador FLAG_EFS_ENABLE, fue posible lograr la inclusión de datos antiguos de la pila en el paquete.

el indicador de canal FLAG_EFS_ENABLE en lugar de la variable remote_efs para decidir si la estructura l2cap_conf_efs efs debe usarse o no y es posible configurar el indicador FLAG_EFS_ENABLE sin enviar realmente datos de configuración EFS y, en este caso, la estructura efs l2cap_conf_efs no inicializada se enviará de vuelta al cliente remoto, por lo que se filtrará información sobre el contenido de la memoria del kernel, incluidos los punteros del kernel.

El problema solo ocurre en sistemas donde el núcleo está construido con la opción CONFIG_BT_HS (deshabilitada de forma predeterminada, pero habilitada en algunas distribuciones, como Ubuntu). Un ataque exitoso también requiere establecer el parámetro HCI_HS_ENABLED a través de la interfaz de administración en verdadero (no se usa de manera predeterminada).

Sobre estos dos fallos descubiertos ya se dieron a conocer los prototipos de explotación que se ejecutan en Ubuntu 22.04 para demostrar la posibilidad de un ataque remoto.

Para llevar a cabo el ataque, el atacante debe estar dentro del alcance de Bluetooth; no se requiere emparejamiento previo, pero Bluetooth debe estar activo en la computadora. Para un ataque, basta con conocer la dirección MAC del dispositivo de la víctima, que puede determinarse mediante un sniffing o, en algunos dispositivos, calcularse en función de la dirección MAC de Wi-Fi.

Finalmente cabe mencionar que se identificó otro problema similar (CVE-2022-42895) en el controlador L2CAP que puede filtrar el contenido de la memoria del kernel en los paquetes de información de configuración. La primera vulnerabilidad se ha manifestado desde agosto de 2014 (kernel 3.16), y la segunda desde octubre de 2011 (kernel 3.0).

Para los interesados en realizar un seguimiento de la corrección en las distribuciones, lo pueden hacer en las siguientes páginas: Debian, Ubuntu, Gentoo, RHEL, SUSE, Fedora y Arch .

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