New WMQ Channel vulnerability and interim fix announced

The IBM Internet Security Systems XForce team recently announced a buffer overflow vulnerability in WebSphere MQ client channels.  According to the release, the vulnerability includes the possibility of remotely executing arbitrary code or “causing the application to crash.”  It is not clear whether “application” in this case refers to the channel agent, channel pooling process or something else.

I’ve already fielded some questions on this alert.  In particular, the following:

Note: This vulnerability can not be exploited on queue managers secured with security exits or authentication through SSL, unless an attacker has valid authentication credentials or a valid SSL certificate.

First, I think that the words “queue managers” here should be “channels”.  A queue manager does not have SSL or security exits, channels do.  And Ihave no reason to believe that enabling a security exit or SSL on one channel solves the problem for the entire queue manager so I think the scope is wrong.  I’ve sent in a suggestion to fix that but haven’t heard back yet.

The second question I received was about how authentication prevents the exploit and whether it is necessary to apply the interim fix.  The SSL handshake must be completed before the channel agent ever sees the connection so any connection rejected by SSL does not get deep enough into the MCA to hit the vulnerability.  Similarly, the security exit is invoked fairly early on in the channel negotiation.  If an attacker’s connection is rejected by either SSL or a security exit, the vulnerability cannot be exploited.

On the other hand, anyone who can complete the connection can execute the exploit.  But is this dangerous and do I need to apply the fix?  If the channel has a blank MCAUSER and the command server is running, then a legitimately connected connected user already has the same level of access by gaining administrative access and defining services.  There are two conditions in which the fix could be important:

  1. The channel has no SSL or exits and relies on a low-privileged MCAUSER value for security.  In this case, anonymous users are allowed connect but will ordinarily not have administrative access.
  2. The channel has SSL and/or exits to authenticate users and a low-privileged MCAUSER that would ordinarily limit the connected user from gaining administrative access and the legitimate users are not trusted.  For example, when allowing client connections from outside the enterprise or when in a regulated environment in which application controls must be strictly enforced.

For now the fix is available separately but it will be incorporated into and releases of WebSphere MQ.   Additional information may be found at APAR IZ50784.

This entry was posted in IBMMQ, News, WMQ Security and tagged , , , , . Bookmark the permalink.

Leave a Reply