Spekulációk egy feltételezett TCP DoS sebezhetőségről

Titkosítás, biztonság, privát szféra

Robert E. Lee és Jack C. Louis állítása szerint egy olyan lehetséges tervezési problémát fedeztek fel a TCP-ben, amelyet kihasználva bármely internetre kapcsolt szerver elérhetetlenné tehető. A felfedezők a Unicorn Scan eszköz tesztelése során bukkantak a problémára. A "TCP sockstress vulnerability" és "TCP state table manipulation vulnerability" néven is futó sebezhetőségről egyelőre nem érhetők el technikai részletek. A részletes információk valószínűleg a T2´08 Information Security Conference rendezvényen válnak majd publikussá. Bővebben itt és itt.

( cstamas | 2008. 10. 05., v – 20:07 )

Nekem kezdenek gyanusak lenni ezek. Csinaljak a hype-ot ahelyett, hogy megmondanak, hogy mire gondolnak.

( bitumen | 2008. 10. 05., v – 21:03 )

Nehéz elhinni, h egy 29 éves eljárás, ami gyakorlatilag minden számítógépen megtalálható buggy legyen...

Hat ezabaj =)

Amugy meg... Nem olyan nehez azt felfogni... Mert vegulis ez nagyon alap... Marmint egy szimpla mindeki altal hasznalt alkalmazast tobb szazezren debuggoljak, meg keresik atamadhatosagat, mig egy TCP-nek ki a **** keresne 2008-ban a hibait, hisz mar egy joideje nincs hibaja... Meg van akiben fel se merul, hogy abban lehet hiba... Es azert az a bazis aki ilyen alapszinten is keresi a hibakat az nagysagrendekkel kisebb tabort fonultat fel, mint az elozo...
Amugy meg en azert erzek benne valami Tulzast... Marmint... Szep es jo, de mint ahogy volt a pelda a DNS-es dolog anno... Persze persze eszelyes, meg minden, de sokkal nagyobb feneket kapott, mint amennyit ert valojaban...
--
by lightgod

( yeo | 2008. 10. 05., v – 23:41 )

kiváncsi vagyok hogy mennyire találtak újdonságot, ez amit eddig publikáltak meg a beszélgetésben elhangzik bennem rég ismert bajokat sejtettnek fel, több publikáció és PoC volt rá 2000 tájékán.

Fyodor is ( nmap ) írt róla egy érdekes elemzést a múlthéten.
A lényeg hogy bizonyos módszerekkel fellehet zabálni a célpont erőforrásait ( buffer, kernel timer, etc ) és ezek régóta ismert alap problémák

küldesz egy raw SYN packetet a célpont felé userlandből, a cél válaszól egy SYN/ACK-el, nos mivel raw packetot küldtél el userlandből ezért az OS nemfogja érteni a SYN/ACKet így RST packetel válasszól, viszont ezt a RST packetet nemengeded ki ( tűzfal ), helyette generálsz egy ACK packetet a meglévő infokból, SYN + SYN/ACK (ISN) packet rendelkezésre áll, ezáltal totál legítim ACKet lehet visszaküldeni.

Nos innentől a kapcsolat validálva lett, és a cél OS már allokálja is neki az erőforrásokat, state bejegyzés stb ahogy kell.

Ezt még lehet fokozni, pl ha web szerver a célpont, olyan packetokat generálsz hogy pl file-t kérsz a servertől, természetesen ekkor ennek is erőforrásokat allokál a cél( bekerül a bufferbe az éppen átvitelre váró darab ) ezeket is elutasitod, ígyhát nemtudja felszabaditani megintcsak az erőforrásokat , valamit belekezd az újraküldésbe ((re-transmit)éljen a TCP ), milliónyi lehetőség.

Egy mai komolyabb tűzfallal sikeresen fel lehet venni a harcot: network quota, syndefender, re-transmit watcher etc

Fyodor írása:
http://insecure.org/stf/tcp-dos-attack-explained.html

régi hasznos infok:

http://seclists.org/bugtraq/2000/Apr/0152.html

http://www.security-express.com/archives/win2ksecadvice/2000-q4/0105.ht…

illetve TCP/IP rfc + doksik :-)

mindemellett meglátjuk hogy tényleg mire jutottak mit találtak...

Hat en meg soha nem implementaltam TCP/IP stacket, de en ezt ugy kepzelem el hogy ha kifogyok az eroforrasokbol, akkor nem engedek uj kapcsolatot nyitni, vagy esetleg eldobalom a mar meglevoket. Innentol mar csak implementacio kerdese a DOS elleni vedekezes, de olyan exploit ami mindenhol mukodik haaat...

Ha szigorúan veszed, akkor tényleg nem...
Viszont lehet egy felső korlátot szabni, (amihez próbálsz igazodni erőforrások terén,) amire azt tudod mondani, hogy azzal 5 9-es szolgáltatást tudsz nyújtani... (99,999%)
Ez egy előkészítő tervezés, és valahol védekezés is DoS ellen.
Persze ahogy közeledsz a korlát felé, úgy lesz lassabb/megbízhatatlanabb a szolgáltatásod.

--
Debian Linux rulez... :D