DO NOT REPLY [Bug 46477] New: problem with tomcat5 + JRE 1.6.11

2009-01-05 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=46477

   Summary: problem with tomcat5 + JRE 1.6.11
   Product: Tomcat 5
   Version: Unknown
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: major
  Priority: P2
 Component: Unknown
AssignedTo: dev@tomcat.apache.org
ReportedBy: free...@mgn.ru


Using CATALINA_BASE:   /etc/apache-tomcat5
Using CATALINA_HOME:   /etc/apache-tomcat5
Using CATALINA_TMPDIR: /etc/apache-tomcat5/temp
Using JRE_HOME:   /usr/java/jre1.6.0_11
Server version: Apache Tomcat/5.5.27
Server built:   Aug 28 2008 10:08:26
Server number:  5.5.27.0
OS Name:Linux
OS Version: 2.6.18-8.el5
Architecture:   i386
JVM Version:1.6.0_11-b03
JVM Vendor: Sun Microsystems Inc.

I'm installing telebank product. when try log in, I'm get this error in
catalina.out.
after this message connection with server is lost.

Error OpenLink:10.7.4.29 16002 java.net.ConnectException: Connection refused
Error SendStr: java.lang.NullPointerException
Error TCP.ReciveStr():java.lang.NullPointerException
Error ApplySP(): java.lang.NullPointerException
Source: null
Error TermParser: java.lang.StringIndexOutOfBoundsException: String index out
of range: -1
Error CryptBlock() java.lang.IllegalArgumentException: Empty key
Error OpenLink:10.7.4.29 16002 java.net.ConnectException: Connection refused
Error SendStr: java.lang.NullPointerException
Error TCP.ReciveStr():java.lang.NullPointerException
Error ApplySP(): java.lang.NullPointerException
Source: null
Error TermParser: java.lang.StringIndexOutOfBoundsException: String index out
of range: -1
Error CryptBlock() java.lang.IllegalArgumentException: Empty key
Error OpenLink:10.7.4.29 16002 java.net.ConnectException: Connection refused
Error SendStr: java.lang.NullPointerException
Error TCP.ReciveStr():java.lang.NullPointerException
Error ApplySP(): java.lang.NullPointerException
Source: null


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 46477] problem with tomcat5 + JRE 1.6.11

2009-01-05 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=46477





--- Comment #2 from CykaDi   2009-01-05 01:36:02 PST ---
what kind of reason this error message "Error TermParser:
java.lang.StringIndexOutOfBoundsException: String index out
of range: -1" ???


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 46477] problem with tomcat5 + JRE 1.6.11

2009-01-05 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=46477


Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Comment #1 from Mark Thomas   2009-01-05 00:59:56 PST ---
That doesn't look like a Tomcat error message to me. Please contact telebank
for support.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 46464] Serialisation issues in catalina

2009-01-05 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=46464





--- Comment #2 from Sebb   2009-01-05 05:43:16 PST ---
I've also just discovered that Java appears not to call the private
readObject(ObjectInput) or writeObject(ObjectOutput) methods in DeltaSession.

It seems Java only looks for "private writeObject(ObjectOutputStream)" not
"private writeObject(ObjectOutput)", likewise for readObject(ObjectInput).

So at present, both StandardSession nor DeltaSession will use the default Java
serialisation - i.e. the readObject/writeObject methods that are defined will
not be used to override the standard mechanism.

It is not clear whether it is intentional or accidental that the default Java
serialisation mechanism is not being overridden.

If it is intended that the default mechanism is used, then I would suggest that
the readObject/writeObject methods are renamed.

Or at the very least, the Javadoc should make it very clear that the method
names are misleading.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 46478] configure in mod_jk 1.2.27 don't find Apache 2.2.11's apxs file with Sun Solaris 8

2009-01-05 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=46478


Mladen Turk  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Comment #1 from Mladen Turk   2009-01-05 10:03:36 PST ---
Please use users list for those kind of questions.

As a hint, try adding the /usr/local/lib the LD_LIBRARY_PATH
if your httpd is from sunfreeware or compiled with gcc and then
run configure.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 46478] New: configure in mod_jk 1.2.27 don't find Apache 2.2.11's apxs file with Sun Solaris 8

2009-01-05 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=46478

   Summary: configure in mod_jk 1.2.27 don't find Apache 2.2.11's
apxs file with Sun Solaris 8
   Product: Tomcat Connectors
   Version: 1.2.27
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: blocker
  Priority: P2
 Component: mod_jk
AssignedTo: dev@tomcat.apache.org
ReportedBy: yannick.l...@atosorigin.com


Created an attachment (id=23085)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23085)
config.log with configure in mod_jk 1.2.7 don't find apxs with Sun Solaris 8

Hello I try to compile mod_jk 1.2.27 with Sun Solaris 8 but I can not because
mod_jk 1.2.27's configure can not find Apache's 2.2.11 apxs binary:

/opt/apache-2.2.11/modules/jdk1.5.0_17/include/solaris

I start to compile with :
cd tomcat-connectors-1.2.27-src/native
CFLAGS="-O3 -mcpu=ultrasparc -mtune=ultrasparc
-I/opt/apache-2.2.11/modules/jdk1.5.0_17/include/solaris
-I/opt/apache-2.2.11/modules/jdk1.5.0_17/include" \
CC=gcc CXX=gcc \
./configure \
--with-apxs=/opt/apache-2.2.11/bin/apxs \
--enable-jni \
--with-java-home=/opt/apache-2.2.11/modules/jdk1.5.0_17 \
--with-java-platform=2
make && make install

This configuration works fine with Redhat Enterprise Linux 4.0 (RHEL4)

I try too with 
--with-apxs=/opt/apache-2.2.11/bin
but it don't work.

Configure error message :
checking build system type... sparc-sun-solaris2.8
checking host system type... sparc-sun-solaris2.8
checking target system type... sparc-sun-solaris2.8
checking for a BSD-compatible install... scripts/build/unix/install-sh -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets $(MAKE)... yes
checking for test... /usr/bin/test
checking for rm... /usr/bin/rm
checking for grep... /usr/bin/grep
checking for echo... /usr/bin/echo
checking for sed... /usr/bin/sed
checking for cp... /usr/bin/cp
checking for mkdir... /usr/bin/mkdir
need to check for Perl first, apxs depends on it...
checking for perl... /usr/local/bin/perl
could not find /opt/apache-2.2.11/bin/apxs
configure: error: You must specify a valid --with-apxs path
make: *** No targets specified and no makefile found.  Stop.

And I have a file /opt/apache-2.2.11/bin/apxs that I can execute well.

See config.log added as an attachment.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r731644 - in /tomcat/trunk/java/org/apache/catalina/manager: LocalStrings.properties ManagerServlet.java

2009-01-05 Thread fhanik 
Author: fhanik
Date: Mon Jan  5 10:34:25 2009
New Revision: 731644

URL: http://svn.apache.org/viewvc?rev=731644&view=rev
Log:
When deployment succeeds but the context still fails to start, provide instant 
feedback


Modified:
tomcat/trunk/java/org/apache/catalina/manager/LocalStrings.properties
tomcat/trunk/java/org/apache/catalina/manager/ManagerServlet.java

Modified: tomcat/trunk/java/org/apache/catalina/manager/LocalStrings.properties
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/manager/LocalStrings.properties?rev=731644&r1=731643&r2=731644&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/manager/LocalStrings.properties 
(original)
+++ tomcat/trunk/java/org/apache/catalina/manager/LocalStrings.properties Mon 
Jan  5 10:34:25 2009
@@ -60,6 +60,7 @@
 managerServlet.configured=OK - Deployed application from context file {0}
 managerServlet.deployed=OK - Deployed application at context path {0}
 managerServlet.deployFailed=FAIL - Failed to deploy application at context 
path {0}
+managerServlet.deployedButNotStarted=FAIL - Deployed application at context 
path {0} but context failed to start
 managerServlet.exception=FAIL - Encountered exception {0}
 managerServlet.deployed=OK - Deployed application at context path {0}
 managerServlet.invalidPath=FAIL - Invalid context path {0} was specified

Modified: tomcat/trunk/java/org/apache/catalina/manager/ManagerServlet.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/manager/ManagerServlet.java?rev=731644&r1=731643&r2=731644&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/manager/ManagerServlet.java (original)
+++ tomcat/trunk/java/org/apache/catalina/manager/ManagerServlet.java Mon Jan  
5 10:34:25 2009
@@ -801,8 +801,10 @@
 }
 }
 context = (Context) host.findChild(path);
