Sorry it took me so long to respond to this. None of this is confidential. The one known security vulnerability is a stack overflow in TProtocol::skip. The solution is pretty simple: keep track of the recursion depth and throw an exception if it gets too deep. I just haven't gotten around to implementing it yet. This fix has already been implemented in the Java protocol, and it is not as big of a risk in Python because Python already throws an exception when recursion goes too deep.
Another issue is with clients sending really long strings (or lists, but I don't think it is an issue with maps or sets). IF the client claims it is sending a 1 GB string, the server will preallocate 1 GB of memory for it. The different language mappings have different levels of support for setting maximums, but not maximums are set by default. A third issue is that, except for the C++ TNonblockingServer, all of the servers hold one thread per connection, even for idle connections, and there is no default read timeout, so a client could easily cause you to waste a ton of threads by simply opening a lot of connections and leaving them idle. I think the general problem is just that Thrift was designed for a LAN environment and was not coded with security in mind, so there are likely to be other pitfalls that we haven't even thought about. HTH. --David Michael Walsh wrote: > Hi David, > Back in http://publists.facebook.com/pipermail/thrift/2008-April/000983.html > you mentioned "There is at least one known security vulnerability, and > there are probably several others." > > That sounds a bit worrying... I'm just wondering has that specific one > (and perhaps some more) been fixed since? > > I understand if you can't mention exactly what the problem was, but if > you could, I'd like to know. :) > > Thanks > Michael >
