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

Apple

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

( Pitta | 2008. 08. 02., szo – 10:22 )

sudo tcpdump | grep domain

looool

#toy like ppl make me boy like

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

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

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

( bra | 2008. 08. 02., szo – 11:11 )

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

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. :)"

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

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:"

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

( vinnui | 2008. 08. 02., szo – 11:17 )

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