-if (context != null && context.getConfigured()) {
+if (context != null && context.getConfigured() && 
context.getAvailable()) {
 writer.println(sm.getString("managerServlet.deployed", 
displayPath));
+} else if (context!=null && !context.getAvailable()) {
+
writer.println(sm.getString("managerServlet.deployedButNotStarted", 
displayPath));
 } else {
 // Something failed
 writer.println(sm.getString("managerServlet.deployFailed", 
displayPath));



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 37515] smap not generated by JspC when used from Ant for precompilation

2009-01-05 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=37515





--- Comment #12 from Jess Holle   2009-01-05 05:53:50 PST ---
Somehow I missed the classpath attribute.  That indeed solves my problem.

I have one much smaller (nuisance) problem.  I want to specify -source and
-target of 1.6 -- as I would with javac.  The JDT used by JspC by default
complains about this claiming it does not understand a value of 1.6 here, which
is silly -- 1.6 has been out a long time now and does have slightly different
byte-code output than previous Java versions.  I could presumably force use of
javac, but I'd rather be more consistent with on-the-fly JSP compilation.  Yes,
I could force use of javac there as well, but I'd rather not.  Is there no JDT
available that understands a -source/-target of 1.6?

Feel free to close the bug, but some answer about the JDT issue would be
appreciated.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r731651 - in /tomcat/trunk/java/org/apache/jasper/compiler: ImplicitTagLibraryInfo.java JspUtil.java ParserController.java TagFileProcessor.java TagLibraryInfoImpl.java

2009-01-05 Thread markt 
Author: markt
Date: Mon Jan  5 11:20:11 2009
New Revision: 731651

URL: http://svn.apache.org/viewvc?rev=731651&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46471
Use the URL of the JAR as well as the path within the JAR to identify a tag 
file to keep tag file definitions unique.

Modified:
tomcat/trunk/java/org/apache/jasper/compiler/ImplicitTagLibraryInfo.java
tomcat/trunk/java/org/apache/jasper/compiler/JspUtil.java
tomcat/trunk/java/org/apache/jasper/compiler/ParserController.java
tomcat/trunk/java/org/apache/jasper/compiler/TagFileProcessor.java
tomcat/trunk/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java

Modified: 
tomcat/trunk/java/org/apache/jasper/compiler/ImplicitTagLibraryInfo.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/ImplicitTagLibraryInfo.java?rev=731651&r1=731650&r2=731651&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/ImplicitTagLibraryInfo.java 
(original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/ImplicitTagLibraryInfo.java 
Mon Jan  5 11:20:11 2009
@@ -194,6 +194,7 @@
 tagInfo = TagFileProcessor.parseTagFileDirectives(pc,
 shortName,
 path,
+pc.getJspCompilationContext().getTagFileJarUrl(path),
 this);
 } catch (JasperException je) {
 throw new RuntimeException(je.toString(), je);

Modified: tomcat/trunk/java/org/apache/jasper/compiler/JspUtil.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/JspUtil.java?rev=731651&r1=731650&r2=731651&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/JspUtil.java (original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/JspUtil.java Mon Jan  5 
11:20:11 2009
@@ -26,7 +26,6 @@
 import java.util.jar.JarFile;
 import java.util.zip.ZipEntry;
 
-import org.apache.jasper.Constants;
 import org.apache.jasper.JasperException;
 import org.apache.jasper.JspCompilationContext;
 import org.xml.sax.Attributes;
@@ -818,9 +817,31 @@
  * 
  * @return Fully-qualified class name of the tag handler corresponding to
  * the given tag file path
+ * 
+ * @deprecated Use {...@link #getTagHandlerClassName(String, String,
+ * ErrorDispatcher)
+ * See https://issues.apache.org/bugzilla/show_bug.cgi?id=46471
  */
 public static String getTagHandlerClassName(String path, ErrorDispatcher 
err)
 throws JasperException {
+return getTagHandlerClassName(path, null, err);
+}
+
+/**
+ * Gets the fully-qualified class name of the tag handler corresponding to
+ * the given tag file path.
+ * 
+ * @param path
+ *Tag file path
+ * @param err
+ *Error dispatcher
+ * 
+ * @return Fully-qualified class name of the tag handler corresponding to
+ * the given tag file path
+ */
+public static String getTagHandlerClassName(String path, String urn,
+ErrorDispatcher err) throws JasperException {
+
 
 String className = null;
 int begin = 0;
@@ -848,7 +869,7 @@
 } else {
 index = path.indexOf(META_INF_TAGS);
 if (index != -1) {
-className = "org.apache.jsp.tag.meta.";
+className = getClassNameBase(urn);
 begin = index + META_INF_TAGS.length();
 } else {
 err.jspError("jsp.error.tagfile.illegalPath", path);
@@ -860,6 +881,15 @@
 return className;
 }
 
+private static String getClassNameBase(String urn) {
+StringBuffer base = new StringBuffer("org.apache.jsp.tag.meta.");
+if (urn != null) {
+base.append(makeJavaPackage(urn));
+base.append('.');
+}
+return base.toString();
+}
+
 /**
  * Converts the given path to a Java package or fully-qualified class name
  * 

Modified: tomcat/trunk/java/org/apache/jasper/compiler/ParserController.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/ParserController.java?rev=731651&r1=731650&r2=731651&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/ParserController.java 
(original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/ParserController.java Mon Jan  
5 11:20:11 2009
@@ -144,15 +144,31 @@
  * This is invoked by the compiler 
  *
  * @param inFileName The name of the tag file to be parsed.
+ * @deprecated Use {...@link #parseTagFileDirectives(String, URL)}
+ * See https://issues.apache.org/bugzilla/show_bug.cgi?id=46471
  */
 public Node.Nodes parseTagFi

DO NOT REPLY [Bug 46471] Compiled tag files from different tag libraries share the same package

2009-01-05 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=46471





--- Comment #2 from Mark Thomas   2009-01-05 11:22:00 PST ---
I have fixed this in trunk and proposed the patch for 6.0.x. The patch is
fairly invasive so there may be some reluctance to back port this to 6.0.x
(although all the TCK tests do pass).


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Why are manager session tokens generated with MD5 by default?

2009-01-05 Thread Minoo Hamilton 
I'd like to re-raise an issue, since I didn't get too much of a 
response, originally.  Who can I talk to to lobby to get the default 
behavior of using MD5 session token hashes to change?  If you weren't 
aware of it, there has been a recent and highly-publicized breaking of 
SSL, by creating a rogue certificate authority, using collisions in 
MD5.  Creating collisions in MD5 are no longer a "highly theoretical" 
attack for potential session hijacking.  I'd very much like to see the 
default behavior of Tomcat  session tokens become more secure by default 
(possibly SHA-256).  I think the default hashing algorithm should not be 
a known broken and insecure one.


MD5 considered harmful today
Creating a rogue CA certificate

http://www.win.tue.nl/hashclash/rogue-ca/

Any thoughts?

Thanks,
Minoo Hamilton


Tim Funk wrote:
It is probably due to old code which works just fine when SHA might 
not have been "easily available" in all JVM's. (back in 2002?)


So a quick recap for folks ... a session id is generated by
1) Getting a random number
2) Hashing it
3) Converting the hashed bytes to something text [base64] so they fit 
in a cookie without extra work


Steps 1-3 are repeated until enough chars are present for the 
configured  session ID length.


So if an attacker *could* get reverse of the hash - it would be a 
random number. SessionId length is configurable - so you could change 
your session length to be larger so that mulitple random numbers 
become digested. And then keep the session length small enough so that 
next hash is not completely concatenated into the id. So at best the 
attack has a one full hash plus part of a another hash to work with. 
(As of this writing - I cant recall how times digest is called by 
default so I'm not sure if a single full hash is in the session id, or 
part of one, or multiples)


*** BUT *** If the random number and entropy to get the random number 
are "good enough" - hashing is already overkill. But in the case where 
the entropy and random number generator are "bad" - hashing provides 
another line of defense against determining the current random number 
and then being able to guess the next random number.



-Tim

Minoo Hamilton wrote:

Greetings Tomcat Developers,
 I am a security researcher who has recently been getting into Apache 
Tomcat security hardening.  Forgive me if my failed attempt to find 
the answer to this question has brought me prematurely to this list.  
I've been trying to figure out why the Apache Tomcat 6 Manager 
component defaults to using the MD5 hash algorithm for session token 
creation.  It has long been seen as a questionable hash algorithm due 
to known collisions.  Why not use SHA-1 by default, instead?  Has 
anybody looked at SecureRandom which uses SHA-1?  I assume eventually 
this should be SHA-2, as SHA-1 is coming under increasing fire, as well.


From: http://tomcat.apache.org/tomcat-6.0-doc/config/manager.html

|algorithm|

Name of the /Message Digest/ algorithm used to calculate session 
identifiers produced by this Manager. This value must be supported by 
the |java.security.MessageDigest| class. If not specified, the 
default value is "MD5".
 



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r731773 - /tomcat/trunk/java/org/apache/jasper/compiler/JDTCompiler.java

2009-01-05 Thread markt 
Author: markt
Date: Mon Jan  5 15:50:55 2009
New Revision: 731773

URL: http://svn.apache.org/viewvc?rev=731773&view=rev
Log:
Reported as part of https://issues.apache.org/bugzilla/show_bug.cgi?id=37515
Add options for Java 1.6 and 1.7

Modified:
tomcat/trunk/java/org/apache/jasper/compiler/JDTCompiler.java

Modified: tomcat/trunk/java/org/apache/jasper/compiler/JDTCompiler.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/JDTCompiler.java?rev=731773&r1=731772&r2=731773&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/JDTCompiler.java (original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/JDTCompiler.java Mon Jan  5 
15:50:55 2009
@@ -301,6 +301,12 @@
 } else if(opt.equals("1.5")) {
 settings.put(CompilerOptions.OPTION_Source,
  CompilerOptions.VERSION_1_5);
+} else if(opt.equals("1.6")) {
+settings.put(CompilerOptions.OPTION_Source,
+ CompilerOptions.VERSION_1_6);
+} else if(opt.equals("1.7")) {
+settings.put(CompilerOptions.OPTION_Source,
+ CompilerOptions.VERSION_1_7);
 } else {
 log.warn("Unknown source VM " + opt + " ignored.");
 settings.put(CompilerOptions.OPTION_Source,
@@ -332,6 +338,16 @@
  CompilerOptions.VERSION_1_5);
 settings.put(CompilerOptions.OPTION_Compliance,
 CompilerOptions.VERSION_1_5);
+} else if(opt.equals("1.6")) {
+settings.put(CompilerOptions.OPTION_TargetPlatform,
+ CompilerOptions.VERSION_1_6);
+settings.put(CompilerOptions.OPTION_Compliance,
+CompilerOptions.VERSION_1_6);
+} else if(opt.equals("1.7")) {
+settings.put(CompilerOptions.OPTION_TargetPlatform,
+ CompilerOptions.VERSION_1_7);
+settings.put(CompilerOptions.OPTION_Compliance,
+CompilerOptions.VERSION_1_7);
 } else {
 log.warn("Unknown target VM " + opt + " ignored.");
 settings.put(CompilerOptions.OPTION_TargetPlatform,



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r731774 - /tomcat/tc6.0.x/trunk/STATUS.txt

2009-01-05 Thread markt 
Author: markt
Date: Mon Jan  5 15:54:58 2009
New Revision: 731774

URL: http://svn.apache.org/viewvc?rev=731774&view=rev
Log:
Add a couple of proposals

Modified:
tomcat/tc6.0.x/trunk/STATUS.txt

Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=731774&r1=731773&r2=731774&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Jan  5 15:54:58 2009
@@ -269,3 +269,15 @@
   http://svn.apache.org/viewvc?rev=730735&view=rev
   +1: markt
   -1: 
+
+* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46471
+  Use jar url and tag file path to uniquely ID a tag file to prevent naming
+  clashes
+  +1: markt
+  -1: 
+
+* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=37515
+  Add options for 1.6 and 1.7 source and target to JDT compiler
+  http://svn.apache.org/viewvc?rev=731773&view=rev
+  +1: markt
+  -1: 



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 37515] smap not generated by JspC when used from Ant for precompilation

2009-01-05 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=37515





--- Comment #13 from Mark Thomas   2009-01-05 15:56:06 PST ---
The JDT issue is a bug. I have committed a fix to trunk and proposed it for
6.0.x


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r731776 - /tomcat/current/tc5.5.x/STATUS.txt

2009-01-05 Thread markt 
Author: markt
Date: Mon Jan  5 15:57:27 2009
New Revision: 731776

URL: http://svn.apache.org/viewvc?rev=731776&view=rev
Log:
Add fix for 37515

Modified:
tomcat/current/tc5.5.x/STATUS.txt

Modified: tomcat/current/tc5.5.x/STATUS.txt
URL: 
http://svn.apache.org/viewvc/tomcat/current/tc5.5.x/STATUS.txt?rev=731776&r1=731775&r2=731776&view=diff
==
--- tomcat/current/tc5.5.x/STATUS.txt (original)
+++ tomcat/current/tc5.5.x/STATUS.txt Mon Jan  5 15:57:27 2009
@@ -169,3 +169,9 @@
   http://svn.apache.org/viewvc?rev=730735&view=rev
   +1: markt
   -1: 
+
+* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=37515
+  Add options for 1.6 and 1.7 source and target to JDT compiler
+  http://svn.apache.org/viewvc?rev=731773&view=rev
+  +1: markt
+  -1: 



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 37515] smap not generated by JspC when used from Ant for precompilation

2009-01-05 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=37515





--- Comment #14 from Mark Thomas   2009-01-05 15:57:32 PST ---
Add also proposed for 5.5.x


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Why are manager session tokens generated with MD5 by default?

2009-01-05 Thread Filip Hanik - Dev Lists 

you don't need to lobby, simply create a patch in Bugzilla

Minoo Hamilton wrote:
I'd like to re-raise an issue, since I didn't get too much of a 
response, originally.  Who can I talk to to lobby to get the default 
behavior of using MD5 session token hashes to change?  If you weren't 
aware of it, there has been a recent and highly-publicized breaking of 
SSL, by creating a rogue certificate authority, using collisions in 
MD5.  Creating collisions in MD5 are no longer a "highly theoretical" 
attack for potential session hijacking.  I'd very much like to see the 
default behavior of Tomcat  session tokens become more secure by 
default (possibly SHA-256).  I think the default hashing algorithm 
should not be a known broken and insecure one.


MD5 considered harmful today
Creating a rogue CA certificate

http://www.win.tue.nl/hashclash/rogue-ca/

Any thoughts?

Thanks,
Minoo Hamilton


Tim Funk wrote:
It is probably due to old code which works just fine when SHA might 
not have been "easily available" in all JVM's. (back in 2002?)


So a quick recap for folks ... a session id is generated by
1) Getting a random number
2) Hashing it
3) Converting the hashed bytes to something text [base64] so they fit 
in a cookie without extra work


