I've been struggling for the better part of the day to get maven to work... and have identified several critical security issues in the process. N.B., these are so critical that many sysadmins will not only allow maven, they'll disallow anything built with it!
(Standard stuff: maven 1.0.b9, binary release, standard configuration since I've been unable to find any configuration files.)
...
The first issue is the practice of physically unpacking plugin jar files in the $MAVEN_HOME/plugins directly. This requires the directory to be writable by the least privileged user who will run maven - in practice this directory will almost always be world-writable, perhaps with the sticky bit set.
Worse in this situation, maven simply loads every jar file in the directory. It does not read an externally defined (and protected) list.
This is an extremely critical error - it means that maven will normally be configured so any user can toss any jar file into that directory and maven will unpack it and do whatever it does with plugins. If the directory is world-writable but doesn't have the sticky bit set, any user could replace a standard jar file with their own malicious one.
If you haven't turned ash white, hit the library and pick up the issue of the Comm. of the ACM where (Kerrigan & Plauger?) discuss their experiments with malicious compilers that insert their own code. The damage is far worse with java, since java.net is a standard component and it is trivial for even an inexperienced java programmer to write net-aware exploits.
Solution: $MAVEN_HOME/plugins must be treated like any other system library directory - it must work with 0555 permissions.
In this case, the fix should actually be straightforward since the nonsense about unpacking the file to read its content with a FileInputStream should be replaced with a java.util.jar.Jarile and a call to java.util.jar.JarEntry.getInputStream().
The caching is another issue... but at first glance I don't understand why this would even be an issue - I'm not aware of any other application that physically unpacks jar files like that. It's not hard to open each jar file and cache the entries at startup -- and hides it all behind a specialized classloader.
...
The second issue is more subtle. When packages are downloaded, they are put into the global $MAVEN_HOME/repository.
The GLOBAL repository.
The same issues crop up - the repository will need to be world-writable, malicious jarfiles can be added (complete with matching MD5 checksums), etc.
There's a standard solution to this - maven should cache files in a per-user repository, not the global repository. Or maven can attempt to write to the global repository first, then quietly fallover to the per-user repository if access is denied.
...
Other fixes.
For the sake of completeness, there is a workaround available... but it's considered unacceptable by most sysadmins. The solution is to set the group of the $MAVEN_HOME/plugins and $MAVEN_HOME/repository directories to some unique group, e.g., "maven", then set the "maven" script setgid "maven." This would allow maven to update these directories, while denying write access to the average user.
(Another variant would set the "user" to "maven" and make the script setuid).
This is unacceptable since it requires making a script setgid (or setuid) - a big no-no in many circles. We can't make the java executable setgid without making the directories effectively world-writable again.
...
Some code may follow, to illustrate possible solutions.
Bear
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
