|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
Java Clients and Security Hole??? |
« View previous topic :: View next topic » |
Author |
Message
|
mqonnet |
Posted: Sun May 16, 2004 5:02 am Post subject: Java Clients and Security Hole??? |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
Hi Guys,
I couldn't stop myself from posting a question on this forum about this topic and this is an extension of what we have been discussing in the following thread.
http://www.mqseries.net/phpBB2/viewtopic.php?t=15366
The scenario is like this:
System A has MQ Server installed.
System B has MQ Client installed. Both are on w2k with MQ 5.3, with or without csd's dont think it matters.
I logon to system B with userid FRED who is in the mqm group on System B.
I defined a userid/principal on System A named FRED. Did *NOT* assign this userid *any* groups. Just setmqaut'd this userid to accept connection on the queue manager. setmqaut -m QM1 -t qmgr -p FRED +connect.
I defined a local queue, TEST on the qmgr on System A. Did *NOT* assign *ANY* authorities to userid FRED to access this queue on System A. Which would mean, userid FRED should be able to connect to qmgr QM1 but should NOT be able to open TEST queue. Also defined the SVRCONN channel with MCAUSER attribute BLANK(set to nothing).
On System B, i have 2 test scenarios.
1) I run amqsputc TEST QM1. Connects fine, but mqopen fails with 2035 as expected.
2) I run a java MQ client app. Connects, opens, puts, closes and disconnects the queue just fine. This is what i believe is the security hole. And i believe it comes off the statement made in the Clients manual, Part 3, Chapter 7, under Access Control.
Which says. "For Java client connections, if the client application does not provide a user ID then no client user identification is provided to the server".
The above statement is what really bugs me. I see this as a major security hole. And i would believe IBM must have some strong theory for keeping it likewise, which obviously MUST already be know to IBM. Anyone on this forum or anyone from IBM throw some light on this???
To add to all this, i ran a trace on the server system A. Guess what.
Amqsputc sends in userid "FRED" for authentication purposes as expected. But the java client sends in userid EntityName Administrato.
I believe the implementation of the above comes from another statement made in the same manual as described above. "However, for the clients that use the MQ_USER_ID environment variable to supply the user ID, it is possible that no environment variable is set. In this case, the user ID that started the server-connection channel is used."
Just a guess.
Any thoughts, anybody.
Cheers
Kumar _________________ IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator
Last edited by mqonnet on Sun May 16, 2004 6:27 am; edited 1 time in total |
|
Back to top |
|
 |
jefflowrey |
Posted: Sun May 16, 2004 6:06 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Yep.
That's the way it works.
D'ya see why PeterPotkay keeps suggesting that everyone put an MCA on their channels? _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
mqonnet |
Posted: Sun May 16, 2004 6:30 am Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
Jeff, the reason for this post and continuation of this discussion is *NOT* because i dont know how things should work or what possible combinations are. :)
"D'ya see why PeterPotkay keeps suggesting that everyone put an MCA on their channels?
"
---Peter is right and i have no doubt about it. One should always try and put the username within the mcauser attribute. But even you miss out, it shouldnt cause a security hole. Just IMHO.
I want to pursue this particular test case since i believe this is a *BUG* and could be fixed. Because this is very much isolated to one particular case and that is within the java bindings.
Cheers
Kumar _________________ IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
Back to top |
|
 |
jefflowrey |
Posted: Sun May 16, 2004 9:30 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
I agree it's a big gaping hole, and it's a problem.
From what I've seen/understood about other things, the reason for the hole is complex.
Since Java is supposed to be "platform neutral", there is nothing in the base Java specification that allows a Java application to get security information from the operating system IN A PLATFORM NEUTRAL way.
So in order for the MQ Java API to do the same thing that the other client APIs do - retrieve the logged in user from the OS and then put that into the context that goes to the server - IBM would have to write JNI code for each operating system and platform and include this with the Java client as compiled object code. And include code to properly detect the host OS/platform (again, likely to be JNI) to decide which set of JNI code to use to determine the logged-in user.
On the server side, IBM has the issue of what to do if, for some reason, the identity context of the client connection request has no user. Should it always hang up? Maybe, but it may not be possible to determine that correctly - due to the way the code works. That is, by functional requirements, it may be that by the time the identity context is available to be checked, the MCA may already need to be started up as some user or another.
On the third hand, IBM has addressed this hole with SSL. The only security risks you run if you enable SSL on all of your channels is the risk of certificates falling into the wrong hands - and that's what revocation lists are for. Well, that and the usual security risk of an "inside job". _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
mqonnet |
Posted: Sun May 16, 2004 10:07 am Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
"Since Java is supposed to be "platform neutral", there is nothing in the base Java specification that allows a Java application to get security information from the operating system IN A PLATFORM NEUTRAL way. "
---Jeff, I am not a Java expert to the extent to know whether there are api calls within Java which one could use to extract the current logged on userid or not. But i would have expected there to be one. Since Java is more or less built on the same lines as C++(oops), except some bits and pieces missing/added. Again, i am not sure how this could be done or whether this is possible or not.
The rule of the thumb always should be. If you develop a product, just because you have 10 different alternate solutions doesnt mean you can ignore a basic flaw in the other solution. Like in this case, just because we have other ways in which we could beef up our security doesnt cater to the drawback thats coming along because of java clients. If you provide an option/usage in a product, one should make sure that there are no loopholes. Just having a workaround for the loophole doesnt satisfy the requirement of the loophole being fixed. Again, all this IMHO.
I am not necessarily profounding that IBM fixes this, but at least if somebody who has been involved in design process throws some light as to why this is left around this way would be great.
As you pointed out, and also peter, we have many more ways to secure things. But i bumped into this one and wanted to get an answer. And this whole effort is the result of the same. :)
Thanks for sharing the thoughts, though.
Cheers
Kumar _________________ IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
Back to top |
|
 |