Steps 1-3 are repeated until enough chars are present for the 
configured  session ID length.


So if an attacker *could* get reverse of the hash - it would be a 
random number. SessionId length is configurable - so you could change 
your session length to be larger so that mulitple random numbers 
become digested. And then keep the session length small enough so 
that next hash is not completely concatenated into the id. So at best 
the attack has a one full hash plus part of a another hash to work 
with. (As of this writing - I cant recall how times digest is called 
by default so I'm not sure if a single full hash is in the session 
id, or part of one, or multiples)


*** BUT *** If the random number and entropy to get the random number 
are "good enough" - hashing is already overkill. But in the case 
where the entropy and random number generator are "bad" - hashing 
provides another line of defense against determining the current 
random number and then being able to guess the next random number.



-Tim

Minoo Hamilton wrote:

Greetings Tomcat Developers,
 I am a security researcher who has recently been getting into 
Apache Tomcat security hardening.  Forgive me if my failed attempt 
to find the answer to this question has brought me prematurely to 
this list.  I've been trying to figure out why the Apache Tomcat 6 
Manager component defaults to using the MD5 hash algorithm for 
session token creation.  It has long been seen as a questionable 
hash algorithm due to known collisions.  Why not use SHA-1 by 
default, instead?  Has anybody looked at SecureRandom which uses 
SHA-1?  I assume eventually this should be SHA-2, as SHA-1 is coming 
under increasing fire, as well.


