On October 16, 2014 at 10:49:33 PM, Niraj Tolia (nto...@maginatics.com(mailto:nto...@maginatics.com)) wrote: > On Thu, Oct 16, 2014 at 9:43 PM, Chris Custine wrote: > > > > I am hoping others can confirm this, but after reading the advisory and > > several commentaries on it, I can’t think of any way that this exploit can > > affect a jclouds client. My interpretation is that in addition to the man > > in the middle requirement to force the protocol downgrade to SSL3 and > > subsequent packet modification, the exploit also requires some injection of > > code onto the client that will cause the client to execute repeated > > requests to an endpoint with an incrementing http path length and > > decrementing body length. > > > > No, anyone on the network path in between the client and server can > initiate this attack. https://www.openssl.org/~bodo/ssl-poodle.pdf and > https://www.dfranke.us/posts/2014-10-14-how-poodle-happened.html has a > lot more context on this but the interesting quote is:
This is the part that enables the exploit of SSL3, but this is not the actual exploit. > > So if an attacker that controls the network between the client and the > server interferes with any attempted handshake offering TLS 1.0 or > later, such clients will readily confine themselves to SSL 3.0. I understand that part, but this is just initiating the protocol downgrade. Downgrading to SSL3 isn’t really the issue, the issue is what is done to exploit that. They would still need to initiate many specifically formatted requests with varying path and body lengths from the *real* client to eventually resolve the encrypted attributes (from a jclouds standpoint this would probably be auth headers). This means that some part of the response from the actual endpoint would have to have some content that causes jclouds itself to go rogue and start making these orchestrated requests to nonsense urls, and with body content that is decremented to match the incrementing path, and do this many times (up to 256 times for each byte) until the server does not reject the SSL. If we have an flaw that allows execution of arbitrary script code of some variety in jclouds, then I am suddenly worried about a lot more than this exploit. :-) My 2 cents. Chris > > Cheers, > Niraj > > > > > > I don’t see any opportunities to inject random script code into a jclouds > > client and have it execute in a way similar to javascript in a browser, and > > from what I have read, that is what it would take to make use of this > > exploit. > > > > Hopefully other will have the opportunity to interpret this and weigh in > > with their insight as well. > > > > Thanks, > > Chris > > > > > > -- > > Chris Custine > > > > > > > > On October 16, 2014 at 6:20:23 PM, Andrew Phillips > > (aphill...@qrmedia.com(mailto:aphill...@qrmedia.com)) wrote: > > > > > > I prefer to exercise an abundance of caution and extend the vote until > > > > we understand the issue. > > > > > > I wasn't planning to close the vote until we have more details on > > > this, indeed. Obviously, the more people can help have a look at this, > > > the better ;-) > > > > > > PR at https://github.com/jclouds/jclouds/pull/575 > > > > > > Thanks! > > > > > > ap > >
