FreeBSD biztonsági figyelmeztetések

FreeBSD

A FreeBSD biztonsági csapat az alábbi FreeBSD Security Advisory-kat (SA) adta ki:

FreeBSD-SA-08:03.sendfile - sendfile(2) write-only file permission bypass (összes támogatott FreeBSD verzió)
FreeBSD-SA-08:04.ipsec - IPsec null pointer dereference panic (FreeBSD 5.5)

( pinyo_villany | 2008. 02. 16., szo – 13:34 )

hmmm, akkor mostanában nem csak a linux-ban találnak súlyos biztonsági hibákat...
lehet, hogy a linux-os eset után elkezdték ők is átnézni a kódokat

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.18-opt2

Aki azt hiszi, hogy a BSD-kben nincsenek problémák, az álomvilágban él. A különbség: ember nincs annyi aki auditálja a kódot, felhasználó nincs annyi, aki a problémákat jelentse és a kihasználásukhoz nem készül annyi exploit, mert az ezzel foglalkozóknak nem fűződik annyi érdeke az exploit megírásához (anyagilag nem jár olyan jól ha eladja). Továbbá, ha probléma van velük, a sajtó 100-ad annyit nem foglalkozik vele, mint egy Linux problémával, ami már a mainstream sajtóban is hír.

--
trey @ gépház

Az nem csak BSD-knél van, sajnos. Mindenhol söprik a szart a szönyeg alá.

Másrészt viszont a felsoroláshoz érdemes azt is hozzávenni, hogy a BSD-ket nem olyan rohanó tempóban és észnélkül fejlesztik, amely szintén közre játszhat abban, hogy kevesebb hibát találnak bennük.

Hát a Solaris-t sem mondhatnám, hogy lóhalálában fejlesztik, mégis megesik ilyen baleset. De nyilván tudok linkelni HP-UX-ot, AIX-et is. A kihasználhatóság szempontjából pedig csont mindegy, hogy a kernelben, vagy máshol, a rendszerrel együtt szállított komponensben van a hiba.

--
trey @ gépház

2006. októberinél találhattál volna azért frissebbet is. :)
Nyilván mindenben van hiba, csak azok mennyisége és minősége nem mindegy. Egyébként épp a mai nap jött ki új kernel az agyontesztelt és auditált, ultrastable 2.4-es ágból is, ráadásul 1-2 nevetséges security hiba javításával.

"2006. októberinél találhattál volna azért frissebbet is. :)"

Szerintem ha akartam volna nagyon keresni, akkor tudtam volna, mert annak idején amikor elfelejtettem a root jelszavam egy Solaris boxon kb. 5 perc alatt találtam a Google-ben működő local root-ot hozzá amivel át tudtam írni a root jelszót. ;)

"Egyébként épp a mai nap jött ki új kernel az agyontesztelt és auditált, ultrastable 2.4-es ágból is, ráadásul 1-2 nevetséges security hiba javításával."

Ezt mondd Oscon-nal, aki hiszi, hogy azok jobb idők voltak. 2.0, 2.2, 2.4, 2.6. Szar mindegyik :))

--
trey @ gépház

Függetlenül attól, hogy értelemszerűen nem csak a Linuxban vannak programozási hibák: a fenti két lyukat én sokkal kevésbé érzem súlyosnak (súlyos alatt a következményeket és az érintett userek számát értem), mint azt a linuxosat, amire te célzol.

A második mondat felvetése sem hiszem, hogy megállná a helyét.

Esetleg vizsgáljuk meg ezt és gondolkozzunk el rajta, hogy mi lenne ha rászívódnának az exploit írók. De nem szívódnak, mert sokkal populárisabb OS-ekkel foglalkoznak, amik több pénzt hoznak. Lásd: 3com Zero Day Initiative és társai, akiknek egy 0day Windows vagy Linux exploit valószínűleg nagyságrendekkel többet ér, mint egy OpenBSD, NetBSD vagy FreeBSD exploit.

--
trey @ gépház

Nem tudom mi lenne. Semmi. :)
Így hirtelen nem jut eszembe olyan program, amelyik user input alapján próbál sztring formájú IP címet (195.228.252.138) konvertálni binárisba (0xC3E4FC8A) ellenőrzés nélkül (és némi ellenőrzés adott esetben még az ezt használó, hívó libc-s függvényekben is van/lehet, nem csak a 3rd party programokban), rootként.

