classic.ISPforum.cz

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:


TEST 2:

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

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.

pgb píše: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

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

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.

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

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.

ludvik píše: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

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.

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