SourceHut dejara de albergar proyectos relacionados con criptomonedas en 2023

SourceHut

SourceHut eliminará los proyectos de software que aprovechan las criptomonedas y la cadena de bloques

Se dio a conocer la noticia que el fundador y creador de la plataforma de desarrollo colaborativo SourceHut, SourceHut, Drew DeVault, ha anunciado un próximo cambio en sus términos de uso. Los nuevos términos, que entrarán en vigencia el 1 de enero de 2023, prohíben la publicación de contenido relacionado con criptomonedas y blockchain.

Después del inicio de las nuevas condiciones, también planean eliminar todos los proyectos similares colocados anteriormente. En una solicitud por separado al servicio de apoyo para proyectos legales y útiles, se puede hacer una excepción.

También se permite la restauración de proyectos eliminados después de apelaciones. No está prohibido aceptar donaciones en criptomoneda, aunque se destaca como método de apoyo no recomendado.

El motivo de la prohibición de las criptomonedas es la abundancia de desarrollos fraudulentos, criminales, maliciosos y engañosos en esta área, lo que afecta negativamente la reputación de SourceHut y perjudica a la comunidad.

Estos dominios están fuertemente asociados con actividades fraudulentas e inversiones de alto riesgo que se aprovechan de las personas que sufren dificultades económicas y una creciente desigualdad de riqueza global. Se han encontrado pocos o ningún caso de uso legítimo para esta tecnología; en cambio, se usa principalmente para esquemas fraudulentos de «hacerse rico rápidamente» y para facilitar actividades delictivas, como ransomware, comercio ilícito y evasión de sanciones. Estos proyectos a menudo fomentan el desperdicio de energía y desechos electrónicos a gran escala, lo que contribuye al deterioro de la salud del medio ambiente de la Tierra. La presencia de estos proyectos en SourceHut expone a nuevas víctimas a estas estafas y es perjudicial para la reputación de SourceHut y su comunidad.

DeVault dijo que la prohibición se aplicaría con cierta discreción, lo que significa que los desarrolladores que sienten que su uso de criptomonedas o blockchain «no está afectado por estos problemas sociales» pueden solicitar permiso para alojarlo en SourceHut o apelar su eliminación poniéndose en contacto con el soporte. De lo contrario, tienen hasta el 1 de enero de 2023 para migrar un proyecto prohibido a una plataforma diferente.

Según SourceHut, las criptomonedas están asociadas con inversiones de riesgo, manipulación por parte de personas con poca comprensión de la economía, estafas de dinero rápido y esquemas criminales asociados con ransomware, comercio ilegal y elusión de sanciones.

A pesar de la utilidad general de la idea de blockchain, también se decidió aplicar el bloqueo a los proyectos que utilizan blockchain, ya que la mayoría de los proyectos que promueven soluciones basadas en blockchain tienen los mismos problemas sociales que las criptomonedas.

Reconocemos que la idea básica de una cadena de bloques, por así decirlo, puede ser útil en general. Sin embargo, la mayoría de los proyectos que se comercializan con tecnología blockchain están sujetos a los mismos males sociales que las criptomonedas. En consecuencia, hemos optado por incluir proyectos relacionados con «blockchain» en esta prohibición por el momento.

Para quienes desconocen de la plataforma Sourcehut, deben saber que esta tiene una interfaz distintiva, a diferencia de GitHub y GitLab, pero simple, muy rápida y funciona sin JavaScript. La plataforma proporciona funciones como trabajar con repositorios públicos y privados de Git y Mercurial, sistema de control de acceso flexible, wiki, informes de errores, infraestructura de integración continua incorporada, chat, discusiones basadas en correo electrónico, vista de árbol de archivos de listas de correo, revisión web de cambios, añadiendo anotaciones al código (adjuntando enlaces y documentación).

