Re: setmqaut +PUT on DLQ [was: Re: Notes from Defcon 15]

Hi Niklas,

Hopefully you can trust a locally connected application's identity and do 
not give it +setid on the DLQ.  If you cannot trust the locally signed-on 
ID or for some reason give +setid on the DLQ, then the business critical 
app that is the likely target has no business residing on that QMgr.  So, 
assuming that you CAN trust the ID and haven't given out +setid, the DLQ 
rules table should specify PUTAPPLID and/or USERID along with the other 
specifications such as DESTQ.  In this way it is possible to limit the 
destinations that a given user ID can attack using the DLQ handler to only 
the application queues it already has access to.

Of course, it's better if an applications never put messages into the 
system DLQ and instead have their own exception queues.  If the shop has 
standards that dictate use of app-specific exception queues (and the rigor 
to consistently apply the standards) then there is no chance of a message 
landing on the system DLQ and no need to give +put there.  But be aware 
that the Java and JMS classes will still inquire on the QMgr to obtain the 
value and will *want* to use the system DLQ if there is a problem with the 
app-specific backout queue.  So if you don't allow +put on it then you 
might want to turn on authorization events and watch for 2035 errors. This 
is a good idea anyway but in this case it will let you know if an 
application attempts to put a message on the DLQ and fails.  Responders 
can then determine the source application and resolve the problem.

The legitimate case of an app needing to get to the DLQ is a Java/JMS app 
that attempts first to put to the queue in BOQNAME and fails, for example 
because the queue is now full.  The Java and JMS classes will fall back to 
the system DLQ in this case, and no special application logic is required. 
 The behavior is built in.  Even vendor code should behave this way, 
assuming the vendor used the Java or JMS classes that IBM provides.  If 
the DLQ rules provide sufficient security, I like to allow +put on the 
system DLQ as a safety net.  If the app is such a likely target that this 
is considered unsafe, it should be on its own QMgr.

When it comes to bouncing fake messages off of the QMgr, what I would be 
more worried about would be exception messages with full data.  An 
attacker needs no special permission to turn on COA and send the message 
to a nonexistent queue.  Then the QMgr will use the Reply-To fields to 
route the resulting report message and there is no restriction on the 
forwarded destination.  The App Programmer Guide advises to look at 
message type and feedback fields before processing messages but in 
practice very few applications do this.  You can't inspect these fields at 
all using JMS (that I am aware of) without using vendor-specific, 
non-portable low level MQ methods.  I have not tried bouncing messages to 
a JMS program this way and there may be some screening done by the 
underlying classes.  Maybe someone out there can test it?  Fortunately, 
the Command Server does look at such things as message type and expects a 
PCF command rather than a report message.  I haven't tried it but I'm 
reasonably sure the Command Server is not vulnerable to this kind of 
attack.

Thanks for the feedback.  I'm revising the slides for the Vienna T&M 
conference and will clarify that section.  Let me know your thoughts on my 
reply so I know if I've addressed your concerns.

Thanks! -- T.Rob

T.Robert Wyatt, Consulting IT Specialist 
IBM Software Services for WebSphere
http://www.linkedin.com/in/tdotrob

Niklas Gustavsson <niklas@...> 
Sent by: MQSeries List <MQSERIES@...>
08/07/2007 04:07 AM
Please respond to
MQSeries List <MQSERIES@...>

To
MQSERIES@...
cc

Subject
setmqaut +PUT on DLQ [was: Re: Notes from Defcon 15]

T-Rob wrote:
> Thanks for the kind words Kerry and Niklas. 
> 
> I have not yet been able to get the version of the presentation that has 

> the notes pages posted to the IBM web site so I've decided to make it 
> temporarily available on my own.
> http://www.t-rob.net/Downloads/IMPACT2007-4224.zip

Thanks T-Rob, the presentation is very interesting! Now, I have a few 
questions regarding some of the recommendations that I hope we could 
discuss. These are issues that we have previously discussed at work, 
sometimes without getting to a firm conclusion. I intend to write up the 
result of these threads if we get anywhere 

Now for the first. Your mention giving applications PUT authority to the 
DLQ, but to prefer application specific exception queues. To make it a 
bit easier to follow for those who haven't read the slides, here's the 
significant part:

"Applications should always have PUT access to the DLQ but rarely should 
they have GET access since this would allow legitimate apps to delete 
other application?s DLQ messages or an attacker to wipe out traces of 
the attack. Remember, the Dead Letter Queue is a shared resource. It is
usually better to set up application-specific exception queues than to 
use the DLQ as a default backout or exception queue. This altogether 
eliminates the need for applications to manage messages in the
DLQ."

If you were to give an application PUT authority on the DLQ in a shared 
environment, how would you then handle the case of that application (or 
an attacker using it's account) of faking some other applications 
messages? For example, application A could put a message looking like 
one on the way to application B on the DLQ. A DLQ handler or an 
administrator could then "re-insert" this message onto the correct 
application B queue (to which application A would not have any access).

Are there legitimate cases where an application really needs PUT 
authority to the DLQ rather than its own exception queue? I suspect that 
there is (like COTS applications requiring the DLQ and not supporting 
configured exception queues), in which case one would have to figure out 
how to handle the attack described above.

/niklas

To unsubscribe, write to LISTSERV@... and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV@... and,
in the message body (not the subject), write: SIGNOFF MQSERIES