Kritikus, távoli kódfuttatást lehetővé tevő sebezhetőség az Exim-ben

Bug

Phil Pennock ma bejelentette az Exim 4.80.1-es kiadását. A 4.80.1 egy ún. "Security Release", azaz biztonsági hibá(ka)t javító kiadás. Ez a Security kiadás egy kritikus, az Exim 4.70 és 4.80 közti verzióit érintő, távoli kódfuttatást lehetővé tevő, kritikus biztonsági hibát javít. Azok az Exim telepítések érintettek, amelyeket DKIM támogatással fordítottak (ez az alapértelmezett). A 4.80.1-es kiadás teljesen egyenértékű a 4.80-nal, mindössze az a különbség, hogy a 4.80.1-ben javításra került a fent említett hiba. A fejlesztők törekedtek arra, hogy a lehető legkisebb legyen a változtatás a két verzió közt, így gyorsabban és könnyebben lehet éles környezetben a biztonsági frissítést alkalmazni.

Azok a felhasználók nem érintettek, akik az Exim-et "DISABLE_DKIM"-mel fordították vagy vagy elhelyezték a "warn control = dkim_disable_verify"-t a konfigurációs állomány megfelelő szekciójában.

Elkerülendő, hogy a felhasználók összekeverhessék "4.80.1" és a "4.81" verziókat, 4.81-es verziót nem adnak ki. A következő, új funkciókat is hozó kiadás az Exim 4.82 lesz.

Részletek a bejelentésben.

(Sajnos az exim.org - beleértve a lists.exim.org-ot is - elérhetetlenné vált. A levelet kitettem a pastebin-re. Elolvasható itt.)

( trey | 2012. 10. 26., p – 17:43 )

Kéne egy szavazás, hogy:

Szerintem pwn-olták az exim.org-ot:

( ) Igen
( ) Nem

:)

--
trey @ gépház

( Fisher v | 2012. 10. 26., p – 22:29 )

Tehát jól értem, kell egy acl, ami így néz ki:

acl_smtp_rcpt:
warn control = dkim_disable_verify

És kész?

( janoszen v | 2012. 10. 27., szo – 00:37 )

Basszus, ez mar a sokadik elegge sulyos sebezhetoseg az Exim DKIM implementaciojaban. Imadom az Eximet mg minden, de most mar igazan elmehetnenek a francba egy kicsit.

Jo tudni... mindenkepp erett mar az Exim csere nalunk, mert mar senki nem nagyon ert hozza (es emiatt egyre hosszabb es hegyesebb bottal piszkaljuk csak), de ez igy kicsit megdobbentett... es talan picit tol a sebessegen. Nagy DKIM userek vagyunk ugyanis.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Peldanak okaert az SMTP kapcsolat soran szamolgatom a buntipontokat a kulonvozo vetsegekert, pl nem letezo mailcimre kuldes, stb. Egyreszt ettol fugg a graylistelese a levelnek, masreszt statisztikazom belole es nezelodok felismerheto patternek utan, amivel a spammereket meg lehet fogni. Sajnos jelenleg keves az idom erre.

Ja, csak amíg bekonfigurálod a postfixet bármire, megöregszel. Nálam a postfix ott hullott ki, hogy egész egyszerűen beleuntam a konfiguráció megértésébe (hogy kell ezt vagy azt a nem standard feladatot bekonfigurálni benne). Tegyük hozzá, hogy pl. anno a sendmail konfigjával nem volt ilyen gondom, pedig az is az őskáosz egy példája. Szerintem a hiba nem az én készülékemben van...

kinek a pap, kinek a paplan, volt szerencsem sendmailt is konfigni meg postfixot is, szvsz a postfix egyszerubb, -- mondjuk amig a sendmailhoz megvan a kivant makro addig tokmind1, ha nincs, akkor remalom -- de ettol fuggetlenul spamszuresre spamfiltert hasznalok, nem az mta -t.

azert peldaul joljon, ha mar van egy mukodo smtp szervered, es spamszurest akarsz hozzatakolni, a meglevo konfig megbolygatasa nelkul ; vagy eppen nem akarod az amugy elegge terhelt mta-ra bizni a szurest.
vagy papucs orran pamutbojt. de mint mar emlitettem, kinek a pap, kinek a paplan...

Egy rakas dolog van, ami nem X, megis X portjan csucsul, mert proxyzik neki, es attol valakinek, valamiert jobb lesz. Pl. Varnish egy ilyen dolog tud lenni.

Nem feltetlen jo dolog az, ha minden szir-szart egybegyursz egy Nagy Es Hatalmas Es Tokeletes Es Hudenagyonszuper megoldasba, neha praktikusabb az egy tool - egy feladat felallas, miszerint a spam filternek rohadtul nincs koze hozza, hogy en a leveleimet igazabol hol tarolom, es hogyan jut el a dolog 25-os portrol a megfelelo helyre. Az MTA-nak meg nem erzem, hogy feladata lenne a content filtering, arra vannak alkalmasabb eszkozok, az MTA oldja meg a transportot.

