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