POODLE in the repeat

POODLE in the repeat

Lately we have heard a lot of POODLE I have already blogged about it twice here and here at ibmconnections.com. But there is much more to tell about it so that the reason I am creating this article.

Nowadays when we talk about POODLE we have to specify which one (to make things easier 🙂 ). Nowadays we have POODLE SSLv3 and POODLE TLS. The one we call POODLE SSLv3 bites IBM Connections the most but POODLE TLS is easier to exploit. So for environments which are connected to the internet I advise you to be sure that both variants of POODLE are not exploitable at your implementation.

I will try to describe both variants in detail and how it/they can be solved. Lets first start with POODLE SSL v3

POODLE SSLv3

The news about this first POODLE exploit was brought to the world as a major problem while in fact the problem wasn’t that big if you ask me. The problem itself was there where still site’s out there who did support SSLv3. SSLv3 has shown in the past that it isn’t sufficient anymore as a secure protocol. I will try to describe why I think it wasn’t really such big news as it was brought by all news agencies. Normally when a clients connect to a server the clients tells the server the highest secure protocol it supports (this is what is generally is called  the ClientHello package). Within this ClientHello package the clients also send also all cipher suites (these cipher suites are the real data encryption packages) it supports for that version of SSL/TLS. The server then responds with 3 things ServerHello and Certificate and ServerHelloDone messages. Within the ServerHello message the server will send the protocol it is gonna use. This is decided on the protocol version send in the ClientHello message and the highest version the server supports. So for the real world (which is kind of dependent on browser behavior and version) this means in general that TLS1.2 is used. But with the POODLE SSLv3 bug if both parties supported SSLv3 it was possible by the attacking code to force the connection down from TLS1.2 to SSLv3 (with all the intermediate protocols because you can always fall back only one version at a time). So when this happens a user would still see it has a secure connection but it is over SSLv3 (and not the most sucre possible way between server and client as they bot did support TLSv1.2). The cipher suites used in SSLv3 are all general seen as insecure (only RC4 seems to be the most secure one) and fairly easy to decrypt unintentionally. So as you can see POODLE SSLv3 wasn’t the real problem if you ask me ! but that the server (and or client) still supported SSLv3 was the real problem :-). I added a screenshot to show how that traffic flows between the client and the server so you have and idea what happens on the network to build a SSL/TLS connection.

dFU6e

With IBM Connections we always had to enable the HTTP server with SSLv3 because the code within IBM Connections was still making use of SSLv3 calls to itself. The reason for that is that in the code they made use for example with code like this SSLContext.getInstance(“SSL”). Within the IBM JDK JSSE interface this SSL Keyword translated to make use of SSLv3. This was basically a combination of 2 problems , one that they still used a bit of outdated code within IBM Connections binaries , and also of the JSSE implementation in the IBM JDK that the keyword SSL still translated to make use of SSLv3. As said and stated by me, SSLV3 shouldn’t be used already for many years if you ask me 🙂

Well for IBM Connections we have a solution now (luckily) I will talk about that a bit later in the article.

POODLE TLS

The original attacking method of POODLE was made so that they made use of the padding bytes. Within SSLv3 nobody (wel thats a assumption) did a check on those padding bytes. Within the TLS specification it is specified to check on those padding bytes but most of the implementations out there didn’t do that (which makes the officially incompatible with the TLS’s RFC’s but okay 🙂 ) . So that makes TLS connections which make use of CBC cipher’s also vulnerable when they don’t check those padding bytes (and the funny thing about this is that most of the devs creating these encrypting/decrypting libararies still used the old functions/implementations within their code base which didn’t check those padding bytes). The IBM HTTP Server (IHS) which makes use of gskit for the data encrypting/decrypting part functionality of the SSL/TLS implementation where the rest of the world makes use of OpenSSL. So in the case of the IBM World we need to make sure if the CBC encrypting/decrypting routine checks on those padding bytes. Well I can tell you that older version of those gskit didn’t do that and are vulnerable to those POODLE on TLS attacks also.

