IBM recently announced a fix for a vulnerability in GSKit that in turn generated a flurry of inquiries for me, so it seemed like a good topic for the first post on the new blog.  (Thanks, IMWUC staff!)  The exec summary of this post is that I don't think it has to be a big deal for MQ.  Possibly for other things using GSKit, but not necessarily for MQ.  Bear with me and I'll explain in a moment.

Obligatory disclaimer

Before I get into that though I should mention that I'm not advising against installing the patch.  I know of many IBM MQ shops that have trouble applying a patch a year, and many that are still running on v6.0 or earlier.  (Which I suppose makes them WebSphere MQ or MQSeries shops but that's best discussed in another blog post.)  The questions I've been fielding come from shops that are generally a patch or two behind and wanting help deciding the priority of this fix.  If that's you, do read on.  If you have aggressive patch management and/or operate in a compliance environment then by all means don't let me talk you out of applying the fix.  

MQ isn't a web server

According to IBM's press release, "an attacker could exploit this vulnerability to obtain authentication credentials."  Scary, yeah?  So why am I not too worried about the patch?  Because MQ is unlike web app servers in that it does not support use of multiple ciphers or negotiate among them for a given channel.  A web server has to support a wide range of browsers, some of which don't yet know about TLS above version 1.0.  The webmaster has to choose between security at the cost of possibly losing visitors and revenue, hence it's common to see web servers supporting some horribly broken ciphers.

The MQ administrator has no such constraint.  The only thing using MQ channels is another MQ component and these support a very limited range of ciphers compared to web servers.  In fact, for any given channel that "range" is exactly one or zero ciphers.  The MQ administrator specifies a particular supported cipher and that’s the only one that MQ uses for that channel. The cipher negotiated in the TLS handshake must match the one in the channel definition or else the connection is refused.

Mitigation

The quick and dirty fix?  Don't use MD5 in your channels.  MD5 has been broken for years so if you are concerned enough to be reading this then chances are you have little or no MD5 in your environment by now anyway. If you do, then this is a good time to switch to something robust.

If you are wondering what to use or how to tell if you have MD5, the ciphersuite name indicates the hashes, ciphers and key exchange used.  For example, TLS_RSA_WITH_AES_128_CBC_SHA uses the RSA key exchange, AES 128 encryption with block chaining, and SHA256 hashing.  Since MD5 is a hashing algorithm it will be at the end of the ciphersuite name where SHA256 is in this example.  Don't see MD5 in the ciphersuite name? Then MD5 isn't used there.

It's the credentials not the certs

I am making some assumptions here due to not having access to the code internals.  It used to be that MQ did not offer all supported ciphers in the handshake and the client cannot negotiate outside the set offered by the server.  As of v8.0 the TLS implementation has been enhanced to make use of a TLS extension called Server Name Indication or SNI, which enables specification of different personal certs on a per-channel basis.  IBM may have changed the behavior to send all possible ciphers in the server's response to the handshake.  I did not check specifically for this the last time I sniffed the network for a channel startup but I think I'd have noticed a massive list of ciphers.  I suspect the QMgr offers a subset consisting of only those specified in at least one channel. 

In any case, I'm not certain of the exact behavior and that does leave a case in which the credentials are exposed.  If the User ID and password are exchanged during the TLS handshake rather than after it, and if the new implementation allows negotiation and ciphersuite downgrade prior to checking the channel's SSLCIPH value, then it might be possible to expose the credentials in the handshake.

Another easy mitigation then is: use certificate validation or an exit such as MQAUSX from Capitalware.  In the case of certificate validation the certificate authenticates the connection and credentials are never exchanged.  The hacker can't steal what isn't present.  In the case of an exit, the credentials are exchanged after the TLS handshake completes and within the exit's session encryption.  (MQAUSX has session encryption but if you wrote your own exit or extended the source of BlockIP2 session encryption isn't guaranteed.  If you use an exit and depend on session encryption to protect your credentials, do your due diligence and verify that it is there!)  Since the TLS handshake must have completed for the exit to be called, and since we don't use MD5 ciphers in SSLCIPH, we know MD5 wasn't used.