From: http://tomcat.apache.org/tomcat-6.0-doc/config/manager.html

|algorithm|

Name of the /Message Digest/ algorithm used to calculate session 
identifiers produced by this Manager. This value must be supported 
by the |java.security.MessageDigest| class. If not specified, the 
default value is "MD5".
 



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 37627] Slow and incomplete dynamic content generation after enabling native connector support

2009-01-05 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=37627





--- Comment #12 from Mark Thomas   2009-01-05 16:01:11 PST ---
Given the trouble we have had re-producing this, could you test with 5.5.27 and
tc-native 1.1.16 in case one of the many fixes since 5.5.20 and 1.1.7 has fixed
this.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 37627] Slow and incomplete dynamic content generation after enabling native connector support

2009-01-05 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=37627


Mark Thomas  changed:

   What|Removed |Added

 Status|REOPENED|NEEDINFO




-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Why are manager session tokens generated with MD5 by default?

2009-01-05 Thread Mark Thomas 
Filip Hanik - Dev Lists wrote:
> you don't need to lobby, simply create a patch in Bugzilla

Although it is likely to get ignored / end up as WONTFIX. I don't see
what the security issue is here. How does an MD5 collisions affect the
security of the session ID?

Mark

> 
> Minoo Hamilton wrote:
>> I'd like to re-raise an issue, since I didn't get too much of a
>> response, originally.  Who can I talk to to lobby to get the default
>> behavior of using MD5 session token hashes to change?  If you weren't
>> aware of it, there has been a recent and highly-publicized breaking of
>> SSL, by creating a rogue certificate authority, using collisions in
>> MD5.  Creating collisions in MD5 are no longer a "highly theoretical"
>> attack for potential session hijacking.  I'd very much like to see the
>> default behavior of Tomcat  session tokens become more secure by
>> default (possibly SHA-256).  I think the default hashing algorithm
>> should not be a known broken and insecure one.
>>
>> MD5 considered harmful today
>> Creating a rogue CA certificate
>>
>> http://www.win.tue.nl/hashclash/rogue-ca/
>>
>> Any thoughts?
>>
>> Thanks,
>> Minoo Hamilton
>>
>>
>> Tim Funk wrote:
>>> It is probably due to old code which works just fine when SHA might
>>> not have been "easily available" in all JVM's. (back in 2002?)
>>>
>>> So a quick recap for folks ... a session id is generated by
>>> 1) Getting a random number
>>> 2) Hashing it
>>> 3) Converting the hashed bytes to something text [base64] so they fit
>>> in a cookie without extra work
>>>
>>> Steps 1-3 are repeated until enough chars are present for the
>>> configured  session ID length.
>>>
>>> So if an attacker *could* get reverse of the hash - it would be a
>>> random number. SessionId length is configurable - so you could change
>>> your session length to be larger so that mulitple random numbers
>>> become digested. And then keep the session length small enough so
>>> that next hash is not completely concatenated into the id. So at best
>>> the attack has a one full hash plus part of a another hash to work
>>> with. (As of this writing - I cant recall how times digest is called
>>> by default so I'm not sure if a single full hash is in the session
>>> id, or part of one, or multiples)
>>>
>>> *** BUT *** If the random number and entropy to get the random number
>>> are "good enough" - hashing is already overkill. But in the case
>>> where the entropy and random number generator are "bad" - hashing
>>> provides another line of defense against determining the current
>>> random number and then being able to guess the next random number.
>>>
>>>
>>> -Tim
>>>
>>> Minoo Hamilton wrote:
 Greetings Tomcat Developers,
  I am a security researcher who has recently been getting into
 Apache Tomcat security hardening.  Forgive me if my failed attempt
 to find the answer to this question has brought me prematurely to
 this list.  I've been trying to figure out why the Apache Tomcat 6
 Manager component defaults to using the MD5 hash algorithm for
 session token creation.  It has long been seen as a questionable
 hash algorithm due to known collisions.  Why not use SHA-1 by
 default, instead?  Has anybody looked at SecureRandom which uses
 SHA-1?  I assume eventually this should be SHA-2, as SHA-1 is coming
 under increasing fire, as well.

 From: http://tomcat.apache.org/tomcat-6.0-doc/config/manager.html

 |algorithm|

 Name of the /Message Digest/ algorithm used to calculate session
 identifiers produced by this Manager. This value must be supported
 by the |java.security.MessageDigest| class. If not specified, the
 default value is "MD5".
  
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 46464] Serialisation issues in catalina

2009-01-05 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=46464


Filip Hanik  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Comment #3 from Filip Hanik   2009-01-05 16:09:22 PST ---
(In reply to comment #2)
> I've also just discovered that Java appears not to call the private
> readObject(ObjectInput) or writeObject(ObjectOutput) methods in DeltaSession.

it shouldn't, it should call 
writeExternal and readExternal


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 46464] Serialisation issues in catalina

2009-01-05 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=46464


Sebb  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |




--- Comment #4 from Sebb   2009-01-05 16:15:41 PST ---
(In reply to comment #3)
> (In reply to comment #2)
> > I've also just discovered that Java appears not to call the private
> > readObject(ObjectInput) or writeObject(ObjectOutput) methods in 
> > DeltaSession.
> 
> it shouldn't, it should call 
> writeExternal and readExternal
> 

writeExternal/readExternal are part of the Externalizable interface.

The problems here are to do with the Serializable interface.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 37515] smap not generated by JspC when used from Ant for precompilation

2009-01-05 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=37515





--- Comment #15 from Jess Holle   2009-01-05 16:49:10 PST ---
Thanks!


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Why are manager session tokens generated with MD5 by default?

2009-01-05 Thread Preston L. Bannister 
How would you reverse a session-id from an MD5 hash? The exploit used to
forge an SSL certificate will not help you. The MD5 exploit is irrelevant to
this particular usage.

Lots of links and discussion:
http://www.schneier.com/blog/archives/2008/12/forging_ssl_cer.html

If you are connecting to *any web application* on a high-value target over
an insecure network using HTTP (not HTTPS) then you already have a *Very
Large Problem* (think about man-in-the-middle attacks). Changing the hash
applied to session ids is not going to help.

Minoo, as a "security researcher" you should already be clear on the
relative importance of differing risks, and cost/value ratios of exploits.
Use of the MD5 hash as described is entirely harmless.



On Mon, Jan 5, 2009 at 4:07 PM, Mark Thomas  wrote:

> Filip Hanik - Dev Lists wrote:
> > you don't need to lobby, simply create a patch in Bugzilla
>
> Although it is likely to get ignored / end up as WONTFIX. I don't see
> what the security issue is here. How does an MD5 collisions affect the
> security of the session ID?
>
> Mark
>
> > Minoo Hamilton wrote:
> >> I'd like to re-raise an issue, since I didn't get too much of a
> >> response, originally.  Who can I talk to to lobby to get the default
> >> behavior of using MD5 session token hashes to change?  If you weren't
> >> aware of it, there has been a recent and highly-publicized breaking of
> >> SSL, by creating a rogue certificate authority, using collisions in
> >> MD5.  Creating collisions in MD5 are no longer a "highly theoretical"
> >> attack for potential session hijacking.  I'd very much like to see the
> >> default behavior of Tomcat  session tokens become more secure by
> >> default (possibly SHA-256).  I think the default hashing algorithm
> >> should not be a known broken and insecure one.
> >>
> >> MD5 considered harmful today
> >> Creating a rogue CA certificate
> >>
> >> http://www.win.tue.nl/hashclash/rogue-ca/
> >>
> >> Any thoughts?
> >>
> >> Thanks,
> >> Minoo Hamilton
> >>
> >>
> >> Tim Funk wrote:
> >>> It is probably due to old code which works just fine when SHA might
> >>> not have been "easily available" in all JVM's. (back in 2002?)
> >>>
> >>> So a quick recap for folks ... a session id is generated by
> >>> 1) Getting a random number
> >>> 2) Hashing it
> >>> 3) Converting the hashed bytes to something text [base64] so they fit
> >>> in a cookie without extra work
> >>>
> >>> Steps 1-3 are repeated until enough chars are present for the
> >>> configured  session ID length.
> >>>
> >>> So if an attacker *could* get reverse of the hash - it would be a
> >>> random number. SessionId length is configurable - so you could change
> >>> your session length to be larger so that mulitple random numbers
> >>> become digested. And then keep the session length small enough so
> >>> that next hash is not completely concatenated into the id. So at best
> >>> the attack has a one full hash plus part of a another hash to work
> >>> with. (As of this writing - I cant recall how times digest is called
> >>> by default so I'm not sure if a single full hash is in the session
> >>> id, or part of one, or multiples)
> >>>
> >>> *** BUT *** If the random number and entropy to get the random number
> >>> are "good enough" - hashing is already overkill. But in the case
> >>> where the entropy and random number generator are "bad" - hashing
> >>> provides another line of defense against determining the current
> >>> random number and then being able to guess the next random number.
> >>>
> >>>
> >>> -Tim
> >>>
> >>> Minoo Hamilton wrote:
>  Greetings Tomcat Developers,
>   I am a security researcher who has recently been getting into
>  Apache Tomcat security hardening.  Forgive me if my failed attempt
>  to find the answer to this question has brought me prematurely to
>  this list.  I've been trying to figure out why the Apache Tomcat 6
>  Manager component defaults to using the MD5 hash algorithm for
>  session token creation.  It has long been seen as a questionable
>  hash algorithm due to known collisions.  Why not use SHA-1 by
>  default, instead?  Has anybody looked at SecureRandom which uses
>  SHA-1?  I assume eventually this should be SHA-2, as SHA-1 is coming
>  under increasing fire, as well.
> 
>  From: http://tomcat.apache.org/tomcat-6.0-doc/config/manager.html
> 
>  |algorithm|
> 
>  Name of the /Message Digest/ algorithm used to calculate session
>  identifiers produced by this Manager. This value must be supported
>  by the |java.security.MessageDigest| class. If not specified, the
>  default value is "MD5".
>