“Se han encontrado pocos o ningún caso de uso legítimo para esta tecnología; en cambio, se usa principalmente para esquemas fraudulentos de ‘hacerse rico rápidamente’ y para facilitar la actividad delictiva, como el ransomware, el comercio ilícito y la evasión de sanciones”, dijo DeVault. “Estos proyectos a menudo fomentan el desperdicio de energía y desechos electrónicos a gran escala, lo que contribuye al deterioro de la salud del medio ambiente de la Tierra.

“La presencia de estos proyectos en SourceHut expone a nuevas víctimas a estas estafas y es perjudicial para la reputación de SourceHut y su comunidad”.

Si se habilita la configuración adecuada, los usuarios sin cuentas locales pueden participar en el desarrollo (autenticación a través de OAuth o participación por correo electrónico).

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/zMTScVi
via IFTTT

RingHopper, una vulnerabilidad en UEFI permite ejecución de código a nivel SMM

vulnerabilidad

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 divulgó información sobre una vulnerabilidad (ya catalogada bajo CVE- 2021-33164) detectada en el firmware UEFI, el fallo detectado permite ejecutar código en el nivel SMM (System Management Mode), que tiene una prioridad más alta que el modo hipervisor y el anillo de protección cero, y brinda acceso ilimitado a toda la memoria del sistema.

La vulnerabilidad, cuyo nombre en código es RingHopper, está relacionada con la posibilidad de un ataque de tiempo usando DMA (Acceso directo a la memoria) para corromper la memoria en el código que se ejecuta en la capa SMM.

Se puede lograr una condición de carrera que involucre el acceso y la validación de la SMRAM mediante ataques de temporización DMA que dependen de las condiciones de tiempo de uso ( TOCTOU ). Un atacante puede usar un sondeo oportuno para intentar sobrescribir el contenido de SMRAM con datos arbitrarios, lo que lleva a que el código del atacante se ejecute con los mismos privilegios elevados disponibles para la CPU (es decir, modo Ring -2 ). La naturaleza asíncrona del acceso a la SMRAM a través de los controladores DMA permite al atacante realizar dicho acceso no autorizado y eludir las verificaciones que normalmente proporciona la API del controlador SMI.

Las tecnologías Intel-VT e Intel VT-d brindan cierta protección contra los ataques de DMA mediante la Unidad de administración de memoria de entrada y salida (IOMMU) para abordar las amenazas de DMA. Aunque IOMMU puede proteger contra ataques de hardware DMA, los controladores SMI vulnerables a RingHopper aún pueden ser objeto de abuso.

Las vulnerabilidades se pueden explotar desde el sistema operativo utilizando controladores SMI vulnerables (Interrupción de administración del sistema), que requieren derechos de administrador para acceder. El ataque también puede llevarse a cabo si hay acceso físico en una etapa temprana del arranque, en una etapa anterior a la inicialización del sistema operativo. Para bloquear el problema, se recomienda a los usuarios de Linux que actualicen el firmware mediante el LVFS (Servicio de firmware del proveedor de Linux) mediante la utilidad fwupdmgr (fwupdmgr get-updates; actualización de fwupdmgr) del paquete fwupd .

La necesidad de tener derechos de administrador para realizar un ataque limita la peligrosidad del problema, pero no impide su uso como vulnerabilidad del segundo eslabón, para mantener su presencia tras la explotación de otras vulnerabilidades en el sistema o el uso de redes sociales métodos de ingeniería.

El acceso a SMM (Ring -2) permite ejecutar código a un nivel que no está controlado por el sistema operativo, que puede usarse para modificar el firmware y colocar código malicioso o rootkits ocultos en SPI Flash que no son detectados por el sistema operativo. , así como para deshabilitar la verificación en la etapa de arranque (UEFI Secure Boot, Intel BootGuard) y los ataques a los hipervisores para eludir los mecanismos de verificación de la integridad de los entornos virtuales.

El problema se debe a una condición de carrera en el controlador SMI (interrupción de administración del sistema) que se produce entre la verificación de acceso y el acceso a SMRAM. El análisis de canal lateral con DMA se puede utilizar para determinar el momento adecuado entre la verificación del estado y el uso del resultado de la verificación.