But also for that there is a solution where I talk about a bit later in this article.

Solution POODLE SSLv3

Well as explained above there are 2 ways how this could have been solved. IBM did choose to fix it on the IBM JDK side instead of the original problem, the code itself. To solve it on the IBM JDK side we have to install a Interim Fix on top of WebSphere which updates the IBM JDK so that the SSL Keyword doesn’t force a SSLv3 connection anymore but a TLS connection. For the different IBM Connections version I will list the Interim Fixes needed.

For IBM Connections 3.0.1 and 3.0.1.1 and 4 you have to apply iFix PI28934
For IBM Connections 4.5 you have to apply PI29575
For IBM Connections 5.0 you have to apply PI28920 or PI28437

The strange thing is that for IBM Connections 5 (which is running on WebSphere 8.5.5.x) we have 2 iFixes available. Personally I have tried to use PI28920 and couldn’t get that iFix to work but I got some reaction from IBM Connections community (for instance from Klaus Bild) that they where able to use to iFix to get SSLv3 switched off. I personally have used PI28437 several times now with success. PI28437 (SDK6 (J9 2.6) SR8 FP1) also installs a newer version of the JAVA SDK then the PI28920 (SDK6 (J9 2.6) SR7 FP1) so my advice is to make use of the PI28437 iFix instead of the PI28920

After you have installed this iFix you can safely disable SSLv3 on your IHS (IBM HTTP Server). This can be done with the SSLProtocolDisable SSLv3 in your vHost configuration part of the config file(default httpd.conf) for your IHS.

Solution POODLE TLS

As described above also the gskit implementation has some problems regarding the checking of the padding bytes. To tell the gskit implementation that we want a strict checking on those padding bytes we have to add the following setting
SSLAttributeSet 471 1 to the config file (default httpd.conf) to all VHOST sections which have SSLEnable in them. This setting can only be applied to the following IHS versions.

  • 7.0.0.33 or later
  • 8.0.0.9 or later
  • 8.5.5.2 or later

For other release version which can not be upgraded, for whatever reason, to the above specified versions you can install any of the following iFixes as what I understood from this technote to make use of this SSLAttributeSet 471 1 setting.

  • PI17025
  • PI05309
  • PI08502
  • PI09443
  • PI13422
  • PI19700
  • PI26894

So I hope this makes everthing a bit more clear in the POODLE jungle out there 🙂

If you have any addition to this story please let me know so I will update the article.

IBM Connections 4.5 CR5 is now available

When IBM Connections was first released, all patches to the on-premises code were released as iFixes – individual fix packages that could be installed and deinstalled individually. This was really flexible and allowed issues to be patched very quickly but also lead to very time-consuming patching processes and almost every system I visited had a different set of code updates installed. Not ideal!

For the past few versions, IBM has managed updates to Connections using Cumulative Refreshes (CRs). These packages consist of a set of cumulative fixes for each of IBM Connections applications.  This is a much more manageable approach, with approximately one CR released each quarter to be installed, and single fixes available from IBM support should an issue be particularly serious.

The latest CR for IBM Connections 4.5 has just been released:

[titled_box title = “Cumulative Refresh 5 summary”]CR5 is a set of 20 fix packages, which update each application entirely. Please apply all 20 fix packages together. The CCM (Connections Content Management) package should only be installed on Connections environments which have Content Management configured. In addition to these 20 fix packages, there is a new TDISOL version released along with CR5, which can be installed on any 4.5 Connections environment. Please download TDISOL 4.5 2014-07-10 from Fix Central.

CR5 uses the same version of the Update Installer as CR4, which is published in Fix Central under this link: 4.5.0.0-IC-Multi-UPDI-20131020

CR5 includes all fixes in CR1, CR2, CR3, and CR4, plus fixes LO74499 and LO74629, listed in this document. It also includes LO74571 for Connections Mail support. It is not necessary to apply these previous fixes if you are installing CR5. CR5 can also be applied on environments that have those fixes already applied.[/titled_box]