Két dolog miatt sem értem, hogy ez hogy kerül ide:
- önmagában privilégium emelésre nem jó (és nem is a kernelben van)
- a hiba nem FreeBSD specifikus, a BIND resolverében is megtalálható (mintha emiatt nem is adtak volna ki új verziót, biztos ők is ennyire súlyosnak ítélték :), illetve maga a kód valamikori leágazása szerintem része a GNU libc-nek is (más kérdés, hogy erről nem írtál cikket, tehát feltételezem ők már évekkel ezelőtt kijavították :)

Ja, biztos többet ér. De akkor ezzel mit is mondtál? Érdemesebb periférikus OS-eket használni, mert arra nem cuppannak rá az exploitírók?
OK. :)

"- önmagában privilégium emelésre nem jó"

Szerintem nem ez határozza meg egy hiba súlyosságát. A mai világban már nem arra játszanak, hogy helyi root jogokat szerezzenek, hanem arra, hogy távoli hozzáférést a rendszerhez. Spam botnetekben van a nagy pénz, nem abban, hogy képernyőmentést csináljanak a "pwned" rendszerről és feltolják a netre. Biztos, hogy nagy probléma a local root sebezhetőség (főleg haveri társaságban üzemeltetett eggdrop szervereknél ahova accountja van boldog-boldogtalannak), de én sokkal nagyobb problémának látom a távoli rendszerhozzáféréses hibákat. Persze a legnagyobb probléma a kettő kombinációja. Szervereken a helyi root legyen annak a problémája, akinek vannak helyi megbízhatatlan felhasználói, lukas a rendszere távolról. A helyi desktop-omon is az értékes adatok nem a root biztokában vannak, hanem annak az usernek, amit én használok. Valószínűleg jobban parázok egy böngésző sebezhetőség miatt (amivel elcsórhatják a banki adataimat, meg a jelszavaimat, kulcsaimat), mint egy local root miatt. Én ilyenekben látom a problémát. Meg abban, hogy a FreeBSD még mindig sendmail-t szállít alapértelmezetten, ami ha jól tévedek (erre nem esküszöm) alap telepítés esetén még fut is vidáman. És nem csak localban.

"(és nem is a kernelben van)"

Ja, mert csak arról folyik a diskurzus? :)

"Ja, biztos többet ér. De akkor ezzel mit is mondtál?"

Azt, hogy nyilván azzal foglalkoznak többet, ami népszerű. Rendkívül kevés hibát fedeznek fel a .... (ide helyettesítsd be a hobby OS-eket), aminek nem az az oka, hogy rendkívül biztonságosak, hanem nagy valószínűséggel az, hogy a rák se használja.

"- a hiba nem FreeBSD specifikus"

Hogy azt ők írják, vagy csak valahonnan "ész nélkül" (hogy idézzek) belelapátolják, az a kihasználhatóság szempontjából teljesen mindegy. Én annyit állítottam, hogy FreeBSD-ben is van hiba. C-ben írják, emberek. Nincsenek illúzióim.

"Érdemesebb periférikus OS-eket használni, mert arra nem cuppannak rá az exploitírók?"

Nem, nem erre céloztam, hanem arra, hogy nyilván kevesebb hibát találnak egy kevésbé széles körben használt OS-ben. Ezen nem kell csodálkozni.

--
trey @ gépház

Én azt gondolom, hogy az embernek alapvetően 2 választása van.

1. Ha bárhol elérhető segítséget szeretne: használja az elterjedt rendszereket (pl. linux-ot szerveren, de akár igaz ez a windows (desktopra) is), és mindent megtesz annak érderkében, hogy biztonságos legyen (állandó hibajavítási frissítés, egyéb security, _emberi_ odafigyelés)

2.Ritka rendszert használ (nevezzük mondjuk szerveren RareBSD-nek, de ilyen a desktop-linux is), mely nincs fókuszban, de ezt nagyon jól ismeri, nem fáj neki, hogy nem jut olyan széleskörű segítséghez, mint az elterjedt (linux-server (v. windows-desktop)) esetén.
Ez esetben kissé kockáztat (a nem kiderült hibák miatt), de szerintem jó hibaszázalékkal elboldogulhat.
A gond akkor van, ha ez a rendszer elterjedtté válik, ekkor vagy az 1. szabály lesz érvényes, vagy vált egy másik RareOS -re, amíg az sem terjed el.

