[lacnog] CVE-2018-19298 Mikrotik Neighbor Discovery Protocol memory exhaustion

Mie Abr 3 19:06:08 -03 2019

Hola, Uesley,

No coincido con algunas cosas:

* Sobre si IPv6 es mas o menos seguro que IPv4, ver pregunta 1.1 de
https://www.internetsociety.org/deploy360/ipv6/security/faq/

* EL argumento de la seguridad no es una "excusa". En muchos entornos,
si Ud. llega a sufrir un ataque, seguramente alguien le pregunte: era
realmente indispensable tener eso habilitado, y demás? -- REspuestas
tales como "no, no lo era... pero queria ser un buen ciudadanos de la
Internet" suelen encontrarse no satisfactorias.

En lo que respecta a la madurez de las implementaciones, la madurez de
las implementaciones de IPv6 es equivalente a la madureza de las
implementaciones de IPv4 en los años '90.

* En materia de culpas, claro que las hay -- sin embargo, la culpa no
es de los operadores. El diseño tiene una cantidad de cosas
cuestionables. Y el no-despliegue fue predicho en su momento:
https://www.rfc-editor.org/rfc/rfc1669.txt

* EL primer paso para resolver un problema es aceptar que existe un
problema. EN torno a IPv6 siempre se ha hecho lo opuesto: marketing
descarado sin fundamento tecnico alguno. Toda la mitologia creada sobre
"los beneficios de IPv6" no ha hecho otra cosa que entorpecer el
progreso, el despliegue, y la evolucion de IPv6.

EL ultimo eslabon ha sido la elevacion de IPv6 a categoria de full
standard, como "señal politica" de IETF a la comunidad...  Sin embargo,
si alguno mirara en detalle los requisitos para que una especificacion
sea elevada a estandar, le costaria (bastante) explicar como es que la
especificacion de IPv6 fue elevada a estandar. -- curiosidad mediante,
el "estandar" publicado tiene completamente mal la parte de
fragmentacion, por lo cual el documento en cuestion ya cuenta con
erratas: https://www.rfc-editor.org/errata_search.php?rfc=8200

* El despliegue de IPv6 no es la lucha contra el hambre en el mundo, ni
una lucha por los derechos humanos, ni nada eso: es un hecho economico.
El que no lo desplego es porque, en base a su analisis (o por omision),
no le resulto necesario para hacer dinero,

https://www.youtube.com/watch?v=dpmAY059TTY

Saludos cordiales,
Fernando

