tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: CVE-2013-1571, VU#225657
Date Thu, 20 Jun 2013 15:33:21 GMT

On 6/20/13 9:31 AM, sebb wrote:
> On 20 June 2013 14:16, Christopher Schultz <> wrote:
>> Sebb,
>> On 6/19/13 4:26 AM, sebb wrote:
>>> On 19 June 2013 09:15, Mark Thomas <> 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.
>> Wow, the code for that quick-fix tool really is awful. If run in
>> recursuve-mode, it will leave every file that matches the "file list"
>> (index.html, etc.) open until the finalizers run (hah). There are also
>> swallowed exceptions, no finally blocks, etc.
> I've made some fixes (resource closures); these are at:
> Comments welcome if you spot any more.

I think you want to do a lot of the close() operations in finally
blocks, in case exceptions occur. While it probably won't allow the
program to function any better (that is, the old file need not be
deleted unless it is successfully-processed), it will reduce the number
of file handles kept open by the process.


View raw message