Monthly Archives: January 2009

KDE 4.2 disponible

Desde el martes tenemos disponible la versión 4.2 de KDE. Como comentaba hace unos días, los traductores de KDE-ES andábamos a tope con las traducciones de KDE 4.2.

El resultado fue bueno y logramos traducir creo que el 100% de las aplicaciones que se incluirían en la release.
Por otro lado seguimos en pleno proceso de confirmación de las asignaciones de traducciones, que finaliza la semana que viene.

Respecto a KDE 4.2, tenemos el anuncio de lanzamiento de KDE 4.2 y en ese anuncio aparecen algunas de las mejoras, nuevas funcionalidades, corrección de errores…

Podeis descargar KDE 4.2 desde los sitios habituales y como siempre, habrá que esperar un poco más a que las distintas distribuciones empiecen a incorporar esta nueva versión a sus repositorios.
En el caso concreto de Debian, tenemos KDE 4 en experimental pero perfectamente instalable y funcional en Lenny (4.1) y Sid (4.2).

Confirmando asignaciones de KDE-ES: 4-febrero

La semana pasada publicaba el ya típico mensaje de renovación de asignaciones en la lista de traductores de KDE-ES.

La idea es sencilla… se ponen TODAS las asignaciones en espera de confirmación, damos un plazo y la asignación que no se confirme queda libre, por asignar, disponible para cualquier traductor que se ofrezca a encargarse de la traducción de ese paquete.
Realizamos ese proceso periódicamente para mantener actualizada la lista de asignaciones.

El día 4 de febrero es el día. A partir de entonces es probable que algún paquete quede disponible y sea la oportunidad para encargarse de traducir un paquete de traducciones de aplicaciones y/o documentación de KDE.

¿Te animas? Los ficheros a traducir están en el SVN de KDE pero ponte antes en contacto conmigo para poder coordinar la asignación de traducciones de forma que no dupliquemos esfuerzos y tengamos a más de una persona traducciendo el mismo paquete.

Vuelve Conficker y los problemas de no parchear

No es nuevo el problema, Microsoft publicaba el parche a finales de octubre en una distribución de esas críticas fuera de ciclo. El hecho de que hagan una distribución fuera de ciclo debe ser motivo para tomárselo en serio y en muchas de las grandes redes se iniciaron los procedimientos para actualizar e instalar dicha actualización cuanto antes.

En menos de un mes ya teníamos al menos un virus detectado y dando guerra. El Conficker se hizo presente. Como siempre, las primeras informaciones eran vagas (conficker, Gimmiv, ¿otro?) y había que fiarse de la intuición y experiencia para identificar como un virus determinados patrones ya sea en el tráfico de la red, en las incidencias de los usuarios, …

A los días las primeras infecciones ya eran masivas. Grandes redes infectadas por un gusano que se introducía en todas las máquinas que no tenían el parche aplicado (y habían reiniciado tras la actualización), los fabricantes de antivirus no daban con la tecla para limpiar las infecciones y sacaban varios patrones de firmas al día tratando de dar con la tecla, las redes mal segmentadas se bloqueaban con el tráfico que el gusano generaba, … caos.

Pasa el tiempo, los administradores (que no lo hicieron a tiempo) van parcheando, los fabricantes de antivirus generan y distribuyen las firmas del virus y parece que todo vuelve a la normalidad… pero no.

A principios del mes de enero, una variante de conficker vuelve a las redes y caen de nuevo las grandes redes. Cuentas de usuario bloqueadas, tráfico que colapsa los routers, los foros y webs echando humo, … en medio de la confusión Panda la caga con un falso positivo y hace que los síntomas de un virus se mezclen con los síntomas del falso positivo de Panda… vuelta a investigar, …

Esta vez la variante es más lista y no sólo se propaga con un gusano típico como en noviembre/diciembre… ahora también lo hace a través de los recursos compartidos, los discos USB, … la Ingeniería Social, crackeando contraseñas débiles usando diccionarios rudimentarios, … vuelta a investigar, vuelta a poner parches (¿pero… no estaban puestos ya? ¿Es que la gente no aprende?).

No se si alguna vez se ganará la guerra a los creadores de virus y malware. Me da que no, siempre vamos al menos un paso por detrás… generando parches y antivirus.

Aun quedan administradores que no ven la actualización de parches de seguridad como algo crítico de sus sistemas (si funciona no lo toques). El miedo a que algo deje de funcionar por instalar un parche sigue pesando más que el miedo a que toda la red deje de funcionar y no puedan dar servicio por una infección masiva (¿?) pero el caso es que los parches no se instalan… o no se hace a tiempo.