You can download IBM Connections 4.5 CR5 from Fix Central.

One of the new features in IBM Connections 4.5 CR3: ‘community re-parenting’

As you may be aware by now, IBM Connections 4.5 Cumulative Refresh 3 (CR3) shipped yesterday.  

Amongst the detail of that fixpack, is a description of the new functions contained within it:

1. Reparenting communities

This function allows an administrator to modify a top-level community to become a subcommunity of another community or modify a subcommunity to become a top-level community.

2. Community activities view

This function provides a view that lists all activities that are part of all the communities that the user belongs to. The view is linked under My Activities left navigation bar. The listed activities do not include public activities, activities that the user tuned out, or activities that have been completed.

3. Badging

This function adds a badge next to the “@ Mentions” and “My Notification” links within the Activity Stream view.

4. Ideation blogs filter APIs

The new APIs provide extra parameters to filter the results by blog type (e.g. blog, ideationblog, and communityblog). There are also new VM methods for displaying most commented and most visited blogs/entries by blog type.

Whilst all all useful in some way to all the organisations I work with, the first is a key features that has been requested for a long time – in fact variations of this request have garnered over 500 votes in the Greenhouse ideation blog.

[line]The ‘Reparenting Communities’ feature allows a Connections administrator (not a user at this stage) to move a community to become a subcommunity of another community, or to move a subcommunity to become a top-level community.  

[box color=”gray”]

This is done using two new wsadmin commands:

  • CommunitiesService.moveSubcommunityToCommunity(“subCommunityUuid”)
  • CommunitiesService.moveCommunityToSubcommunity(“parentCommunityUuid”, “communityToMoveUuid”)
[/box] [line]In the first case, of [mark]moving a sub-community to become a top-level one[/mark], this is the impact.  The new top-level community retains the following characteristics of the original sub-community:

  • Original access level (public, moderated, or restricted)
  • Membership list
  • Community logo (picture), tags, and description
  • Community theme
  • Original start page setting
  • Any existing web addresses (Note: The URL to access this community changes slightly because the parent handle no longer exists.)
[line]In the second case, of [mark]moving a top-level community to become a sub-community of another[/mark], there is a bigger change… 

  • First, the new sub-community with existing web address is cleared – Any “Invited” users on the sub-community that have not accepted or declined the invitation are removed.

The new sub-community retains the following characteristics of the original top-level community:

  • Start page setting.
  • Community logo (picture), tags, and description.
  • Community theme.

Membership relationships between parent and subcommunity are as follows:

  • Community owners in the parent are copied to the new subcommunity as owners.
  • Sub-community members and owners are copied to the new parent as members.

There will be an error generated if the following reparenting actions are attempted:

  • Reparenting a community that has sub-communities.
  • Reparenting a community that is already a sub-community
[line]These restrictions make sense to me – I can’t see how else they could have been managed.  It is a shame that users cannot do this for themselves, but given the complexities of ownership and access, I can see why this is the case.  It is great that us admins now have this ability baked into the released product.

As an aside, it is also worth looking at Domain Patrol Social, a third-party solution that offers a UI for admins that allows reparenting communities and much more besides. I resell the product and would recommend it highly, even with this functionality now in the main product.

Installing IBM Connections 4.5 or CCM? You need these fixes

Important details for fixes for the newly released IBM Connections 4.5:

iFix LO74499 is required for all IBM Connections 4.5 environments. Please download the iFix from Fix Central, then apply to the IBM Connections 4.5 server using the update installer.

Use this link to download iFix LO74499 from Fix Central

For details on how to apply interim fixes, please review the “Installing interim fixes” topic in the IBM Connections 4.5 documentation.

5.2.0.0-P8CPE-IF001 is a FileNet Content Engine iFix, required if your IBM Connections 4.5 environment is using Connections Content Manager. If you are using Connections Content Manager, please review this document for details on the issue that iFix resolves, and instructions on how to download and apply it:

Fail to check out a published document when Library is workflow enabled