shogan2003 |
Posted: Sun May 16, 2004 11:51 pm Post subject: |
|
|
Centurion
Joined: 03 Jul 2003 Posts: 133 Location: London
|
So is anyone going to suggest a workaround ? How about a channel exit at the server-end, of course. _________________ MQSI2 certified specialist
MQSeries certified specialist |
|
Back to top |
|
 |
JasonE |
Posted: Mon May 17, 2004 12:59 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003 Posts: 1220 Location: Hursley
|
Kumar, Unless you branch out into C code, inside java you have the user.name property you can query.
The problems with this are many. You can't, for example, query it from an applet. Similarly you can override is when the java pgm is run (see someones post on the other thread), and under windows it appears to actuall come from an environment variable in some circumstances so could still be set to anything!!!
Yes, IBM could ship out a native layer for each platform for the client bindings, but that really wouldnt solve anything and would cause lots of other problems. After all, whats to stop me installing the native client on my local box, and defining a userid musr_mqadmin (windows) or mqm (unix) and connecting.
I think thats the guts behind why it is more appropriate to use security exits or SSL. |
|
Back to top |
|
 |
mqonnet |
Posted: Mon May 17, 2004 2:51 am Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
"Kumar, Unless you branch out into C code, inside java you have the user.name property you can query."
---So why was it not implemented.
"The problems with this are many. You can't, for example, query it from an applet"
---Thats my whole point. Whether it is an application or an applet written in Java, it eventually makes the MQ api calls. Hence, my question is, whats stopping IBM from implementing a JNI wrapper and get the logged on userid. All this of course within the MQ java classess and *NOT* in the user MQ app/applet. And if this was achieved, then the other problem wont arise, as below.
"After all, whats to stop me installing the native client on my local box, and defining a userid musr_mqadmin (windows) or mqm (unix) and connecting"
"I think thats the guts behind why it is more appropriate to use security exits or SSL"
---The answer to this is in my previous post. Here's the extract.
The rule of the thumb always should be. If you develop a product, just because you have 10 different alternate solutions doesnt mean you can ignore a basic flaw in the other solution. Like in this case, just because we have other ways in which we could beef up our security doesnt cater to the drawback thats coming along because of java clients. If you provide an option/usage in a product, one should make sure that there are no loopholes. Just having a workaround for the loophole doesnt satisfy the requirement of the loophole being fixed. Again, all this IMHO.
Looking at the responses in this and the other thread i am getting a feel that IBM left this loophole because there was no real easy was to *fix* this. Is that the case.
Thanks jason for your insights, though.
PS: All this is just a discussion, i dont have any problem on my system etc which i am trying to resolve. :)
Cheers
Kumar _________________ IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
Back to top |
|
 |
JasonE |
Posted: Mon May 17, 2004 3:05 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003 Posts: 1220 Location: Hursley
|
Quote: |
Whether it is an application or an applet written in Java, it eventually makes the MQ api calls |
No, it doesnt - I think this is why you dont fully understand the picture.
When a java app makes an MQCONN call in bindings mode, it goes through the C layer, calls mqm.dll as per a c app. However, when run in client mode, the java layer makes a socket to the server. The java layer builds the flows and communicates with the server. ie the java layer is PURE java. |
|
Back to top |
|
 |
Michael Dag |
Posted: Mon May 17, 2004 3:20 am Post subject: |
|
|
 Jedi Knight
Joined: 13 Jun 2002 Posts: 2607 Location: The Netherlands (Amsterdam)
|
biggest problem I find with the Java Client is that the door is already wide open, by default... so without tempering with the system you end up being 'mqm'...
If the problem can't be fixed in a technical way, at least IBM should provide a 'detection' mechanism so people who don't know this are aware
of the situation.
something like a message in the log would suffice (i.e. AMQxxxx Java Client came in from IP xxx.xxx.xxx.xxx no MCA set, so became mqm, regards IBM... ) _________________ Michael
MQSystems Facebook page |
|
Back to top |
|
 |
