IPv6 UKNOF43

pgb

Tak doufám že máte už všichni aktualizováno, je to hustý :). Předem všechny upozorňuji, kdo ten dokument nečetli a nezkoušeli, tak by tak měli učinit a postavit se k tomu. Předem říkám že nebudu psát postup, jak chybu replikovat, je to až komicky jednoduché a je to v originálním dokumentu od nálezce chyby. Provedl jsem nějaké testy na stole a drsný.

CVE-2018-19298 - chyba/vlastnost v Neighbour Solicitation

CVE-2018-19299 - IPv6 Route Cache issue

CVE-2018-19298 se mi daří replikovat bez problémů, pomůže na to firewall s na nové spojení za 1s

CVE-2018-19299 trochu problém opraven pomocí optimalizace velikosti routovací tabulky

TEST 1:

zapojení PC=>WAP1=>WAP2=>dst subnet /64

- data proudí z PC do cílové /64

- vygenerovaný datový tok 20Mbps

MK 6.40.8: wap1 down 10s (kernel reboot)

MK 6.44.2: wap1 ok, wap2 ipv6 down 10s, ipv4 ok (bez kernel reboot, pouze nedostupnost)

TEST 2:

zapojení PC=>CCR1=>CCR2=>dst subnet /64

- data proudí z PC do cílové /64

- vygenerovaný datový tok 20Mbps (edit: tady je vidět že CCR1 má dost výkonu a na CVE-2018-19299 bych ho musel zatížit více)

MK 6.44: CCR1 OK, CCR2 down IPv4 i IPv6 po 30s (bez kernel reboot, pouze nedostupnost)

MK 6.44.2 CCR1 OK, CCR2 IPv6 30% packetloss, IPv4 OK

MK 6.44.2 CCR1 OK, CCR2+firewall limit IPv6 a IPv4 OK

honzam

Už se to to dávno řeší zde na foru:

<--- l -->viewtopic.php?p=254451#p254451<--- l -->

nějaké čtení ohledně chyby zde:

https://indico.uknof.org.uk/event/46/co ... PROVED.pdf

pgb

Vím že se to řeší jinde, jen ty testy by tam hodně zapadly, takhle to třeba někoho donutí s tím u sebe něco dělat.

honzam

Vím že se to řeší jinde, jen ty testy by tam hodně zapadly, takhle to třeba někoho donutí s tím u sebe něco dělat.

Jasný, však v poho. Souhlasím s tím že více informací je lépe. Aspoň si toho nějaký admin všimne

ludvik

Počkej ... i autor exploitu uznal, že to mikrotik opravil. Dle tvých testů to nevypadá.

pgb

CVE-2018-19299 vypadá opravená - v reálu tam jde o to, že mk má staré jádro (3.3.5) a autor cve popisovat, že se tam používá jiná práce v ipv6 route cache nežli u moderních kernelů. Dříve tato chyba postihla jakýkoliv tranzitní router, kdy došlo k přetečení počtu záznamů v route chache (byl nastaven maximální počet záznamů, který se nevešel do paměti), po vyčerpání došlo k rebootu jádra. ====>>>> IPv4 route chache i IPv6 jsou nyní více oddělené a tranzitní problém již neshodí router, nicméně ho zatíží (dle zdrojů jaký má, defakto to je dos útok).

CVE-2018-19298 tady jsem trochu na rozpacích, obrana proti tomu je velmi jednoduchá, estab+related na koncovém routeru (nebo v případě otevřeného tranzitu pokud chcete odlehčit koncovému zákazníkoj limit na nová spojení). Jde tam o to, že se posláním ipv6 NS vyčerpá počet záznamů v ND. Nevím co s tím mk udělal. Ale ta tabulka zase dříve uměla přetýct. Dnes už je limitovaná a nezpůsobí kernel reboot. To že se vyčerpá to je hold fakt.

hapi

hodilo by se znát co znamená route cache.

pgb

The routing cache stores recently used routing entries in a fast and convenient hash lookup table, and is consulted before the routing tables. If the kernel finds a matching entry during route cache lookup, it will forward the packet immediately and stop traversing the routing tables.

pgb

Počkej ... i autor exploitu uznal, že to mikrotik opravil. Dle tvých testů to nevypadá.

TEST 6.44.2 PC=>HEXPOE1=>HEXPOE2=>cílová /64

no nevím co jsi četl ty, ale já jsem četl že je fajn, že to alespoň nesejme celý router (ale musí mít dost paměti - nad 200MB)

pro ostatní mohu potvrdit, že stejně jako příspěvek od maznu jsem teď donutil restartovat HEXPOE2 u CVE-2018-19298

https://forum.mikrotik.com/viewtopic.php?f=2&t=147048&start=150#p724993

ludvik

MK 6.44.2: wap1 ok, wap2 ipv6 down 10s, ipv4 ok (bez kernel reboot, pouze nedostupnost)

MK 6.44.2 CCR1 OK, CCR2 IPv6 30% packetloss, IPv4 OK

to mi právě jako OK moc nepřišlo.

pgb

Tomu CCR2 se ucpává právě ta ND tabulka (firewall to vyřeší), ale opravené na tom je to, že už se to nerestartuje a ipv4 nepadá.