Como resultado, debido a la naturaleza asíncrona del acceso a la SMRAM a través de DMA, un atacante puede determinar el momento adecuado y sobrescribir el contenido de la SMRAM mediante DMA, sin pasar por la API del controlador SMI.

Los procesadores habilitados para Intel-VT e Intel VT-d incluyen protección contra ataques DMA basados ​​en el uso de IOMMU (Unidad de administración de memoria de entrada y salida), pero esta protección es eficaz para bloquear ataques DMA de hardware realizados con dispositivos de ataque preparados, y no no protege contra ataques a través de controladores SMI.

La vulnerabilidad ha sido confirmada en firmware de Intel, Dell e Insyde Software (se afirma que el problema afecta a 8 fabricantes, pero los 5 restantes aún no han sido revelados). El firmware de AMD, Phoenix y Toshiba no se ve afectado por el problema.

Fuente: https://kb.cert.org/

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

.NET 7 ya fue liberado y llega con diversas mejoras de rendimiento

NET-7

Con .NET 7 se pueden crear aplicaciones multiplataforma en el navegador, la nube, el escritorio, los dispositivos IoT y las plataformas móviles

Microsoft dio a conocer el lanzamiento de la nueva versión de su plataforma «.NET 7» que incluye Runtime con el compilador RyuJIT JIT, especificaciones API, bibliotecas WPF y demás herramientas.

Ademas, tambien y por separado se han publicado las aplicaciones web ASP.NET Core 7.0, la capa ORM de Entity Framework Core 7.0, la biblioteca WPF 7 (Windows Presentation Foundation), el marco de Windows Forms 7 para GUI de desarrollo, plataforma Orleans.

Principales novedades de .NET 7

En esta nueva versión la biblioteca de clases base (BCL, Base Class Library) se ha unificado para su uso en varios tipos de aplicaciones, incluidos programas para sistemas de escritorio, aplicaciones web, plataformas en la nube, aplicaciones móviles, juegos, programas integrados y sistemas de aprendizaje automático. Puede usar un SDK, Runtime y un conjunto de bibliotecas comunes para desarrollar diferentes tipos de aplicaciones.

Ademas de ello, tambien se destaca que se proporcionó la capacidad de vincular una aplicación a una API compatible con la versión .NET 7 a través de una definición de marco de destino «net7.0», como «<TargetFramework>net7.0</TargetFramework>». Para enlazar a las API específicas de la plataforma, puede especificar el tipo de plataforma al especificar el destino, por ejemplo, especificando «net7.0-android».

Tambien se destaca la compatibilidad mejorada para la arquitectura ARM64 y trabajo continuo para lograr la paridad en el rendimiento de las aplicaciones .NET cuando se ejecutan en arquitecturas x86 y ARM64. Eficiencia de caché L3 mejorada en tiempo de ejecución en sistemas ARM64. Las instrucciones LSE se utilizan para delimitar el acceso a la memoria de subprocesos paralelos, lo que da como resultado una reducción del 45 % en la latencia.

La biblioteca agregó controladores que usan los tipos de vectores Vector64, Vector128 y Vector256, y las funciones EncodeToUtf8 y DecodeFromUtf8 se reescribieron en función de las instrucciones vectoriales, lo que aumentó su rendimiento hasta en un 60% (para las funciones NarrowUtf16ToAscii y GetIndexOfFirstNonAsciiChar, la ganancia de rendimiento alcanza 35%). En general, la velocidad de aprobación de las pruebas en la plataforma ARM64 aumentó entre un 10 y un 60 %.

Por otra parte, tambien se destacan las mejoras de soporte para Linux, incluida la adición de paquetes con .NET 6 a los repositorios de stock de Ubuntu 22.04 y la provisión de una imagen acoplable optimizada, compacta y lista para usar para implementar rápidamente contenedores con aplicaciones basadas en .NET.