(Nyilván minél ritkább rendszert használ, annál biztonságosabb lehet (effektíve, statisztikailag, nem elméletben), de annál nehezebben talál támogatást/segítséget hozzá. Az is igaz, hogy ha már _közepesen_ elterjedt a cucc, akkor mindkét hátrányát "élvezheti" (tehát a támadásokat + a doksi /help /javítás hiányát is..)

"2.Ritka rendszert használ (nevezzük mondjuk szerveren RareBSD-nek, de ilyen a desktop-linux is), mely nincs fókuszban, de ezt nagyon jól ismeri, nem fáj neki, hogy nem jut olyan széleskörű segítséghez, mint az elterjedt (linux-server (v. windows-desktop)) esetén.
Ez esetben kissé kockáztat (a nem kiderült hibák miatt), de szerintem jó hibaszázalékkal elboldogulhat."

"Nyilván minél ritkább rendszert használ, annál biztonságosabb lehet (effektíve, statisztikailag, nem elméletben)

Ez igy hibas hozzaallas. A hibakkal a legjobb dolog, ami tortenhet, (azon kivul, hogy gyumolcsok lesznek a Jogobellaban) az az, hogy kiderulnek, amikoris kijavitjak oket, es mindenki boldog. A script-kiddie-ket leszamitva senki nem fog mar publikalt sechole-okat kihasznalni. Ha pedig az adott szoftver tele van felfedezetlen, exploitable sechole-okkal, az csakis azoknak kedvez, akik be akarnak jutni.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Valóban az a jó, ha a hibák kiderülnek- és kijavítják. Ezen nem vitatkozom, ne értsd félre. Csak két lehetséges stratégiát vázoltam fel, értékítélet nélkül. Lehet, hogy kissé cinikus volt, de ezek a lehetséges hozzáállások. Ki-ki más utat választ. Mindkét út a maga módján kényelmes és fáradságos.
Nyilván az 1. esetben állandóan követni kell az eseményeket, de hamar megoldást talál az ember, míg a 2. esetben hátradőlhet azok nyugalmával, hogy senkit sem érdekel az ő rendszere, de ha egyszer bukik, akkor óriásit bukik, és vért kell izzadnia, míg helyrehozza a hibát. Lehet választani.

Nem érzem úgy, hogy ezzel a hibával nagy tömegben lehetne távoli gépeken tetszőleges kódot futtatni.

Olyan képességű nyílt forrású MTA, mint a sendmail nem sok van (van?). Az exim közelíti, de azt hiszem tovább nem is kell ragoznom, mert az is bugware.
Fut, mivel a FreeBSD alaptelepítésben képes önmagáról státuszriportokat küldeni, illetve ha megfelelően állítottad be a hostnevet, hálózatot, egyebeket, akkor az internetre is elmegy minden leveled.
A távoli elérésnek nem lenne értelme, a sendmail alapból azért van benne a rendszerben, hogy a fenti funkciókat ellássa:
root sendmail 745 4 tcp4 127.0.0.1:25 *:*

Kernel: nem feltétlenül, konkrétan ez a szál egy libc/libbind resolver (userspace) hibával indult, ami határozottan nem a kernel, emiatt pedig mégkevésbé súlyos (lásd első hozzászólást).

FreeBSD specifikus: azt írtad, hogy nem szívódnak rá az exploitírók (lehet, hogy sztrájkolnak egyébként a forgatókönyvírókkal együtt :), mert a populárisabb OS-ekkel foglalkoznak. A hiba nem FreeBSD specifikus->a populárisabb OS-ekben is kihasználható lehet->rá kellene szívódniuk. Nem teszik->nem súlyos a hiba. QED. :)

Ha kevesebb hibát találnak benne, a script kiddie-eknek esélyük sem lesz, így sokkal kevesebb ember tud bemenni a gépedre. Nem ugyanazt jelenti?
Vajon hányan foglalkoznak VMS, vagy NonStop OS hibakereséssel? Mennyi az esélye annak, hogy ezekhez exploitokat tölts le, összehasonlítva a unixokkal, vagy windows-zal?
Azért mégiscsak fontos lehet ez, jelentősen szűkíti azok körét, akik hozzá tudnak piszkálni az ilyen gépedhez...

Túl hosszú lenne, és amúgy is reménytelen veled vitatkozni, mert látszik, hogy nem tapasztalatból, hanem feltételezésekből ítélsz.
De mondok egyet, amivel például tegnap kerültem szembe (elég primitív): a null senderrel érkező leveleket irányítsd más irányba. Ha pedig irányítás: IP szerint több helyre irányítsd ezeket a leveleket, egy elsődleges és több másodlagos szerverre, utóbbiak csak akkor kapjanak levelet, ha az elsődleges nem elérhető.

De mondhatnám pld. a feltételes LDAP keresést is: ha DNS szerint te vagy a domain MX-e (a te egy, vagy több állítható IP cím), akkor LDAP lookup, ha talált elfogad, ha nem elutasít. Ha nem te vagy az MX, elutasít.

