3 ms·

https://xkcd.com/1354/ https://xkcd.com/1354/ In Heartbleed the parser parsed an incoming field specifying length, but failed to correlate it with the rest of

by ngneer 7y ago

https://xkcd.com/1354/ https://xkcd.com/1354/ In Heartbleed the parser parsed an incoming field specifying length, but failed to correlate it with the rest of the request. Had the parser been written to a stricter specification, that would not have happened. Typically that is what is meant by bounding computational complexity. Or at least that is my understanding of it.

tptacek 7y ago
I'm familiar with the bug, but not with the parser-theoretic response to the bug. Would LangSec somehow do away with the on-the-wire length encoding? Or would it simply say "your parser should check the length of incoming data"? Isn't that about as useful an insight as "validate user input"?
- ngneer 7y ago
  You raise a good point. The thing to realize is that the incoming packet data, like all data, is code. "Code written for which machine?" you might ask. Well, think of that data as code that is executed by the parser. If you think of the parser as the machine (yes, it is weird), then it becomes easier to see how the adversary tries to program it using data as code. Just like we advise people never to eval() untrusted data, the LangSec response is not just to validate user input, but to constrain the programmability of the machine. By lowering its ability to compute, you are effectively lowering the privilege given to the adversary. So, the LangSec answer would be to design the protocol so as to not require a parser that can become so easily confused by conflicting information. Hope that helps. FWIW, I think you raise a great point about the ease of use and practical utility of LangSec, and agree that its potential is thus capped.
  - ngneer 7y ago
    As another example, you should never unpickle untrusted data. The machine for parsing pickles is too powerful. https://stackoverflow.com/questions/25353753/python-can-i-safely-unpickle-untrusted-data https://stackoverflow.com/questions/25353753/python-can-i-sa...
squiggleblaz 7y ago
I don't understand how that's a problem with a parser. A parser is a tool for turning a flat buffer into structured data. The heartbleed problem described there is that a person wrote code that read outside of the buffer it was meant to read. Why aren't they independent problems? Also, how can you design an efficient data format that accepts data of a length determined by the user (hopefully cooperatively with the server), that is immune to buffer overflow reads. Once you say "I want between four and one thousand bytes", haven't you just stuffed yourself?

by ngneer 7y ago

tptacek 7y ago

I'm familiar with the bug, but not with the parser-theoretic response to the bug. Would LangSec somehow do away with the on-the-wire length encoding? Or would it simply say "your parser should check the length of incoming data"? Isn't that about as useful an insight as "validate user input"?

ngneer 7y ago
You raise a good point. The thing to realize is that the incoming packet data, like all data, is code. "Code written for which machine?" you might ask. Well, think of that data as code that is executed by the parser. If you think of the parser as the machine (yes, it is weird), then it becomes easier to see how the adversary tries to program it using data as code. Just like we advise people never to eval() untrusted data, the LangSec response is not just to validate user input, but to constrain the programmability of the machine. By lowering its ability to compute, you are effectively lowering the privilege given to the adversary. So, the LangSec answer would be to design the protocol so as to not require a parser that can become so easily confused by conflicting information. Hope that helps. FWIW, I think you raise a great point about the ease of use and practical utility of LangSec, and agree that its potential is thus capped.
- ngneer 7y ago
  As another example, you should never unpickle untrusted data. The machine for parsing pickles is too powerful. https://stackoverflow.com/questions/25353753/python-can-i-safely-unpickle-untrusted-data https://stackoverflow.com/questions/25353753/python-can-i-sa...

squiggleblaz 7y ago

I don't understand how that's a problem with a parser. A parser is a tool for turning a flat buffer into structured data. The heartbleed problem described there is that a person wrote code that read outside of the buffer it was meant to read. Why aren't they independent problems? Also, how can you design an efficient data format that accepts data of a length determined by the user (hopefully cooperatively with the server), that is immune to buffer overflow reads. Once you say "I want between four and one thousand bytes", haven't you just stuffed yourself?