Bekijk Volledige Versie : Exim 0day
Zie http://www.exim.org/lurker/message/20101207.215955.bb32d4f2.en.html
Er is nog geen publieke exploit, maar dat zal een kwestie van tijd zijn. Snelste fix om eventuele problemen te voorkomen is Exim te recompilen met de volgende extra optie in Local/Makefile:
ALT_CONFIG_PREFIX=/etc
Op deze manier kan het config bestandje niet geladen worden en dus geen setuid bits geset worden. Natuurlijk er van uitgaande dat je /etc niet writable is voor exim ;-)
Zie http://www.exim.org/exim-html-current/doc/html/spec_html/ch52.html voor meer info wat de config setting doet.
Wij houden dit ook nauwlettend in de gaten. Er zijn nog geen externe pogingen tot misbruik gesignaleerd en we hebben zelf het probleem nog niet kunnen bevestigen (maar draaien ook een nieuwere basis versie). Dit lijkt potentieel inderdaad erg gevaarlijk!
Met een nieuwere basis versie ben je er denk ik niet. De handigste fix op dit moment is echt er voor zorgen dat er geen gekke config files ingeladen kunnen worden.
Wellicht dat de buffer overflow toevallig al gefixed is in een nieuwere versie, maar de root escalation werkt sowieso ook in de laatste versie.
Had dit ook al gezien inderdaad, maar het is me niet helemaal duidelijk of dit nu om de specifieke apt-exim-package gaat, of dat dit een algemeen exim probleem is...
cPanel heeft er ook last van (zelfs onder FreeBSD nog...), dus ik denk haast dat het een algemeen Exim probleem is.
Alleen Exim <4.70 lijkt affected (Debian stable draait 4.69 dus heel veel servers zullen dit probleem wel hebben). wdv, waar heb je gelezen dat de laatste versie ook affected is? Wij krijgen het bij ons niet gereproduceerd (4.72).
cPanel heeft inmiddels een fix uitgebracht:
=============
Summary
=============
A privilege escalation vulnerability exists in Exim, the mail transfer agent used by cPanel & WHM.
-----------------------
Security Rating
-----------------------
This update has been rated as Critical by the cPanel Security team.
Description
-----------------------
Research up to this point indicates the exploit is a buffer overflow vulnerability that takes advantage of the default Exim configuration settings related to altering Exim's runtime configuration file along with overriding the macro definitions in the configuration file. This buffer overflow may lead to arbitrary code execution with the privileges of the user executing the Exim daemon. However, the Exim user retains root privileges when running the -C and -D command line flags. Through the creation of a temporary exim configuration which is processed with the -C or -D flags, the Exim user is able to execute arbitrary commands as root.
Solution
-----------------------
To resolve and work around the issue, for Linux-based systems cPanel has issued new Exim RPMs. The new version of Exim locks configuration file locations to the /etc/exim prefix as well as disabling use of the -D flag. Server Owners are strongly urged to upgrade to the following Exim RPM versions:
• Systems configured to use Maildir: Exim 4.69-25
• Systems configured to use mbox (deprecated): Exim 4.63-4
Exim RPMs will be distributed through cPanel's package management system. All cPanel & WHM servers receiving updates automatically will receive the updated Exim RPM during normal update and maintenance operations (upcp). If you prefer to install the update right now, please run the following in a root shell:
/scripts/eximup
On cPanel & WHM FreeBSD servers, Exim is an unmanaged install performed from the Ports system. To apply a like setup on FreeBSD systems, server administrators will need to perform the following manual configuration:
• Remove WITHOUT_ALT_CONFIG_PREFIX=yes from /etc/make.conf
• Add the following to /var/db/ports/exim/options
WITH_ALT_CONFIG_PREFIX=true
SEDLIST+= -e 's,^(ALT_CONFIG_PREFIX=).*,\1/etc/exim,'
SEDLIST+= -e 's,^\# (DISABLE_D_OPTION=),\1,'
• Change directory to /usr/ports/mail/exim
• Execute 'make deinstall'
• Execute 'make install'
Caution: the above changes have potential to be undone by /scripts/checkmakeconf, and updates to the Exim port. An upcoming version of cPanel & WHM 11.28 will resolve this for FreeBSD users.
References
-----------------------
http://docs.cpanel.net/twiki/bin/view/AllDocumentation/SecurityLevels
http://www.exim.org/lurker/message/20101207.215955.bb32d4f2.en.html
_______________________________________________
Het lijkt er inderdaad op dat het vanaf 4.70 gefixt is. Ik denk alleen dat de meesten <4.70 draaien. Ik blijf het vreemd vinden dat hier pas zo laat en traag op gereageerd wordt.
De cPanel oplossing is een workaround, de beste fix lijkt vooralsnog een upgrade naar Exim >4.69. DirectAdmin thread: http://www.directadmin.com/forum/showthread.php?t=38586&highlight=exim
Maar Exim 4.72 lijkt ook vulnerable te zijn. De persoon die de bug heeft ontdekt, zegt ook:
"I haven't reproduced remote part of attack, but escalation from Debian-exim to
root works also at exim4-daemon-light 4.72-2 from Debian Squeeze. "
Edit: never mind, verderop lees ik dat >4.69 alleen onder Debian de bug nog bevat. Zie http://www.exim.org/lurker/message/20101210.083335.f3d05cab.en.html
Maar Exim 4.72 lijkt ook vulnerable te zijn."
Van Ted Cooper:
There are 2 different pieces to this - the buffer overflow allowing shell access as the exim user - and the priviledge escalation using -C and/or -D . The priv escalation is possible any time someone is running as the exim user, even up to the current version but can be prevented entirely by recompiling with -C restrictions.
Normally, users can't run as the exim user so they need the buffer exploit or some kind of cheating by root (which is how it was tested to see if it still working in 4.72)
No one has been able to get the buffer overflow to work in 4.7x yet
Vooralsnog lijkt een upgrade naar Exim 4.72 dus in eerste instantie in ieder geval voldoende.
Inmiddels al een flinke batch cPanel servers een exim update gegeven. Vanavond de DA bakken maar eens bij langs.
We zijn hier inmiddels alle DirectAdmin servers aan het patchen. Exim 4.72 van source compilen en de fixes die cPanel heeft gedaan even toepassen. Dan is het in principe redelijk veilig.
Tim.Bracquez
10/12/10, 12:51
We zijn hier inmiddels alle DirectAdmin servers aan het patchen. Exim 4.72 van source compilen en de fixes die cPanel heeft gedaan even toepassen. Dan is het in principe redelijk veilig.
Hier ook al in het update script geplaatst, volgen het wel nog wat op...
ter referentie hier gelijk ff zetten hoe je makkelijk kan updaten met directadmin
cd /usr/local/directadmin/custombuild
./build set custombuild 1.2
./build update
./build exim
systemdeveloper
10/12/10, 22:42
ter referentie hier gelijk ff zetten hoe je makkelijk kan updaten met directadmin
cd /usr/local/directadmin/custombuild
./build set custombuild 1.2
./build update
./build exim
En de sourcecompile dan ook maar even erbij (FreeBSD, voor linux de paden even aanpassen):
/usr/local/bin/wget http://files.directadmin.com/services/custombuild/exim-4.72.tar.gz
/usr/bin/tar xvzf exim-4.72.tar.gz
cd exim-4.72/Local
/usr/local/bin/wget http://www.directadmin.com/Makefile
/usr/bin/perl -pi -e \'s/^EXTRALIBS/#EXTRALIBS/\' Makefile
/usr/bin/perl -pi -e \'s/HAVE_ICONV=yes/HAVE_ICONV=no/\' Makefile
cd ..
make
make install
cp -f /usr/sbin/exim-4.72-1 /usr/sbin/exim
chmod 4755 /usr/sbin/exim
/usr/local/etc/rc.d/exim restart
Ja leuk maar da's dus voor custombuild 1.2.
Kun je nadien weer terug naar 1.1? Want waarom anders die handleiding voor de source compile?
Of is het nadien gewoon weer een kwestie van:
./build set custombuild 1.1
./build update
Ja leuk maar da's dus voor custombuild 1.2.
Kun je nadien weer terug naar 1.1? Want waarom anders die handleiding voor de source compile?
Of is het nadien gewoon weer een kwestie van:
heb je een specifieke reden waarom je terug zou willen naar 1.1?
Enig specifiek voordeel aan 1.2?
Ik vroeg het me maar af want ik heb m'n Exim's al gepatched. Maar wat is dan het voordeel van 1.2? Ik begrijp van de DA forums dat 1.1 stable is en 1.2 nog niet.
Kon zo vlug ook niet een "wat is het verschil" vinden op de DA site, behalve dan dat php6 in 1.2 zit.
Gaat het nu om alle OS en of alleen Debian?
Ik zie in versions.txt
exim:4.72:ef5f78399eb75b84ea453e8f8722e2d2
Ik heb een paar dagen geleden met custombuild en yum alles geupdate op mijn server met Directadmin.
Ben ik nu veilig voor deze exploit? of hoe kan ik dat zien?
Ik heb wel niet zo veel ervaring ermee...
Gelukkig gaat alles altijd goed.
het is een CentOS 5.5
Het makkelijkst kan je denk ik even telnetten naar port 25 van de server. Daar zie je het versiemummer van Exim staan.
Gaat het nu om alle OS en of alleen Debian?
Het gaat om alle Exim mailservers met versie < 4.70
Je kunt ook even doen;
/usr/sbin/exim -bV
Het makkelijkst kan je denk ik even telnetten naar port 25 van de server. Daar zie je het versiemummer van Exim staan.
Dan zie ik dat ik Exim 4.69
220 server.domain.com ESMTP Exim 4.69 Sat, 11 Dec 2010 14:38:59 +0100
Ik vind het raar dat er dan in versions.txt Exim 4.72 staat?
Dan zie ik dat ik Exim 4.69
220 server.domain.com ESMTP Exim 4.69 Sat, 11 Dec 2010 14:38:59 +0100
Ik vind het raar dat er dan in versions.txt Exim 4.72 staat?
Wat in versions.txt staat is wat custombuild graag wil installeren. Deze wordt ook ge-update wanneer je './build update' doet. :)
Wat in versions.txt staat is wat custombuild graag wil installeren. Deze wordt ook ge-update wanneer je './build update' doet. :)
aha, ik lees net in de Custombuild FAQ op het DA forum dat enkel bij custombuild 1.2 is.
Mail options:
exim - install/update Exim using "./build exim" or "./build all". Possible values: yes/no (default: no). This option is only available from CustomBuild 1.2.
Ik gebruik nog custombuild 1.1, dus waarschijnlijk tijd om dat ook te upgraden...
ik hoop dat er dan niks verkeerd kan gaan.
Als ik dan eerst custombuild upgrade naar 1.2 en dan Exim (via custombuild) dat is het in orde? of moet ik wat speciaal instellen?
Thanks!
Dat staat eigenlijk al in deze thread vermeld.
Je kunt upgraden naar custombuild en dan Exim upgraden en dan is het in orde.
Je kunt ook bij custombuild 1.1 blijven en dan de handmatige upgrade doen. Handige daarvan is dat je nog wat in de Makefile kunt aanpassen. Just to be sure. Ook hier is een handleiding voor op DA.
Daarnaast moet je sowiezo nog handmatig een nieuwe config plaatsen en wat aanpassingen doen als je van de nieuwe opties van 4.72 gebruik wilt maken.
Dat geldt zowel met 1.1 alsook met 1.2 custombuild. Maar ook daar is een mooie handleiding van te vinden op DA.
http://help.directadmin.com/item.php?id=51
Doe wel eerst die yum install wat erbij hoort en klik op de readme bij de vette letters, daar kom je nog mee op een link met de nodige info.
Dat staat eigenlijk al in deze thread vermeld.
Je kunt upgraden naar custombuild en dan Exim upgraden en dan is het in orde.
Je kunt ook bij custombuild 1.1 blijven en dan de handmatige upgrade doen. Handige daarvan is dat je nog wat in de Makefile kunt aanpassen. Just to be sure. Ook hier is een handleiding voor op DA.
Daarnaast moet je sowiezo nog handmatig een nieuwe config plaatsen en wat aanpassingen doen als je van de nieuwe opties van 4.72 gebruik wilt maken.
Dat geldt zowel met 1.1 alsook met 1.2 custombuild. Maar ook daar is een mooie handleiding van te vinden op DA.
http://help.directadmin.com/item.php?id=51
Doe wel eerst die yum install wat erbij hoort en klik op de readme bij de vette letters, daar kom je nog mee op een link met de nodige info.
Ik had Exmin 4.72 al met custombuild 1.2 geïnstalleerd.
Ik heb inderdaad die yum install eerst gedaan.
De config heb ik wel niet aangepast, alles blijkt goed te werken en nieuwe functies heb ik niet echt nodig. Zolang het veilig is ben ik tevreden.
Thanks!
edit : de config toch maar aangepast ;-)
met succes.
Ik krijg deze error op CentOS x86_64 vanaf source compile:
/usr/bin/ld: cannot find -ldb
collect2: ld returned 1 exit status
make[1]: *** [exim_dbmbuild] Error 1
Terwijl ik deze yum install toch al gedaan heb:
yum install db4-devel cyrus-sasl-devel
Iemand enig idee? Via Google kom ik alleen maar threads tegen waarin men zegt dat je db4 moet installeren maar dat heb ik al gedaan.
Heb het inmiddels geinstalleerd via een RPM package (zie: http://help.directadmin.com/item.php?id=126)
Echter krijg ik wanneer ik vanuit roundcube (met het admin account) een mail probeer te versturen:
SMTP fout 535: authenticatie mislukt
Zou dit met de update te maken hebben of het admin account? Heb zo snel geen ander account waar ik mee kan testen.
Heb het inmiddels geinstalleerd via een RPM package (zie: http://help.directadmin.com/item.php?id=126)
Echter krijg ik wanneer ik vanuit roundcube (met het admin account) een mail probeer te versturen:
SMTP fout 535: authenticatie mislukt
Zou dit met de update te maken hebben of het admin account? Heb zo snel geen ander account waar ik mee kan testen.
Heb zelf de source install gedaan op onze servers die een oude versie draaiden (lees: < 4.70). Geen problemen hier.
Waarom RPM draaien? :TLW
Wat is je resultaat met source install?
ter referentie hier gelijk ff zetten hoe je makkelijk kan updaten met directadmin
cd /usr/local/directadmin/custombuild
./build set custombuild 1.2
./build update
./build exim
Mijn custombuild geeft in de 'config' nog versie 1.1 aan. Version.txt geeft de nieuwste versie van exim aan.
Maar kan ik dan gewoon bovenstaande code uitvoeren? Of moet ik dan ./build set custombuild 1.1 gebruiken?
Nou vanuit source krijg ik dit dus
/usr/bin/ld: cannot find -ldb
collect2: ld returned 1 exit status
make[1]: *** [exim_dbmbuild] Error 1
Terwijl ik deze yum install toch al gedaan heb:
yum install db4-devel cyrus-sasl-devel
Nou vanuit source krijg ik dit dus
Je moet niet alleen db4-devel doen maar ook db4
Ja, die heb ik ook geinstalleerd. Zelfs nog een reinstall gedaan, maar dat mocht ook niet baten.
Via de RPM is het wel gelukt (alhoewel ik daarvoor ook die yum install db4 db4-devel cyrus-sasl-devel moest doen)
Ik ben inmiddels slachtoffer geworden van deze exploit. Er circuleren inmiddels scripts rond waarbij het een kwestie is van het invullen van een IP adres van een server, om root toegang te krijgen.
Ik wil daarom iedereen waarschuwen voor deze bug. Het schijnt al 2 jaar bekend te zijn (toen is de impact verkeerd beoordeeld), maar sinds deze week zweven er exploits op internet.
Zie:
http://www.metasploit.com/
http://lists.debian.org/debian-security-announce/2010/msg00181.html
Ik draai Debian Lenny (stable), en de exploitbare versie zit hier in.
Het zelfde hier waargenomen op een lenny spare server die ik had hangen (zonder al teveel aandacht). Belangrijke patch dus.
Ik ben inmiddels slachtoffer geworden van deze exploit. Er circuleren inmiddels scripts rond waarbij het een kwestie is van het invullen van een IP adres van een server, om root toegang te krijgen.
Heb jij dan niet hercompiled met de toevoegingen in makefile die genoemd zijn/draaide je niet de laatste versie?
Heb jij dan niet hercompiled met de toevoegingen in makefile die genoemd zijn/draaide je niet de laatste versie?
Dan zou hij geen last gehad hebben he ..
Ik draai Debian Lenny (stable), en de exploitbare versie zit hier in.
Heb je wel de security updates server aan je sources.list toegevoegd?
deb http://security.debian.org/ lenny/updates main contrib non-free
Is bekend of 4.71 ook affected is?
Is bekend of 4.71 ook affected is?
Er zijn 2 bugs. Exim <4.70 kan remote worden overgenomen. Daar ben je dus veilig voor. Lokale gebruikers met Debian-exim rechten kunnen echter ook root worden, dat kan in je configuratie worden aangepast en is dus alleen relevant als bepaalde mensen dat niveau van toegang hebben.
Er zijn 2 bugs. Exim <4.70 kan remote worden overgenomen. Daar ben je dus veilig voor. Lokale gebruikers met Debian-exim rechten kunnen echter ook root worden, dat kan in je configuratie worden aangepast en is dus alleen relevant als bepaalde mensen dat niveau van toegang hebben.
Check, maar die bug zit ook in 4.71 en 4.72?
(Bedankt voor je uitleg ;))
Check, maar die bug zit ook in 4.71 en 4.72?
(Bedankt voor je uitleg ;))
De tweede bug standaard wel ja.
Heb jij dan niet hercompiled met de toevoegingen in makefile die genoemd zijn/draaide je niet de laatste versie?
Nee, ik was helaas te laat. Ik voer elke week een apt-get update / upgrade uit, heb uiteraard wel de security patches in de sources.list staan.
De bug an sich was al lang bekend, maar niet dat deze exploitbaar is. Dat is pas deze week bekend geworden zover ik begrepen heb.
Zojuist geupgrade naar 4.69-9+lenny. :) Hierin zou dit probleem niet meer in aanwezig zijn.
Dan zou hij geen last gehad hebben he ..
Daarom vraag ik het ook.. als hij wel geupdate zou hebben en hij was toch gehacked dan zou 4.72 ook geen bescherming bieden ;)
Ik moet zeggen dat ik deze bug / exploit verre van duidelijk vind. Iedereen klept als een kip zonder kop wat anders. men dient er overigens ook rekening mee te houden dat er op moment ook een nieuw gevonden kernel exploit is.
http://seclists.org/fulldisclosure/2010/Dec/index.html#85
Aanvulling, niet alle kernels zijn met OOPS compiled, tijdelijke work-around
echo 1 > /proc/sys/kernel/panic_on_oops
Verder kan als serieuze sidenote genomen worden dat door de wildgroei van custom kernels en weet ik veel allemaal wat het verstandig is om na te gaan of OOPS er wel of niet in zit.
Ik moet zeggen dat ik deze bug / exploit verre van duidelijk vind. Iedereen klept als een kip zonder kop wat anders.
Ik dacht al, ben ik nou de enige die geen duidelijke lijst met infected software en daarbij horende oplossing heeft gevonden..:innocent:
men dient er overigens ook rekening mee te houden dat er op moment ook een nieuw gevonden kernel exploit is.
http://seclists.org/fulldisclosure/2010/Dec/index.html#85
Dat lijkt me een eigen topic waard ...
Dat lijkt me een eigen topic waard ...
Niet helemaal, niet elke exim install draait als root. Dus diegene die dachten nog enig veilig te zitten zijn in combinatie wel een gevaarlijk duo!
./build set custombuild 1.2
heb ik gedaan.
En vervolgens wil ik dus dit doen:
./build exim
En ik zie:
Cannot install PHP6 and PHP5 as CLI.
Huh :?
./build set custombuild 1.2
heb ik gedaan.
En vervolgens wil ik dus dit doen:
./build exim
En ik zie:
Cannot install PHP6 and PHP5 as CLI.
Huh :?
Check je options.conf eens.
Gefixxed, met een stukje code uit de DA-forum.
perl -pi -e 's/php6_cli=yes/php6_cli=no/' /usr/local/directadmin/custombuild/options.conf
Nu loop ik vast bij:
./build exim
[exim] error 1
gcc: auths/auths.a: No such file or directory
Ik draai Centos 5 bytheway
En ik neem aan dat ik niet Exim om zeep kan helpen met een falende installatie?
iemand enig idee?
Opgelost met:
yum install db4-devel
yum install cyrus-sasl-devel
Waarna de ./build exim wel lukte, waarna ik de .custombuild weer vrijgaf.
Dat is dus waar ik eerder ook al commentaar over gaf. Waarom naar custombuild 1.2?
Je moet dan toch effe op de verschillen letten.
Je options.conf moet je dus eerst aanpassen dan krijg je dat php 6 gedoe niet.
Overigens is er ook een aangepaste DA Exim uit, dus gewoon in custombuild 1.1 een:
./build update
en daarna
./build update_versions
Of misschien beter:
./build update
./build php n
Is voor custombuild 1.1 al een paar dagen voldoende en ben je voorzien van een gepatchte 4.72.
./build php n, we hebben het over exim?
Of mis ik soms wat?
In ieder geval is het inmiddels gelukt via Custombuild 1.2...
...je mist niks.
Enige verschil tussen 1.1 en 1.2,
1.1 is stable te noemen, 1.2. zitten wat meer test software versie's.
Ja, maar waarom je ./build php n moet doen voor de nieuwste EXIM? Dat is wel opmerkelijk te noemen, vind ik.
./build exim zou logischer klinken, en die heeft CB 1.1 juist niet, en daarom ben ik naar CB1.2 gegaan.
als je de 1.2 niet vertrouwd kan je nog altijd teruggaan naar 1.1 ook hoor... en als je de options.conf ff hernoemd haalt hij de standaard options file terug binnen. natuurlijk ff checken of alle opties naar wens staan dan
Ja, maar waarom je ./build php n moet doen voor de nieuwste EXIM? Dat is wel opmerkelijk te noemen, vind ik.
Sorry, zat effe in de war met php omdat daar ook alweer een nieuwe versie van was. Daar kwam ik achter en ik dacht het bericht verwijderd te hebben. Schijnbaar is dat niet gelukt, maar dat was me niet opgevallen.
Dat van php kun je dus gewoon negeren.
Ik had eigenlijk hier naar willen verwijzen:
http://help.directadmin.com/item.php?id=125
Voor als je niet naar Custombuild 1.2 wilde. Daar moest je eerst nog zelf de regels voor aan de makefile toevoegen maar dat was dus het aangepaste waar ik over wilde spreken. Die regels toevoegen is door die aanpassing niet meer nodig.