Re: [boost] Library for configuration file parsing

Subject: Re: [boost] Library for configuration file parsing
From: Marsh Ray (marsh_at_[hidden])
Date: 2010-11-29 17:56:19

On 11/28/2010 11:56 PM, Joel de Guzman wrote:
> On 11/29/2010 12:09 PM, Rob Riggs wrote:
>> On 11/28/2010 05:54 PM, Marsh Ray wrote:
>>> Honestly, the couple of times I've tried to use Spirit I have not
>>> been successful. I've
>>> done a few templates in my time but that library blows my mind. The
>>> concept is brilliant
>>> - and its implementation, heroic.
>>> But trying to actually use it tends to just make me feel dumb.
>> You are not the only one.
>>> Something I could understand in a debugger or, more importantly,
>>> review for security in
>>> a network-facing application.
>> +1
>>
>> The use of JSON will go far beyond that of a config file parser. The
>> number of "eyes" that
>> can grok Spirit code and accurately review it are vanishingly small.
>
> Why do you have to grok the internals of a library in order to use it
> successfully?

For most programs - you don't. Most code is written to the 
garbage-in-garbage-out standard. For valid inputs it is tested to 
produce valid outputs.

Well-written code goes the extra mile and tries to have well-defined 
handling even for invalid input.

But there's a third level for code in internet-facing apps that handles 
untrusted data. In this case it has to be resilient against even 
actively malicious inputs crafted by a skilled attacker. Proving the 
negative (there are no possible inputs which can produce undesired 
behavior) is usually harder than proving the positive (these valid 
inputs produce desired behavior). Experience shows that this kind of 
code doesn't happen by accident, even from the most solid traditional 
software process.

The state of secure coding art seems to be today much like where 
"software quality" processes were way back when we were just discovering 
things like unit testing. So we still fall back to subjective human 
judgement in most cases: has the code been reviewed for security? Did 
the reviewers find it comprehensible? In good taste? How many security 
holes did they find? Are the developers willing to stand behind? Even 
beyond its original design requirements?

> I bet these same people can't grok template heavy code
> like MPL internals too.

:-)

> Yet, MPL is core to many libraries in Boost. Are
> you saying that people shouldn't use any library that depends on MPL too?

I'm not saying anyone "shouldn't use" anything.

I am saying that handling malicious crafted input tends to be outside 
the initial design requirements of most code (in cases where it's not, 
the developers will likely mention it somewhere). So taking 
general-purpose code and using it in security-critical contexts does 
require care.

It's a bit like using commercial off-the shelf parts in your space 
satellite. Probably that transistor will work just fine, but you have to 
do some extra work to requalify it for your application.

But with respect to something like MPL, yes, it's a consideration.

Generative templates are an interesting case because they don't 
interpret data at runtime. But understanding exactly what code they do 
generate is still important though. The attacker may be reading your 
code bottom-up with a disassembler, so the potential exists for him to 
understand the generated code better than you do.

> Or are you singling out Spirit? If so, why?

Wasn't intending to, but maybe a little bit. In this case:

1. I tried and could not make a Spirit parser for my input format after 
some amount of time.

2. I'm sure I could have gotten something working eventually, but I 
would not have felt comfortable with my understanding of all its failure 
modes.

3. JSON is an intentionally simple thing to parse. A competent C 
programmer could write a parser by hand in a short time. This exact 
thing is probably available under a free license.

4. JSON is used specifically for internet-facing apps due to its 
integration with Javascript. I.e., it's right there on the front lines 
of the attack surface.

> I've almost had enough of this FUD mongering.

I'm sorry that you feel that way. It was not my intention to cast FUD.

C++ and Boost are well suited for secure coding because of the support 
for type safety, automatic cleanup, and overall deterministic execution. 
But probably nothing will replace the need to understand what's going on 
under the hood as well as the attacker.

- Marsh