--
|8]

De pont hogy szerintem nem egy tool - egy feladat felallas. Hisz peldaul minek bele a content filter-be TLS?secure smtp tamogatas amikor az MTA tudna? Gondolok meg egy par dolgot talalnek amit kell csinaljon csak azert mert a 25-os porton ul.
Legtobb opensource MTA ertelmezesem szerint nem maga csinalja a content filtering-et hanem atadja masnak, gondolok postfix content_filter/milter, sendmail milter interface-re. Nem lattom miert lenne jobb az ASSP metodusa. Termeszetesen ha Exchanged van akkor szivas, bar akkor is en inkabb egy postfix+valamit valasztannek.

Ezen kivul kinnek a pap, kinek a papne/ministrans fiu.

vannak elonyei. peldaul akarmelyik smtp szerver ele oda lehet tenni, lehet az eppen exchange is.
vagy eppen az, hogy az ide-oda tologato atpasszolom az amavisnak ami tovabbadja a spamassassinnak ami majd mond ra valamit megoldast, ami a minimum ket plusz daemonnjaval ket plusz hibalehetoseget hoz be, levaltja egy hibalehetosegre. ( persze lehet amavis nelkul kozvetlenul a spamassassin arcaba is tolni a levelet, arra a megoldasra ez a megallapitas nem all meg. )
futhat masik gepen, amavist még nemlattam olyat, ami ne azonos masinan futott volna, mint az smtp szerver.
mert a bejovo forgalmat a cimzett domainja szerint szet tudja dobni tobb smtp szerver kozott.
ropteben szuri a spamot, -- a nagyon egyertelmu spam el sem jut az mtaig ; -- nem kell megvarni, amig bejon az egesz level, aztan attolni a content filteren, ezzel talan sporol egy kis eroforrast.
most igy hirtelen ennyi jut eszembe, de nem akarlak meggyozni, ha neked az jo, amit hasznalsz, akkor hasznald azt.

Az a bajom az ilyen 25-os portra ultetos jatekokkal, hogy vagy megirom, vagy jo esellyel csak AS-jelleggel tamogatja az SMTP-t, az eSMTP-rol nem is beszelve. Ilyen szempontbol nekem az Exim, mint MTA "framework" sajat DSL-el joval szimpatikusabb es uzemeltethetobb, mint a random nyelveken megirt mindenfele futkoraszo daemonok. Az egyetlen baj, hogy az utobbi idoben kicsit elkanaszodtak, szal szet kellene csapni kozottuk egy meretesebb kenyersuto szerszammal.

hat ize. esmtp-t nem jo esellyel, hanem fullosan de tenyleg. hasznalom mar pareve, szoval valaki csak lazadt volna ha.

465-os porton tls-t tenyleg nem tud, viszont lehet de nem kotelezo odaultetni. ( lehet v2 assp megiscsak supportalja a tls-t, bevallom leragadtam v1.x -nel ott ) ssl v3 support van, de azon perpill nemnagyon jon spam, szoval az mehet az mtara direktben ahogy kell.

de mint fentebb irtam, leszoktam a meggyozesrol, ha neked az tetszik, amit hasznalsz, akkor hasznald azt, en meg boldog vagyok, hogy nem kell a spamokkal foglalkozni, es userek sem lazadnak.
beke veled :D

a postfix nem akar egymaga minden lenni, pl. mta, content filter, whatever. Ezekbol csak mta akar lenni, ami pedig ezen felul van, pl. content filter, whatever, azt kulon kiterjeszteskent teheted melle.

Ezert ha spf, dkim, speci content filter, whatever kell, akkor tegy melle egy olyan implementaciot, ami smtp-n / lmtp-n tud kommunikalni. Amit felvetettel, arra en egy policy demonnal mennek ra. A postfix atadja neki az smtp-n elerheto adatokat (ok, ez egy postfix specifikus protokoll), aztan a vegen adj vissza egy smtp kodot (pl. 250, 450 vagy 550), es abbol tudja a postfix, hogy mit csinaljon a kapcsolattal.

Miert kell nekem sajnalnom a Klubradiot?

Postfixre, mert nalunk csak divat-Eximezes folyik (nincs olyan feature hasznalva az Exim-bol, amit csak az Exim tudna). Viszont egy olyan kornyezetben, ahol kb. senki nem ert az Exim-hez en karosnak itelem a letet, mert ha barmi problema van vele, senkinek nincs tapasztalata megoldani. Es az Exim tipikusan nem az a kezikonyv atolvasasa utan vezerelheto valami. Ha valaki nem erez ra a logikajara, akkor el tud veszni benne.

Szerintem az Exim egy nagyon jo celszerszam, de nem tobb. Atlagos MTA feladatokra en inkabb Postfixet alkalmazok, de ha lenne valami meg ennel is egyszerubb, akkor azt alkalmaznek.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal