RE: Invalid HTTP Header - attack?

[Justiniano, Tony]

My apologies, the version of Apache that came with the application is 9.0.13.

Tony Justiniano
Engineer I, EUS Engineering

Wyndham Destinations
6277 Sea Harbor Drive
Orlando, FL 32821
Office: +1-407-626-5416
Mobile: +1-407-463-4297
tony.justini...@wyn.com

-Original Message-
From: John Dale 
Sent: Thursday, August 1, 2019 4:37 PM
To: Tomcat Users List 
Subject: Re: Invalid HTTP Header - attack?

This e-mail is from an external source.  Use caution when opening attachments 
or clicking on links.

9.0.16.0 - this is the version installed with apt-get tomcat9 on ubuntu 18.04

Thank you for your feedback.

John


On 8/1/19, Konstantin Kolinko  wrote:
> чт, 1 авг. 2019 г. в 22:11, John Dale :
>>
>> Great feedback.  Thanks.
>>
>> I am the network department. :)
>>
>> This is a public facing service and shortly after I see this in the
>> log, I get an OOM exception and server shutdown.  Twice now this
>> morning.
>>
>
> The exception text is a bit misleading. It says "header", but it
> actually caused by sanity checks that are done when parsing the first
> line of the request (it precedes all the headers) aka the "request
> line". Thus you can see "parseRequestLine()" in the stack trace.
>
> As you may know, starting with HTTP/1.1 a client can send several HTTP
> request over the same connection (aka "keep alive", also "request
> pipelining"). If the length of the preceding request was not processed
> correctly either because the client sent an incorrect value of
> Content-Length header or if there is a bug, Tomcat will start parsing
> a new request at a wrong place and you will see such an error.
>
> Other cause of similar errors is when a client tries to connect using
> https: protocol to a http: connector. A small difference is that in
> that case the sanity check will be triggered earlier: when parsing the
> HTTP method name (the first component of the request line). In your
> case the error message says about the HTTP protocol version (the third
> component of the request line).
>
>
> 1. Personally, I always run with
> org.apache.catalina.connector.RECYCLE_FACADES=true
> as documented in [1].
>
> This property helps if there is a bug in a web application.
>
> 2. Make sure that you use an up-to-date version of Tomcat. You didn't
> tell us what version of Tomcat 9.0.x you are using.
>
> 3. If there is bug that causes Tomcat to incorrectly process a length
> of a request (a known way to trigger such a bug), I think that it will
> be treated as a security vulnerability that leads to an information
> leak.
>
> See CVE-2018-8037 )fixed in 9.0.10), CVE-2017-5651 and CVE-2017-5647
> (both fixed in 9.0.0.M19) for an idea.
>
> https://tomcat.apache.org/security-9.html
>
> Maybe you can configure creation of a heap dump during the OOM, so
> that it could be diagnosed what is causing a memory leak?
>
> Note that there is a procedure to report security issues [2]. A public
> Bugzilla should not be used for such reports.
>
> 4. The error message that you saw is printed only once in every 24
> hours. The latter occurrences during the same day are suppressed
> (logged at DEBUG level) to prevent flooding one's log files. This
> behaviour is controlled by system properties [3],
>
> org.apache.juli.logging.UserDataHelper.CONFIG
> org.apache.juli.logging.UserDataHelper.SUPPRESSION_TIME
>
> [1]
> https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html#System_Pr
> operties
>
> [2] https://tomcat.apache.org/security.html
>
> [3]
> https://tomcat.apache.org/tomcat-9.0-doc/config/systemprops.html#Loggi
> ng
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

This email message (including all attachments) is for the sole use of the 
intended recipient(s) and may contain confidential and/or privileged 
information, or may otherwise be protected by work product or other legal 
rules. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message. Unless otherwise 
indicated in the body of this email, nothing in this communication is intended 
to operate as an electronic signature and this transmission cannot be used to 
form, document, or authenticate a contract. Wyndham Destinations, Inc., and/or 
its affiliates may monitor all incoming and outgoing email communications, 
including the content of emails and attachments, for security, legal 
compliance, training, quality assurance and other purposes. The sender believes 
that this email and any attachments were free of any virus, worm, Trojan horse, 
malicious code and/or other contaminants when sent. Email transmissions cannot 

RE: FW: Apache Vulnerability - Understanding Connector Protocols

[Justiniano, Tony]

And that is what I was thinking, inadvertently, our scanning tool just found 
the apache version during a scan and corresponded it (the apache version) with 
a CVE.

