Bekijk Volledige Versie : Groot security risico OpenSSL !!!
FransVanNispen
07/09/06, 19:37
Op het moment lopen erg veel webserver gevaar! Er is een bug ontdekt in OpenSSL, wat het mogelijk maakt door gebruik te maken van een bepaald certificaat en zo zonder wachtwoord in te loggen als root.
Edit: In de inmiddels verschenen officiële informatie is niet terug te vinden dat deze bug inderdaad kan worden misbruikt om als root in te loggen. ECHTER is het wél erg aan te raden toch de laatste versie te installeren.
References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4339
http://www.openssl.org/news/secadv_20060905.txt
Alle versies tot 0.9.7j en 0.9.8b lopen gevaar !
Het checken van de versie:
# openssl version
Hoe te updaten (alleen getest op CentOS 4):
cd /root/Update-all/ ; OpenSSL=0.9.7k ; wget http://www.openssl.org/source/openssl-$OpenSSL.tar.gz ; tar xvzf openssl-$OpenSSL.tar.gz ; cd openssl-$OpenSSL/ ; rm -rf /usr/lib/libssl.so.0 ; rm -rf /usr/lib/libssl.so ; rm -rf /lib/libssl.so.2 ; rm -rf /usr/lib/libcrypto.so.0 ; ./config --prefix=/usr no-threads shared ; make clean ; make ; make test ; make install ; echo "/usr/local/ssl/lib" >> /etc/ld.so.conf ; /sbin/ldconfig -v ; rm -f /lib/libssl.so.4 ; rm -f /usr/lib/libcrypto.so.0 ; ln -s /usr/lib/libssl.so.0.9.7 /lib/libssl.so.4 ; ln -s /usr/lib/libcrypto.so.0.9.7 /usr/lib/libcrypto.so.0
Na deze update dient ook Apache opnieuw gebouwd te worden!
Dat is een belangrijk informatie, bedankt beste Frans.
Nu is mijn vraag, ik heb het volgende versie : OpenSSL 0.9.7a Feb 19 2003
Moet ik ook update?
En wat bedoel je met apache herbouwen?
cd /usr/local/directadmin/customapache
rm -f configure.*
./build clean
./build update
./build all
Deze mischien?
FransVanNispen
07/09/06, 21:47
Alle versies voor 0.9.7k zouden geupdate moeten worden.
Voor de 0.9.8 versie alles voor 0.9.8c.
Om Apache te herbouwen hoef je slechts te doen:
cd /usr/local/directadmin/customapache
./build clean
./build apache
In geval je Apache 2 draait wordt dat laatste natuurljk:
./build apache_2
Eventueel kun je voor dat je opnieuw gaat bouwen eerst nog de laatste versie invullen in build. Voor Apache2 is dat 2.0.59
Daarna natuurlijk nog wel even apache herstarten:
/sbin/service httpd restart
Remote root? :)
Het ergste wat deze bug kan veroorzaken is volgens securityfocus dat je fout gesignde certificaten niet zou kunnen herkennen. Vooral client side dus. Gewoon upgraden als jouw distributie een update uitbrengt dus en niet in paniek geraken :p
http://www.securityfocus.com/bid/19849/info
http://www.openssl.org/source/openssl-.tar.gz
=> `openssl-.tar.gz'
Resolving www.openssl.org... 195.30.6.166
Connecting to www.openssl.org|195.30.6.166|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
21:54:56 ERROR 404: Not Found.
Zojuist even apt-get gedraaid en die maakte ook expliciet melding van de veiligheidslekken die in de nieuwe versie gedicht zijn! Ik zou iedereen willen aanraden om direct te upgraden, dit is een zeer ernstige bug/exploit!
sp-services
07/09/06, 22:07
apache 2.0.59 heeft een php include bug die nog niet direct opgelost is voor zover ik weet.
Zojuist even apt-get gedraaid en die maakte ook expliciet melding van de veiligheidslekken die in de nieuwe versie gedicht zijn! Ik zou iedereen willen aanraden om direct te upgraden, dit is een zeer ernstige bug/exploit!
yum update niet tot nu toe :)
Grote kans dat je Exim ook mag recompilen.
Waarom zou je iets moeten recompilen? De openssl libs worden dynamisch gelinkt met de andere applicaties. Herstarten is genoeg. Als je wilt weten welke applicaties gebruik maken van libssl dan doe je lsof |grep libssl
Updaten is wel aan te raden. Met een onjuiste key kun je nu zo inloggen
(22:50:45 ) [root@****] ~$ ssh -lroot -p22 server01.icehosting.nl
Last login: Thu Sep 7 19:44:26 2006 from ************
[root@server.icehosting.nl] ~# openssl version
OpenSSL 0.9.7e-p1 25 Oct 2004
Heb inmiddels verschillende adv. gelezen, op dit moment wordt hij nog steeds niet bestempeld als high crit.
Updaten is wel aan te raden. Met een onjuiste key kun je nu zo inloggen
jij hebt ook nog wat te doen :)
(23:58:19 ) [root@kostunrix] ~$ ssh root@xxxx.besthost.nl -p22 -i id_dsa_badcert
Last login: Thu Sep 7 22:41:49 2006 from 83.98.15x.xxx
[root@xxxx.besthost.nl] ~# openssl version
OpenSSL 0.9.7a Feb 19 2003
crazycoder
08/09/06, 00:07
Op het moment lopen erg veel webserver gevaar! Er is een bug ontdekt in OpenSSL, wat het mogelijk maakt door gebruik te maken van een bepaald certificaat en zo zonder wachtwoord in te loggen als root.
References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4339
http://www.openssl.org/news/secadv_20060905.txt
Alle versies tot 0.9.7j en 0.9.8b lopen gevaar !
En waar staat dat iemand zomaar als root in zou kunnen loggen? Ik heb het helaas nog niet kunnen ontdekken, het is op zich zeker mogelijk dat ik er overheen heb gelezen..
jij hebt ook nog wat te doen :)
(23:58:19 ) [root@kostunrix] ~$ ssh root@xxxx.besthost.nl -p22 -i id_dsa_badcert
Last login: Thu Sep 7 22:41:49 2006 from 83.98.15x.xxx
[root@xxxx.besthost.nl] ~# openssl version
OpenSSL 0.9.7a Feb 19 2003
Het is zorgwekkend. Ik heb op alle machines SSH maar uitgezet nu. Vannacht SSL updaten en SSH weer aanzetten.
Volgens mij ben ik stom want het werkt niet :( :P
http://www.openssl.org/source/openssl-.tar.gz
=> `openssl-.tar.gz'
Resolving www.openssl.org... 195.30.6.166
Connecting to www.openssl.org|195.30.6.166|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
21:54:56 ERROR 404: Not Found.
Het linkt werkt niet :)
Nee, die link mist ook het versienummer (dat moet achter de '-' komen)...
Alle versies voor 0.9.7k zouden geupdate moeten worden.
Voor de 0.9.8 versie alles voor 0.9.8c.
Om Apache te herbouwen hoef je slechts te doen:
cd /usr/local/directadmin/customapache
./build clean
./build apache
In geval je Apache 2 draait wordt dat laatste natuurljk:
./build apache_2
Eventueel kun je voor dat je opnieuw gaat bouwen eerst nog de laatste versie invullen in build. Voor Apache2 is dat 2.0.59
Daarna natuurlijk nog wel even apache herstarten:
/sbin/service httpd restart
Dit is al voldoende:
./build apache_mod_ssl && openssl version
Vreemde bug trouwens, neemt DirectAdmin deze update zelf ook nog mee, of moeten we elke nieuwe bak straks weer handmatig updaten?
Een beetje een overreactie hier. Het is idd een serieuze bug, maar de paniek die hier in deze thread heerst is er een klein beetje over... Lees eerst eens even door de advisory en zo, en trek je conclusies.
Een beetje een overreactie hier. Het is idd een serieuze bug, maar de paniek die hier in deze thread heerst is er een klein beetje over... Lees eerst eens even door de advisory en zo, en trek je conclusies.
Liever voorkomen dan genezen. ;)
Een beetje een overreactie hier. Het is idd een serieuze bug, maar de paniek die hier in deze thread heerst is er een klein beetje over... Lees eerst eens even door de advisory en zo, en trek je conclusies.
Paniek is nooit goed, maar het risico van deze bug/exploit moet niet onderschat worden. Het risico om root te krijgen op een willekeurige machine lijkt mij inderdaad niet heel erg groot. Wat wel een groot risico is, dat met deze bug/exploit de veiligheidsketen op internet in gevaar komt en dat is een enorm risico.
crazycoder
08/09/06, 09:14
Paniek is nooit goed, maar het risico van deze bug/exploit moet niet onderschat worden. Het risico om root te krijgen op een willekeurige machine lijkt mij inderdaad niet heel erg groot. Wat wel een groot risico is, dat met deze bug/exploit de veiligheidsketen op internet in gevaar komt en dat is een enorm risico.
Of men via de gevonden bug als root in kan loggen weet ik niet. Heb daar niets over gelezen.
Als je bang bent dat derden als root in proberen te loggen dan smijt je inkomend verkeer op poort 22 dicht, met als enige uitzondering je eigen IP adressen.
Het is hoe dan ook geen verkeerd idee om het derden onmogelijk te maken van ssh gebruik te maken.. Al was het alleen maar om de honderden ssh probes te stoppen.
Het is zeker zinvol om zo spoedig mogelijk openssl te upgraden. Maar de paniek die hier klinkt is op dit moment nog niet nodig.
dutchcrazytiger
08/09/06, 09:29
En helaas het best bewaarde geheim uit the scene is helaas naar boven gekomen .... Laat ik het erop houden dat wij deze manier vroeger gebruikten om tal van servers te gebruiken voor upload etc.
Dus om even iedereen weer bang te maken... het werkt op 90% van alle linux machines out of the box, en er zijn dus gewoon tooltjes voor. Echter kan ik je ook vertellen dat als je een machine wil overnemen je natuurlijk ook het ip spoofed.
Dit backdoortje bestaat dus al heel lang. Eerste keer dat wij hem zagen was ongeveer in januari 2002 ofzo. Toen was deze fout er dus al.... Of iig iets wat er heel scherp tegen aan ligt. Wij hebben in iedergeval genoeg exploits gezien.
@dutchcrazytiger: wat onderbouw graag... voorbeeldje van een scriptje en zo zou fijn zijn. Anders vind ik je maar wat uit je nek kletsen.
crazycoder
08/09/06, 10:07
Dus om even iedereen weer bang te maken... het werkt op 90% van alle linux machines out of the box, en er zijn dus gewoon tooltjes voor. Echter kan ik je ook vertellen dat als je een machine wil overnemen je natuurlijk ook het ip spoofed.
Natuurlijk spoof je even het IP.
Misschien wil je dan ook een aantal URL's geven over succesvolle methodes om IP adressen te spoofen en complete sessies probleemloos levend te houden..
Laatste keer dat ik er over las moest je er wel voor zorgen dat het gespoofde IP niet zou antwoorden.. maar misschien heb jij meer actuele informatie.
systemdeveloper
08/09/06, 10:28
je moet het gespoofde gewoon ip even bezig houden zodat hij geen tijd heeft om te antwoorden ;)
dutchcrazytiger is bij fleur op de koffie geweest denk ik
(ps dit heb ik niet gepost, dit is dmv spoofing gebeurd ik ben onschuldig!)
dutchcrazytiger is vast vergeten te vermelden dat dit alleen werkte met prot 1 en een handvol versies....
Er zijn er nog een hoop die wat te doen hebben :)
(11:07:22 ) [root@kostunrix] ~$ ssh root@xxxx.citus.nl -p22 -i id_dsa_badcert
Last login: Thu Sep 8 08:33:17 2006 from xxxxx.home.nl
[root@xxxx.citus.nl] ~# openssl version
OpenSSL 0.9.7e-p1 25 Oct 2004
TotallyHosted
08/09/06, 11:23
Protocol1 staat toch al jaren standaard uitgeschakeld?
jinxedworld
08/09/06, 11:25
Is dit hele verhaal dan alleen een issue met v1 en niet met v2? SSH staat er toch los van, of heb ik dat mis?
Volgensmij staat SSH hier ook los van en gaat dit alleen om OpenSSL voor Apache?!? (je kan gewoon openssl eruit gooien dus)
even voor de duidelijkheid aan een ieder, ik ga id_dsa_badcert niet verspreiden. Straks wordt ik aangewezen doordat velen dan ineens hun concurrent killen die een week eerder op msn zei dat hij een ************* **** ************* ************ *********** ** **** **** *************** ********** ********** ***** ** *** ** *** ******* ****** ******** ************* ******* ****** ********** *** *** ** **************** ** ************* ***** ****** ***** ******* is :)
MartijnRSD
08/09/06, 12:19
Is dit hele verhaal dan alleen een issue met v1 en niet met v2?
dat zou ik ook wel willen weten
dat zou ik ook wel willen weten
Als jullie nou eens daadwerkelijk lezen, en googlen, en wat security sites bekijken dat weet je in ieder geval wat er publiekelijk te vinden is. En welke versies daaronder vallen. Alles voorkouwen heeft geen zin, de schifting tussen diegene die het serieus nemen (hun vak) is bij dit soort posts gelijk zichtbaar.
MartijnRSD
08/09/06, 12:33
Beste Mike,
Al verschillende security sites gelezen over protocol niets gevonden, maar zal beter mijn best doen. Je conclusie is erg kort door de bocht
groet
martijn
Het is sowieso niet verstandig om root login überhaubt toe te staan. Gebruik liever je eigen 'henk' account en su - root vanuit user henk...
Ik heb de update gevolgd, maar als ik openssl version invoer, dan krijg ik weer 0.97k - 'OpenSSL 0.9.7k 05 Sep 2006'
Ik heb de update gevolgd, maar als ik openssl version invoer, dan krijg ik weer 0.97k - 'OpenSSL 0.9.7k 05 Sep 2006'
de kans is groot dat je vendor alleen de patch toegepast heeft, en dus dezelfde versie hanteert maar met een ander patch level.
Oh wacht.. Ik heb de post verkeerd gelezen, alle versies vóór 0.97k. Ik zit nu dus veilig! (bijna)
crazycoder
08/09/06, 15:42
de kans is groot dat je vendor alleen de patch toegepast heeft, en dus dezelfde versie hanteert maar met een ander patch level.
0.9.7k is de laatste versie ;)
0.9.7k is de laatste versie ;)
dat wil nog steeds niet zeggen dat je als je update met bijvoorbeeld REL dat je van a naar k gaat.... Bekijk de patch policy van RedHat er maar eens op na.
hoe date je up met debian en directadmin?
mvg
Gewoon compilen de boel net als op elk ander linux systeem.
# wget http://www.openssl.org/source/openssl-0.9.8c.tar.gz && tar -zxf openssl-0.9.8c.tar.gz && cd openssl-0.9.8c && ./config --prefix=/usr && make && make install
Naderhand even je services opnieuw compilen zodat de libraries daar ook goed worden gebruikt.
thanks best dat ik mijn andere servers uitbesteed ;)
Ook dan maar even mijn versie van de how-to gebruikmakend van update.script.
Getest met directadmin op Centos 4 & FC4
mkdir /usr/local/directadmin/customapache/update
cd /usr/local/directadmin/customapache/update
wget http://tools.web4host.net/update.script
chmod 755 update.script
./update.script OPENSSL
./update.script OPENSSH
cd ..
./build clean
./build update
./build all n
service httpd restart
Compiled openssl,apache,openssh,php.
Volgens mij moest openssh ook opnieuw gecompileerd worden, omdat deze bij versie info nog oude openssl leek te gebruiken.
Check even naderhand of je een nieuwe SSH connectie aan kan maken, *bij 1 test server was dat niet het geval, opgelost door nog een keer openssh te compilen. *
-----
Toen ik eerder naar 0.9.8 ben geupdate, werkte ssl in exim niet meer, weet iemand of dit probleem nog steeds speelt, en hoe het op te lossen is?
hoe date je up met debian en directadmin?
mvg
Doe je debian niet best gewoon via apt-get?
#apt-get update
#apt-get upgrade openssl
Reading Package Lists... Done
Building Dependency Tree... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Helaas... Of zou dit kunnen omdat OpenSSL bij mij uit de Plesk Base Packages komt? Zo ja, kan ik dan veilig een #apt-get install openssl uitvoeren zonder mijn plesk-installatie te verkrachten (en dat straks ook de plesk updater nog gewoon werkt)?
IceHosting
09/09/06, 00:07
Toen ik eerder naar 0.9.8 ben geupdate, werkte ssl in exim niet meer, weet iemand of dit probleem nog steeds speelt, en hoe het op te lossen is?
Ook die opnieuw bouwen ;)
Reading Package Lists... Done
Building Dependency Tree... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Helaas... Of zou dit kunnen omdat OpenSSL bij mij uit de Plesk Base Packages komt? Zo ja, kan ik dan veilig een #apt-get install openssl uitvoeren zonder mijn plesk-installatie te verkrachten (en dat straks ook de plesk updater nog gewoon werkt)?
Voer gewoon de commando's uit vande eerste post. Plesk is niet afhankelijk van openssl.
na het rebuilden van apache kom ik bij het opstarten echter de volgende error tegen:
serv01:/usr/local/directadmin/customapache# /etc/init.d/httpd start
Starting httpd: Error: Apache has not been designed to serve pages while
running as root. There are known race conditions that
will allow any local user to read any file on the system.
If you still desire to serve pages as root then
add -DBIG_SECURITY_HOLE to the EXTRA_CFLAGS line in your
src/Configuration file and rebuild the server. It is
strongly suggested that you instead modify the User
directive in your httpd.conf file to list a non-root
user.
serv01:/usr/local/directadmin/customapache#
opgelost,
was een verkeerde instelling in etc/passwd
CentOS heeft een openssl update uitgebracht. (yum update)
dutchcrazytiger
11/09/06, 08:55
Waarom een script plaatsen:P je hoeft naast het certificate verder niets naders te doen. Daarnaast werkte het gebruiken van een te groot certificaat dat geen meervoud van 2 is ook redelijk goed.
Gewoon er dus voor zorgen dat hij extern (*optie in ssl/sshd) controleert op geldigheid en daarna voorals nog door zijn unix/pam gaat in plaats van jeh log maar gelijk in.
Daarentegen wil ik de mensen erop wijzen dat het hier niet alleen om SSH1 gaat maar ook om SSH2. Tenminste als je certificaat dat je maakte de zelfde processing aanging om het cert te verifieren.
Ik ga hier inderdaad niet het certificaat plakken maar google er maar eens op of kijk op milworm ;) daar stond hij heeel mooi vermeld. Misschien een tip voor jullie allemaal en voor wie milworm nog niet kende, moet zich schamen. Daar staan toch wel de meest laatste echte leaks in de hosting branch op vermeld zodat mensen uit de scene vrij makkelijk naar binnen kunnen. En voor diegenen die graag een scriptje wouden... be happy... die zit er bij ;)
CentOS heeft een openssl update uitgebracht. (yum update)
8 september al, en je blijft nog steeds op 0.9.7a zitten ;) . let wel op deze is geptached.
8 september al, niks van gemerkt. Ik had op 9 en 10 september yum update gedaan, maar geen openssl te bekennen.
Kijk eens of je de update channel wel gebruikt en niet alleen de base.
Help Help Help !
Ik heb alles gedaan oop rebuild apache en dan httpd restart
maar ik krijg dit error :
Starting httpd: Syntax error on line 81 of /etc/httpd/conf/httpd.conf:
Cannot load /usr/lib/apache/libphp4.so into server: libssl.so.4: cannot open shared object file: No such file or directory
[FAILED]
FransVanNispen
11/09/06, 15:54
ff 'yum update openssl' uitvoeren, dan ben je in ieder geval weer werkend.
Meeste distro's zijn inmiddels weer up-to-date
Sorry je snapt me niet.
Ik heb alles gedaan wat in je 1ste post staat.
En daarna httpd restart maar toen kreeg ik dat error.
Mijn httpd staat nu helaas uit !!
Daarna heb ik build all gedaan en dan krijg ik dit error :
chmod 755 /usr/lib/apache/libphp4.so
cp /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.bak
cp /etc/httpd/conf/httpd.conf.new /etc/httpd/conf/httpd.conf
rm /etc/httpd/conf/httpd.conf.new
Installing PHP CLI binary: /usr/local/bin/
Installing PHP CLI man page: /usr/local/man/man1/
Installing PEAR environment: /usr/local/lib/php/
/usr/local/directadmin/customapache/php-4.4.3/sapi/cli/php: error while loading shared libraries: libssl.so.4: cannot open shared object file: No such file or directory
make[1]: *** [install-pear-packages] Error 127
make: *** [install-pear] Error 2
*** The install has failed, do you want to try to install it again? (y,n):
Trouwens yum update openssl
Setting up Update Process
Setting up repositories
Reading repository metadata in from local files
Excluding Packages in global exclude list
Finished
Could not find update match for openssl
No Packages marked for Update/Obsoletion
ff 'yum update openssl' uitvoeren, dan ben je in ieder geval weer werkend.
Meeste distro's zijn inmiddels weer up-to-date
ik zou het erg prettig vinden als je uit je start post haalt dat je als root in kan loggen dmv een bugged cert. Dit wordt nergens beschreven, als je alles leest staat er alleen dat een een prove is geleverd dat de handeling van cert niet correct is. Niet wat er daadwerkelijk gebeurd. Dit is onnodig bang makerij!
Sorry je snapt me niet.
Ik heb alles gedaan wat in je 1ste post staat.
En daarna httpd restart maar toen kreeg ik dat error.
Mijn httpd staat nu helaas uit !!
Daarna heb ik build all gedaan en dan krijg ik dit error :
chmod 755 /usr/lib/apache/libphp4.so
cp /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.bak
cp /etc/httpd/conf/httpd.conf.new /etc/httpd/conf/httpd.conf
rm /etc/httpd/conf/httpd.conf.new
Installing PHP CLI binary: /usr/local/bin/
Installing PHP CLI man page: /usr/local/man/man1/
Installing PEAR environment: /usr/local/lib/php/
/usr/local/directadmin/customapache/php-4.4.3/sapi/cli/php: error while loading shared libraries: libssl.so.4: cannot open shared object file: No such file or directory
make[1]: *** [install-pear-packages] Error 127
make: *** [install-pear] Error 2
*** The install has failed, do you want to try to install it again? (y,n):
Trouwens yum update openssl
Setting up Update Process
Setting up repositories
Reading repository metadata in from local files
Excluding Packages in global exclude list
Finished
Could not find update match for openssl
No Packages marked for Update/Obsoletion
probeer eerst eens ./build clean
Wat ik nu heb gedaan is :
./build clean
rm php-4.4.3/ -rf
./build update
./build all
Dan gaat alles goed behalve als ik hier ben :
You may want to add: /usr/local/lib/php to your php.ini include_path
Installing build environment: /usr/local/lib/php/build/
Installing header files: /usr/local/include/php/
Installing helper programs: /usr/local/bin/
program: phpize
program: php-config
Installing man pages: /usr/local/man/man1/
page: phpize.1
page: php-config.1
PHP Installed.
*** Cannot find /usr/local/directadmin/customapache/mod_perl-1.0-current.tar.gz. Aborting ***
[****@**** customapache]#
Arto,
./build update_data
ls mod_perl*
ff als root ingelogged met een fake cert en voila:
[****@**** customapache]# ./build update_data
*ff wachten*
[****@**** customapache]# ls mod_perl*
mod_perl-1.0-current.tar.gz
:)
httpd werkt nu alleen exim gaat telkens zelf stopen.
# wget http://perl.apache.org/dist/mod_perl-1.0-current.tar.gz
wget: error while loading shared libraries: libssl.so.4: cannot open shared object file: No such file or directory
@Zorin
Als ik ls mod_perl* doe krijg ik : ls: mod_perl: No such file or directory
Edit :
Ik heb mod_perl-1.0-current.tar.gz handmatig erop gegooid.
Nu krijg ik # ls mod_perl*
mod_perl-1.0-current.tar.tar
Maar wekl mod_perl-1.0-current.tar.tar in het rood.
Wat moet ik nu doen?
Je build script gebruikt wget, wget lijkt gelinkt te zijn aan openssl.
Fetch werkt dan wel vermoed ik?
Geen enige idee als ik nu ./build update doe krijg ik dit :
./build update
wget: error while loading shared libraries: libssl.so.4: cannot open shared object file: No such file or directory
wget: error while loading shared libraries: libssl.so.4: cannot open shared object file: No such file or directory
mv: cannot stat `build.new': No such file or directory
File already exists: apache_1.3.37.tar.gz
File already exists: configure.apache_ssl
File already exists: configure.php
File already exists: mod_frontpage.c
File already exists: Makefile.tmpl.patch
File already exists: frontpage.patch
File already exists: fp-patch-apache_1.3.22
File already exists: fp-patch-suexec
File already exists: httpd
File already exists: httpd_freebsd
File already exists: httpd_debian
File already exists: mime.types
Downloading mod_perl-1.0-current.tar.gz...
wget: error while loading shared libraries: libssl.so.4: cannot open shared object file: No such file or directory
Fileserver is down, using the backup file server..
wget: error while loading shared libraries: libssl.so.4: cannot open shared object file: No such file or directory
File already exists: mod_ssl-2.8.28-1.3.37.tar.gz
File already exists: curl-7.15.5.tar.gz
File already exists: gd-2.0.33.tar.gz
File already exists: libmcrypt-2.5.7.tar.gz
File already exists: mhash-0.9.1.tar.gz
File already exists: zziplib-0.10.82.tar.gz
File already exists: php-4.4.3.tar.gz
File already exists: mod_frontpage-1.6.1.tar.gz
File already exists: fp50.linux.tar.gz
File already exists: webalizer-2.01-10-src.tgz
Moet ik nu gewoon ./build all pakken?
Edit :
Ondaks ik mod_perl-1.0-current.tar.gz. in het juiste map heb geupload krijg ik toch het error.
*** Cannot find /usr/local/directadmin/customapache/mod_perl-1.0-current.tar.gz. Aborting ***
Controleer na de update ff je mail logs op het volgende:
smtp transport process returned non-zero status 0x000b: terminated by signal 11
Deze mails werden niet afgelerverd op bepaalde servers na de update.
Na een rebuild van exim werkt alles weer.
weet niet 100% of dit er mee te maken heeftmaar is wel toevallig..
Alles werkt nu behalve exim.
Ik kan ook geen mails versturen en in Direct Admin service panel zie ik ook dat exim is gesopt en niet kan worden gestart.
Zia error log :
/usr/sbin/sendmail: error while loading shared libraries: libssl.so.4: cannot open shared object file: No such file or directory
/usr/sbin/sendmail: error while loading shared libraries: libssl.so.4: cannot open shared object file: No such file or directory
/usr/sbin/sendmail: error while loading shared libraries: libssl.so.4: cannot open shared object file: No such file or directory
Na update exim werkt exim ook weer :
wget http://files.directadmin.com/servic...-4.60-1.src.rpm
rpm -ivh da_exim-4.60-1.src.rpm
cd /usr/src/redhat/SPECS
rpmbuild -bb exim.spec
cd /usr/src/redhat/RPMS/i386
rpm -Uvh --force --nodeps da_exim-4.60-1.i386.rpm
Alleen wget werkt niet ik heb heb zelf geupload.
wget http://files.directadmin.com/servic...-4.60-1.src.rpm
wget: error while loading shared libraries: libssl.so.4: cannot open shared object file: No such file or directory
FromTheSun
15/09/06, 14:45
Waarom ./build ?
make is toch het commando?
FransVanNispen
15/09/06, 14:49
./build start het DirectAdmin script. Dit voert inderdaad o.a. een make uit voor diverse onderdelen, maar doet nog veel meer.
./build start het DirectAdmin script. Dit voert inderdaad o.a. een make uit voor diverse onderdelen, maar doet nog veel meer.
Nogmaals:
ik zou het erg prettig vinden als je uit je start post haalt dat je als root in kan loggen dmv een bugged cert. Dit wordt nergens beschreven, als je alles leest staat er alleen dat een een prove is geleverd dat de handeling van cert niet correct is. Niet wat er daadwerkelijk gebeurd. Dit is onnodig bang makerij!
FransVanNispen
15/09/06, 16:43
Wat is het nut om na een week dat aan te passen? En omdat je het niet kunt vinden, wil dat nog niet zeggen dat het niet kan.
Aangezien ik op deze bug werd gewezen een aantal dagen voordat het probleem op de security lijsten gemeld werd, door een collega hoster die een persoonlijke demonstratie heeft gehad dat dit wel degelijk mogelijk is, lijkt het mij niet overbodig dit gewoon te laten staan.
Wat is het nut om na een week dat aan te passen? En omdat je het niet kunt vinden, wil dat nog niet zeggen dat het niet kan.
Aangezien ik op deze bug werd gewezen een aantal dagen voordat het probleem op de security lijsten gemeld werd, door een collega hoster die een persoonlijke demonstratie heeft gehad dat dit wel degelijk mogelijk is, lijkt het mij niet overbodig dit gewoon te laten staan.
dan bestempel ik het gewoon als broodje aap, ik heb al eerder in deze thread aangegeven of je je start post aanpaste. En die collega webhoster was die niet die zelf gehacked was ? Hear-say verhalen ... zeker demotje gehad omtrendt protocol 1..
FransVanNispen
15/09/06, 17:10
Je moet helemaal zelf weten wat je met de info doet. Als je zelf niet de moeit e wilt nemen om te updaten omdat je denkt dat wat hier staat onzin is, ok.
Ter informatie: het 'fout afhandelen van certificaten' zorde ervoor dat deze werden gepassed als valid. Maak er zelf maar van hoe groot dat risico is.
Ik heb niet meet gedaan dan mijn conculega's via deze weg er dringend op te wijzen dat het een groot security issue is en ze tevens het zoekwerk te besparen om de update te kunnen doen voordat alle mainstream distro's hun packages up to date hebben.
Overigens staat het overgrote deel van alle servers protocol 1 gewoon toe. Ook een standaard DirectAdmin installatie!
crazycoder
15/09/06, 17:43
Wat is het nut om na een week dat aan te passen? En omdat je het niet kunt vinden, wil dat nog niet zeggen dat het niet kan.
Aangezien ik op deze bug werd gewezen een aantal dagen voordat het probleem op de security lijsten gemeld werd, door een collega hoster die een persoonlijke demonstratie heeft gehad dat dit wel degelijk mogelijk is, lijkt het mij niet overbodig dit gewoon te laten staan.
Het minimale wat wij van mods die dergelijke informatie posten verwachten is dat zij dat zo objectief mogelijk doen. Zoals jij het schreef lijkt het meer een hoax.
Jij claim in jouw openings post dat iets kan terwijl het via geen enkele andere bron (bijv. bugtraq) bevestigd wordt. Kortom: bewijs het of beweer het niet.
Het verspreiden van informatie over gevaren die zouden bestaan noemen wij paniek zaaien.
Het zou je sieren als je controleerbare informatie plaats en niet teveel in zou spelen op sentimenten.
Jij heb overigens gelijk dat iets wat (nog) niet bekend is wel degelijk mogelijk is. Maar dan schrijf je dat op een andere manier.
Ik ben het voor de verandering volledig met mikey eens.
Dat je erop gewezen bent eerder dan op security lijsten vind ik niet zo heel gek. Secunia heeft op 7 september rits mailingen gedaan dat de major distro's updates beschikbaar gesteld hebben. Op openssl.org valt te lezen dat deze melding op 05 september al gedaan is. Als deze bug dusdanig was waarom komt redhat pas 2 dagen later met een redelijke simpele update ? Dat terwijl ze genoeg betaalde subscriptions hebben waarin grote bedrijven gebruik van maken. Is dat dan moedwilleg wachten tot je produkt gecracked wordt ? Not crititcal == geen haast. Hij is niet voor niets bestempeld als "Less critical".
En ik doe inderdaad wat ik doe met de info, relativeren. Misschien dat je de mailing list bij openssl er eens op naslaat. Tot nu toe geen enkele user die gecracked is met een cert en waarbij de atackker root werd. Misschien hebben we het alleen over een buffer/ stack.
relativeren frans, relativeren frans.
crazycoder
15/09/06, 17:47
Overigens staat het overgrote deel van alle servers protocol 1 gewoon toe. Ook een standaard DirectAdmin installatie!
Je bent niet goed bij je hoofd als je een standaard install zonder enige aanpassing online zet.
Overigens staat het overgrote deel van alle servers protocol 1 gewoon toe. Ook een standaard DirectAdmin installatie!
Ik zie de link directadmin niet in dit verhaal, dit is een distro instelling en geen da instelling !
FransVanNispen
15/09/06, 18:32
Op het moment van posten was niet meer info beschikbaar over de bug. Wat ik uit betrouwbare bron heb is dat het wel degelijk mogelijk is. Of dit nu met protocol 1 was of niet, doet er niet toe.
Een dag of 3 nadat wij op de hoogte gesteld waren, kwamen de eerste berichten binnen dat er inderdaad een probleem was met OpenSSL, waarop wij met spoed een laatste versie zijn gaan installeren.
In de samenloop van omstandigheden achtte ik het wel degelijk nodig om de OP op deze manier weg te zetten.
Of je nu wél of niet als root kunt, vind ik persoonlijk op dit moment niet relevant meer. De post is gedaan met wat op dat moment bekend was. Wij hebben de waarschuwing van onze conculega in ieder geval serieus genomen.
Inmiddels zijn zowat alle systemen geüpdate. Het op dit moment nog aanpassen van de OP is daarom volgens mij niet noodzakelijk.
Je bent niet goed bij je hoofd als je een standaard install zonder enige aanpassing online zet.
Nergens staat dat wij een standaard install gebruiken. En dit staat volledig lost van dit topic.
Ik zie de link directadmin niet in dit verhaal, dit is een distro instelling en geen da instelling !
Ik zou zeggen, leest de openings post en je eigen reacties terug.
Dit is een DA topic omdat het gaat over 'Hoe update ik OpenSSL op een DA machine'.
DA modificeert óók je SSH config. Of protocol 1 aan of uit staat heeft daar dus wel degelijk mee te maken. Wij zelf schakelen protocol 1 en root access standaard uit voordat we een server opleveren.
Maar aangezien jullie het nodig achten om hierover een elle lange wellus-nietus discussie te voeren, zal ik de OP wel even aanpassen.
Kan ik weer verder met zoeken naar een structurele oplossing voor de laatse cruciale bug in PHP4 en PHP5 waar nog steeds geen officiële fix voor is uigebracht op de download site.
Zal wel niet belangrijk worden gevonden door de grote distro's, dat je met 4 regels php code Safe Mode kunt uitschakelen op alle PHP versies tot en met PHP5.1.6 en PHP4.4.4.
Of je nu wél of niet als root kunt, vind ik persoonlijk op dit moment niet relevant meer. De post is gedaan met wat op dat moment bekend was. Wij hebben de waarschuwing van onze conculega in ieder geval serieus genomen.
Bedank deze collega maar vast voor onnodig bangmakerij. Het muisje werd langzamerhand een olifant.
Vermeld in het vervolg er maar bij wij hebben van een conculega vernomen blablabla...
Zal wel niet belangrijk worden gevonden door de grote distro's, dat je met 4 regels php code Safe Mode kunt uitschakelen op alle PHP versies tot en met PHP5.1.6 en PHP4.4.4.
in road map van 6 is safe mode weg, er zijn genoeg alternatieven, like suphp, mod_suid, mod_ruid rsbak grsec etc etc. Ik en vele andere weten heel goed dat je je beveiliging niet moet toespitsen op safemode. Misschien dat verschillende major distro's hetzelfde hierin denken ?
//edit DA past in jouw sshd_config alleen aan zodat je niet meer met root in kan loggen. Prot nr;s blijven onaangetast.
FransVanNispen
15/09/06, 20:51
Het is dus duidelijk dat je niet op de hoogte bent van DA. Het niet kunnen inloggen met root is iets wat je écht zelf moet aanpassen nadat DA is geïnstalleerd.
Waar staat dat onze beveiliging alleen afhangt van Safe Mode ? Mijn punt hier is dat er een behoorlijk lek in zit dat het toestaat om safe mode zelf uit te schakelen. Dit is al meer dan een week bekend, maar toch is er nog geen update op de PHP website of door de grote distro's.
Ik vind dit een cruciale bug. Dat een distro of website er dus geen haast mee maakt, wil dus niet zeggen dat het geen groot probleem is of kan zijn.
Maar dit gaat nergens meer over. Punt is gemaakt. OP is aangepast. Conculega's zijn gewaarschuwd.
Deze mag weer ontopic over OpenSSL upgrade vragen en problemen, anders gaat er een slotje op.
Het is dus duidelijk dat je niet op de hoogte bent van DA. Het niet kunnen inloggen met root is iets wat je écht zelf moet aanpassen nadat DA is geïnstalleerd.
Waar staat dat onze beveiliging alleen afhangt van Safe Mode ? Mijn punt hier is dat er een behoorlijk lek in zit dat het toestaat om safe mode zelf uit te schakelen. Dit is al meer dan een week bekend, maar toch is er nog geen update op de PHP website of door de grote distro's.
Ik vind dit een cruciale bug. Dat een distro of website er dus geen haast mee maakt, wil dus niet zeggen dat het geen groot probleem is of kan zijn.
Maar dit gaat nergens meer over. Punt is gemaakt. OP is aangepast. Conculega's zijn gewaarschuwd.
Deze mag weer ontopic over OpenSSL upgrade vragen en problemen, anders gaat er een slotje op.
Dan mag je mij eens uitleggen wat DA wel aanpast aan jouw sshd_config . Er staat me echt iets van bij dat de bsd installer dat namelijk wel doet. Tevens vind ik jouw uitspraak Het is dus duidelijk dat je niet op de hoogte bent van DA een gewaagde en vooral kortzichtig. Ik wil je best een keer uitnodigen om in mijn portfolio te loeren. Zowel hosts als beheerde/ reeds geinstalleerde licenses.
Waar staat dat onze beveiliging alleen afhangt van Safe Mode ?
Waar staat mijn conclusie dat jouw beveiliging daarvan afhangt. Ik geef een mogelijke aanleiding waarom de mainstream distro's geen haast hebben bij een update. Ik trek in geen enkele post de conclusie dat jouw beveiliging op die manier werkt. Die conclusie heb je zelf gemaakt niet ik. Dat kan ik niet, want ik weet niet hoe jij je servers beheert / installeerd.
FransVanNispen
16/09/06, 01:57
@Mikey,
In BSD is het standaard niet mogelijk om als root in te loggen. Tevens moeten users daar deel uitmaken van de wheel group om root commando's uit te kunnen voeren.
Op bijv CentOS is dit niet het geval. Daar staat in de ssh config root login standaard aan, evenals protocol 1 + 2. DA voegt alleen AllowUsers root en AllowUsers admin toe.
Dit berust dus duidelijk op een misverstand en expertise op verschillende distributies. Ik neem mijn uitspraak dan ook terug.
Ik wil graag een keer met je babbelen over DirectAdmin, security en andere technische zaken. Maar laten we dat nu niet verder in dit topic doen en hier gewoon nu on topic blijven.
aight :) , ik ben moe en ga nu iemand anders lastig vallen ;)
Nog even een reactie over dit bericht.
Op dit moment hebben we de OpenSSL geupdate echter wanneer er gekeken word bij de phpinfo.php staat er voor de rest overal de nieuwe versie echter niet bij het kopje Openssl
Hier staat nog gewoon:
openssl
OpenSSL support enabled
OpenSSL Version OpenSSL 0.9.7a Feb 19 2003
Nog even een reactie over dit bericht.
Op dit moment hebben we de OpenSSL geupdate echter wanneer er gekeken word bij de phpinfo.php staat er voor de rest overal de nieuwe versie echter niet bij het kopje Openssl
Hier staat nog gewoon:
openssl
OpenSSL support enabled
OpenSSL Version OpenSSL 0.9.7a Feb 19 2003
PHP rebuilden? :)
cd /usr/local/directadmin/customapache
./build clean
./build php n
FromTheSun
19/09/06, 09:06
./build start het DirectAdmin script. Dit voert inderdaad o.a. een make uit voor diverse onderdelen, maar doet nog veel meer.
Waar kan ik precies vinden wat het dan allemaal doet?