tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Tomcat (v 6.0.32) write response to wrong client socket
Date Wed, 09 Jul 2014 09:49:01 GMT
On 09/07/2014 08:43, wrote:
> Hello,
> We got a serious problem on our online banking applications: a user U1 of bank A got
to see the data of another user U2 of another bank B.
> It happened only once, before and after that went everything well.
> The two same online banking applications are running on one instance of tomcat (V.6.0.32)
and have different backend path.

That is quite an old version with a number of public security
vulnerabilities to be using for a banking application.

> The logs show that the problem must be not on the side of web application (frontend),
backend and firewall. The scenario looks as following:
> 1.      U1 log on the online banking of bank A and U2 log on the online banking of
> bank B, and the two sessions have been running well a while till
> 2.      later at the exactly same time U1 wanted to see the start page and U2
> booking
> detail
> 3.      U1 got to see the false data of the booking detail of U2.
> 4.         after that the two sessions went further well without any problem
> In the access log of the tomcat seems everything went well:
> Access log Bank A (U1):
> - - F862B9AD5DA9AC4A0D38B46D4E5B0D6C [15/Jun/2014:16:03:41 +0200]
> HTTP/1.1 GET /finprdcbo/defAccountStartPage.account
> ?DIRTY=Y&DEFAULT=1&node=STARTSEITE 200 69000 /ebanking/defAccountStatementDetail.account
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0
> Access log Bank B (U2):
> - - 12A6E21F0D6321A95C553B160DBCC9A0 [15/Jun/2014:16:03:40 +0200]
> HTTP/1.1 POST /finprdzrb/defAccountStatementOfAccount.account  200 45765 /ebanking/defAccountAssetOverview.account
Mozilla/5.0 (X11; Linux i686;
> rv:24.0) Gecko/20100101 Firefox/24.0

These logs show the requests coming from the same IP address. Since the
requests are from different users then there must be something acting as
a reverse proxy. Is it the firewall? Is it some other component?

> But the response of the request for booking detail from U2 was mistakenly sent to U1.
 We can confirm this by looking into the logs of firewall as
> following:
> Firewall log of Session U2:
> Jun 15 16:04:16  Web-Requests Access m:WR-SG-SUMMARY
> (https) POST /ebanking/defAccountStatementOfAccount.account
=> , status:<n/a>
, redirection URL:<n/a> , referer:/ebanking/defAccountAssetOverview.account , mapping:blappl-zrb
, request size: 1089 , backend response size: <n/a> , audit
> token:308792478954626740 rid:U52nvH8AAAEAAAoy1CIAAAno
> sid:384490af19eb229b7f0874b6ef0323c8 ip:  12
> Fact :  "backend response size: <n/a>" means there is no reponse from tomcat for
the request of  POST /ebanking/defAccountStatementOfAccount.account and a timeout is trigged
> Firewall log of Session U1:
> Jun 15 16:03:40  Web-Requests Access SG_child[14145]: m:WR-SG-SUMMARY
> (https) GET /ebanking/defAccountStartPage.account?DIRTY=Y&DEFAULT=1&node=STARTSEITE
=> , status:200 , redirection
URL:<n/a> , referer:/ebanking/defAccountStatementDetail.account , mapping:blappl-cbo
, request size: 614 , backend response size: 45765 , audit
> token:147310158715306970 request total 287469 , allow/deny filters 3780 , backend responsiveness
208455 , response processing 74282 , ICAP reqmod <n/a> , ICAP respmod <n/a> rid:U52nvH8AAAEAAATYu6cAAATi
sid:1dad4372b4a2f67d980e6e195aa954fe ip:  12
> Fact: "backend response size: 45765" means the reponse of Request of U2 is mistakenly
passed to U1. See the same size of the response in the access log Bank B
> (U2):s

The firewall appears to be transforming the URL. That suggests it is the
firewall that is acting as the reverse proxy. (Aside: Transforming the
URL like this is doable but does require very careful configuration to
ensure everything still works properly)

> My questions:
> 1.      Is such a problem (bug) already known?

Have you looked in the changelog?
Mixing up responses would be a security issue so have you looked in

> 2.      When will the tomcat access log be written? after sent of response or
> before?

It isn't quite that simple. In Tomcat 6 (it changes in 7.0.x) the access
log is written after the application has finished writing the response
to the buffer but before the content of that buffer is written to the

> 3.      how could the problem happen on the side of tomcat?

Depending on exactly how the application works, CVE-2011-3375 might be
able to trigger this but given that requires an error to occur it looks

> 4.      how could the problem be hidden otherwise?

Most errors of this type are eventually traced to application errors.
The most frequent error is the application retaining a reference to the
response and/or request objects beyond a single request.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message