vicidial.org

Not trying to incite panic here but this is serious.

All system admins if your vicidial is exposed to the web and has https:// runing your system can be compromised. A new bug in openssl allows reading of your mysql user and password. We were able to exploit our own servers in about 5 minutes with this bug. We were able to get the vicidail database user and password for mysql as well as usernames and passwords of managers logged into vicidial.

vicibox by default has https enabled so this effects you whether your using it or not.

to check and see if your effected run:

Code: Select all

openssl version


if you get:
OpenSSL 1.0.1e 11 Feb 2013

Your server is vulnerable.

The bug exists in openssl 101e opensuse has not patched it as of now. 04/08/2014 12:30 pm PST..

You can either disable https or compile openssl.. We chose to compile it...

Compile at your own risk.. However its a bigger risk IMHO to sit on your hands and wait for a patch.

Log out all agents before doing this..

Code: Select all

zypper si openssl
cd /usr/src
wget http://www.openssl.org/source/openssl-1.0.1g.tar.gz
tar xvzf openssl-1.0.1g.tar.gz
cd openssl-1.0.1g/
./config --prefix=/usr/
make
make install
reboot


Vicibox 4.0.3 has version: OpenSSL 1.0.0k

Heartbeat was implemented in ... OpenSSL 1.0.1 and later versions only.

In theory this means 4.0.3 is NOT vulnerable.

5.0.3, on the other hand, is apparently involved (OpenSSL 1.0.1e 11 Feb 2013). Uninstalling is a good idea, or perhaps recompiling (with the "heartbeat" function disabled) or installing a newer version (which unfortunately is not yet available in SuSE via zypper ...), but mostly Be Sure There Are No Badguys able to attempt to hack your server.

DGG or whitelisting: http://www.viciwiki.com/index.php/DGG

Of course, you can:
zypper up openssl
Which will upgrade openssl to openssl-1.0.1e-1.44.1.x86_64.rpm, but that is still "e" and I have not checked to see if this patch solves the problem. Easier to perform a full upgrade than to Test, since the upgraded version is theoretically fixed.

That being said, the instructions provided by the good amjohnson appear to work nicely in Vicibox 5.0.3. For the record, however, they are not just "compile" actually, they are "install new version from source", as the previously installed software package is being ignored ... the first line supplied (zypper si openssl) may not actually do anything as it is designed to download the source for the installed software package ... but then two lines later we download a new source package! LOL). It does work,though
[later note: apparently it installs without flaw, but is not actually used ... which means the upgrade was not successful]

The first line gets all the prereqs to compile Thats the only reason for the 'zypper si openssl' if the system is missing anything to compile openssl then it will be installed..

We skipped it. The rest still executed without flaw. Vicibox 5.0.3.

BTW if you read my post 1.0.1e is an effected version with the bug.. I believe you need to be at 1.0.1g but not sure about f

I am aware. That's why I said Vicibox 5.0.3 is affected, it has that version. But 4.0.3 is NOT affected because it is 1.0.0 and the bug was introduced in 1.0.1. Then fixed at 1.0.1g (which is not yet available as an auto-install via zypper in OpenSuSE 12.3 ... which is Vicibox's OS/version).

OK, after due diligence was performed, the previous code did not actually update the installed SSL, it installed a parallel version (wrong location) as it is not configured for SuSE at all. Using which openssl will still result in the original package and phpinfo(); will result in the original package version as well. Bummer.

It was a prefix issue... I changed the first post to reflect the required changes. it should now work just fine.

Cool. Can you confirm all modules replaced? I still show 1.0.1e in phpinfo() on our test server after the installation (and uninstalling 1.0.1e, and a reboot)

Code: Select all

OpenSSL support  enabled 
OpenSSL Library Version  OpenSSL 1.0.1e 11 Feb 2013 
OpenSSL Header Version  OpenSSL 1.0.1e 11 Feb 2013 


I ran the exploit on my servers after installing that it shows it patched now so that is something.. I will look into the php module and see what else needs to happen..

I suspect phpinfo is getting that from header data at compile time, the version in the source is wrong or it was compiled with the library staticly linked.

Here is the file list for the openssl RPM obtained from rpmfind.net

