Anuncio de la Liberación de OpenBSD 7.4 , parte 4

in blurthispano •  2 years ago 


image.png

OpenBSD 7.3

Continuamos con la cuarta entrega del anuncio de la liberación de esta versión de OpenBSD, donde se pueden apreciar mejoras en la seguridad sobre todo en el aspecto de comunicaciones de red seguras.


En el siguiente post continuarémos con el aspecto esas mejoras del sistema que corresponden al entorno de red del sistema operativo tanto por parte del entorno de usuario como por la parte del kernel.

Este post es una traducción del anuncio original que se encuentra en la siguente liga:

https://www.openbsd.org/73.html

  • Mejoras de Seguridad:
    • Los permisos (RWX, MAP_STACK, etc.) en regiones de espacio de dirección pueden volverse (inmutables) immutable, de tal forma que mmap(2),mprotect(2) o munmap(2) fallen con EPERM. La mayor parte del especio de direcciones estático del programa ahora es automáticamente inmutable (programa principal, ld.so, pila principal, bibliotecas compartidas en tiempo de carga, y bibliotecas mapeadas dlopen()'d sin RTLD_NODELETE). Los programadores pueden solicitar datos estáticos no inmutables usando la sección "openbsd.mutable", o manualmente traer la inmutabilidad a (un monton de objetos alineados de página) usando mimmutable(2). Los datos internos principales de malloc(3) estan marcados como inmutables.
    • Algunas arquitecturas ahora tienen código no legible ("xonly"), tanto de la perspectiva del entorno de usuario leyendo su propia memoria, o del kernel tratando de leer memoria en una llamada de sistema. Muchas prácticas descuidadas en el código de entorno de usuario tienen que ser reparadas para permitir esto. El enlazador (ld.lld(1) o ld.bfd(1)) tiene activada la opción "--execute-only" por defecto. En orden de desarrollo: arm64, riscv64, hppa, amd64, powerpc64, powerpc (solamente G5), octeon, y sparc64 (solo para sun4u; sin terminar).
    • Esto puede beneficiar todavía al cambiar a binarios --execute-only si el CPU genera diferentes trampas para recuperacion de instrucciones contra recuperación de datos. El sistema de máquina virtual no permitirá que la memoria sea leída después de que los binarios sean ejecutados si el cpu genera diferentes trampas por recuperación de instrucciones (instruction-fetch) contra recuperación de datos (data-fetch). El sistema VM no permitirá que la memoria sea leída después de que son ejecutados lo cual es valioso junto con el reenlazado de las bibliotecas. Las arquitecturas que se cambiaro incluyen loongson.
  • ld.so(1) y crt0 registra la ubicación del talón execve(2) con el kernel usando pinsyscall(2), después de lo cual el kernel solo acepta una llamada execve desde la ubicación especificada.
  • Se agregaron en execve(2) violaciones de pinsyscall(2) políticas para el correo diario, disponible por medio de rc.conf.local(5) y con accounting=YES.
  • Se agregó retguard (retaguardia) (Se hace verificación de consistencia (consistency-check) de la dirección que devuelve en la pila) para llamadas de sistema (syscalls) en amd64.
  • reenlazado aleatorio de sshd al momento del arranque: Se reenlaza aleatoriamiene y se instala sshd(8), resultado en un binario sshd con una disposición desconocida después de varios reinicios.
  • Se agregó otra mitigación contra BROPs clásicos en sistemas sin aplicación de hardware mmu de ejecución única. Una envoltura de verificación de rango en frente de copyin(9) y copyinstr(9) que asegura que la dirección de orígen del entorno de usuario no se traslape con el texto del programa principal y otros segmentos de texto, de ese modo se hace que los rangos de esa dirección sean ilegibles para el kernel. No se han descubierto programas que requieran leer sus propios segmentos de texto con una llamada de sistema.
  • En arm64, se introduce la mitigación para el Spectre-BHB (Inyección de la Historia de la Rama) vulnerabilidad de CPU por medio de usar vectores trampolín específicos del núcleo.
  • Se activó la característica de Sincronización de Datos Independientes (Data Independent Timing (DIT)) de arm64 tanto en el kernel como en el entorno de usuario en CPUs que lo soporten para mitigar ataques de sincronización de tiempo del lado del canal.
  • Cambios en la Pila de Red:
    • Se hizo /dev/pf un dispositivo clonable para rastrear los recursos de kernel usados por los procesos.
  • Se modificó el auto escalado de tamaño de buffer de recepción TCP para que use el alisado RTT (SRTT) en lugar de la opción de timestamp, el cual mejora el rendimiento en redes de alta latencia si la opción de marca de tiempo no está disponible.
  • Se relajaron los requerimientos para soporte multidifusión (multicast) de interfases para configuración IPv6. Esto permite que interfases que no son de multidifusión tales como interfases punto a punto y el NBMA / punto a multipunto como las mpe(4), mgre(4) y wg(4) puedan funcionar con IPv6.
  • Se mide el tiempo de expiración de TCP_KEEPALIVE con getnsecruntime(9) en lugar de el tiempode encendido del sistema. Previene que conexiones TCP falle innecesariamente en masa después de encender el sistema desde un estado de suspensión.
  • Se usó stoeplitz (algoritmo de hash Toeplitz simétrico) para generar un hash/id de flujo para llaves de estado de pf(4). Con este cambio, pf realizará un hash de tráfico de la misma manera que el hardware, usando una llave stoeplitz realizará un hash de tráfico de entrada en anillos. Stoeplitz también es usado por la pila TCP para generar un id de flujo, el cual es usado para elegir cual anillo de transmisión es usado en tarjetas con múltiples colas también. Usar el mismo algoritmo a traves de la pila, aníma a la afinidad de paquetes de anillo y encabezados de hilos softnet en toda la vía.
  • Previno posibles choques de kernel por medio de tirar paquetes TCP con destino al puerto 0 en pf(4) y en la pila.
  • Se corrigió un bug endian de swap causante de problemas con vlan(4) en em(4) sistemas sparc64.
  • Se deniega la configuración "pipex no" de tunel para interfaces pppx(4).
  • Se corrigió colisión pfsync(4) en la eliminación de pf_state_key.
  • Se corrigió un panico en pfsync(4) donde no hay datos listos para la transferencia a granel.
  • Se apagó la Segmentación TCP fuera de descarga (TSO) si la interface es agregada a dispositivos de capa 2.
  • Se mejoró vnet(4) para que funcione mejor en condiciones muy ocupadas.
  • Se agregó un tiempo de expiración en bpf(4) por medio de (BIOCSWTIMEOUT) entre capturar un paquete y hacer el buffer legible, previniendo, por ejemplo que,pflogd(8) se despierte cada medio segundo incluso si no hay nada que leer. Por defecto este buffer es infinito y debe ser llenado para que para volverse legible.
  • Se evita activar TSO en interfases los cuales ya estan conectadas a un puente.
  • Daemons de Ruteo y otras mejoras de red q-rificación y la capacidad de política abierta. La declaración de "anunciar política" fue simplificado al mismo tiempo.
    • Se mejoró comportamiento al iniciar por medio de introducir un pequeño retraso antes de abrir la conexión a un nuevo par.
    • Soporte para configuración de tabla aspa-set la cual puede ser proporcionada por rpki-client(8).
    • Se hace posible el filtrar el RIB por prefijos inválidos y filtrados en bgpctl y bgplgd.
    • Se agregó salida de OpenMetrics a bgpctl para varias estadísticas BGP y agregar/métricas de punto final en bgplgd.
    • Se corrigió verificaciones de longitud incorrectas que permiten lectura fuera de los límites en bgpd.
    • rpki-client(8) ha visto algunos cambios:
      • Se agregó una opción nueva de línea de comando '-H' para crear una lista corta de repositorios con los cuales sincronizarse. Por ejemplo, cuando se esté invocando "rpki-client -H rpki.ripe.net -H chloe.sobornost.net", la herramienta no se conectará con ningún otro host que no sea los dos especificados por medio de la opción -H.
      • Se agregó soporte para validar autenticadores Geofeed (RFC 9092). Para ver un ejemplo, descargue https://sobornost.net/geofeed.csv y ejecute el comando "rpki-client -f geofeed.csv"
      • Se agregó soporte para validar objetos de Clave de Ancla Confiable (Trust Anchor Key (TAK)). Los objetos TAK pueden ser usados para producir nuevos Localizadores de Ancla Confiable (Trust Anchor Locators (TALs)) firmados por y verificados contra las Clave de Ancla Confiable previas. Vea el documento draft-ietf-sidrops-signed-tal para ver la especificación completa.
      • Línea de bitácora relativas a problemas de conexión RRDP/HTTPS ahora incluye la dirección IP del punto final problemático (entre corchetes o brackets[]).
      • Se mejoró el mensaje de error cuando un nombre de archivo inválido es encontrado en campo rpkiManifest en la extensión de la Información de Acceso del Asunto (Subject Access Information (SIA)).
      • Se emite una advertencia cuando extensiones inesperadas X.509 son encontradas.
      • Se restringe el campo ipAddrBlocks ROA para permitir solo dos estructuras ROAIPAddressFamily (una por familia de direcciones). Vea el documento draft-ietf-sidrops-rfc6482bis.
      • Verifica la ausencia de la restricción de Longitud de Ruta (Path Length) en la extensión de restricciones Básica.
      • Se restringe la extensión SIA para solo permitir los métodos de acceso (AccessMethod) signedObject y rpkiNotify.
      • Se verifica que el método de acceso de Objetos Firmados este presente en certificados de Entidad Final (End-Entity) ROA, MFT, ASPA, TAK, y GBR.
      • Adicionalmente al esquema 'rsync://', también permite otros esquemas (tales como 'https://') en el método de acceso de Objeto Firmado (signedObject) SIA.
      • Verifique que la extensión KeyUsage este asignada a nadamas digitalSignature en certificados de Entidad-Final (End-Entity).
      • Verificar que la extensión KeyUsage este asignada a nada mas que keyCertSign y CRLSign en certificados CA.
      • Verifique que la extensión ExtendedKeyUsage este ausente en certificados CA.
      • Se corrigió un bug en el manejo del puerto del http_proxy.
      • La opción de línea de comando '-r' ha sido marcada como obsoleta.
      • La salida de modo de archivo (-f) ahora esta presente como una tabla basada en texto.
      • La clave de 'expira' en los formatos de salida JSON/CSV/OpenBGPD ahora son calculadas con más precisión. El cálculo tiene en cuenta el valor nextUpdate de todos los CRLs intermedios en la ruta de firmas dirigida al Ancla de Confianza, adicionalmente al momento de expiración del leaf-CRL y del CAs.
      • El manejo de CRLs y Manifiestos ante publicaciones delta RRDP inconsistentes ha sido mejorado. Una copia de una versión alternativa de las CRL aplicables se mantiene en el área del escenario del directorio cache, en orden de incrementar el potencial para establecer un punto de publicación completa, en casos donde un punto de actualización de publicación simple fue embarrada a traves de multiples archivos delta RRDP.
      • La salida de la configuración OpenBGPD ahora incluye cargas útiles de Autorización Autónoma de Proveedor de Sistema (ASPA) como un bloque de configuración 'aspa-set {}'.
      • Cuando el rpki-client es invocado con detalles incrementados ('-v'), El número de serie y la Session ID RRDP actuales sn mostrados para ayudar en la depuración.
      • Certificados X.509 autofirmados (tales como los certificados de Ancla de Confianza) ahora se consideran inválidos si ellos contienen una extensión AuthorityInfoAccess de X.509.
      • Objetos Firmados donde el atributo CMS signing-time contiene una marca de tiempo (timestamp) posterior a la marca de tiempo "notAfter" del certificado X.509 son considerados inválidos.
      • Manifiestos donde el atributo CMS signing-time contiene una marca de tiempo (timestamp) posterior a la marca de tiempo eContent nextUpdate del Manifiesto son considerados inválidos.
      • Cualquier objeto cuya extensión del Punto de Distribución CRL contenga un campo CRLIssuer, CRL Reasons, o un nameRelativeToCRLIssuer son considerados inválidos de acuerdo con el RFC 6487 sección 4.8.6.
      • Por cada certificado X.509 el SHA-1 de la Clave Pública de Asunto (Subject Public Key) es calculada y comparada al Identificador Clave del Asunto (SKI). Si se encuentra un error de coincidencia no se confiará en el Certificado.
      • Se requiere que la firma OID fuera del TBS por cada certificado CA intermedio y CRL X.509 sea sha 256 con Encripciób RSA (sha256WithRSAEncryption).
      • Se requiere que el parámetro del exponente del modulo del par de llaves TSA y del público se conforme estricamente al perfil del RFC 7935.
      • Asegurese de que no quede presente ninguna basura sobrante en objetos firmados mas allá del campo de longitud auto-embebido.
      • Se requiere que el ID de sesión RRDP sea estrictamente con UUIDs versión 4.
      • Cuando se decodifica y valída un archivo RPKI individual usando filemode (rpki-client -f file), despliega la ruta de la firma dirigida al Ancla de Confianza y la marca de tiempo cuando la ruta de la firma expirará.
      • Cuando se decodifica y valída un archivo RPKI individual usando filemode (rpki-client -f file), se despliega el tiempo de firma opcional CMS, non-optional X.509 marca de tiempo no antes (notBefore) y non-optional X.509 marca de tiempo no después (notAfter)

Si lo deseas puedes votar por mi como witness para poder aumentar las capacidades de un servidor.

https://blurtwallet.com/~witnesses?highlight=cosmicboy123


image.png

Integrate al grupo de Telegram de @team-mexico 😀 donde yo y otros usuarios de México y de otros países de habla hispana compartimos experiencias y opiniones así como nuestros propios posts. Una gran iniciativa de @cristo


image.png

| 👉Entra a https://t.me/TeamMexico1 👈 |

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE BLURT!