Details
-
Type:
Bug
-
Status: RESOLVED
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 20.1, 21.0 [Tentative], 22.0 [Tentative]
-
Fix Version/s: 22.0 [Tentative]
-
Component/s: Tests & Quizzes (Samigo)
-
Labels:None
-
Test Plan:
Description
Seen in T&Q but may show up in other contexts.
When formatted text is processed by AntiSamy, long text in the <img> tag alt attribute with linebreaks can cause a java.lang.StackOverflowError, an uncaught exception in the tool POST handling. In T&Q this stop a student from continuing with an assessment.
Long and complex alt text like this can be created by CKeditor plugins like WIRIS MathType which are creating a text representation of a complex formula.
Full stack trace obtained by adding -XX:MaxJavaStackTraceDepth=50000 to JAVA_OPTS (in 20.x) shows
Caused by: java.lang.StackOverflowError at java.util.regex.Pattern$5.isSatisfiedBy(Pattern.java:5265) ... at java.util.regex.Matcher.matches(Matcher.java:604) at org.owasp.validator.html.model.Attribute.matchesAllowedExpression(Attribute.java:69) at org.owasp.validator.html.scan.MagicSAXFilter.startElement(MagicSAXFilter.java:322) at org.owasp.validator.html.scan.MagicSAXFilter.emptyElement(MagicSAXFilter.java:138) at org.cyberneko.html.HTMLTagBalancer.startElement(HTMLTagBalancer.java:744) at org.cyberneko.html.HTMLTagBalancer.emptyElement(HTMLTagBalancer.java:791) at org.cyberneko.html.HTMLScanner$ContentScanner.scanStartElement(HTMLScanner.java:2757) at org.cyberneko.html.HTMLScanner$ContentScanner.scan(HTMLScanner.java:2110) at org.cyberneko.html.HTMLScanner.scanDocument(HTMLScanner.java:920) at org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:499) at org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:452) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(TransformerImpl.java:659) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:728) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:343) at org.owasp.validator.html.scan.AntiSamySAXScanner.scan(AntiSamySAXScanner.java:159) at org.owasp.validator.html.scan.AntiSamySAXScanner.scan(AntiSamySAXScanner.java:107) at org.owasp.validator.html.scan.AntiSamySAXScanner.scan(AntiSamySAXScanner.java:89) at org.owasp.validator.html.AntiSamy.scan(AntiSamy.java:129) at org.owasp.validator.html.AntiSamy.scan(AntiSamy.java:75) at org.sakaiproject.util.impl.FormattedTextImpl.processFormattedText(FormattedTextImpl.java:395) at org.sakaiproject.util.impl.FormattedTextImpl.processFormattedText(FormattedTextImpl.java:313) at org.sakaiproject.jsf.renderer.RichTextEditArea.decode(RichTextEditArea.java:270) at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:858)
The alt text is validated by AntiSamy using the paragraph regexp defined in low-security-policy.xml:
<regexp name="paragraph" value="([\p{L}\p{N},'\.\s\-_\(\)\?]|&[0-9]{2};)*" />
The problem can be avoided by using a simpler regexp to validate alt text, e.g.
<regexp name="anyWithPara" value="(?s).*" />
although there may be appropriate checks handled by the paragraph regexp that should not be removed.
An alternate workaround is to increase the thread stack size in the JVM with -Xss10m for example (default is 1m), but this seems a bad idea because of additional memory overhead and it's not clear how large this would need to be to avoid all such problems.