CVE-2020-1935

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

CVE-2020-1935

George Stanchev-2
The description for this CVE is pretty vague (as perhaps necessary) but we have a customer that is trying to assess their risk for this CVE. They are behind a reverse-proxy. Even though the description on Tomcat's security page states that the risk is low it doesn't describe how would a reverse-proxy mishandle the Transfer-Encoding in order to compromise the backend Tomcat server. Any information about this exploit would be appreciated. (I did try to read the commit but it is rather large so it would require more time to unroll the fix for me than getting a direct answer)...

George
Reply | Threaded
Open this post in threaded view
|

Re: CVE-2020-1935

Christopher Schultz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

George,

On 7/24/20 15:15, George Stanchev wrote:
> The description for this CVE is pretty vague (as perhaps
> necessary) but we have a customer that is trying to assess their
> risk for this CVE.

Their risk is probably very low. Their risk of a bunch of other
"important" items included in later releases is probably much higher.

What's going on at this client that they are rapidly approaching an
8-month delay in issuing this security patch?

> They are behind a reverse-proxy. Even though the description on
> Tomcat's security page states that the risk is low it doesn't
> describe how would a reverse-proxy mishandle the Transfer-Encoding
> in order to compromise the backend Tomcat server.
It's a fairly small window of opportunity. Basically, several bugs in
both the reverse proxy /and/ Tomcat would have to both be present in
order to thread the needle.

