Wednesday, April 16, 2014

Heartbleed vulnerability status on IBM Sametime and IBM Connections

I´ve done some investegating regarding whether or not IBM Sametime and Connections are vulnerable when it comes to the Heartbleed OpenSSL security issue. 

IBM Sametime:
IBM Sametime consists of
  • IBM Domino Server + Community Server on top
  • IBM DB2 Server
  • IBM Websphere as base for the Meeting, Proxy, Media Manager SP+CF, VMGR
  • VMGR also uses SolidDB
  • MCU server, which is Polycom based.
  • Linux servers, either RHEL or SLES.

Regarding the WebSphere parts of the solution, IBM sametime is not vulnerable:
http://www-01.ibm.com/support/docview.wss?&uid=swg21669774

Regarding the Domino Server part of the solution, IBM Sametime IBM sametime is not vulnerable:
http://www-01.ibm.com/support/docview.wss?uid=swg21669782

But, if you have enabled the Community Server to use TLS, you are vulnerable:
http://www-01.ibm.com/support/docview.wss?uid=swg21670015
By default, TLS is not enabled btw. So if you haven´t configured TLS manually for the Community Server, you´re in the clear.

IBM also says, in the same link as the Community Server impact document above, that:
No other versions/servers of IBM Sametime are vulnerable to CVE-2014-0160.
Which is good! But I have not found anything regarding the Polycom MCU server yet. I really would like to read something regarding all the components of the Sametime 9 Solution and not just a general phrase like that.


The MCU server requirements does have OpenSSL libraries on the requirements list:
http://www-01.ibm.com/support/docview.wss?uid=swg21650340

The libraries that gives me concern are:
  • openssl-0.9.8e-*.el5_9.1.x86_64.rpm
  • openssl-0.9.8e-*.el5_9.1.i386.rpm
I did some digging, and found this post:
http://www.bit-tech.net/news/bits/2014/04/08/openssl-heartbleed/1
 which states that:
Ironically, those who have not upgraded in a while may be protected against the flaw: the older OpenSSL 1.0.0 and 0.9.8 branches are unaffected, having been frozen before the bug was introduced.
So, since the MCU server uses 0.9.8, I hope that it´s safe to say that this server component is not affected.

Update: In this security bulletin from Polycom, they state that the SoftMCU is not affected:
http://supportdocs.polycom.com/PolycomService/support/global/documents/support/documentation/Heartbleed_Security_Advisory_v_1_4.pdf


Everyone who has installed the Media Manager parts of Sametime 9 also has a Linux server for the VMGR server and the MCU server.

I use RHEL 6.4 on my servers, and I found this:
https://access.redhat.com/site/solutions/781793
RedHat themselves also mentions the fact that only specific versions of the openSSL libraries are affected. The first affected version shipped with RHEL 6.5 (RHEL 6.4 and older shipped with the unaffected openssl-1.0.0 series).

If you use the SUSE 11 version of Linux, you are also safe.
More info here: http://www.zdnet.com/heartbleed-security-patches-coming-fast-and-furious-7000028216/

The DB2 servers are not affected at all:
http://www-01.ibm.com/support/docview.wss?uid=swg21669950

To sum up, only the Community Server is affected, IF and only if you have TLS enabled it.

P.S: I could not find anything regarding the solidDB engine and heartbleed. I don´t think it uses openSSL at all, but if others know anything about this, please let me know.



Regarding IBM Connections:

IBM Connections 4.5 is based on WebSphere App servers. Plus, it uses IBM HTTP server in front + the WebSphere Plugin.

Regarding the WebSphere parts of the solution, IBM Connections is not vulnerable:
http://www-01.ibm.com/support/docview.wss?&uid=swg21669774

Regarding IHS, this is not affected neither:
http://www-01.ibm.com/support/docview.wss?uid=swg21383959

And to sum up for IBM Connections: https://www-304.ibm.com/support/docview.wss?uid=swg21669946


And, typically!!, at the end of my blog post, I discovered that IBM has released their own overview over what types of IBM systems are affected or not....... yikes... Well, ok. I´ll post this blog anyways, and leave you with the IBM overview link as well:

https://www-304.ibm.com/connections/blogs/PSIRT/entry/openssl_heartbleed_cve_2014_0160?lang=en_us


Thursday, April 3, 2014

Connections 4.5 - Editing profile string problem - mindpuzzle

I tried following the guide on how to edit the property file strings for the profiles fields.
The label "Building" was suppose to change to the word "Location", but whatever I tried, following the wiki, did not work.
The wiki page is here btw

The wiki says that you should copy the uilabels.properties from the lc.profiles.web.app.jar file to the "customizationdir\strings" catalog.
And rename the uilabels.properties file to "com.ibm.lconn.profiles.strings.uilabels.properties"

And then edit the file with the string changes you want.

This did not work. Having done this in 4.0, and it seems to be the same procedure in 4.5, it puzzled me why this just was not working.

So, after tons of restarts, updating the versionstamp, emptying caches and temp catalogs, calling a friend from another businesspartner to verify my procedure (Thanks Marius).... google proved once again to be my friend.

Solution:

 http://www-01.ibm.com/support/docview.wss?uid=swg21651954



So it turns out, that this 4.0 technote also applies to the 4.5 version of Connections.



Tuesday, April 1, 2014

Sametime 9 - Strecbot wmm errors

I have a PMR running regarding wmm errors in the meeting server log when doing recordings.
As a solution, IBM support came up with this technote:
http://www-01.ibm.com/support/docview.wss?uid=swg21667054

Be aware if you have the same issue!
This script sets the login properties to "uid;mail" for the internalFileRepository + it adds a mail address to the Websphere Administrator user. That is, if your WAS admin user is called "wasadmin"...

If your Was admin user has a different uid, you need to modify the .py script accordingly.

My WAS admin user has "stwasadmin" as an uid, and then I needed to change the scripts third last line from
AdminTask.updateUser ('[-uniqueName uid=wasadmin,o=defaultWIMFileBasedRealm -mail '+ adminEmail + ']')
to
AdminTask.updateUser ('[-uniqueName uid=stwasadmin,o=defaultWIMFileBasedRealm -mail '+ adminEmail + ']')

So, heads up people...