tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: CVE-2013-1571, VU#225657
Date Wed, 19 Jun 2013 08:26:01 GMT
On 19 June 2013 09:15, Mark Thomas <markt@apache.org> wrote:
> On 19/06/2013 00:42, Nick Williams wrote:
>>
>> Oracle has announced a Javadoc vulnerability (CVE-2013-1571 [1],
>> VU#225657 [2]) whereby Javadoc generated with Java 5, Java 6, or Java
>> 7 < 7u25 is vulnerable to a frame injection attack. Oracle has
>> provided a repair-in-place tool for Javadoc that cannot be easily
>> regenerated, but is urging developers to regenerate whatever Javadoc
>> they can using Java 7u25. For all practical purses, the vulnerability
>> really only applies to publicly-hosted Javadoc, so the Javadoc in our
>> existing Maven artifacts, downloads, and archived downloads really
>> doesn't have to be worried about (not that we could do anything about
>> it). My thoughts on this:
>>
>> 1) We should apply the repair-in-place tool ASAP to the Javadoc on
>> the website for Tomcat 6 and Tomcat 7.
>
>
> And Tomcat 5 and earlier. The javadoc for those isn't linked but remains
> available.
>
> I'll get on to this now.
>
>
>> 2) Future Tomcat 6 and 7 Javadoc should be generated with 7u25 or
>> better.
>
>
> Hmm. That will need some thought as the build needs to be run with the
> minimum Java version required for that major version. Maybe we can just run
> the Javadoc part with a different JDK. Either that, or run the fix tool over
> the result. This needs some investigation.
>
>
>> There will be no fix for Java 5 or 6. Thankfully, generating
>> Javadoc using a different JDK than you used to compile is quite easy
>> in both Maven and Ant. In fact, I personally prefer it that way,
>> because the Javadoc is much more visually attractive in Java 7.
>
>
> Hopefully it will be as simple as you suggest.
>

I found for JMeter that the only file that needed fixing was the
top-level index.html.
If always true that reduces what needs to be checked-out/put back.

There's also a bug in the quick-fix tool - it fails to delete the
renamed original file (on Windows, which locks files from delete)
because it fails to call fis.close() first.
[The code does not check that the delete is successful either.]

Should be easily possible to run the (fixed) tool on locally generated
javadoc before committing in future.

>
>> I will file an issue about this two, but I wanted to go ahead and
>> make the list aware.
>
>
> Thanks,
>
> Mark
>
>
>
>> Nick
>>
>> [1]
>>
>> http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html
>>
>>
> [2] http://www.kb.cert.org/vuls/id/225657
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>

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


Mime
View raw message