[
https://issues.apache.org/jira/browse/LOG4J2-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams updated LOG4J2-289:
---------------------------------
Description:
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 interpreted, 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 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 Log4j 1 and Log4j 2.
2) Future Log4j 1 and 2 Javadoc should be generated with 7u25 or better. 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 prefer it that way, because the Javadoc is much more visually
attractive in Java 7.
[1]
http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html
[2] http://www.kb.cert.org/vuls/id/225657
was:
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 interpreted, 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 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 Log4j 1 and Log4j 2.
2) Future Log4j 1 and 2 Javadoc should be generated with 7u25 or better. 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 prefer it that way, because the Javadoc is much more visually
attractive in Java 7.
I will file an issue about this two, but I wanted to go ahead and make the list
aware.
Nick
[1]
http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html
[2] http://www.kb.cert.org/vuls/id/225657
> Change Javadoc generation per CVE-2013-1571, VU#225657
> ------------------------------------------------------
>
> Key: LOG4J2-289
> URL: https://issues.apache.org/jira/browse/LOG4J2-289
> Project: Log4j 2
> Issue Type: Bug
> Components: Documentation
> Affects Versions: 2.0-beta7
> Reporter: Nick Williams
> Priority: Critical
> Fix For: 2.0-beta8
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> 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 interpreted, 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 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 Log4j 1 and Log4j 2.
> 2) Future Log4j 1 and 2 Javadoc should be generated with 7u25 or better.
> 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 prefer it that way, because the Javadoc is much more visually
> attractive in Java 7.
> [1]
> http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html
> [2] http://www.kb.cert.org/vuls/id/225657
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
