Hello Rick,
Sorry, this will be in reply to your previous mail down the trail (I lost the
original); I agree with your last sentence completely.
Disabling the channel is not quite the same as writing my messages to other person's
queue (from security breach point of view). Disabling channel is more a
denial-of-service type of attack.
But in general your analogy is valid: one of actual reasons for my conservatism wrt
DLQ is that this is another non-protected MQ resource available for modification to
any application. (from Unix point of view, DLQ reminds me a file writable to "others",
and even worse because there is no analog for per-user ulimit or quota). The first
such resource is, of course, a QM->QM channel of any type :-) Of course, the situation
may be improved with Exits, but it takes a lot of work...
Pavel
Rick Tsujimoto
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
.CANON.COM> cc:
Sent by: MQSeries List Subject: Re: Security with
Server Connection channels
<[EMAIL PROTECTED]>
09/10/2003 03:38 PM
Please respond to MQSeries
List
How would you decide who, or who isn't an authorized user? The contention
is/was that we could have a malicious user, who could be an authorized user
as well.
Bill Anderson
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
ITA.AERO> cc:
Sent by: Subject: Re: Security with Server
Connection channels
MQSeries List
<[EMAIL PROTECTED]
en.AC.AT>
09/10/2003 03:24
PM
Please respond
to MQSeries List
In regard to the dlq, making use of the MCAUSER on a receiver channel might
lend a hand (this will not work for client connections). When the MCAUSER
on a receiver channel is "non blank" it behaves much different than a
server connection for a client. For a receiver you have to set the
authorizations as follows to avoid getting a troublesome 2035:
Authorizations needed for queue manager: +inq, +connect, +set, + setall
Authorizations needed for destination queue and DLQ: +put and +setall
So, on selected receivers, you could block access to the dlq by not doing
the +put thing, and still have it available for "authorized" users.
Rick Tsujimoto
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
.CANON.COM> cc:
Sent by: MQSeries List Subject: Re:
Security with Server Connection channels
<[EMAIL PROTECTED]>
09/10/2003 02:22 PM
Please respond to MQSeries
List
I'm not sure I agree with your contention that a DLQ would enable a user to
gain more privileges. Also, by not having a DLQ, you could also stop the
channel by trying to send a message to a bogus remote queue. This would,
in effect, also deny legitimate messages from being sent.
Pavel Tolkachev
<pavel.tolkachev To:
[EMAIL PROTECTED]
@DB.COM> cc:
Sent by: Subject: Re: Security with
Server Connection channels
MQSeries List
<[EMAIL PROTECTED]
en.AC.AT>
09/10/2003 01:49
PM
Please respond
to MQSeries List
Well, by default the default dlq handler is running as mqm. One thing the
user who is allowed to publish messages can always do is to overflow his
queue, deny others access to the dead letter queue (by flooding it as well)
and, subject to his knowledge of the dlq rules in effect, and the rules
themselves, try to achieve forwarding his or her messages to other queues
where s/he does not belong.
Pavel
Rick Tsujimoto
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
.CANON.COM> cc:
Sent by: MQSeries List Subject: Re:
Security with Server Connection channels
<[EMAIL PROTECTED]>
09/10/2003 10:37 AM
Please respond to MQSeries
List
Pavel,
Could you explain how a user could obtain more privilege vis-a-vis the dlq
handler?
Pavel Tolkachev
<pavel.tolkachev To:
[EMAIL PROTECTED]
@DB.COM> cc:
Sent by: Subject: Re: Security with
Server Connection channels
MQSeries List
<[EMAIL PROTECTED]
en.AC.AT>
09/10/2003 09:28
AM
Please respond
to MQSeries List
Well, denial of service attack is always there, of course (I did not try it
myself with MQ and listener pool, to be completely honest). Of course, I
assume your system will use only SSL channels to have a strong
authentication and confidentiality on the wire. Do not forget to set
SSL_PEER to actually authenticate clients. It is slightly inconvenient
though as you can only accept a single distinguished name per a channel
instance -- but this is how it's done in MQ.
Also, be careful with triggering and DLQ (and DLQ handlers) *inside* the
cluster -- of course, the attacker must penetrate the SSL perimeter to try
to take advantage of them. The threat here is that a legal, but restricted,
user may try to get more privileges in trigger/dlq handler than s/he is
supposed to have. That's one reason why I try to never use any of
triggering / dlq handling.
I am sure there are other threats, just because they are always there
(access to system queues?) but I cannot think of anything concrete right
away. Will let you know if (when?) I will run into anything.
Hope this will help,
Pavel
[EMAIL PROTECTED]
.AU To:
[EMAIL PROTECTED]
Sent by: MQSeries cc:
List Subject: Security with
Server Connection channels
<[EMAIL PROTECTED]
n.AC.AT>
09/10/2003 01:33
AM
Please respond to
MQSeries List
Howdy all,
I need some thoughts on possible security vulnabilities.
If I have an MQ server being used as a gateway into a cluster, (it holds no
queues) and no command server is running and a pool of listners are running
for clients to connect with using a server connection channel, can anyone
do anything malicious to my cluster.
The platform would be Linux (red hat) and MQ v5.3 is installed, no other
inetd services are installed.
____________________________________________
Sid Young B I.T. (cs dc) AD (cse)
DBA
Intranet Developer
Analyst / Programmer
Information Systems Department
[EMAIL PROTECTED]
QML Pathology Phone: (07) 3840 4941 Fax: Fax??? This is the 21st Century!
www.qml.com.au
60 Ferry Rd
West End, QLD 4101
--
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
--
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
--
This e-mail may contain confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
