[Red Hat JIRA] (WFLY-14247) Error Page is not displayed when trying to access META-INF or WEB-INF
by Michal Petrov (Jira)
[ https://issues.redhat.com/browse/WFLY-14247?page=com.atlassian.jira.plugi... ]
Michal Petrov commented on WFLY-14247:
--------------------------------------
Undertow rejects certain requests straight-away, bypassing the custom error page.
It's because of this method in {{ServletInitialHandler}}
{code:java}
private boolean isForbiddenPath(String path) {
return path.equalsIgnoreCase("/meta-inf/")
|| path.regionMatches(true, 0, "/web-inf/", 0, "/web-inf/".length());
}
{code}
So it will reject "/META-INF/" specifically and anything that starts with "/WEB-INF/".
Allowed request then end up with {{DefaultServlet}} which has this method:
{code:java}
private boolean isAllowed(String path, DispatcherType dispatcherType) {
if (!path.isEmpty()) {
if(dispatcherType == DispatcherType.REQUEST) {
//WFLY-3543 allow the dispatcher to access stuff in web-inf and meta inf
if (path.startsWith("/META-INF") ||
path.startsWith("META-INF") ||
path.startsWith("/WEB-INF") ||
path.startsWith("WEB-INF")) {
return false;
}
}
}
…
}
{code}
[~flavia.rainone], do you know why there are two checks set up like this? And shouldn't the first check still forward to the custom error page?
> Error Page is not displayed when trying to access META-INF or WEB-INF
> ---------------------------------------------------------------------
>
> Key: WFLY-14247
> URL: https://issues.redhat.com/browse/WFLY-14247
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 21.0.2.Final
> Reporter: Melvin Yam
> Assignee: Flavia Rainone
> Priority: Minor
> Attachments: mywebapp.war
>
>
> I have a simple webapp war file with the following structure:
> {quote}{{Listing archive: mywebapp.war}}{{--}}
> {{Path = mywebapp.war}}
> {{Type = zip}}
> {{Physical Size = 1441}}{{Date Time Attr Size Compressed Name}}
> {{------------------- ----- ------------ ------------ ------------------------}}
> {{2020-12-23 20:09:20 ....A 18 18 error.html}}
> {{2020-12-23 20:09:02 ....A 18 18 index.html}}
> {{2020-12-23 20:10:13 D.... 0 0 META-INF}}
> {{2020-12-23 03:16:37 ....A 39 39 META-INF\MANIFEST.MF}}
> {{2020-12-23 20:12:38 D.... 0 0 WEB-INF}}
> {{2020-12-23 20:12:28 D.... 0 0 WEB-INF\classes}}
> {{2020-12-23 20:12:35 D.... 0 0 WEB-INF\lib}}
> {{2020-12-23 20:11:54 ....A 480 248 WEB-INF\web.xml}}
> {{------------------- ----- ------------ ------------ ------------------------}}
> {{2020-12-23 20:12:38 555 323 4 files, 4 folders}}
> {quote}
>
> In web.xml, it defines the error page:
> {quote}<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://xmlns.jcp.org/xml/ns/javaee"
> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd" version="4.0">
> <display-name>mywebapp</display-name>
> <welcome-file-list>
> <welcome-file>index.html</welcome-file>
> </welcome-file-list>
> <error-page>
> <location>/error.html</location>
> </error-page>
> </web-app>
> {quote}
>
> After deploying the webapp successfully in local WildFly server.
> Accessing the following URL will trigger the error page to be shown:
> [http://127.0.0.1:8080/mywebapp/dummy]
> [http://127.0.0.1:8080/mywebapp/META-INF/MANIFEST.MF]
> [http://127.0.0.1:8080/mywebapp/META-INF/dummy/dummy]
>
> However, the following URL will NOT trigger the error page:
> [http://127.0.0.1:8080/mywebapp/META-INF]
> [http://127.0.0.1:8080/mywebapp/WEB-INF]
> [http://127.0.0.1:8080/mywebapp/WEB-INF/web.xml|http://127.0.0.1:8080/mywe...]
> [http://127.0.0.1:8080/mywebapp/WEB-INF/dummy/dummy]
> Instead, it just displays the text "404 - Not Found"
>
>
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (JGRP-2523) Cap max data read by TcpConnection or NioConnection
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2523?page=com.atlassian.jira.plugin... ]
Bela Ban resolved JGRP-2523.
----------------------------
Resolution: Done
> Cap max data read by TcpConnection or NioConnection
> ---------------------------------------------------
>
> Key: JGRP-2523
> URL: https://issues.redhat.com/browse/JGRP-2523
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.2.11, 5.1.3
>
>
> Both NioConnection and TcpConnection read the length (4 bytes) first, then allocate a buffer and call InputStream.readFully().
> If some random client ({{nc}}, {{curl}}, {{wget}} etc)connects accidentally, {{length}} might be huge and the memory allocation will fail with an OOME. This may even terminate the JVM, e.g. if {{-XX:+ExitOnOutOfMemoryError}} is set.
> Solution: introduce an attribute which caps the max length, and throws an exception (closing the connection), avoiding reading the data. If 0, the length will not be capped.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (JGRP-2135) OOM with JGroups 3.6.11.
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2135?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2135:
--------------------------------
Fixed properly in https://issues.redhat.com/browse/JGRP-2523
> OOM with JGroups 3.6.11.
> ------------------------
>
> Key: JGRP-2135
> URL: https://issues.redhat.com/browse/JGRP-2135
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.11
> Reporter: Zoltan Farkas
> Assignee: Bela Ban
> Priority: Major
> Fix For: 3.6.12, 3.6.20.Final
>
> Attachments: AppCluster.xml
>
>
> We are running our JVMs with : -XX:OnOutOfMemoryError="kill -9 %p"
> we have been experiencing OOMs fairly often, and the OOMs happen at:
> {code}
> Object / Stack Frame |Name | Shallow Heap | Retained Heap |Context Class Loader |Is Daemon
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> java.lang.Thread @ 0x81bdf838 |Connection.Receiver [144.77.77.53:50363 - 144.77.77.53:50363],sis-cluster.service,prodpmwsv5-6461| 120 | 456 |sun.misc.Launcher$AppClassLoader @ 0x800175a8|false
> |- at java.lang.OutOfMemoryError.<init>()V (OutOfMemoryError.java:48) | | | | |
> |- at org.jgroups.blocks.cs.TcpConnection$Receiver.run()V (TcpConnection.java:310)| | | | |
> |- at java.lang.Thread.run()V (Thread.java:745) | | | | |
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> {code}
> the Code where it happens is in TcpConnection.java:
> {code}
> while(canRun()) {
> try {
> int len=in.readInt();
> if(buffer == null || buffer.length < len)
> buffer=new byte[len];
> in.readFully(buffer, 0, len);
> updateLastAccessed();
> server.receive(peer_addr, buffer, 0, len);
> }
> catch(OutOfMemoryError mem_ex) {
> t=mem_ex;
> break; // continue;
> }
> catch(IOException io_ex) {
> t=io_ex;
> break;
> }
> catch(Throwable e) {
> }
> }
> {code}
> when allocating: buffer=new byte[len];
> it looks to me that some invalid large value is received and the process OOMs when allocating a huge byte array
> Running JVMs without kill on OOM would make this issue "dissapear" in the sense that it is swallowed by:
> {code}
> catch(OutOfMemoryError mem_ex) {
> t=mem_ex;
> break; // continue;
> }
> {code}
> Handling OutOfMemoryError is a strange implementation choice...
> instead a size limit should be employed to protect from receiving invalid sizes...
> My heap limit is 1GB and my heap dumps are 50Mb so the attempted allocation size is huge...
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months
[Red Hat JIRA] (JGRP-2523) Cap max data read by TcpConnection or NioConnection
by Bela Ban (Jira)
Bela Ban created JGRP-2523:
------------------------------
Summary: Cap max data read by TcpConnection or NioConnection
Key: JGRP-2523
URL: https://issues.redhat.com/browse/JGRP-2523
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.2.11, 5.1.3
Both NioConnection and TcpConnection read the length (4 bytes) first, then allocate a buffer and call InputStream.readFully().
If some random client ({{nc}}, {{curl}}, {{wget}} etc)connects accidentally, {{length}} might be huge and the memory allocation will fail with an OOME. This may even terminate the JVM, e.g. if {{-XX:+ExitOnOutOfMemoryError}} is set.
Solution: introduce an attribute which caps the max length, and throws an exception (closing the connection), avoiding reading the data. If 0, the length will not be capped.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 3 months