¿Qué cuesta más? ¿Mantener un parque de máquinas actualizadas y con los parches de seguridad y antivirus al día o quedarte sin servicio, sin previo aviso, tener que parchear a toda prisa y sin hacer las pruebas pertinentes el día de la catástrofe?

La Gestión de la Seguridad de la Información suele recomendar eso de parchear…

Traducciones para KDE 4.2

Llegan las prisas…
Se acerca la fecha del etiquetado de KDE 4.2 y los traductores de KDE-ES estamos a tope.

Todo lo que no tengamos listo no saldrá en KDE 4.2 y tendrá que esperar a la siguiente versión. Andamos con asignaciones de traducciones de emergencia…

Nuestras estadísticas no suelen ser malas… de hecho no lo son pero es cierto que deberíamos darle un empujón, entre otras cosas, a la documentación que es lo que peor llevamos siempre

Lo que si es cierto es que hace unos años eramos los mejores o los segundos mejores y ahora ni siquiera estamos en el Top-10 de equipos de traducción. Algo falla. 🙁
Ahora mismo los turcos están más cerca de alcanzarnos a nosotros que nosotros de alcanzar a los brasileños…

Pasa que, por la razón que sea, la gente no mantiene los paquetes que tiene asignados y al final nos pilla el toro. La gente trabaja, estudia, tiene otras obligaciones… otras aficiones y claro las traducciones no siempre están en primer lugar.

Tendremos que encontrar nuevas formas de motivar a los traductores actuales y de atraer a nuevos traductores. ¿A alguien se le ocurre alguna estrategia?

¿Cómo lo hacen los ucranianos? ¿Y los gallegos?
Mi enhorabuena a los ganadores 🙂

Datos biométricos en el pasaporte

¿Hasta dónde van a llegar para controlarnos? ¿Qué es lo que hay que proteger? ¿Dónde está el límite de la privacidad? ¿Cómo de intrusivos deben o pueden ser los sistemas de autenticación y seguridad? ¿Cuánto estamos los usuarios dispuestos a tragar? ¿Ni una protesta? ¿Nadie se queja?

La Eurocámara ha aprobado una medida que obliga a la inclusión de datos biométricos en los pasaportes.
¿Incluirá esta medida también los requisitos mínimos de seguridad que deben incluir los pasaportes para garantizar nuestra privacidad?

Tenemos dispositivos RFID y datos biométricos en los pasaportes… mala mezcla… los vendedores de carteras y fundas con jaulas de faraday se van a hartar a vender.

¿Han valorado el coste de lo que pretenden proteger y el coste de la implantación de esas medidas?

25 errores más peligrosos al desarrollar software

Leo en MITRE una lista donde detallan los 25 errores más peligrosos de la programación y creo que es una buena referencia que puede tomarse como una checklist, una lista a comprobar cuando los desarrolladores están realizando su trabajo.

Como dicen en su introducción, esa lista puede servir también de referencia a los educadores y profesores de programación, ingeniería del software, … para que los alumnos conozcan también estos típicos errores que generan vulnerabilidades peligrosas y tópicas.

Una breve enumeración:

  • No validar las entradas. (CWE-20)…
  • … y no formatear (o escapar) adecuadamente las salidas. (CWE-116).
  • Cuidado con la inyección de SQL. (CWE-89).
  • Cuidado con el Cross-site scripting (XSS). (CWE-79).
  • Atención a la ejecución de comandos. (CWE-78).
  • Falsificaciones de peticiones en sitios cruzados. (CWE-352).
  • Transmisión de información sensible en claro. (CWE-319).
  • Race conditions la expresión en español típica (condición de carrera) no es una traducción que me guste en exceso. (CWE-362).
  • Cuidado con la información de los mensajes de error, que no den más información de la cuenta. (CWE-209).
  • Desbordamientos de buffer. (CWE-119).
  • Cuidado con el almacenamiento de datos críticos, no sea que están accesibles. (CWE-642).
  • Cuidado con las rutas y ficheros, exposición de más información de la cuenta o acceso a rutas no necesarias. (CWE-73). Este me parece a mi un error más de configuración de sistemas que de desarrollo puro y duro pero es interesante. Es sencillo encontrar ejemplos de máquinas potencialmente vulnerables.
  • Control sobre el directorio de búsqueda de recursos. (CWE-426).
  • Generación de código. (CWE-94). Veo este error muy relacionado con los de validación de entradas y salidas… pero bueno, así comprobamos dos veces. 🙂
  • Cuidado con la reutilización. (CWE-494). ¡Para qué volver a reinventar la rueda…? pero eso sí, asegurémonos de que la rueda es redonda antes de ponerla.
  • La basura de un hombre es el tesoro de otro. (CWE-404).
  • Inicializa correctamente las variables y objetos. (CWE-665).
  • Cálculos incorrectos. (CWE-682). También relacionada con la validación de las entradas y el desbordamiento de buffer.
  • Control de acceso ineficaz. (CWE-285).
  • Utilización de algoritmos criptográficos débiles o rotos. (CWE-327).
  • No incluir contraseñas en el código. (CWE-259).
  • Asignación de permisos inseguros para recursos críticos. (CWE-732). ¿No es esto demasiado parecido al control de acceso ineficaz del que hablaban antes?
  • Aleatoriedad previsible. (CWE-330).
  • Utilización de más permisos de la cuenta. (CWE-250). Este también es un problema habitual. Muchos desarrolladores se acostumbran a desarrollar con usuarios privilegiados y generan código que requiere esos privilegios para ejecutarse cuando no hay necesidad real.
  • Confiar la seguridad del servidor al clientes. (CWE-602).

