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.
>> 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
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
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
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
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk