On Thu, Jan 14, 2021 at 12:21 AM Tom Hintz <[email protected]> wrote:
> Avoiding selection of arbitrary classes is key to CWE 502, but also the > bounding of arrays and strings (which are a specialized form of array). I don't see any mention of that in CWE 502, but I agree parsing untrusted data needs to be done carefully. I'll note that bounding arrays and strings is also very different than what is mentioned in CWE 502 as that can be done post-parser if you are only concerned with application behavior. The bigger concern with arrays and strings in my mind is memory consumption. In any case, this discussion is now quite specific to individual serialization formats and implementations and starts departing from what gRPC can provide. The main bound for arrays and strings is max message size. The default size is a bit too generous, but is still better than unbounded. You are free to reduce the max message size. That is pretty good protection for things like JSON decoded to Lists/Maps and probably for Flatbuffers. But for Protobuf and JSON decoded to schema-specific types, that works only weakly for arrays. The problem with arrays is not the array itself. Instead, the concern is more in line with a compression attack using a message that contains many fields. The serialized form may contain only a single field but in-memory it would consume memory for all its fields. The "fix" to this is complicated, although you can reduce the risk during your schema design (which is obviously error-prone). You can audit schemas though, and many of them are probably fine (assuming we're worried about attacks on a server and not untrusted servers), although you only need one with an issue to have a problem. Consider attacks based on messages with intentionally large number of > objects. Before that message is unpacked you need to know that the object > count is reasonable. Is that possible today? That requires parsing to find out. So you basically have to parse twice or integrate your check into the parser. That is possible via a proxy or in some language-specific APIs, but it would be annoying as there's no protobuf partial-parser to my knowledge that uses schema information but doesn't actually store the fields. You can make something yourself using classes like CodedInputStream in each language, but you'd need to consume the schema information as you parse. Protobuf has native protections for recursion limit and message size (although gRPC handles the size limit itself and disables the check in protobuf). Further detailed discussion should probably happen with protobuf folks if you care about the protobuf perspective. -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oNJPRiwWy9eDyuvgGcA4hb_48T32ptZzsAzXZTRF1HpsA%40mail.gmail.com.
smime.p7s
Description: S/MIME Cryptographic Signature