/etc/ssl
/etc/ssl/certs
/etc/ssl/openssl.cnf
/etc/ssl/private
/usr/bin/c_rehash
/usr/bin/openssl
/usr/share/doc/packages/openssl
/usr/share/doc/packages/openssl/AVAILABLE_CIPHERS
/usr/share/doc/packages/openssl/CHANGES
/usr/share/doc/packages/openssl/CHANGES.SSLeay
/usr/share/doc/packages/openssl/INSTALL
/usr/share/doc/packages/openssl/INSTALL.DJGPP
/usr/share/doc/packages/openssl/INSTALL.MacOS
/usr/share/doc/packages/openssl/INSTALL.NW
/usr/share/doc/packages/openssl/INSTALL.OS2
/usr/share/doc/packages/openssl/INSTALL.VMS
/usr/share/doc/packages/openssl/INSTALL.W32
/usr/share/doc/packages/openssl/INSTALL.W64
/usr/share/doc/packages/openssl/INSTALL.WCE
/usr/share/doc/packages/openssl/LICENSE
/usr/share/doc/packages/openssl/NEWS
/usr/share/doc/packages/openssl/README
/usr/share/doc/packages/openssl/README.SuSE
/usr/share/man/man1/asn1parse.1ssl.gz
/usr/share/man/man1/ca.1ssl.gz
/usr/share/man/man1/crl.1ssl.gz
/usr/share/man/man1/crl2pkcs7.1ssl.gz
/usr/share/man/man1/dgst.1ssl.gz
/usr/share/man/man1/dhparam.1ssl.gz
/usr/share/man/man1/dsa.1ssl.gz
/usr/share/man/man1/dsaparam.1ssl.gz
/usr/share/man/man1/enc.1ssl.gz
/usr/share/man/man1/gendsa.1ssl.gz
/usr/share/man/man1/genrsa.1ssl.gz
/usr/share/man/man1/nseq.1ssl.gz
/usr/share/man/man1/openssl.1ssl.gz
/usr/share/man/man1/passwd.1ssl.gz
/usr/share/man/man1/pkcs12.1ssl.gz
/usr/share/man/man1/pkcs7.1ssl.gz
/usr/share/man/man1/pkcs8.1ssl.gz
/usr/share/man/man1/rand.1ssl.gz
/usr/share/man/man1/req.1ssl.gz
/usr/share/man/man1/rsa.1ssl.gz
/usr/share/man/man1/rsautl.1ssl.gz
/usr/share/man/man1/s_client.1ssl.gz
/usr/share/man/man1/s_server.1ssl.gz
/usr/share/man/man1/smime.1ssl.gz
/usr/share/man/man1/spkac.1ssl.gz
/usr/share/man/man1/verify.1ssl.gz
/usr/share/man/man1/version.1ssl.gz
/usr/share/man/man1/x509.1ssl.gz
/usr/share/man/man3/crypto.3ssl.gz
/usr/share/man/man3/dsa.3ssl.gz
/usr/share/man/man3/rand.3ssl.gz
/usr/share/man/man3/rsa.3ssl.gz
/usr/share/man/man3/ssl.3ssl.gz
/usr/share/man/man3/x509.3ssl.gz
/usr/share/man/man5/config.5ssl.gz
/usr/share/ssl
/usr/share/ssl/misc
/usr/share/ssl/misc/CA.pl
/usr/share/ssl/misc/CA.sh
/usr/share/ssl/misc/c_hash
/usr/share/ssl/misc/c_info
/usr/share/ssl/misc/c_issuer
/usr/share/ssl/misc/c_name
/usr/share/ssl/misc/tsget

All of mine seem to have the correct date. (04/08/2014). Altho admittedly I didn't check the doc files... lol
Also libopenssl1_0_0 have the correct date..

/lib64/engines
/lib64/engines/lib4758cca.so
/lib64/engines/libaep.so
/lib64/engines/libatalla.so
/lib64/engines/libcapi.so
/lib64/engines/libchil.so
/lib64/engines/libcswift.so
/lib64/engines/libgmp.so
/lib64/engines/libgost.so
/lib64/engines/libnuron.so
/lib64/engines/libpadlock.so
/lib64/engines/libsureware.so
/lib64/engines/libubsec.so
/lib64/libcrypto.so.1.0.0
/lib64/libssl.so.1.0.0

Am I missing anything?

I know when I upgraded some of my Ubuntu servers there was quite a bit of things that went in also but some of them had not been updated in awhile. I will check in depth what the package manager updated tomorrow.

I can say this tho, the exploit no longer works on my servers against https port 443 on my servers.

I even tried recompiling PHP and it didnt change what phpinfo is reporting..

I may try building a Custom Vicibox 5.0.3 install cd with openssl and php compiled with the latest version for openssl and put it on a test server and see what happens.. I will let you know.

LOL. A "Feature" of PHP ... somehow a header is locked. But if you tested before and after and the vulnerability was gone after, I'd say that says enough. The persistent version notation is annoying, though.

This website provides a tool to check if a site is effected:

http://filippo.io/Heartbleed/

Here is the security announce from opensuse:

http://lists.opensuse.org/opensuse-secu ... 00005.html

and a link to how to update opensuse:

http://lists.opensuse.org/opensuse-secu ... 00004.html

In the future it would be useful if you could link the CVE that was used in your post so I can see if it's being rolled into the packages so that everyone can get it on a zypper up eventually.

The CVE is here: http://cve.mitre.org/cgi-bin/cvename.cg ... -2014-0160


The patch has been applied to latest versions of openssl in OpenSuSE v.12.3 and 13.1. The thread is here: http://lists.opensuse.org/opensuse-secu ... 00004.html

So, do a 'zypper refresh' followed by 'zypper in -t patch openSUSE-2014-277' to install the SSL patch. It should also be pulled in by a normal 'zypper up'.

I'll verify the patch later. I have to update my internal repo's before I can do testing.

And then get a new cert, as the fix says. If you are self-signed:

Code: Select all

gensslcert -n sample.linuxsuperserver.com

And restart apache

using your domain name, of course, but since you're self-signed the cert will still toss an error even with the proper domain name.

Confirmed to fix the bug. Here's what you do

1) zypper refresh
2) zypper up
3) rcapache2 restart

And done. As a follow up you can create new SSL keys for a more full fix.

Yea the fix is now in the repos and at the time I wrote the original message opensuse was quiet on the matter and the fix was not in the repos..

I reinstalled the repo version to keep everything uniform.

Good work, too.

Have you tested Kumba's solution to see if the zypper up (after asterisk install) will break asterisk? We'll likely be testing later this evening.