Nekem csak az a kerdesem, hogy az olyan rendszerek hasznaloi, ahol sendmail alapertelmezetten telepitesre kerul, ilyen beallitasokkal futatja?
Vagy csak a felhasznalok 0.1%-nal van szukseg ilyenekre.
Amugy postfix policyd-je eleg sok mindenre kepes.

York.

------
"Nyugi! Minden a legnagyobb rendben csúszik ki a kezeim közül..."

Milyen beállításokkal?
A felhasználóknak nem tudom, hogy mekkora részének van rá szüksége.

A postfix policy protokolljával több problémám is van:
- a levélhez magához nem lehet hozzáférni (pontosabban lehet, de alapból ez nehéz a jogosultságok és amiatt, hogy maga a queue formátum nem garantált, hogy állandó marad, bármikor változhat és amúgy is tűzzel-vassal írtják a direktben piszkálódókat)
- engem például zavar, hogy csak az SMTP időben történő dolgokról lehet értesítést kapni, pld. olyan nincs, hogy a queue-ból távozott a levél, vagy megpróbálta kézbesíteni, de hiba történt
- az állapotot (pld. rcpt-k) neked kell tárolni és összegyűjteni (előny, meg hátrány is lehet)
- csak egy vége lehet a sessionnek (OK, REJECT, DISCARD, DUNNO, FILTER, HOLD, PREPEND, REDIRECT, WARN), azaz nem tudok headert hozzáadni és redirectelni, a filterrel lehet route-olni, de lásd előbb, meg amúgy is...
- a levéllel kapcsolatban nem lehet módosításokat (a PREPEND-et leszámítva) végezni, nem lehet fejléceket hozzáadni, eltávolítani, átírni, a bodyban turkálni, stb

Azt mondanám, hogy ennél a milter azért jobb. A policy protokoll akkor lenne jó, ha ilyen egyszerű lenne ÉS megengedné azt, amit a milterrel lehet.

Szia

En nem azt mondtam, hogy jo mindenre, csak azt hogy sok mindent egyszeruen es jol meg lehet vele csinalni.
Igen engem is zavart, hogy nem lehet a levelhez hozzanyulni benne.
De ha jol emlekszem valamelyik postfix verziotol mar van milter, azt nem nezted?

York.

------
"Nyugi! Minden a legnagyobb rendben csúszik ki a kezeim közül..."

Jó. Sajnos a legtöbb unixon valaminek rootként kell futnia ahhoz, hogy helyi kézbesítéseket tudjon tenni, ill. ugyanezen OS-eken szokás alapból rendelkezni minimális levelező képességekkel (pld. a helyi kézbesítéssel minimum).

Nem tudom, egyre inkább távolodunk attól, hogy az inet_network hiba nem súlyos a FreeBSD-ben... :)

"Jó. Sajnos a legtöbb unixon valaminek rootként kell futnia ahhoz, hogy helyi kézbesítéseket tudjon tenni, ill. ugyanezen OS-eken szokás alapból rendelkezni minimális levelező képességekkel (pld. a helyi kézbesítéssel minimum)."

Ezzel nincs is baj (mármint, hogy kell helyi kézbesítésre MTA), de röhögőgörcsöt kapok, amikor fanboyok jönnek a BSD az überbiztonság témával, közben localban tésztaszűrő jellegű MTA végzi a kézbesítést és mindezt miért? Licencfétis miatt.

"Nem tudom, egyre inkább távolodunk attól, hogy az inet_network hiba nem súlyos a FreeBSD-ben... :)"

Meggyőztél, hogy az nem komoly. Helyette váltottam a sendmail-re.

--
trey @ gépház

Hát most már az MTA-issue kezd megoldódni, egyrészt mert pl. a NetBSD berakta a postfixet, másrészt a qmail kódja nemrég lett public domain, harmadrészt meg készül alternatív MTA kizárólag local/smarthoston keresztüli delivery-re.
A licencfétisizmusra meg hadd ne reagáljak. :-)
It doesn't matter if you like my song as long as you can hear me sing

A BSD és az überbiztonság két külön fogalom, ahogy a unix (egyikből következik a másik) és az überbiztonság is. Egyszerűen nem erre tervezték, architekturálisan alkalmatlan a feladatra. :)
Az, hogy konkrétan a FreeBSD-ben miért sendmail van vsz. többrétű, hagyomány, kompatibilitás (a sendmail ugye a leginkább sendmail kompatibilis, ill. a már meglévő bázisnak is egyértelmű) és nyilván a licensz is fontos egy ilyen programnál (kb. mintha a bootloader, vagy az init lenne GPL-es).
Szerintem nincs ezzel semmi baj.
Akinek nem kell, kikapcsolja, akinek más kell, felrakja. Ahol én sendmailt használtam, ott is portból tettem, mivel egyszerűbb azt frissíteni, illetve a kiegészítőket hozzátenni onnan, mint a base sendmail esetén.

