Még mindig nem oldotta meg teljesen az Apple a DNS problémát

 ( trey | 2008. augusztus 2., szombat - 9:45 )

Biztonsággal foglalkozó blogok arról számolnak be, hogy noha az Apple tegnapelőtt a Security Update 2008-005 javítással orvosolta a Mac OS X Server DNS problémáját, a klienseken a megfelelő javítás elmaradt. Több szakember is észlelte, hogy a Mac OS X klienseken a DNS kliens library "elfelejti" randomizálni a forrás portot, így - ha kis mértékben is - de továbbra is számolni kell OS X klienseken a problémával.

A TidBITS szerint a kihasználás "látszólag rendkívül valószínűtlen, de nem tudjuk, hogy mennyire valószínűtlen, amíg a biztonsági szakértő Dan Kaminsky, a probléma felfedezője, teljes felvilágosítást nem ad 2008. augusztus 6-án a Black Hat konferencián tartnadó Black Ops 2008: Its (sic) the End of the Cache as We Know It beszédében".

Andrew Storms a 360° Security-től összehasonlított egy FreeBSD 6.3 és egy OS X 10.4.11 rendszert:

FreeBSD 6.3

    08:49:58.405934 IP [BSD].64328 > [SERVER].domain: 39741+ A? www.yahoo.com. (34)
    08:50:02.708123 IP [BSD].51023 > [SERVER].domain: 45758+ A? www.yahooooo.com. (35)
    08:50:07.625034 IP [BSD].50648 > [SERVER].domain: 23806+ A? www.www.net. (29)


OSX 10.4.11

    08:05:47.741385 IP [OSX].49193 >[SERVER].domain: 55613+ A? www.cnn.com. (29)
    08:05:48.207547 IP [OSX].49194 >[SERVER].domain: 1106+ PTR? 21.91.236.64.in-addr.arpa. (43)
    08:05:51.717245 IP [OSX].49195 >[SERVER].domain: 27650+ A? www.cnn.com. (29)

Jól látható, hogy míg a FreeBSD minden egyes kérésnél randomizálja a forrásportot, addig az OS X csak egyesével növeli azt.

A tesztet bárki elvégezheti rendszerén az alábbi módon:

Nyit egy konzolt, majd tcpdump segítségével figyeli a forgalmat, miközben egy másikon pingel egy hostot:

sudo tcpdump | grep domain 
ping hup.hu

A tcpdump kimenetén randomizált portokat kell látnunk.

Referenciák:
Apple's Security Update 2008-005: DNS workaround finally included
DNS Clients Have Small Vector of Risk after Patch
Apple DNS Patch Fails To Randomize - Users Still At Risk

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

sudo tcpdump | grep domain

looool

#toy like ppl make me boy like

tcpdump 'port 53'
ez igy jobb lesz :D

Így szerepel a hivatkozott cikkben. Egyébként mi a probléma vele?

--
trey @ gépház

Nem elegáns. Az elegáns:

sudo tcpdump -ni wlan0 udp and dst port 53

"Nem elegáns."

Na ez az a dolog, ami speciel engem sohasem tudott igazán érdekelni. Vi helyett is vígan használok "mcedit"-et, ha lehetőségem van rá. Tudom, bújjak el.

--
trey @ gépház

Bezzeg ha valaki nem használ behúzásokat, vagy nem úgy ahogy megszoktad, átláthatatlan a kódja.

Ja és a bash-t szeretem. Shame on me. :))

--
trey @ gépház

A behúzásra visszatérve, személy szerint átestem a ló túloldalára. http://en.wikipedia.org/wiki/Haml
Szárazabb, biztonságosabb érzés, kevesebb ínhüvely gyullad.
Úgyhogy olykor hasznos ám a kritika. :)

Ne haragudj, de így szombat délelőtt nem fogok 4 wikipédia oldalt elolvasni, hogy rájöjjek mire is célzol. Esetleg 3-4 szóba összefoglalod? Ebben a melegben nem esik le :)

--
trey @ gépház

Behúzással struktúrált absztrakciós nyelv, html kód generálásához, a tagok egymásba ágyazását a behúzás határozza meg, nem kell vesződni a tagok lezárásával. Olyasmi a HTML-hez képest mint a YAML / JSON viszonya az XML-lel.

És ez hogy kapcsolódik ide?

--
trey @ gépház

Ha anno nem írod egy blogbejegyzésemre hogy a kódom átláthatatlan a behúzások hiánya miatt (kvázi nem elegáns), most nem használnék haml-t.

Ebben a melegben csak a sör esik le^Wjól. :)

--
Ruby takes the elegance and simplicity of Perl, and mixes it with the library support of Lisp.

Tapasztalataim szerint a tcpdump grep paros kicsit lassab(talan vmi buffereles miatt a kiirasnal)

Szintén nem érdekel. Ha kiiratom a képernyőre akkor látni akarom nem? Lehet, hogy még így is gyors. Ha nem akarom látni, akkor majd file-ba iratom. A grep egy univerzális eszköz, cserébe mindenhez használható. Nem fogom kismillió program obscure kapcsolóját fejből megtanulni, csak azért, hogy elegáns legyek.

--
trey @ gépház

Szerintem félreérted. Úgy érti a lassúságot, hogy a második pipe után már a bufferelés miatt nem azonnal jelenik meg az utolsó kimeneten, ami a bemeneten bemegy.

Itt konkértan egy darab grep volt a példában, mégis meg lett "looool"-ozva. Elolvastam az eredeti cikket, ahol ez szerepelt, nekem nem volt vele semmi bajom. Ezért kérdeztem meg, hogy itt az _egy darab_ grep-re, miért a "looool", hátha tanulok valamit. Egyelőre csak annyi van, hogy nem elegáns. Magyarul nem elegáns a "grep" használata egyáltalán? Vagy csak nem elegáns a "grep" használata a "tcpdump" paranccsal? Szívesen tanulok minden nap valami újat, ha annak van értelme.

--
trey @ gépház

Ebből még én is tanultam valamit. Anno a css elterjedésekor voltak akik mezei táblázatokat is div-ekkel akartak megjeleníteni. Valami beteges tábla-fóbia miatt ott sem akarták használni a táblázatokat ahol logikus lett volna. Agyrém. Szelektálni kell tudni. Bo selecta!

Noha nem én mondtam, hogy LOL, de igyekszem megmagyarázni azt, hogy miért szóltam hozzá. Már ha már így rákérdeztél. Nálam egyáltalán nem működik az eredeti cikk írója által készített parancssor, mert nem adta meg a tcpdump-nak a -i paramétert, és itt épp nem a legkisebb felkonfigurált NIC-et használom (alapbeállított Ubuntu Hardy egy notebook-on, amiben van ethernet csati, de én wifi-zek). Másrészt ha a tcpdump-nak nem adod meg a -n paramétert, akkor mindent megpróbál feloldani (neveket, portokat, protokollokat...), ami néhány ip esetében igen kínosan hosszú lehet. A harmadik érvet implicit módon már leírtam: egy pipe-pal nincs baj, csak ha valaki mindenhol ezt szokja meg, úgy, hogy nem érti pontosan (és itt természetesen nem rád gondolok), akkor természetesen rakja össze a sok pipe-ot, ami offline bemenetnél teljesen jó, de ha folyamatosan jönnek az adatok (mint például a tcpdump-ból vagy "tail -f"-ből), akkor nem fog jól működni. És ilyenkor az ilyen ember nem érti, hogy mi az oka a nem működésnek. Ezért írtam le.

Nem is veled van a gond. Te nyilván tudod, hogy a feladat úgy kívánja, akkor nem használsz pipe-okat. (Mellesleg a szövegszerkesztők meg tényleg csak vallási kérdés.) Csak az a baj, hogy a sok wannabe megszokja a folyamatos pipe-okat, aztán nem érti, hogy ez miért piszok lassú (pontosabban nem azonnal mutatja, amit akarunk):

tail -f /var/log/messages | grep slapd | grep -v ADD

annyit én is hozzátennék, hogy ha nem adsz meg a tcpdumpnak egy -n-et, akkor szokott reverse dnst futtatni a címekre, amiatt pedig elég lassú... szóval nem az "elegancia", hanem a türelemnek a próbára tétele...

de éljen a mcedit, én is "vígan használom" :)

mcedit +1
-----
“Firefox, you say? No I don't play Pokémon”

Na, az OSX már előrébb jár, mint a népszerű Linux disztribúciók:
11:07:27.140846 IP 172.16.1.115.57718 > 172.16.1.55.53: 1793+ A? www.elte.hu. (29)
11:07:32.004622 IP 172.16.1.115.57718 > 172.16.1.55.53: 11126+ A? www.elte.hu. (29)
11:07:36.100758 IP 172.16.1.115.57718 > 172.16.1.55.53: 41612+ A? www.elte.hu. (29)
cat /etc/debian_version
4.0

Egyébként nagyon kevesen lehetnek olyanok, akiknek ez biztonsági kockázatot jelent.

Egy népszerű Linux disztribúciót használok:

10:41:31.784525 IP 192.168.100.252.50071 > resolver1.opendns.com.domain: 18230+ PTR?
10:41:36.841339 IP 192.168.100.252.49199 > resolver1.opendns.com.domain: 16587+ PTR?
10:41:36.889354 IP 192.168.100.252.42841 > resolver1.opendns.com.domain: 46475+ PTR?
10:41:41.942238 IP 192.168.100.252.55171 > resolver1.opendns.com.domain: 46313+ PTR?