Do you concur?

Tony Justiniano
Engineer I, EUS Engineering

Wyndham Destinations
6277 Sea Harbor Drive
Orlando, FL 32821
Office: +1-407-626-5416
Mobile: +1-407-463-4297
tony.justini...@wyn.com

-Original Message-
From: Mark Thomas 
Sent: Thursday, August 1, 2019 3:05 PM
To: users@tomcat.apache.org
Subject: Re: FW: Apache Vulnerability - Understanding Connector Protocols

This e-mail is from an external source.  Use caution when opening attachments 
or clicking on links.

On 01/08/2019 19:49, Justiniano, Tony wrote:
> Forwarding from an initial email this morning.
>
> ___
>
> Good Morning,
>
> I have been referred to this team in an attempt to have some questions 
> answered.  Before I ask those question let me provide a little background on 
> how I got to this point.
>
> Vulnerability scans showed that two of my servers in the DMZ came back with 
> CVE-2019-10072 vulnerability.  The CVE information is below:
>
> The fix for CVE-2019-0199 was incomplete and did not address HTTP/2
> connection window exhaustion on write in Apache Tomcat versions
> 9.0.0.M1 to 9.0.19 and 8.5.0 to 8.5.40 . By not sending WINDOW_UPDATE
> messages for the connection window (stream 0) clients were able to
> cause server-side threads to block eventually leading to thread
> exhaustion and a DoS.
> (CVE-2019-10072<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-201
> 9-10072>)
>
> The question I have is based on the server.xml configuring the connector and 
> protocols used.  Below are both of my servers server.xml connector entries:
> Server6:  protocol="org.apache.coyote.http11.Http11NioProtocol"
>
> Server5:  protocol="org.apache.coyote.http11.Http11NioProtocol"
>
> What I have highlighted are the protocols that are used for those specific 
> connectors on the servers.
>
> So, my question is in your professional opinions, if I'm not calling the 
> http2 protocol in any connector, my servers shouldn't be susceptible to the 
> particular CVE's vulnerability assessment.
>
> Please let me know if this question can be answered.

If you don't have



nested in a Connector anywhere in your server.xml that you can't possibly be 
vulnerable to HTTP/2 related vulnerabilities.

Looks like it is time to start shopping for a new vulnerability scanner.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

This email message (including all attachments) is for the sole use of the 
intended recipient(s) and may contain confidential and/or privileged 
information, or may otherwise be protected by work product or other legal 
rules. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message. Unless otherwise 
indicated in the body of this email, nothing in this communication is intended 
to operate as an electronic signature and this transmission cannot be used to 
form, document, or authenticate a contract. Wyndham Destinations, Inc., and/or 
its affiliates may monitor all incoming and outgoing email communications, 
including the content of emails and attachments, for security, legal 
compliance, training, quality assurance and other purposes. The sender believes 
that this email and any attachments were free of any virus, worm, Trojan horse, 
malicious code and/or other contaminants when sent. Email transmissions cannot 
be guaranteed to be secure or error-free, so this message and its attachments 
could have been infected, corrupted or made incomplete during transmission. By 
reading the message and opening any attachments, the recipient accepts full 
responsibility for any viruses or other defects that may arise, and for taking 
remedial action relating to such viruses and other defects. Neither Wyndham 
Destinations, Inc., nor any of its affiliated entities is liable for any loss 
or damage arising in any way from, or for errors or omissions in the contents 
of, this message or its attachments.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

FW: Apache Vulnerability - Understanding Connector Protocols

[Justiniano, Tony]

Forwarding from an initial email this morning.

___

Good Morning,

I have been referred to this team in an attempt to have some questions 
answered.  Before I ask those question let me provide a little background on 
how I got to this point.

Vulnerability scans showed that two of my servers in the DMZ came back with 
CVE-2019-10072 vulnerability.  The CVE information is below:

The fix for CVE-2019-0199 was incomplete and did not address HTTP/2 connection 
window exhaustion on write in Apache Tomcat versions 9.0.0.M1 to 9.0.19 and 
8.5.0 to 8.5.40 . By not sending WINDOW_UPDATE messages for the connection 
window (stream 0) clients were able to cause server-side threads to block 
eventually leading to thread exhaustion and a DoS. 
(CVE-2019-10072)

The question I have is based on the server.xml configuring the connector and 
protocols used.  Below are both of my servers server.xml connector entries:
Server6: