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 <ch...@christopherschultz.net> > Sent: Friday, July 24, 2020 3:40 PM > To: users@tomcat.apache.org > 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: 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
