You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by bu...@apache.org on 2013/06/24 14:25:19 UTC
[Bug 55132] New: Javadoc vulnerability (CVE-2013-1571, VU#225657)
https://issues.apache.org/bugzilla/show_bug.cgi?id=55132
Bug ID: 55132
Summary: Javadoc vulnerability (CVE-2013-1571, VU#225657)
Product: Ant
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: critical
Priority: P2
Component: Core tasks
Assignee: notifications@ant.apache.org
Reporter: uwe@thetaphi.de
Recently Oracle released Java 7 update 25 to work around a serious frame
injection bug in the Javadocs as produced by JDK's javadoc tool. This also
applies to IBM J9 and JRockit.
The problem is: There is no public available bugfix release for Java 6 or Java
5 (which are also affected by the security issue). You can download 1.6.0_45
for MacOSX provided by Apple.
Any project that is on an older Java version (e.g. 1.5 or 1.6) and builds the
release candidates using the "official supported" Java version will produce
Javadocs that can no longer be published on the internet, because it would
bring any webserver administrator into trouble and may do harm to the company
(e.g., the ASF). ASF no longer allows to publish new javadocs with the frame
injection bug anymore (see mail to all committers) and enforces all PMCs to
"patch" their web site.
The Oracle patch tool is officially not ASF compliant (License-wise, see
https://issues.apache.org/jira/browse/LEGAL-171), so cannot be include into
official builds. But we still want to patch our javadocs directly after
generating them.
For Maven I provided a "replacement pather with ASF license), see
https://jira.codehaus.org/browse/MJAVADOC-370 - Maven will release a new
version ASAP.
For ANT, the Apache Lucene project has a ANT macro that can be called directly
after the <javadoc/> call (https://issues.apache.org/jira/browse/LUCENE-5072),
looks like that:
<!--
Patch frame injection bugs in javadoc generated files - see CVE-2013-1571,
http://www.kb.cert.org/vuls/id/225657
Feel free to use this macro in your own Ant build file. This macro works
together with the javadoc task on Ant
and should be invoked directly after its execution to patch broken
javadocs, e.g.:
<patch-javadoc dir="..." docencoding="UTF-8"/>
Please make sure that the docencoding parameter uses the same charset like
javadoc's docencoding. Default
is the platform default encoding (like the javadoc task).
The specified dir is the destination directory of the javadoc task.
-->
<macrodef name="patch-javadoc">
<attribute name="dir"/>
<attribute name="docencoding" default="${file.encoding}"/>
<sequential>
<replace encoding="@{docencoding}" summary="true"
taskname="patch-javadoc">
<restrict>
<fileset dir="@{dir}" casesensitive="false"
includes="**/index.html,**/index.htm,**/toc.html,**/toc.htm"/>
<!-- TODO: add encoding="@{docencoding}" to contains check, when we
are on ANT 1.9.0: -->
<not><contains text="function validURL(url) {" casesensitive="true"
/></not>
</restrict>
<replacetoken><![CDATA[function loadFrames() {]]></replacetoken>
<replacevalue expandProperties="false"><![CDATA[if (targetPage != "" &&
!validURL(targetPage))
targetPage = "undefined";
function validURL(url) {
var pos = url.indexOf(".html");
if (pos == -1 || pos != url.length - 5)
return false;
var allowNumber = false;
var allowSep = false;
var seenDot = false;
for (var i = 0; i < url.length - 5; i++) {
var ch = url.charAt(i);
if ('a' <= ch && ch <= 'z' ||
'A' <= ch && ch <= 'Z' ||
ch == '$' ||
ch == '_') {
allowNumber = true;
allowSep = true;
} else if ('0' <= ch && ch <= '9'
|| ch == '-') {
if (!allowNumber)
return false;
} else if (ch == '/' || ch == '.') {
if (!allowSep)
return false;
allowNumber = false;
allowSep = false;
if (ch == '.')
seenDot = true;
if (ch == '/' && seenDot)
return false;
} else {
return false;
}
}
return true;
}
function loadFrames() {]]></replacevalue>
</replace>
</sequential>
</macrodef>
It would be good to modify the ANT javadoc task to do this transformation
internally directly after calling the javadoc executable. The similar patch, as
used in Maven, could be ported 1:1 to Ant (replace plexus-utils with
DirectoryScanner and IOUtil/FileUtils by the ANT equivalents):
https://jira.codehaus.org/secure/attachment/63558/MJAVADOC-370.patch
We tested this approach with various JVMs, it correctly detects the buggy
javascript and patches for Oracle JDK 1.5.0_22, 1.6.0_32, 1.6.0_35, 1.7.0_21,
1.8.0-ea-b93, also Oracle JRockit and IBM J9 version 6 and 7. Oracle JDK
1.7.0_25 (and Apple JDK 1.6.0_45) will correctly not be touched. Same applies
for pre-1.5 JVMs as those dont have Javascript that's vulnerable, so patch will
ignore them.
Unfortunately, fixing ANT to do this would not help all projects, because in
contrast to Maven, the build.xml writer cannot decide which "javadoc-plugin" is
to be used, it depends on the Ant version installed on user's machine. So In
Lucene we will stay for a while with the current manual Ant macro, but it would
still be good to support patching by default with later Ant versions. On the
other hand, anybody who is afraid of publishing vulnerable javadoc can always
use <antversion/> to fail the build...
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55132] Javadoc vulnerability (CVE-2013-1571, VU#225657)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55132
Uwe Schindler (ASF) <uw...@thetaphi.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |uwe@thetaphi.de
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55132] Javadoc vulnerability (CVE-2013-1571, VU#225657)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55132
--- Comment #13 from Jackie Rosen <ja...@hushmail.com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55132] Javadoc vulnerability (CVE-2013-1571, VU#225657)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55132
--- Comment #11 from Stefan Bodewig <bo...@apache.org> ---
yes, done, thanks
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55132] Javadoc vulnerability (CVE-2013-1571, VU#225657)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55132
--- Comment #5 from Uwe Schindler (ASF) <uw...@thetaphi.de> ---
Are you sure that this works correct on windows?
fixData = FileUtils.readFully(new InputStreamReader(in, "US-ASCII")).trim()
.replace("\r\n", StringUtils.LINE_SEP)
.replace("\n", StringUtils.LINE_SEP);
On Windows and if the text file is also windows format this would replace \r\n
to \r\n (ok, no change), the second replace would replace the first \n again
into \r\n, so you would get \r\r\n.
On Linux it works correctly, maybe this is why you did not get it.
I checked this morning the Replace task, it does it correctly:
fixData = FileUtils.readFully(new InputStreamReader(in, "US-ASCII")).trim()
.replace("\r\n", "\n")
.replace("\n", StringUtils.LINE_SEP);
Also please note that String.replace uses a regular expression!!! So its better
to also use patchContent() to replace the line feeds.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55132] Javadoc vulnerability (CVE-2013-1571, VU#225657)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55132
--- Comment #12 from Stefan Bodewig <bo...@apache.org> ---
Ant 1.9.2 containing your fix has just been released.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55132] Javadoc vulnerability (CVE-2013-1571, VU#225657)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55132
Stefan Bodewig <bo...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
Target Milestone|--- |1.9.2
--- Comment #9 from Stefan Bodewig <bo...@apache.org> ---
In Ant's case the chicken-egg problem is less of a problem as Ant bootstraps
itself. In fact you do build Javadocs with the version you've just compiled -
or at least you can and will do so during the release process.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55132] Javadoc vulnerability (CVE-2013-1571, VU#225657)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55132
--- Comment #10 from Uwe Schindler (ASF) <uw...@thetaphi.de> ---
Hi Stefan,
i modified our ANT-based macro that patches Javadocs a little bit:
I removed the <restrict/> and made the <non><contains/></not> be part of the
fileset. So it should work with older ANT versions that dont understand
<restrict/>.
Here the code, maybe you can update the documentation page of the javadoc task
on the ANT website:
<!--
Patch frame injection bugs in javadoc generated files - see CVE-2013-1571,
http://www.kb.cert.org/vuls/id/225657
Feel free to use this macro in your own Ant build file. This macro works
together with the javadoc task on Ant
and should be invoked directly after its execution to patch broken
javadocs, e.g.:
<patch-javadoc dir="..." docencoding="UTF-8"/>
Please make sure that the docencoding parameter uses the same charset like
javadoc's docencoding. Default
is the platform default encoding (like the javadoc task).
The specified dir is the destination directory of the javadoc task.
-->
<macrodef name="patch-javadoc">
<attribute name="dir"/>
<attribute name="docencoding" default="${file.encoding}"/>
<sequential>
<replace encoding="@{docencoding}" summary="true"
taskname="patch-javadoc">
<fileset dir="@{dir}" casesensitive="false"
includes="**/index.html,**/index.htm,**/toc.html,**/toc.htm">
<!-- TODO: add encoding="@{docencoding}" to contains check, when we
are on ANT 1.9.0: -->
<not><contains text="function validURL(url) {" casesensitive="true"
/></not>
</fileset>
<replacetoken><![CDATA[function loadFrames() {]]></replacetoken>
<replacevalue expandProperties="false"><![CDATA[if (targetPage != "" &&
!validURL(targetPage))
targetPage = "undefined";
function validURL(url) {
var pos = url.indexOf(".html");
if (pos == -1 || pos != url.length - 5)
return false;
var allowNumber = false;
var allowSep = false;
var seenDot = false;
for (var i = 0; i < url.length - 5; i++) {
var ch = url.charAt(i);
if ('a' <= ch && ch <= 'z' ||
'A' <= ch && ch <= 'Z' ||
ch == '$' ||
ch == '_') {
allowNumber = true;
allowSep = true;
} else if ('0' <= ch && ch <= '9'
|| ch == '-') {
if (!allowNumber)
return false;
} else if (ch == '/' || ch == '.') {
if (!allowSep)
return false;
allowNumber = false;
allowSep = false;
if (ch == '.')
seenDot = true;
if (ch == '/' && seenDot)
return false;
} else {
return false;
}
}
return true;
}
function loadFrames() {]]></replacevalue>
</replace>
</sequential>
</macrodef>
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55132] Javadoc vulnerability (CVE-2013-1571, VU#225657)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55132
--- Comment #7 from Uwe Schindler (ASF) <uw...@thetaphi.de> ---
Hi Stefan,
works fine. I built the release and ran it on our Lucene checkout. I can
confirm, it works fine, it prints the message that it patched 1 file per
javadocs run (with vulnerable JDK). With 1.7.0_25 no line was printed.
In both cases, the Lucene-own macro patcher did not find any vulnerability
anymore - so it is also compatible with build.xml files that use the quick fix
macro.
I also checked the index.html output, the file is patched correctly and the
line feeds on windows look correct.
Thanks!
Uwe
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55132] Javadoc vulnerability (CVE-2013-1571, VU#225657)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55132
--- Comment #6 from Stefan Bodewig <bo...@apache.org> ---
good catch - should be fixed with svn revision 1496104
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55132] Javadoc vulnerability (CVE-2013-1571, VU#225657)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55132
--- Comment #1 from Stefan Bodewig <bo...@apache.org> ---
I'll look into it
First of all I'll add a FAQ entry pointing over here for the macrodef - and add
the macro to the javadoc manual page as well.
Porting the Maven patch over should be pretty easy, the DirectoryScanner API
looks quite compatible to Ant's DirectoryScanner - I wonder why ;-)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55132] Javadoc vulnerability (CVE-2013-1571, VU#225657)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55132
--- Comment #4 from Stefan Bodewig <bo...@apache.org> ---
manual page should be fixed as well
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55132] Javadoc vulnerability (CVE-2013-1571, VU#225657)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55132
--- Comment #8 from Uwe Schindler (ASF) <uw...@thetaphi.de> ---
One thing:
We have a chicken-egg or also known as bootstrap problem (same applied to the
maven javadoc plugin release, I pointed that out on the mailing list): The
Javadocs generated for the new ANT version with the internal fixer will have
the bug, because ANT does not build the javadocs with the version it currently
compiles. So theoretically to prevent buggy javadocs, Ant's build.xml file
should contain the macro to fix manually.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55132] Javadoc vulnerability (CVE-2013-1571, VU#225657)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55132
--- Comment #3 from Stefan Bodewig <bo...@apache.org> ---
Uwe, could you please look over svn revision 1496083 - this is a port of your
Maven patch.
The problem with the link seems to be it is opened inside the frame - I'll
modify the page to open it in a new window/tab.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55132] Javadoc vulnerability (CVE-2013-1571, VU#225657)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55132
--- Comment #2 from Uwe Schindler (ASF) <uw...@thetaphi.de> ---
Thanks for the link inside the manual, maybe post the whole macro there?
In my browser, the link does nothing... (Chrome)
--
You are receiving this mail because:
You are the assignee for the bug.