trey@alderaan:~$ cat /etc/debian_version
lenny/sid

Mögöttem jár.

"Egyébként nagyon kevesen lehetnek olyanok, akiknek ez biztonsági kockázatot jelent."

Nem is arról szól ez, hanem arról, hogy megint szar munkát végeztek az Apple-nél. Ha már patch-eltek (kb. egy hónappal a többiek után, akkor igazán megcsinálhatták volna normálisan.)

--
trey @ gépház

Mármint, hogy mi van a /etc/resolv.conf-ban?

OpenDNS. Miért?

--
trey @ gépház

Mert ha nem saját gépeden futó névszervert használsz a Debianban a hiba még fenn kell, hogy álljon (a linkelt DSA és a tapasztalat szerint is).

Lehet, hogy a resolvered neked is hibás, csak frissebb kerneled van, ami elintézi a forrásport véletlenszerűsítését...

Milyen kernelt használsz? (verzió, vendor, vagy saját)

Ezek szerint aki legalább 2.6.24-et, annak a kernel elintézi (már persze ha az alkalmazás nem választ maga):
http://lwn.net/Articles/289206/

"Lehet, hogy a resolvered neked is hibás, csak frissebb kerneled van, ami elintézi a forrásport véletlenszerűsítését..."

Nekem tök minden mi intézi el, a lényeg, hogy az OS vendorom látszólag megoldotta a problémát :)

"Milyen kernelt használsz? (verzió, vendor, vagy saját)"

2.6.24-es (2.6.24-19-generic), vendor.

--
trey @ gépház

Inkább a kernel írói, meg a véletlen. :)

Azért vannak még páran, akiket az Apple szó helyett lehetne szerepeltetni a címben:
http://en.wikipedia.org/wiki/Comparison_of_Linux_distributions#Technical

Ha jól látom, a góbó nem érintett :-D


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

"Inkább a kernel írói, meg a véletlen. :)"

Nekem mindegy, hogy ki, a lényeg, hogy meg van oldva.

"Azért vannak még páran, akiket az Apple szó helyett lehetne szerepeltetni a címben:
http://en.wikipedia.org/wiki/Comparison_of_Linux_distributions#Technical"

Keress róla cikket a neten, belinkeljük azt is. :)

--
trey @ gépház

Erre a hype-ra már egy külön site-ot kellene nyitni.

misi@ftp:~$ cat /etc/resolv.conf
nameserver 212.24.164.1
nameserver 12.24.160.1
misi@ftp:~$ uname -a
Linux ftp 2.6.24-etchnhalf.1-686 #1 SMP Mon Jul 21 11:17:43 UTC 2008 i686 GNU/Linux

Akkor biztos a kernel intézi el.

Érdekes, nekem random debian 4.0 alatt.

Már a debian és a debian sem egyforma? :)

Nem felejtettél el frissíteni? :)

--
trey @ gépház

Nem.

http://www.debian.org/security/2008/dsa-1605
"At this time, it is not possible to implement the recommended countermeasures in the GNU libc stub resolver. The following workarounds are available:
1. Install a local BIND 9 resolver on the host, possibly in forward-only mode. BIND 9 will then use source port randomization when sending queries over the network. (Other caching resolvers can be used instead.)

2. Rely on IP address spoofing protection if available. Successful attacks must spoof the address of one of the resolvers, which may not be possible if the network is guarded properly against IP spoofing attacks (both from internal and external sources).
This DSA will be updated when patches for hardening the stub resolver are available.
Fixed in:"

cat /etc/resolv.conf

Nem nyert.

Szintén debian etch 4.0

19:13:10.268453 *.46717 > ns.datanet.hu.domain:  3071+ PTR? * (42)
19:13:11.269266 *.36103 > ns.datanet.hu.domain:  51788+ PTR? * (42)
19:13:12.272548 *.37917 > ns.datanet.hu.domain:  34497+ PTR? * (42)
19:13:13.273352 *.35080 > ns.datanet.hu.domain:  1807+ PTR? * (42)
19:13:14.273322 *.59858 > ns.datanet.hu.domain:  35197+ PTR?  * (42)

Lehet, hogy a hiba az ön készülékében van.

ja most olvasok lejjebb. 2.6.25.11 alapú mérsékelt gányolós kernel van.

Egyébként meg 4.0 hoz van "gyári" etch and half 2.6.24es kernel.

--------------------

r=1 vagyok, de ugatok...

Az enyémben ugyan nincs, az a Debian nem az én készülékem. :)

Kipróbáltam, Leopard alatt minden DNS lekérdezésnél 1-el nő a forrásport.

Ez a probléma. Random != inkrementált.

--
trey @ gépház

Lehet hogy random inkrementált. (Véletlenül mindig eggyel növeli.)

LOL! :)