From wikipedia:

"Allman, who is openly gay, lives in Berkeley, California with his partner of more than 20 years, Marshall Kirk McKusick. McKusick is a lead developer of BSD; the two first met in graduate school."

Allman a Sendmail szerzője.

De, mint írtam, ez csak rossz vicc volt. Nyilván nem ezért.

--
trey @ gépház

hmmm, akkor mostanában nem csak a linux-ban találnak súlyos biztonsági hibákat...

Ezek nem "súlyos" biztonsági hibák.

lehet, hogy a linux-os eset után elkezdték ők is átnézni a kódokat

Minden nap találnak ezeknél súlyosabb Linux biztonsági hibát, csak nem mindegyikre írnak exploitot és pláne nem mindegyiket publikálják a széles nyilvánosság előtt.

Nem érdemes a legutóbbi Linux hibát egyedinek és ritkaságnak gondolni... :)

Annyira jol tudtok mellebeszelni a temarol, hogy mindig orom nezni a "szomszed kernele mindig hibasabb" tipusu hozzaszolasokat. :)
Minden ilyen hirnel kotelezoen beirja valaki !linux eseteben, hogy deeznemannyirahibasmintaszarlinuksz, linux eseten meg egyeseknek (ro/rw)botjuk egybol (fel/ra)all a temara es pastelik a szokasos szaralinukszhulyelinukszfanboj es tarsai szoveget olyan mennyisegben, mintha nem talaltak volna fel mar a fekezett habzasu mosoport. Utana mindenki rajon, hogy szar minden lenyegeben, es ha meg szuicid hajlamu is az illeto, akkor nekiall ritualisan maganak felvezetni az ethernet/optikai kabelt, hogy o kapja meg az exploitokat es felaldozza magat a security oltaran. Ergo hihetetlen ez az allando agymenes errol itt, olyan mint valami vegtelen ciklus. :)
Bar lenyegeben amig nem kezdodnek el a "bezzeg a ..." tartalmu mondatok, egeszen jo.

koszi, de nekem a problemam nem azzal van, de nyilvan ha elolvasod amit irtam, megerted; ha megsem megsporolom neked a kovetkezo replyt ahol leirod, hogy marpedig te nem erted: csupan arra akartam burkoltan celozni es elvenni a mondandom komolysaganak elet, hogy marha uncsi ez a x vs y vitak, ahol amugy mindenkinek lenyegeben igaza van (szerintem), de sokszor ez egyreszt elmegy szemelyeskedesbe (bar szerencsere par ember banjaval ez csokkent talan), masreszt meg leragott csont... ha azt hozod fel hogy rossz threadre nyomtam, ezt elfogadom, mert nem (csak) Neked szantam es nem csak ezzel kapcsolatban irtam. Bar amit en hangoztatok az is leragott csont. :) Ugyhogy fogom az utp kabelt es... :)))

Nem sok személyeskedést láttam eddig, a vita szerintem leginkább azon van, hogy mi számít súlyos hibának, illetve Trey gyakorlatoztatja a keresőt és a memóriáját. ;)
Aki IPSecet használ, az nyilván súlyosnak ítéli, ha a 0x4fdeadbeef csomag beküldése után szétrohad a kernel, vagy ha éppen inet_network-kel alakítja át az IRC-s DDoS botja a privmsg-ben kapott célpont IP-jét dotted quad sztringből.

Másnak meg az fáj, ha a nobody user jelszó nélkül su-zik...

Mar azt hittem tul nyakatekert lett, de akkor valaki csak erti! :)
A flame jo, talan kell is, de egy bizonyos szint utan felesleges es mar unalmas, mert mindig ugyanarrol szol
es az egesz neha nekem ugy tunik mintha visszaterne onmagahoz, aztan kezdodik elolrol, csak max mas kapcsan.
Mindenesetre annak orulok, hogy ha picivel is, de kevesebb az anyazas, mar csak ez a "mindent meg tudok magyarazni, amugy hulyenek nezlek" stilust kene csokkenteni. :)

( endru | 2008. 02. 16., szo – 19:29 )

Akkor összefoglalom:

Miután egyik sem SKYNET, tehát az összes rendszer egy rakás sz@r. :)