3 ms·
My first question was: whoa, security? But you answer it in the docs, a bit. http://kentonv.github.com/capnproto/encoding.html http://kentonv.github.com/capnpr
by neilk 14y ago
My first question was: whoa, security? But you answer it in the docs, a bit.
http://kentonv.github.com/capnproto/encoding.html http://kentonv.github.com/capnproto/encoding.html (at the end)
How do we know that cycles/deep-nesting are the only possible attacks?
Maybe I'm overreacting - when you say pointers, these are really pointers to other locations in a file, not to code. I'm trying to think of what you could do with malformed data, but the worst thing I can think of is seeking to impossible positions. Maybe you could confuse or crash certain poorly written libraries, maybe by declaring a size for a data structure larger than the file. But the damage seems containable.
- kentonv 14y agoOh yes, security is a high priority. It's definitely wrong if malicious data can crash the receiver. The security notes on that page are not a complete story, just mentioning a couple of the less-obvious concerns. It's my intent that the Cap'n Proto runtime should protect the application from all security issues related to decoding, so that apps don't have to worry about it. The pointers are not actually native pointers, and when you dereference a pointer, the implementation does bounds checking to make sure it points within the message. I am a security wonk myself and have been thinking carefully about these things, but I also hope to get a formal security review from a third party before any production release.
- neilk 14y agoI'm not much of a security person, just thinking out loud. Cap'n Proto looks great though. I am also looking forward to saying "Cap'n Proto" in a work context.
- codexon 14y agoDoesn't this mean you are just pushing the decoding overhead into the runtime instead of upon receiving?
- kentonv 14y agoTo some extent, yes. But the total overhead of bounds-checking pointers in a Cap'n Proto message is orders of magnitude smaller than the overhead of decoding an equivalent protobuf message. (You can see this in my benchmarks. Look for "object manipulation time". It's usually a bit slower for Cap'n Proto, but the total time is dwarfed by I/O time.)
- alexchamberlain 14y agoWill you be able to disable bounds checking in a production version and/or move it to a once only for the entire object model?
- kentonv 14y agoYes! If you really, truly trust your input data, and it is in a single flat array, you can call capnproto::readRootTrusted<MyType>(ptr) instead of setting up a MessageReader. All bounds checks and other validation will be skipped. But, IMO this is only a good idea for, like, static constants embedded into the source code. Anything you read dynamically could be corrupted if not malicious, and you don't want that to kill your server. That's up to you, though.
- alexchamberlain 14y agoAgreed that bounds checking is the correct default here, but it's nice to know that in true C++ fashion we can shoot our leg off if we so choose.