Re: Why are manager session tokens generated with MD5 by default?

2009-01-05 Thread Minoo Hamilton 
Perhaps, I am making a big deal over a small theoretical issue, but I 
don't think I am.  In my mind, if you're ever in a situation to 
guess/predict/brute force a valid and current session token, there are a 
range of session hijacking possibilities that are all potentially bad.  
If you'd really like to learn more about why it is a potentially big 
deal, I'm providing some references:


Credential/Session Prediction
http://www.webappsec.org/projects/threat/classes/credential_session_prediction.shtml

"iDefense: Brute-Force Exploitation of Web Application Session ID's", By 
David Endler - iDEFENSE Labs

http://www.cgisecurity.com/lib/SessionIDs.pdf

"Best Practices in Managing HTTP-Based Client Sessions", Gunter Ollmann 
- X-Force Security Assessment Services EMEA

http://www.technicalinfo.net/papers/WebBasedSessionManagement.html
[see: Brute Forcing]

"A Guide to Web Authentication Alternatives", Jan Wolter
http://www.unixpapa.com/auth/homebuilt.html

Also see sections A5/A7/A8 of the OWASP Top 10 for 2007
http://www.owasp.org/index.php/Top_10_2007

A5 - Cross Site Request Forgery (CSRF) 


http://www.owasp.org/index.php/Top_10_2007-A5

A7 - Broken Authentication and Session Management 


http://www.owasp.org/index.php/Top_10_2007-A7

A8 - Insecure Cryptographic Storage 


http://www.owasp.org/index.php/Top_10_2007-A8

   * *Do not* *create cryptographic algorithms*. Only use approved
 public algorithms such as AES, RSA public key cryptography, and
 SHA-256 or better for hashing.
   * *Do not* *use weak algorithms*, such as MD5 / SHA1. Favor safer
 alternatives, such as SHA-256 or better.


PDF: http://www.owasp.org/images/e/e8/OWASP_Top_10_2007.pdf

Thanks,
Minoo Hamilton


