I'm guessing you mean the setReadLength() and setMaxSkipDepth stuff,
which forces lengths of strings etc. to be less than a particular limit,
and limits the maximum depth that will be skipped.
Unfortunately, one can still (I think) force an arbitrary amount of
memory to be allocated. (I think garbage collection should clean it up,
though).
Looking over some of the java code, I'm guessing that
marshalling/demarshalling efficiency was not considered to be of much
importance.
Mark Slee wrote:
Some of the libraries do have APIs to let the user specify maximum size-limits
(for instance I think the Java protocol implementations support this).
Most of it is not rocket science, it's just a matter of going in and making
sure the library objects all have the appropriate APIs to let the user specify
what the size limits should be. This work is not complete across all the
language library implementations.
In C++ there is a more complex vulnerability, which is that stack overflow can
be created by a rogue client sending an infinitely-nested
sturct-of-struct-of-struct..., which would cause TProtocol::skip() to keep
allocating stack frames.
-----Original Message-----
From: Mayan Moudgill [mailto:[email protected]]
Sent: Monday, April 26, 2010 1:52 PM
To: [email protected]; Mark Slee
Subject: Re: Anyone using Thrift for public endpoints?
I was wondering - isn't part of the problem that there is no way for a
user to handle these issues, that they are handled in the Thrift library
layer, so to speak?
Suppose a user wanted to add the behavior: "abort if an RPC message is
going to allocate more than 1MB data". Can a user do this? Or will he
have to hack the library code?
Mark Slee wrote:
Wrapping Thrift up in protocols like HTTP can help alleviate some of the common
issues and is a pretty reasonable thing to do.
But make no mistake, you still need to protect against the real issues. Even if
you use HTTP, someone can still send a bogus request that *claims* to contain a
1GB string and trick the server into a huge allocation, even if the HTTP POST
> request is < 1K in size.
Same goes for arguments about framing, etc. Even with a framed transport,
> nothing stops someone form intentionally sending a bogus frame size.
You do need to make sure that your Thrift code is equipped to handle all
these cases.
-----Original Message-----
From: Aron Sogor [mailto:[email protected]]
Sent: Sunday, April 25, 2010 5:50 PM
To: [email protected]
Subject: Re: Anyone using Thrift for public endpoints?
It depends.. If you talking about raw socket protocol, sure you need some
flow control and there is no such thing out of box.
If run over HTTP that your HTTP container probably can limit the POST
size... so you probably will not crash the server.
Aron
On Thu, Apr 22, 2010 at 1:24 AM, Mathias Herberts <
[email protected]> wrote:
Given that Thrift still suffers from crashes due to invalid data being
entered, I would not yet consider this a safe practice.
Maybe after GSoC.
But facebook does it for a test service IIRC.