On 1/4/19 13:11, Uesley Correa wrote:
> Estimado Ariel, como te vas?
> 
> En realidad es muy complejo este tema. Incluso veo algunos que no
> hicieron su despliegue utilizando sucesos así como escusa, diciendo
> hasta mismo que se trata de un protocolo inseguro. Estoy de acuerdo con
> todo que usted he dicho y añado: no es culpa del IPv6 todos eses
> sucesos. Solo nosotros tenemos la culpa por demasiado tarde empezar el
> despliegue. Quizás tuviéramos comenzado a la fecha correcta, dichos
> problemas ya estarían resueltos y estaríamos hoy con menos problemas en
> el protocolo que ya es el estándar de internet. Entonces, más allá de no
> bajar su IPv6 (el amigo Rubens envió una nueva versión, todavía beta más
> que debemos aguardar el investigador probar) debemos adelantar el
> despliegue para que adelantemos posibles problemas y soluciones.
> 
> Saludos cordiales,
> 
> Uesley Corrêa
> 
> PS.: cuando digo nosotros, me incluyo aunque haga siempre el máximo para
> el despliegue del protocolo.
> 
> On Mon, Apr 1, 2019, 04:17 Rubens Kuhl <rubensk en gmail.com
> <mailto:rubensk en gmail.com>> wrote:
> 
> 
>     Mikrotik has now disclosed itself what the bugs are:
>     https://forum.mikrotik.com/viewtopic.php?p=724264#p724238
> 
>     "There were two IPv6 related issues resolved in this version:
>     1) IPv6 packet forwarding might get stuck (due to IPv6 route cache
>     processing) that could lead to Watchdog reboot;
>     2) IPv6 neighbor table processing might get stuck (due to large
>     neighbor table) that could lead to Watchdog reboot.
> 
>     Seems that one of these was considered as CVE and another one was
>     not. Since author of these CVEs still has a problem, seems that
>     actually #1 was not included in this CVE. However, this "problem"
>     actually is not much of an issue. RouterOS IPv6 route cache max size
>     by default is 1 million. If you try to reach 1 million hosts in your
>     network, route cache grows and can take up to 500 MB. If you have
>     device that does not have such resources, it will reboot itself. If
>     router has, for example, 1 GB of RAM - there is no problem. We will
>     most likely allow to change cache size or will decide its size based
>     on RAM size. However, it can not be considered as a bug or
>     vulnerability. You make router work and then complain that resources
>     are required to do the job. This is not a bug."
> 
>     And launched a new beta version to address them:
> 
>     https://mikrotik.com/download/changelogs/testing-release-tree
> 
>     What's new in 6.45beta23 (2019-Apr-01 05:51):
> 
>     MAJOR CHANGES IN v6.45:
>     ----------------------
>     !) ipv6 - fixed soft lockup when forwarding IPv6 packets;
>     !) ipv6 - fixed soft lockup when processing large IPv6 Neighbor table;
>     ---------------------- 
> 
>     Changes in this release:
> 
>     *) ipsec - properly drop already established tunnel when address
>     change detected;
>     *) ipv6 - adjust IPv6 route cache max size based on total RAM memory;
>     *) smb - fixed possible buffer overflow;
> 
> 
> 
>     On Mon, Apr 1, 2019 at 4:49 AM Ariel Weher <ariel en weher.net
>     <mailto:ariel en weher.net>> wrote:
> 
>         Estimados amigos:
> 
>         Se encuentra circulando en internet información relacionada a una
>         vulnerabilidad relacionada con los sistemas Mikrotik que tienen
>         configurado IPv6.
> 
>         Aparentemente el investigador Marek Isalski asegura que puede
>         consumir
>         el total de la memoria de cualquier equipo Mikrotik (y forzar su
>         reinicio) con solo enviar paquetes mal formados a cualquier
>         interface
>         que cuente con direccionamiento IPv6.
> 
>         Aparentemente el investigador hizo una demo del ataque:
>         https://youtu.be/TzC-JVjMK8k
> 
>         Varios sitios que tratan el problema piden que se deshabite el
>         protocolo IPv6 para solucionar esta falla de seguridad.
> 
>         Los detalles de la vulnerabilidad aún no son públicos. El
>         investigador
>         asegura que los va a volver públicos en el evento UKNOF43 el día
>         9 de
>         Abril de 2019.
> 
>         Mientras tanto:
> 
>         * POR FAVOR NO APAGAR EL PROTOCOLO IPv6 *
> 
>         Esto podría ser corregido por el equipo que desarrolla RouterOS
>         antes
>         de la fecha mencionada, o bien podría ser remediado con alguna otra
>         medida al momento de conocerse los detalles de la vulnerabilidad.
> 
>         Es muy importante estar informado acerca de los nuevos releases de
>         software y de los detalles de este caso antes de tomar cualquier
>         medida extrema.
> 
>         Saludos!
>         _______________________________________________
>         LACNOG mailing list
>         LACNOG en lacnic.net <mailto:LACNOG en lacnic.net>
>         https://mail.lacnic.net/mailman/listinfo/lacnog
>         Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
> 
>     _______________________________________________
>     LACNOG mailing list
>     LACNOG en lacnic.net <mailto:LACNOG en lacnic.net>
>     https://mail.lacnic.net/mailman/listinfo/lacnog
>     Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
> 
> 
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
> 

-- 
Fernando Gont
SI6 Networks
e-mail: fgont en si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492