mqonnet |
Posted: Mon May 17, 2004 4:42 am Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
"No, it doesnt - I think this is why you dont fully understand the picture.
When a java app makes an MQCONN call in bindings mode, it goes through the C layer, calls mqm.dll as per a c app. However, when run in client mode, the java layer makes a socket to the server. The java layer builds the flows and communicates with the server. ie the java layer is PURE java."
---Jason, as i mentioned earlier, this is NOT a problem that i am dealing with. Rather i am trying to understand why it is desinged the way it has been. So, as you and even Roger pointed out, i may not have the full picutre. And thats precisely what i am trying to get out here. :)
I dont know how it all works in the underlying layer. But here's my assumption and this is what i thought was the way it works.
Java client -> makes MQ api calls(say, starts with connect)->the library(MQ java libraries, com.ibm.mq.jar and so on) has the prototypes and defs for the methods you try to invoke.
Within the connect method(or whatever it is called internally) there must be something like this.
If (this is bindings mode)
---Do X
else if(this is a clients mode)
---Do Y
The reason why i think in the above direction is. I uninstalled MQ 5.3 on my system and found that the MQ java app wasnt working. Which is what you would expect, since it was unable to find the jar files. Or as you mentioned may be even the .dll files.
Assuming that all jar files are found, it goes ahead with the processing.
Now be it X or be it Y, can we not code in such a way that for both routes/flows we do what X does as of now. Which is making JNI calls(if i got it right).
I dont think this to be an impossible or out of the way task. But again, i may be missing something here.
Cheers
Kumar _________________ IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
Back to top |
|
 |
JasonE |
Posted: Mon May 17, 2004 6:56 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003 Posts: 1220 Location: Hursley
|
Quote: |
If (this is bindings mode)
---Do X
else if(this is a clients mode)
---Do Y
Now be it X or be it Y, can we not code in such a way that for both routes/flows we do what X does as of now. Which is making JNI calls(if i got it right). |
You have it correct and have hit the nail on the head. The *only* way of doing what 'X' does today is to branch into JNI which defeats the purpose of a pure java client (and I dont think it can be done in an applet enviornment either). To remain a pure java client, which is the way it will stay, you cannot do what you are asking for. |
|
Back to top |
|
 |
mqonnet |
Posted: Mon May 17, 2004 7:01 am Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
Thank you Jason for your responses.
This question might be a bit silly, but am still asking it since everybody seems to be referring to it. What exactly does "pure java client" mean.
Also, how would an applet do something different as opposed to a java app as far as calling MQ api calls is concerned. As i mentioned in the other thread, i am not well versed with the internals of how java app/applets work. :(.
My point is, be it a java app or an applet, both would make MQ api calls, why does the applet/application care what MQ does underneath(making JNI calls) and why would it not be supported.
I know i may be digging deep into something which is very obvious. :). But just wanted to clarify some points that i was unaware of.
Thanks again for your time.
Cheers
Kumar _________________ IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon May 17, 2004 7:08 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Kumar -
The Java client does not actually call the MQ API in order to do it's work.
They have rewritten the MQ Client API in Java. There's no C/C++ under there, except at the Java Virtual Machine - which is not written or supplied by the IBM MQSeries dev team.
That is, all of the code that the Java client executes and calls is 100% executed within the JVM using java compiled into JVM bytecode.
I have copied the Java jar files from the Windows machine they were installed on, to a completely different OS running on a completely different hardware architecture (OS X on G3) and had the Java client make a successfull connection to an MQServer. This would not be possible if the Java classes were making JNI calls anywhere.
Applets run in special JVMs that are run on the browser machine (not the webserver) and usually run in a special "sandbox" that severely limits what that Java code can do (so that I can't write a Java applet that will erase your harddrive when you click on my webpage - unless you specifically configure your browser sandbox to allow that).
Since applets run on the browser/client side, there's no guarantee of anything being installed there. So, IBM can't write code that depends on such stuff - and Sun wouldn't certify it as "100% Pure Java" if they did. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
mqonnet |
Posted: Mon May 17, 2004 7:19 am Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
Jeff, i am more confused now. :). Do correct me if i got it wrong here.
"The Java client does not actually call the MQ API in order to do it's work.
"
" have copied the Java jar files from the Windows machine they were installed on, to a completely different OS running on a completely different hardware architecture (OS X on G3) and had the Java client make a successfull connection to an MQServer. "
---If java is *NOT* making calls to MQ api then whats the purpose of the jar files. As far as i understand these jar files contain the prototypes and defs of MQ api calls that java clients make. And if you dont have them, neither your java app nor your java applet would work. So, which means, Java client *does* make MQ api calls.
"Since applets run on the browser/client side, there's no guarantee of anything being installed there. So, IBM can't write code that depends on such stuff - and Sun wouldn't certify it as "100% Pure Java" if they did."
---I havent done much of this myself. But last time i wrote a java applet, i had to use the jar files. Not sure if they are needed or not, but they are always there in my classpath. But again, as i mentioned above, without jar files you wouldnt be able to do the mq api calls.
Cheers
Kumar _________________ IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
Back to top |
|
 |
|
|
 |
Goto page 1, 2, 3 Next |
Page 1 of 3 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|