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:
- 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.
- 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 6.0.2.6 and 7.0.1.0 releases of WebSphere MQ. Additional information may be found at APAR IZ50784.
WebSphere MQ – Coming soon to an audit near you!
The June 29 episode of The Deep Queue is finally up! Sorry about the delay, I was on an engagement last week that had me staying over the weekend in Boston to perform a production implementation on Saturday. Although I’ve got a great recording setup at home, I’m afraid I don’t have decent equipment to do the podcast on the road. Instead, I flew my wife up to Boston and we spent Sunday at the aquarium and then went to see Blue Man Group.
The week delay worked out great though, because last week a friend contacted me to tell me his shop needs to remediate for PCI compliance. He has a hundred days to create a segmented MQ network within which to isolate his PCI applications. The time limit is due to having found out about the problems in the course of an audit rather than through independent research or assessment. Since this is likely to be a growing problem, it turned out to be my topic for this month’s episode.
Continue reading →
Share this: