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:

Kód: Vybrat vše

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:

Kód: Vybrat vše

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:
viewtopic.php?p=254451#p254451

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á.