Mark Thomas wrote:

Filip Hanik - Dev Lists wrote:
  

you don't need to lobby, simply create a patch in Bugzilla



Although it is likely to get ignored / end up as WONTFIX. I don't see
what the security issue is here. How does an MD5 collisions affect the
security of the session ID?

Mark

  

Minoo Hamilton wrote:


I'd like to re-raise an issue, since I didn't get too much of a
response, originally.  Who can I talk to to lobby to get the default
behavior of using MD5 session token hashes to change?  If you weren't
aware of it, there has been a recent and highly-publicized breaking of
SSL, by creating a rogue certificate authority, using collisions in
MD5.  Creating collisions in MD5 are no longer a "highly theoretical"
attack for potential session hijacking.  I'd very much like to see the
default behavior of Tomcat  session tokens become more secure by
default (possibly SHA-256).  I think the default hashing algorithm
should not be a known broken and insecure one.

MD5 considered harmful today
Creating a rogue CA certificate

http://www.win.tue.nl/hashclash/rogue-ca/

Any thoughts?

Thanks,
Minoo Hamilton


Tim Funk wrote:
  

It is probably due to old code which works just fine when SHA might
not have been "easily available" in all JVM's. (back in 2002?)

So a quick recap for folks ... a session id is generated by
1) Getting a random number
2) Hashing it
3) Converting the hashed bytes to something text [base64] so they fit
in a cookie without extra work

Steps 1-3 are repeated until enough chars are present for the
configured  session ID length.

So if an attacker *could* get reverse of the hash - it would be a
random number. SessionId length is configurable - so you could change
your session length to be larger so that mulitple random numbers
become digested. And then keep the session length small enough so
that next hash is not completely concatenated into the id. So at best
the attack has a one full hash plus part of a another hash to work
with. (As of this writing - I cant recall how times digest is called
by default so I'm not sure if a single full hash is in the session
id, or part of one, or multiples)

*** BUT *** If the random number and entropy to get the random number
are "good enough" - hashing is already overkill. But in the case
where the entropy and random number generator are "bad" - hashing
provides another line of defense against determining the current
random number and then being able to guess the next random number.


-Tim

Minoo Hamilton wrote:


Greetings Tomcat Developers,
 I am a security researcher who has recently been getting into
Apache Tomcat security hardening.  Forgive me if my failed attempt
to find the answer to this question has brought me prematurely to
this list.  I've been trying to figure out why the Apache Tomcat 6
Manager component defaults to using the MD5 hash algorithm for
session token creation.  It has long been seen as a questionable
hash algorithm due to known collisions.  Why not use SHA-1 by
default, instead?  Has anybody looked at SecureRandom which uses
SHA-1?  I as

Re: Why are manager session tokens generated with MD5 by default?

2009-01-05 Thread Minoo Hamilton 

Preston L. Bannister wrote:

How would you reverse a session-id from an MD5 hash? The exploit used to
forge an SSL certificate will not help you. The MD5 exploit is irrelevant to
this particular usage.

Lots of links and discussion:
http://www.schneier.com/blog/archives/2008/12/forging_ssl_cer.html
  
I'm fully aware that this is different, Preston.  And I am certain that 
there are many things I don't understand about security.  All I meant to 
point out by the reference was that the idea that MD5 collisions are 
theoretical, based on the notion of computational expense, should now be 
shattered.



If you are connecting to *any web application* on a high-value target over
an insecure network using HTTP (not HTTPS) then you already have a *Very
Large Problem* (think about man-in-the-middle attacks). Changing the hash
applied to session ids is not going to help.
  
Yes, but what I'm suggesting relates to brute forcing and session 
hijacking scenarios.  I totally agree that SSL definitely makes it all 
much harder to pull off.  Nonetheless, many sites have vulnerabilities 
in how they handle these things (e.g. the recent Yahoo Mail problem), so 
taking SSL for granted can be a problem, as well.



Minoo, as a "security researcher" you should already be clear on the
relative importance of differing risks, and cost/value ratios of exploits.
Use of the MD5 hash as described is entirely harmless.
  
Thanks for the air quotes, Preston.  The problem with your line of logic 
is that it ignores asymmetries -- the thing you don't thing is a problem 
that can sometimes be your biggest problem.   I tend to treat things 
equally till I'm certain, because risk does not follow a normal 
distribution model, when it comes to vulnerabilities. 

Anyhow, I have come to the Tomcat developer community to both be 
supportive and to ask for help in determining if this is or is not a 
real risk.  Clearly you think it is not.  I appreciate your feedback.


Minoo




  



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Why are manager session tokens generated with MD5 by default?

2009-01-05 Thread William A. Rowe, Jr. 
Mark Thomas wrote:
> Filip Hanik - Dev Lists wrote:
>> you don't need to lobby, simply create a patch in Bugzilla
> 
> Although it is likely to get ignored / end up as WONTFIX. I don't see
> what the security issue is here. How does an MD5 collisions affect the
> security of the session ID?

The only reason I can think of to apply it would be that md5 shouldn't
enter the equation as an algorithm on a FIPS-140 application.  But since
anyone approaching this problem is trying to apply FIPS-140 to the SSL
communications layer, and that the session and user credentials are
probably not subjected to those rigours, you are possibly right.

The real answer as Filip suggests is to offer a patch, and find a committer
who will champion it and apply it for you :)

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org