Archived

This topic is now archived and is closed to further replies.

-vic-

[java] Can i trust JPasswordField?

Recommended Posts

What would happen if someone would make a malicious version of JPasswordField, and then this person delete the original JPasswordField and substitutes it with that malicious version? Would it be that easy to break the password protection? Victor. PS: Please, i am NOT trying to make anything malicious... actually, i want to prevent it.

Share this post


Link to post
Share on other sites
Edit: Clarify: If your program uses a JPasswordField and you compile it with a good password class, your executable bytecode would not be compromised. BUT, if you supply the source code to your program and it is recompiled with a malicious JPasswordField, then their malicious class would be included.

If they recompiled the source code, then yes, their code would override the working password field.

If what you give to them is the compiled version, no.

[edited by - Ronin Magus on March 3, 2003 5:35:53 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by Ronin Magus
If they recompiled the source code, then yes, their code would override the working password field.

If what you give to them is the compiled version, no.



Hmm, i''m not so sure about that. Like i said: the guy would substitute the ".class" file. The .class is loaded at runtime, so if it''s substituted...

Victor.

Share this post


Link to post
Share on other sites
My mistake, I see what you mean.

But I do know this: the .class file is loaded in from the machine running the program, so if your class is compiled to import the absolute path to the JPasswordField, then the only way the original class could be overrided would be to either:

1) Copy the malicious class file over the original class file for EVERY machine that will run the code (not really possible for web applets)

2) compile the class to the bytecode's directory with "javac -d . JPasswordField.java" and then execute the client program using the malicious jpassword class with "java -d . myClient"

I'm by no means a java expert so if I'm wrong please someone correct me

[edited by - Ronin Magus on March 3, 2003 5:48:31 PM]

Share this post


Link to post
Share on other sites
Are you sure about that??

quote:
Original post by Ronin Magus
Edit: Clarify: If your program uses a JPasswordField and you compile it with a good password class, your executable bytecode would not be compromised. BUT, if you supply the source code to your program and it is recompiled with a malicious JPasswordField, then their malicious class would be included.

If they recompiled the source code, then yes, their code would override the working password field.

If what you give to them is the compiled version, no.




In the situation i imagined is exacly how you described it: "your program uses a JPasswordField and you compile it with a good password class", and in this situation the source code is not provided.

But how on earth will java know that the good JPasswordField was substituted by a malicious one, if both of them got the same class name, and are on the same package? I got a feeling that the java runtime wouldn't notice that, and would let the program run with the malicious one!

Victor.



[edited by - -vic- on March 3, 2003 5:48:32 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by Ronin Magus
My mistake, I see what you mean.

But I do know this: the .class file is loaded in from the machine running the program, so if your class is compiled to import the absolute path to the JPasswordField, then the only way the original class could be overrided would be to either:

1) Copy the malicious class file over the original class file for EVERY machine that will run the code (not really possible for web applets)

2) compile the class to the bytecode''s directory with "javac -d . JPasswordField.java" and then execute the client program using the malicious jpassword class with "java -d . myClient"

I''m by no means a java expert so if I''m wrong please someone correct me

[edited by - Ronin Magus on March 3, 2003 5:48:31 PM]



Yes, the class is loaded on the machine running the program. Still, someone could put a malicious JPasswordField on a specific machine (to get the passwords used on that machine).

Boy, i CANNOT BELIEVE it''s that easy to break the security of a Java program! =O Someone please tell me i''m wrong, please!!!

Victor.

Share this post


Link to post
Share on other sites
Well,

there is much more in the game than just your classes!

In a standard environment you would probably be unable to "insert" the malicious code into the system libraries first (the JRE installed on the machine you're on)!
In real life situations you'll rarely have administrator access to a machine you're working at, or R/W access rights to installed programs. Also the installation of software by unauthorized users (you) would be prevented by this.
So the only way you could compile a class on that machine would be to copy the installed JDK to a temporary directory and use the compiler to do the trick. Then you would need to find a stupid enough user, that would mindlessly enter a secret password in your presence (not to mention that YOU are logged in onto the machine) into the malicious JPasswordField.

The easiest way IMO would be not to toy around with classes, but to implement an always on-top "gimme-the-password-clock/weather/whatever" frame , that captures any input and sends it over the network to you.

Imagine the people saying ...
"What a good program, it tells me what's the time/weather/etc."

To sum up ...
There are so many other ways (in java) to gather passwords than the one you described.

The solution ...
Use a server-side authentication, that returns the jar containing your application. Also do not store the passwords in the memory if you don't need them, or at least encrypt them in some way.

and have fun

[edited by - Petr Stedry on March 4, 2003 2:33:12 AM]

Share this post


Link to post
Share on other sites
Umm... Think very carefully about what you''re talking about. Find the actual source of the security problem.

If someone manages to replace a .class file on YOUR COMPUTER, the problem is that YOUR COMPUTER isn''t secure. If they can replace a .class file, they can install a keylogger, or similar exploits.

What you''re describing really has nothing to do with java security.

Share this post


Link to post
Share on other sites
Allright, let me awnser the base of your question.

Is it possible to swap the implementation of JPasswordField?

It depends ofcourse.
Yes you need write access to the location of you JRE (As somebody allready mentioned)
However, to do this at runtime, you would need to be able to execute your own classloader to override the hierachical classloading.

When your program requests javax.swing.JPasswordField the classloader of your program takes that request and forwards it to his parent.
Eventualy it would reach the primordeal classloader which will load the class from the classpath.

So yes its possible if you have security turned off.
But even standard security prevents that (specifying a security manager that is)

Java security is complex subject worthy of a good study

I borrowed O''reillys book on Java 2 security from my boss a few weeks ago

"There is a $500 fine for detonating explosives within the confines of a city"

Share this post


Link to post
Share on other sites