Se trata de una lista, unas recomendaciones muy útil para mejorar el desarrollo seguro y generar herramientas y programas con menos vulnerabilidades.
No tenemos por qué estar de acuerdo con todas las cosas que aquí dicen… pero desde luego que son cosas interesantes a tener en cuenta por los desarrolladores.

Un TBR-160s para mi HF9V

Estas fiestas, entre otras cosas me han regalado (¡muchas gracias!) esto:

 

No, no es sólo un muelle… que también.

Se trata de una bobina y un par de condensadores (digamos un filtro, resonador, como lo queráis llamar) de forma que se consigue que la HF9V pueda funcionar en la banda de 160m (1.8MHz), la top-band.

Ahora a esperar a poder subir al tejado… porque creo que hoy no es el día.

 

¡Nos escuchamos en 160m!

73

Ataque a certificados con MD5

Desde InfoSec News nos llega una noticia que ya tiene unos días pero es realmente interesante e importante.

Lo importante del tema es que por lo visto un grupo de investigadores de la Universidad de Eindhoven ha conseguido generar certificados digitales falsos. Las aplicaciones de estos certificados son muchas pero el ejemplo se centra en la falsificación de páginas web y por si aun queda alguien que no ve la importancia de este hallazgo añadirá que sería posible falsificar páginas de cualquier banco online, eBay, Paypal o cualquier otro sitio de pagos electrónicos, compras, …

¿Está ahora un poco más claro eso de que es importante?

¿Cómo es que pueden falsear la web de mi banco?

Los bancos (y demás “sitios seguros”) utilizan para identificarse y que sepamos que son el sitio correcto un certificado digital. Dicho certificado digital (un ejemplo sería como nuestro DNI) del banco debe estar firmado por una autoridad de certificación (CA) en la que nosotros confiemos (el equivalente sería la Fábrica Nacional de Moneda y Timbre).

Los navegadores suelen tener los certificados de las CA instalados (ya hablaré otro día de cómo es que permitimos que los fabricantes de navegadores decidan por nosotros en quien confiamos sin preguntar) y de esa forma, cuando navegamos por Internet podemos comprobar la validez de los certificados que nos presentan los servidores web que visitamos.

Como ya he dicho, las CA también tienen certificados por lo que si alguien consigue un certificado firmado por una CA de confianza para una CA maliciosa podrá generar/firmar certificados para cualquier sitio web y duplicar cualquier web segura de la red.
Nuestra confianza en los proveedores de certificados se basa en que suponemos que comprueban que los certificados que firman son realmente para las direcciones que dicen ser.

La imposibilidad de duplicar o falsificar estos certificados viene dada por el hash de ciertos datos del certificado. El hash del certificado se genera con SHA en muchas CA pero con MD5 en otras y es para este último algoritmo para el que han realizado el ataque.

Lo interesante es cómo lo hacen y viene perfectamente explicado en la web donde detallan cómo han conseguido demostrar que es posible crear una CA falsa y que el MD5 no es tan seguro como pensábamos. La explicación está llena de detalles y explicaciones pero aun así conviene tener algunos conceptos claros antes de aventurarse a leerla.
El ataque tiene algunas cosas menos “matemáticas” como que depende de la asignación de números secuenciales de certificado de algunas CA… y eso es fácilmente subsanable.

Tras la publicación del ataque, muy rápidamente, se han producido los movimientos adecuados en la industria de los certificados por lo que muchos han dejado de usar MD5 para pasarse a otros algoritmos de hash para generar las firmas… algo que tenían que haber hecho hace mucho.

Supongo que en breve tendremos actualizaciones de los navegadores con la instalación de nuevos certificados raiz.

Las empresas de certificación digital viven de la confianza… si los usuarios perdemos la confianza en ellas, se quedan sin negocio.

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.

ACEPTAR
Aviso de cookies