GitHub ha publicado una serie de cambios en las reglas, definiendo principalmente la política con respecto a la ubicación de exploits y los resultados de la investigación de malware, así como el cumplimiento de la actual Ley de derechos de autor de EE. UU.
En la publicación de las nuevas actualizaciones de las políticas, mencionan que stas se centran en la diferencia entre contenido activamente dañino, que no está permitido en la plataforma y código en reposo en apoyo de la investigación de seguridad, que es bienvenido y recomendado.
Estas actualizaciones también se centran en eliminar la ambigüedad en la forma en que usamos términos como «exploit», «malware» y «entrega» para promover la claridad de nuestras expectativas e intenciones. Hemos abierto una solicitud de extracción para comentarios públicos e invitamos a los investigadores y desarrolladores de seguridad a colaborar con nosotros en estas aclaraciones y ayudarnos a comprender mejor las necesidades de la comunidad.
Dentro de los cambios que podremos encontrar, se han agregado las siguientes condiciones a las reglas de cumplimiento de la DMCA, además de la prohibición de distribución previamente presente y garantizar la instalación o entrega de malware y exploits activos:
Prohibición explícita de colocar tecnologías en el repositorio para eludir los medios técnicos de protección de los derechos de autor, incluidas las claves de licencia, así como los programas para generar claves, omitir la verificación de claves y extender el período libre de trabajo.
Sobre ello se menciona que se está introduciendo el procedimiento para presentar una solicitud de eliminación de dicho código. El solicitante de la eliminación debe proporcionar detalles técnicos, con la intención declarada de enviar la solicitud para su examen antes del bloqueo.
Al bloquear el repositorio, prometen proporcionar la capacidad de exportar problemas y relaciones públicas, y ofrecer servicios legales.
Los cambios en la política de exploits y malware reflejan críticas tras la eliminación por parte de Microsoft de un prototipo de exploit de Microsoft Exchange utilizado para llevar a cabo ataques. Las nuevas reglas intentan separar explícitamente el contenido peligroso utilizado para llevar a cabo ataques activos del código que acompaña a la investigación de seguridad. Cambios realizados:
Está prohibido no solo atacar a los usuarios de GitHub publicando contenido con exploits o usar GitHub como vehículo de entrega de exploits, como estaba antes, sino también publicar código malicioso y exploits que acompañan a los ataques activos. En general, no está prohibido publicar ejemplos de exploits elaborados en el transcurso de estudios de seguridad y que afecten a vulnerabilidades ya solucionadas, pero todo dependerá de cómo se interprete el término «ataques activos».
Por ejemplo, la publicación en cualquier forma de código fuente de JavaScript que ataca al navegador cae bajo este criterio: el atacante no evita que el atacante descargue el código fuente en el navegador de la víctima mediante la búsqueda, parcheando automáticamente si el prototipo de exploit se publica en una forma inutilizable, y ejecutándolo.
Lo mismo ocurre con cualquier otro código, por ejemplo, en C++: nada impide que se compile y ejecute en la máquina atacada. Si se encuentra un repositorio con dicho código, se planea no eliminarlo, sino cerrar el acceso a él.
Además de ello se agregó:
- Una cláusula que explica la posibilidad de presentar un recurso en caso de desacuerdo con el bloqueo.
- Un requisito para los propietarios de repositorios que alojan contenido potencialmente peligroso como parte de la investigación de seguridad. La presencia de dicho contenido debe mencionarse explícitamente al principio del archivo README.md, y los detalles de contacto para la comunicación deben proporcionarse en el archivo SECURITY.md.
Se afirma que, en general, GitHub no elimina los exploits publicados junto con los estudios de seguridad para las vulnerabilidades ya divulgadas (no el día 0), pero se reserva la capacidad de restringir el acceso si considera que aún existe el riesgo de usar estos exploits para ataques reales y en el servicio El soporte de GitHub ha recibido quejas sobre el uso de código para ataques.
Los cambios aún se encuentran en estado borrador, disponibles para discusión durante 30 días.
Fuente: https://github.blog/