Este proyecto está actualmente en desarrollo activo. Las siguientes versiones reciben actualizaciones de seguridad:

La seguridad de nuestro proyecto es importante para nosotros. Si descubres una vulnerabilidad de seguridad, te agradecemos que nos lo comuniques de manera responsable.

Por favor, NO reportes vulnerabilidades de seguridad a través de issues públicos de GitHub.

En su lugar, reporta las vulnerabilidades de seguridad a través de:

1. GitHub Security Advisories (método preferido):

   • Ve a la pestaña "Security" del repositorio
   • Haz clic en "Report a vulnerability"
   • Completa el formulario con los detalles

2. Email directo:

   • Envía un email a los mantenedores del proyecto
   • Incluye "SECURITY" en el asunto
   • Proporciona detalles completos del problema

Por favor, incluye la siguiente información en tu reporte:

• Tipo de vulnerabilidad (ej., buffer overflow, inyección, etc.)
• Ubicación del código fuente afectado (archivo y número de línea)
• Configuración especial requerida para reproducir el problema
• Pasos detallados para reproducir la vulnerabilidad
• Prueba de concepto o código de explotación (si es posible)
• Impacto del problema, incluyendo cómo un atacante podría explotarlo
• Versión afectada del software

Asunto: SECURITY - Buffer overflow en función FetchByte

Tipo: Buffer Overflow
Archivo: cpu.cpp, línea 123
Versión afectada: 0.1.0

Descripción:
La función FetchByte no valida correctamente los límites de memoria,
permitiendo leer fuera del rango de memoria asignado.

Pasos para reproducir:
1. Crear un objeto CPU y Mem
2. Configurar PC a 0xFFFF
3. Llamar a FetchByte()
4. Se produce una lectura fuera de límites

Impacto:
Puede permitir la lectura de memoria no autorizada y potencialmente
causar un crash del programa.

Sugerencia de solución:
Añadir validación de límites antes de acceder a la memoria.

Cuando reportes una vulnerabilidad:

1. Confirmación (24-48 horas):

   • Confirmaremos la recepción de tu reporte
   • Te proporcionaremos un timeline estimado para la investigación

2. Investigación (1-7 días):

   • Validaremos y reproduciremos la vulnerabilidad
   • Evaluaremos el impacto y severidad
   • Te mantendremos informado del progreso

3. Desarrollo de Parche (variable):

   • Desarrollaremos y probaremos una solución
   • Podemos solicitar tu ayuda para validar el fix

4. Divulgación (coordinada):

   • Publicaremos el parche en una nueva versión
   • Te acreditaremos en el security advisory (si lo deseas)
   • Publicaremos un CVE si es aplicable

• Intentamos resolver vulnerabilidades críticas en 7 días
• Vulnerabilidades de severidad media/alta en 30 días
• Vulnerabilidades de baja severidad en 90 días

Preferimos la divulgación coordinada:

• Te pedimos que mantengas la vulnerabilidad confidencial hasta que publiquemos un fix
• Una vez que el parche esté disponible, puedes divulgar públicamente
• Te notificaremos cuando sea seguro divulgar

Clasificamos las vulnerabilidades usando el sistema CVSS:

• Crítica (9.0-10.0): Explotable remotamente, sin autenticación, alto impacto
• Alta (7.0-8.9): Explotable con complejidad baja, impacto significativo
• Media (4.0-6.9): Requiere condiciones especiales, impacto moderado
• Baja (0.1-3.9): Difícil de explotar, impacto limitado

Actualmente no hay vulnerabilidades de seguridad conocidas en las versiones soportadas.

No hay vulnerabilidades reportadas o corregidas hasta la fecha.

Para usuarios del proyecto:

1. Mantén actualizado: Usa siempre la última versión
2. Valida entradas: Si cargas programas externos, valida los datos
3. Limita permisos: Ejecuta el emulador con los permisos mínimos necesarios
4. Monitorea recursos: El emulador no debería consumir recursos excesivos

Para desarrolladores:

1. Validación de límites: Siempre valida accesos a memoria
2. Manejo de errores: Implementa manejo robusto de errores
3. Code review: Revisa el código para vulnerabilidades comunes
4. Tests de seguridad: Incluye tests para casos edge y límites

• Vulnerabilidades en el código del emulador (cpu.cpp, mem.cpp)
• Problemas de memoria (buffer overflow, use-after-free)
• Problemas de lógica que permitan bypass de restricciones
• Vulnerabilidades en el sistema de build

• Vulnerabilidades en dependencias externas (reportar al proyecto upstream)
• Problemas en el código de ejemplo o tests
• Issues de usabilidad o bugs que no sean de seguridad
• Ataques de ingeniería social

Agradecemos a los siguientes investigadores de seguridad por sus contribuciones responsables:

(Ninguno aún - ¡sé el primero!)

• OWASP Top 10
• CWE - Common Weakness Enumeration
• CVE - Common Vulnerabilities and Exposures
• GitHub Security Best Practices

Para asuntos de seguridad urgentes, contacta directamente a los mantenedores del proyecto a través de GitHub.

Última actualización: 8 de Diciembre de 2024

¡Gracias por ayudar a mantener seguro el CPU 6502 Emulator!