4.0.9 fixes a bug in the JRun connector ?

[Tom Chiverton]

I see there is a new version out, that only has "Workaround to avoid a
bug discovered in the Adobe JRun Connector (for IIS and Apache) that
can lead to corrupt requests and high memory usage" as a new thing.

Could anyone shed some more light on the bug, such as what
circumstances trigger the corruption and/or memory usage ?

I'm trying to figure out if it's worth rebooting our instances sooner
rather than later.

Tom

[Darren Pywell]

The JRun connector calls back to the web server (e.g. IIS/Apache) when
certain request information is requested by CF or an application
running in JRun. This occurs via a socket that runs the JRPP protocol.
We were able to identify that the when calls to getPathTranslated()
are made they go back to IIS/Apache via the JRun connector and the
data received could be consumed out the next request if the request
URL made against the server is malformed. This leads to the next
request being corrupted because some of its protocol bytes have been
read already. The JRPP protocol uses a simple 4 byte length encoding
for the size of data being passed over the socket and if the byte
protocol has become misaligned then it can happen that JRun interprets
the next 4 bytes as the size of the remaining data and allocates a
huge amount of memory for it - which can result in memory issues. We
have changed FusionReactor to alleviate the issue but it will need a
fix in the JRun connector which we are sending to Adobe.

If you have not been experiencing very rapid spikes in memory after
certain requests run then I would say that its not urgent for you. If
your server sometimes increases memory usage unpredictably around
500MB-1.5GB in memory usage then it is worth to apply FR4.0.9.

Hope that helps,
Darren

[Tom Chiverton]

Awesomely clear response, cheers !

Tom

[Nick Gleason]

Thanks for the info on 4.0.9 Darren.

There was some mention recently of an xss or sql injection vulnerability in
FR (related to the Request History screen, I think). Is that addressed in
4.0.9 as well?

Best,

Nick

> --
> You received this message because you are subscribed to the Google
> Groups "FusionReactor" group.
> To post to this group, send email to fusion...@googlegroups.com.
> To unsubscribe from this group, send email to
> fusionreacto...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/fusionreactor?hl=en.

[Darren Pywell]

Hi Nick,

We have a fix for the xss in test at the moment. It's gone to the two
guys who reported it and we continuing our testing internally. We hope
to have that available next week.

Kind Regards,
Darren

[Dave]

Darren,

What does this increase in memory look like in a heap dump? I have
similar symptoms but would like to confirm if it's the same issue.

dave

[Darren Pywell]

Hi Dave,

Heap memory increases by 500MB to 1.5GB from what we've seen. The
memory is being held in a byte array called sb1.

Hope that helps,
Darren

[Bartosz Frak]

Darren,

How was this fixed? Did you end up patching JRun directly or did you involve an agent to catch the malformed request and patch them before ProxyEndpoint takes a stab at them? Either way, would it be possible to post the solution here?

Thanks,

Bart

[Darren Pywell]

Bart,

In our case FusionReactor was calling methods to track data about the request from JRun. One of the calls that we made was to getPathTranslated() on the HttpServletRequest. This exacerbated a bug in the JRun connector which is used to provide the path data but due to a misaligned protocol buffer content would cause huge amount of memory to be allocated. We removed the call to getPathTranslated() and the problem was resolved. It could be that other methods also call back through the JRun connector so you may have to look if you are using getPathTranslated() or methods. 

Hope that helps,

Darren