Se presentó .NET Upgrade Assistant para facilitar la migración de aplicaciones antiguas a ramas .NET 6 o .NET 7. La nueva versión ha ampliado el soporte para migrar aplicaciones de ASP.NET a ASP.NET Core, agregando analizadores y correctores de código para WinForms, WPF y bibliotecas de clases, soporte implementado para el análisis de archivos ejecutables, soporte agregado para UWP (Universal Windows Platform).

Se proponen interfaces genéricas para funciones matemáticas y se brinda la posibilidad de definir elementos estáticos en interfaces virtuales, lo que permitió aplicar métodos de programación genéricos para realizar operaciones matemáticas sin información exacta sobre el tipo de valores.

El rendimiento en el compilador JIT tambien fue mejorado, ademas de que se agregó soporte para el mecanismo OSR (On Stack Replacement) para cambiar el código de los métodos que ya se están ejecutando, lo que le permite realizar optimizaciones en los métodos que tardan mucho tiempo en completarse sin esperar a que se complete la llamada actual (en la prueba TechEmpower, hay es un aumento del 10-30% en el rendimiento del procesamiento de las primeras solicitudes en un 10-30%).

De los demás cambios que se destacan:

  • Se agregó soporte para compilar en ejecutables autónomos (AOT nativo), en el que todo el proyecto se compila inicialmente en código de plataforma de destino nativo sin usar código intermedio y sin usar JIT.
  • SDK de .NET implementa la capacidad de restringir el uso de las plantillas de proyecto proporcionadas; por ejemplo, puede determinar en qué sistemas operativos es válida la plantilla.
  • NuGet ha agregado un modo de administración de paquetes centralizado que le permite administrar dependencias para varios proyectos a la vez.

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

Para los interesados, deben saber que las compilaciones de .NET SDK 7, .NET Runtime 7 y ASP.NET Core Runtime 7 están creados para Linux, macOS y Windows. .NET Desktop Runtime 6 solo está disponible para Windows.

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

DXVK 2.0 llega con mejoras en controladores, actulizaciones y mas

DXVK

DXVK se puede usar para ejecutar aplicaciones y juegos 3D en Linux usando Wine

Se dio a conocer el lanzamiento de la nueva versión de DXVK 2.0, una implementación de DXGI Direct3D 9, 10 y 11, que funciona a través de la traducción de llamadas a la API de Vulkan. DXVK requiere controladores compatibles.

En esta nueva versión se aumentaron los requisitos para la versión de la API de gráficos Vulkan: ahora requiere un controlador con soporte para Vulkan 1.3 (anteriormente se requería Vulkan 1.1), lo que hizo posible implementar soporte para nuevas funciones relacionadas con la compilación de sombreadores.

En la práctica, DXVK 2.0 se puede ejecutar en cualquier sistema que admita el uso del paquete Proton Experimental para ejecutar juegos basados ​​en D3D11 y D3D12. Winevulkan requiere al menos Wine 7.1 para funcionar.

Se adoptó el código del proyecto dxvk-native, que permite generar compilaciones DXVK nativas para Linux (no vinculadas a Wine), que se pueden usar no para ejecutar aplicaciones de Windows, sino en aplicaciones ordinarias de Linux, que pueden ser útiles para crear puertos de juegos para Linux sin cambiar el código de renderizado basado en D3D.

Se ha ampliado la compatibilidad con Direct3D 9, incluida la gestión mejorada de la memoria (los archivos reflejados en la memoria se utilizan para almacenar copias de textura), se ha implementado la compatibilidad con la lectura correcta de puntos de acceso (resolvió problemas con la aparición de artefactos al jugar GTA IV) y se ha rediseñado la implementación del control de transparencia.

Para Direct3D 10, se descontinuaron las bibliotecas d3d10.dll y d3d10_1.dll, que no se instalaron de forma predeterminada debido a la presencia de una implementación más avanzada de D3D10 en Wine. Al mismo tiempo, la compatibilidad con la API D3D10 continúa en la biblioteca d3d10core.dll.

