Are server 500 errors a security issue?

I’ve found that it’s possible to cause 500 errors on a server using curl and a faked GWT-Permutation with a POST payload. The payload is generating a java.lang.Exception on an Apache server.

Does this open up a security issue? Should I report it to Google’s GWT support?

To clarify the question: Would a significant number of server errors be a concern as a denial of service. I.e. could they exhaust server resources. (Sorry, if this is too hypothetical).

SEVERE: Exception while dispatching incoming RPC call
java.lang.NumberFormatException: Expected type 'int' but received a non-numerical value: 
    at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.getNumberFormatException(ServerSerializationStreamReader.java:999)
    at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.readInt(ServerSerializationStreamReader.java:537)
    at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.readString(ServerSerializationStreamReader.java:582)
    at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.prepareToRead(ServerSerializationStreamReader.java:488)
    at com.google.gwt.user.server.rpc.RPC.decodeRequest(RPC.java:240)
    at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:206)
    at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:248)
    at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:96)
    at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
    at java.lang.Thread.run(Thread.java:662)

Thanks! Dave

Answer

Obviously a stack trace is information disclosure.

Beyond that, I believe that a user should -never- see a 500 series error because – what is the user supposed to do about it?

Additionally, from a pentesting and remediation perspective – a 500 error could mean that any number of vulnerabilities exist, or none at all. How do we know?

It also makes it difficult to test the risk of a specific vulnerability. Using a recent example such as the now infamous Log4j vulnerabvility – if I send the ${jndi} payload and I get a 500 error – is it because the payload succeeded or is it entirely unrelated?

IMO all teams need to handle all exceptions, no excuses.