Porous config more prevalent than vulnerabilities

It's worth mentioning that nobody will bother going to the trouble of cracking your crypto if they can get in through a hole in the configuration.  An acquaintance of mine has been single-handedly securing his company's MQ network on his own initiative and on an as-available basis.  As of a couple months ago he had locked all the SVRCONN and RCVR channels to low-privileged security profiles.  When he completed that phase he sent me a few dmpmqcfg listings and we took a checkpoint.

"How does it look now?"

"Much better.  But why did you leave the CLUSRCVR channels untouched?  They were on my fix list."

"We don't use cluster channels."

"Maybe not, but the people you are protecting your network from do and these are perfectly useable."

"Oh, right.  Didn't think about that but it makes sense now.  I'll get right on that."

Like most people, my friend is a creative type.  Creative types tend to start from the requirements and work into the solution, not even aware of the tunnel vision that sometimes sets in.  Almost nobody uses SYSTEM.AUTO.SVRCONN or SYSTEM.AUTO.RCVR and for a long time these were overlooked during security remediation.  Eventually the task of locking these down made it into the security checklist of every MQ user on the planet and nobody leaves these open anymore.  (Or if you do you don't admit to it.)

Many people do use CLUSRCVR channels so broad advice to lock down SYSTEM.DEF.CLUSRCVR would do more harm than good.  But at the same time the lack of such advice leads to the kind of tunnel vision that caused my friend to overlook it, because we think in terms of what we need to provision. There's a lot of bespoke configuration when locking down cluster channels.  That doesn't fit neatly into a cheat cheet so it gets left out of How-To guides.  Our perception of MQ is then shaped by that absence of information and the natural incentive created is to overlook that security control.

Hackers and security pros tend to have a strong destructive streak.  There's a healthy creative element present but the ability - and urge - to break stuff is prominent.  They too start from the perspective of what needs to be provisioned, but only so they can use those boundaries to define negative space and then explore all the territory outside of that perimeter.  That's where we find unsecured channels, missing Deny-All rules, missing SSLPEER or cert mapping rules, etc. No hacker will take the time to break your MD5 if a channel is left unsecured or partially secured.

Before going to the trouble of applying an interim fix, first make sure there isn't an easier path into the queue manager.

It's deprecated

If you are using MQ v8.0 then all ciphers with MD5 are disabled by default.  You'd have to deliberately choose to turn them on and explicitly set a channel to use it.  Obviously there are cases where for backward compatibility, with some remote QMgr that was frozen in carbonite at version 7.0.x, whose administrator is an adreneline junkie who likes to live dangerously, then sure you might need to enable deprecated ciphers, in which case you get MD5 in the mix.  But since all that took deliberate work, there's a natural incentive to eliminate MD5 through simple attrition. 

Summing it all up

Operating in a compliance environment?  Upcoming audit (and the auditor knows a thing or two about MQ)?  Apply the fix. 

Not using ID and password credentials?  Don't apply the fix.

Using MQAUSX or another exit to exchange credentials inside an encrypted, non-MD5 channel?  Don't apply the fix.

Haven't enabled deprecated ciphers on your QMgr?  Don't install the fix.

There are known or suspected back doors due to holes in the configuration?  Don't apply the fix.

The one iffy use case is that deprecated ciphers are available, UserID and password credentials are exchanged natively in the MQ channel (no security exit used), you think all the back doors are truly locked down, and you are missing sleep over all this.  In this case you could either open a PMR and ask for an explanation of the precise behavior during the TLS handshake (Is cipher downgrade negotiation possible? What set of ciphers is offered to the client?) or else cut to the chase and just install the patch.

Coming up...

Please let me know in the comments if you found this useful.  Also, please feel free to suggest topics for new posts on anything related to MQ security.  I hope to meet you in person at Interconnect, IIW, or looking way ahead to September, at MQTC.