I should have added that I am not arguing against patching and releasing a new RC. It will certainly help people to have warm fuzzies, but I can't see any way for it to be used against a codebase like jclouds. Hopefully someone can point out if I am wrong about that.
-- Chris Custine On October 16, 2014 at 11:04:22 PM, Chris Custine (chris.cust...@gmail.com(mailto:chris.cust...@gmail.com)) wrote: > > 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 > > > >