> Any information about this exploit would be appreciated. (I did
> try to read the commit but it is rather large so it would require
> more time to unroll the fix for me than getting a direct
> answer)...
Nobody from the Security Team is going to explain how to exploit this
or test to see if you are vulnerable. Sorry. :(

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8bVSUACgkQHPApP6U8
pFjXJg//Zto3QQN0sdPgl/JNCFwJTMdzQg1+OzwebLLa+epRmdkZ5HpUBTGpB5Uh
JHRHu/U1CnFUaCOUNYCix5TaqyKErODhouJlGG7uII68EqMb+xSB0qMRvr16tqrp
l32wv6PE/ehSN/1VTpWwOvctEifYAuK8CFEs4U6iOfKhPKNew/ynv2DeErD0rS9n
d8IQLGK255CWx3CiYDUT+eGCgJ1eVSVed0jZU00iADoivCK4MAWO3b6Cn66QFHLq
Qe0Siq0ZuY3BvWYOvHybtaDJiEEgLar6v/15ueslsh7q20m+SyOi+5HEikTSlUhU
Ws5PREOAJuGVk2HT9NL2OgSRtcT/zAi7WPkGaa20wOugoTB/bcPOjoT37BxpPpsB
YffsGVPiTEwlLX29jY09X/JfgyI0HWIkZVUrvIxuAdVqRyfbz4PNqSvz45HUS66X
fWnfAYPw3l6pDPWtdu0Hqc/oQtuDOyfzVLsEjgx3cCxnTY5honEVpL6Gt+P9AQQY
tlBdtEpynrvmiF2aE+dxu2GbdtjoDaHouE5eqBuA1VCFiLmMb5HHey1N6j/yLZke
ffc6IQToyCdeubgf+qGP3wC5eYUOVmy3LCZEPU/LzbckW0xF28GPCKmwZ4FyKr1W
EKMtKr25ibHJDp60DhbCD8eqGFHfWC5JGNjS0Gqkr798kf4qghU=
=dU//
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: CVE-2020-1935

George Stanchev-2
Chris,

This is just silly. The code change is there. If I am rouge actor, I can and I will understand issue and try to produce exploit. With explanation like this legitimate Tomcat users are left to scratch their head if they are vulnerable or not especially as the explanation says that a 3rd party upstream component *could* be misconfigured but does not explain how. I hope you understand the absurdity of the situation and how it makes the job of people like me just harder and it does not provide any additional security. I hope the rest of the Tomcat team doesn't share your sentiment.

Cheers!

George

-----Original Message-----
From: Christopher Schultz <[hidden email]>
Sent: Friday, July 24, 2020 3:40 PM
To: [hidden email]
Subject: Re: CVE-2020-1935

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

George,

On 7/24/20 15:15, George Stanchev wrote:
> The description for this CVE is pretty vague (as perhaps
> necessary) but we have a customer that is trying to assess their risk
> for this CVE.

Their risk is probably very low. Their risk of a bunch of other "important" items included in later releases is probably much higher.

What's going on at this client that they are rapidly approaching an 8-month delay in issuing this security patch?

> They are behind a reverse-proxy. Even though the description on
> Tomcat's security page states that the risk is low it doesn't describe
> how would a reverse-proxy mishandle the Transfer-Encoding in order to
> compromise the backend Tomcat server.
It's a fairly small window of opportunity. Basically, several bugs in both the reverse proxy /and/ Tomcat would have to both be present in order to thread the needle.

> Any information about this exploit would be appreciated. (I did try to
> read the commit but it is rather large so it would require more time
> to unroll the fix for me than getting a direct answer)...
Nobody from the Security Team is going to explain how to exploit this or test to see if you are vulnerable. Sorry. :(

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8bVSUACgkQHPApP6U8
pFjXJg//Zto3QQN0sdPgl/JNCFwJTMdzQg1+OzwebLLa+epRmdkZ5HpUBTGpB5Uh
JHRHu/U1CnFUaCOUNYCix5TaqyKErODhouJlGG7uII68EqMb+xSB0qMRvr16tqrp
l32wv6PE/ehSN/1VTpWwOvctEifYAuK8CFEs4U6iOfKhPKNew/ynv2DeErD0rS9n
d8IQLGK255CWx3CiYDUT+eGCgJ1eVSVed0jZU00iADoivCK4MAWO3b6Cn66QFHLq
Qe0Siq0ZuY3BvWYOvHybtaDJiEEgLar6v/15ueslsh7q20m+SyOi+5HEikTSlUhU
Ws5PREOAJuGVk2HT9NL2OgSRtcT/zAi7WPkGaa20wOugoTB/bcPOjoT37BxpPpsB
YffsGVPiTEwlLX29jY09X/JfgyI0HWIkZVUrvIxuAdVqRyfbz4PNqSvz45HUS66X
fWnfAYPw3l6pDPWtdu0Hqc/oQtuDOyfzVLsEjgx3cCxnTY5honEVpL6Gt+P9AQQY
tlBdtEpynrvmiF2aE+dxu2GbdtjoDaHouE5eqBuA1VCFiLmMb5HHey1N6j/yLZke
ffc6IQToyCdeubgf+qGP3wC5eYUOVmy3LCZEPU/LzbckW0xF28GPCKmwZ4FyKr1W
EKMtKr25ibHJDp60DhbCD8eqGFHfWC5JGNjS0Gqkr798kf4qghU=
=dU//
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: CVE-2020-1935

Mark Thomas-2
George,

As an open source project with an open development process, the Tomcat
security team has a number of challenges to deal with.

First, any commit to address a security issue will be public before the
security issue is announced and before a release is available that
includes the fix. We therefore have to be careful that the commit and
associated log entry do not draw attention to the issue.

Secondly, we know that a large proportion of attacks are from "script
kiddies" that run every attack they (or more likely the toolkit they
downloaded) know against every server they can find. We therefore do not
provide proofs of concept, recipes for reproducing issues (we can't stop
the original reporter producing them) or specific details of the attack
where we can avoid doing so. Yes, a sophisticated attacker could reverse
engineer some issues but they tend not share when they do so and - on
balance - we consider not disclosing the details the right thing to do.

(As an aside I haven't looked at how easy issues are to reverse engineer
from the commit that fixed them. Going from memory I can only recall
that some would be very simple and some very unlikely. I can't recall
enough information to determine what proportion they are in. That might
be an interesting exercise.)

Thirdly, we want to provide users with enough information to determine
if they are vulnerable without providing instructions to reproduce the
issue (see previous point).

As I am sure you can appreciate, there is a tricky balance to strike
here. As I wrote both the commit that fixed the issue and the
vulnerability announcement, let me see if I can reword it in a way that
is more helpful.

If the reverse proxy accepts anything other then CRLF as the end of line
marker for an HTTP header (it shouldn't the HTTP/1.1 RFCs require CRLF
for headers) then a request smuggling attack as described by
CVE-2020-1935 is likely to be possible.

It should be relatively simple to test what the reverse proxy accepts
and doesn't accept. For completeness you might want to test how it
responds to all bytes from 0x00 to OxFF in a field name and/or value as
well and ensure that it is compliant with RFC 7230.

HTH,

Mark



On 24/07/2020 23:13, George Stanchev wrote:

> Chris,
>
> This is just silly. The code change is there. If I am rouge actor, I can and I will understand issue and try to produce exploit. With explanation like this legitimate Tomcat users are left to scratch their head if they are vulnerable or not especially as the explanation says that a 3rd party upstream component *could* be misconfigured but does not explain how. I hope you understand the absurdity of the situation and how it makes the job of people like me just harder and it does not provide any additional security. I hope the rest of the Tomcat team doesn't share your sentiment.
>
> Cheers!
>
> George
>
> -----Original Message-----
> From: Christopher Schultz <[hidden email]>
> Sent: Friday, July 24, 2020 3:40 PM
> To: [hidden email]
> Subject: Re: CVE-2020-1935
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> George
> George,
>
> On 7/24/20 15:15, George Stanchev wrote:
>> The description for this CVE is pretty vague (as perhaps
>> necessary) but we have a customer that is trying to assess their risk
>> for this CVE.
>
> Their risk is probably very low. Their risk of a bunch of other "important" items included in later releases is probably much higher.
>
> What's going on at this client that they are rapidly approaching an 8-month delay in issuing this security patch?
>
>> They are behind a reverse-proxy. Even though the description on
>> Tomcat's security page states that the risk is low it doesn't describe
>> how would a reverse-proxy mishandle the Transfer-Encoding in order to
>> compromise the backend Tomcat server.
> It's a fairly small window of opportunity. Basically, several bugs in both the reverse proxy /and/ Tomcat would have to both be present in order to thread the needle.
>
>> Any information about this exploit would be appreciated. (I did try to
>> read the commit but it is rather large so it would require more time
>> to unroll the fix for me than getting a direct answer)...
> Nobody from the Security Team is going to explain how to exploit this or test to see if you are vulnerable. Sorry. :(
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8bVSUACgkQHPApP6U8
> pFjXJg//Zto3QQN0sdPgl/JNCFwJTMdzQg1+OzwebLLa+epRmdkZ5HpUBTGpB5Uh
> JHRHu/U1CnFUaCOUNYCix5TaqyKErODhouJlGG7uII68EqMb+xSB0qMRvr16tqrp
> l32wv6PE/ehSN/1VTpWwOvctEifYAuK8CFEs4U6iOfKhPKNew/ynv2DeErD0rS9n
> d8IQLGK255CWx3CiYDUT+eGCgJ1eVSVed0jZU00iADoivCK4MAWO3b6Cn66QFHLq
> Qe0Siq0ZuY3BvWYOvHybtaDJiEEgLar6v/15ueslsh7q20m+SyOi+5HEikTSlUhU
> Ws5PREOAJuGVk2HT9NL2OgSRtcT/zAi7WPkGaa20wOugoTB/bcPOjoT37BxpPpsB
> YffsGVPiTEwlLX29jY09X/JfgyI0HWIkZVUrvIxuAdVqRyfbz4PNqSvz45HUS66X
> fWnfAYPw3l6pDPWtdu0Hqc/oQtuDOyfzVLsEjgx3cCxnTY5honEVpL6Gt+P9AQQY
> tlBdtEpynrvmiF2aE+dxu2GbdtjoDaHouE5eqBuA1VCFiLmMb5HHey1N6j/yLZke
> ffc6IQToyCdeubgf+qGP3wC5eYUOVmy3LCZEPU/LzbckW0xF28GPCKmwZ4FyKr1W
> EKMtKr25ibHJDp60DhbCD8eqGFHfWC5JGNjS0Gqkr798kf4qghU=
> =dU//
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: CVE-2020-1935

George Stanchev-2
Hi Mark,

Thank you for the detailed answer. I really appreciate your response. As someone who handles security at work I can empathize and agree with all the points you are making. In previous security disclosures it has been pretty easy for me to assess the risk of a vulnerability with either the disclosure or looking at the fix. This particular one is worded especially  vague because of the nebulous reference to an upstream 3rd party product's misconfiguration. We have a customer concerned about security, behind an F5 reverse proxy asking us if our product is going to be affected by this CVE and to explain why if not. Without at least basic understanding of how the issue happens, I cannot provide what they ask. Your explanation provides context, so again, I really appreciate your response.

Cheers!

George


-----Original Message-----
From: Mark Thomas <[hidden email]>
Sent: Sunday, July 26, 2020 5:09 AM
To: [hidden email]
Subject: Re: CVE-2020-1935

George,

As an open source project with an open development process, the Tomcat security team has a number of challenges to deal with.

First, any commit to address a security issue will be public before the security issue is announced and before a release is available that includes the fix. We therefore have to be careful that the commit and associated log entry do not draw attention to the issue.

Secondly, we know that a large proportion of attacks are from "script kiddies" that run every attack they (or more likely the toolkit they
downloaded) know against every server they can find. We therefore do not provide proofs of concept, recipes for reproducing issues (we can't stop the original reporter producing them) or specific details of the attack where we can avoid doing so. Yes, a sophisticated attacker could reverse engineer some issues but they tend not share when they do so and - on balance - we consider not disclosing the details the right thing to do.

(As an aside I haven't looked at how easy issues are to reverse engineer from the commit that fixed them. Going from memory I can only recall that some would be very simple and some very unlikely. I can't recall enough information to determine what proportion they are in. That might be an interesting exercise.)

Thirdly, we want to provide users with enough information to determine if they are vulnerable without providing instructions to reproduce the issue (see previous point).

As I am sure you can appreciate, there is a tricky balance to strike here. As I wrote both the commit that fixed the issue and the vulnerability announcement, let me see if I can reword it in a way that is more helpful.

If the reverse proxy accepts anything other then CRLF as the end of line marker for an HTTP header (it shouldn't the HTTP/1.1 RFCs require CRLF for headers) then a request smuggling attack as described by
CVE-2020-1935 is likely to be possible.

It should be relatively simple to test what the reverse proxy accepts and doesn't accept. For completeness you might want to test how it responds to all bytes from 0x00 to OxFF in a field name and/or value as well and ensure that it is compliant with RFC 7230.

HTH,

Mark



On 24/07/2020 23:13, George Stanchev wrote:

> Chris,
>
> This is just silly. The code change is there. If I am rouge actor, I can and I will understand issue and try to produce exploit. With explanation like this legitimate Tomcat users are left to scratch their head if they are vulnerable or not especially as the explanation says that a 3rd party upstream component *could* be misconfigured but does not explain how. I hope you understand the absurdity of the situation and how it makes the job of people like me just harder and it does not provide any additional security. I hope the rest of the Tomcat team doesn't share your sentiment.
>
> Cheers!
>
> George
>
> -----Original Message-----
> From: Christopher Schultz <[hidden email]>
> Sent: Friday, July 24, 2020 3:40 PM
> To: [hidden email]
> Subject: Re: CVE-2020-1935
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> George
> George,
>
> On 7/24/20 15:15, George Stanchev wrote:
>> The description for this CVE is pretty vague (as perhaps
>> necessary) but we have a customer that is trying to assess their risk
>> for this CVE.
>
> Their risk is probably very low. Their risk of a bunch of other "important" items included in later releases is probably much higher.
>
> What's going on at this client that they are rapidly approaching an 8-month delay in issuing this security patch?
>
>> They are behind a reverse-proxy. Even though the description on
>> Tomcat's security page states that the risk is low it doesn't
>> describe how would a reverse-proxy mishandle the Transfer-Encoding in
>> order to compromise the backend Tomcat server.
> It's a fairly small window of opportunity. Basically, several bugs in both the reverse proxy /and/ Tomcat would have to both be present in order to thread the needle.
>
>> Any information about this exploit would be appreciated. (I did try
>> to read the commit but it is rather large so it would require more
>> time to unroll the fix for me than getting a direct answer)...
> Nobody from the Security Team is going to explain how to exploit this
> or test to see if you are vulnerable. Sorry. :(
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8bVSUACgkQHPApP6U8
> pFjXJg//Zto3QQN0sdPgl/JNCFwJTMdzQg1+OzwebLLa+epRmdkZ5HpUBTGpB5Uh
> JHRHu/U1CnFUaCOUNYCix5TaqyKErODhouJlGG7uII68EqMb+xSB0qMRvr16tqrp
> l32wv6PE/ehSN/1VTpWwOvctEifYAuK8CFEs4U6iOfKhPKNew/ynv2DeErD0rS9n
> d8IQLGK255CWx3CiYDUT+eGCgJ1eVSVed0jZU00iADoivCK4MAWO3b6Cn66QFHLq
> Qe0Siq0ZuY3BvWYOvHybtaDJiEEgLar6v/15ueslsh7q20m+SyOi+5HEikTSlUhU
> Ws5PREOAJuGVk2HT9NL2OgSRtcT/zAi7WPkGaa20wOugoTB/bcPOjoT37BxpPpsB
> YffsGVPiTEwlLX29jY09X/JfgyI0HWIkZVUrvIxuAdVqRyfbz4PNqSvz45HUS66X
> fWnfAYPw3l6pDPWtdu0Hqc/oQtuDOyfzVLsEjgx3cCxnTY5honEVpL6Gt+P9AQQY
> tlBdtEpynrvmiF2aE+dxu2GbdtjoDaHouE5eqBuA1VCFiLmMb5HHey1N6j/yLZke
> ffc6IQToyCdeubgf+qGP3wC5eYUOVmy3LCZEPU/LzbckW0xF28GPCKmwZ4FyKr1W
> EKMtKr25ibHJDp60DhbCD8eqGFHfWC5JGNjS0Gqkr798kf4qghU=
> =dU//
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]