La compatibilidad con Direct3D 11 se actualizó al nivel de función 12_1 ( D3D11 Feaure Level ), para lograr que se implementen características como recursos en mosaico ( Recursos en mosaico ), rasterización conservadora ( Rasterización conservadora ) y representación ordenada en el rasterizador ( Vistas ordenadas de rasterizador ).

La implementación de la interfaz ID3D11DeviceContext, que representa el contexto del dispositivo que genera los comandos de dibujo, se ha rediseñado y tiene un comportamiento más cercano a Windows. El rediseño permitió mejorar la compatibilidad con bibliotecas de terceros y reducir la carga en la CPU. En particular, el uso de la CPU se ha reducido en juegos que usan contextos diferidos en gran medida (como Assassin’s Creed: Origins) o que llaman con frecuencia a la operación ClearState (como God of War).

Se han realizado cambios relacionados con la compilación de shaders. En presencia de controladores Vulkan con soporte para la extensión VK_EXT_graphics_pipeline_library, los sombreadores Vulkan se compilaron cuando los juegos cargaron sombreadores D3D, y no durante el renderizado, lo que resolvió los problemas con las congelaciones debido a la compilación de sombreadores durante el juego.

De los demás cambios que se destacan:

  • Actualmente, la extensión requerida solo es compatible con los controladores patentados de NVIDIA a partir de la versión 520.56.06.
  • Los sombreadores D3D11 usan el modelo de memoria Vulkan.
  • Se eliminó el límite en la cantidad de recursos que se pueden vincular a la vez.

Finalmente si estás interesado en conocer más al respecto sobre este nuevo lanzamiento, puedes consular los detalles en el siguiente enlace.

¿Cómo añadir el soporte de DXVK a Linux?

DXVK se puede usar para ejecutar aplicaciones y juegos 3D en Linux usando Wine, actuando como una alternativa de mayor rendimiento a la implementación de Direct3D 11 integrada en Wine que se ejecuta sobre OpenGL.

DXVK requiere de la última versión estable de Wine para ejecutarse. Por lo que, si no cuentas con este instalado. Ahora solo tendremos que descargar el último paquete estable de DXVK, este lo encontramos en el siguiente enlace.

wget https://github.com/doitsujin/dxvk/releases/download/v1.10.2/dxvk-1.10.2.tar.gz

Después de haber realizado la descarga ahora vamos a descomprimir el paquete recién obtenido, esto lo pueden hacer con desde su entorno de escritorio o desde la misma terminal ejecutando en el siguiente comando:

tar -xzvf dxvk-2.0.tar.gz

Después accedemos a la carpeta con:

cd dxvk-2.0

Y ejecutamos el comando sh para ejecutar el script de instalación:

sudo sh setup-dxvk.sh install
setup-dxvk.sh install --without-dxgi

Cuando se instale DXVK en un prefijo de Wine. La ventaja es que se puede usar Wine vkd3d para juegos D3D12 y DXVK para juegos D3D11.

Además, la nueva secuencia de comandos permite instalar la dll como enlaces simbólicos, lo que facilita la actualización de DXVK para obtener más prefijos de Wine (puede hacerlo a través del comando –symlink).

Como verán la carpeta de DXVK contiene otras dos dll para 32 y 64 bits estas las vamos a colocar de acuerdo a las siguientes rutas.
En donde “usuario” lo remplazas por el nombre de usuario que utilizas en tu distribución de Linux.

Para 64 bits las colocamos en:

~/.wine/drive_c/windows/system32/

O

/home/”usuario”/.wine/drive_c/windows/system32/

Y para 32 bits en:

~/.wine/drive_c/windows/syswow64

O

/home/”usuario”/.wine/drive_c/windows/system32/

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

Lawsuit Seeks Food Benefits Stolen By Skimmers

A nonprofit organization is suing the state of Massachusetts on behalf of thousands of low-income families who were collectively robbed of more than a $1 million in food assistance benefits by card skimming devices secretly installed at cash machines and grocery store checkout lanes across the state. Federal law bars states from replacing these benefits using federal funds, and a recent rash of skimming incidents nationwide has disproportionately affected those receiving food assistance via state-issued prepaid debit cards.

The Massachusetts SNAP benefits card looks more like a library card than a payment card.

On Nov. 4, The Massachusetts Law Reform Institute (MLRI) filed a class action lawsuit on behalf of low-income families whose Supplemental Nutrition and Assistance Program (SNAP) benefits were stolen from their accounts. The SNAP program serves over a million people in Massachusetts, and 41 million people nationally.

“Over the past few months, thieves have stolen over a million SNAP dollars from thousands of Massachusetts families – putting their nutrition and economic stability at risk,” the MLRI said in a statement on the lawsuit. “The criminals attach a skimming device on a POS (point of sale) terminal to capture the household’s account information and PIN. The criminals then use that information to make a fake card and steal the SNAP benefits.”

In announcing the lawsuit, the MRLI linked to a story KrebsOnSecurity published last month that examined how skimming thieves increasingly are targeting SNAP payment card holders nationwide. The story looked at how the vast majority of SNAP benefit cards issued by the states do not include the latest chip technology that makes it more difficult and expensive for thieves to clone them.

The story also highlighted how SNAP cardholders usually have little recourse to recover any stolen funds — even in unlikely cases where the victim has gathered mountains of proof to show state and federal officials that the fraudulent withdrawals were not theirs.

Deborah Harris is a staff attorney at the MLRI. Harris said the goal of the lawsuit is to force Massachusetts to reimburse SNAP skimming victims using state funds, and to convince The U.S. Department of Agriculture (USDA) — which funds the program that states draw from — to change its policies and allow states to replace stolen benefits with federal funds.

“Ultimately we think it’s the USDA that needs to step up and tell states they have a duty to restore the stolen benefits, and that USDA will cover the cost at least until there is better security in place, such as chip cards,” Harris told KrebsOnSecurity.

“The losses we’re talking about are relatively small in the scheme of total SNAP expenditures which are billions,” she said. “But if you are a family that can’t pay for food because you suddenly don’t have money in your account, it’s devastating for the family.”

The USDA has not said it will help states restore the stolen funds. But on Oct. 31, 2022, the agency released guidance (PDF) whose primary instructions were included in an appendix titled, Card Security Options Available to Households. Notably, the USDA did not mention the idea of shifting to chip-based SNAP benefits cards.

The recently issued USDA guidance.

“The guidance generally continues to make households responsible for preventing the theft of their benefits as well as for suffering the loss when benefits are stolen through no fault of the household,” Harris said. “Many of the recommendations are not practical for households who don’t have a smartphone to receive text messages and aren’t able to change their PIN after each transaction and keep track of the new PIN.”

Harris said three of the four recommendations are not currently available in Massachusetts, and they are very likely not currently available in other states. For example, she said, Massachusetts households do not have the option of freezing or locking their cards between transactions. Nor do they receive alerts about transactions. And they most certainly don’t have any way to block out-of-state transactions.

“Perhaps these are options that [card] processors and states could provide, but they are not available now as far as we know,” Harris said. “Most likely they would take time to implement.”

The Center for Law and Social Policy (CLASP) recently published Five Ways State Agencies Can Support EBT Users at Risk of Skimming. CLASP says while it is true states can’t use federal funds to replace benefits unless the loss was due to a “system error,” states could use their own funds.

“Doing so will ensure families don’t have to go without food, gas money, or their rent for the month,” CLASP wrote.

That would help address the symptoms of card skimming, but not a root cause. Hardly anyone is suggesting the obvious, which is to equip SNAP benefit cards with the same security technology afforded to practically everyone else participating in the U.S. banking system.

There are several reasons most state-issued SNAP benefit cards do not include chips. For starters, nobody says they have to. Also, it’s a fair bit more expensive to produce chip cards versus plain old magnetic stripe cards, and many state assistance programs are chronically under-funded. Finally, there is no vocal (or at least well-heeled) constituency advocating for change.

A copy of the class action complaint filed by the MLRI is available here.

from Krebs on Security https://ift.tt/ZV5N0wy
via IFTTT