[C-safe-secure-studygroup] coverage, fuzzing, symbolic/concolic execution, and more

Robert Seacord rcseacord at gmail.com
Thu Jan 5 01:37:51 UTC 2017


I think we care about different forms of analysis, but we want the standard
to be "minimally supported by static analysis" meaning that we don't want
to include requirements that would prevent static analyzers from
conforming.  Fuzzing seems like a mechanism for rules diagnosed through
dynamic analysis.  I'm not sure how a fuzzing tool would demonstrate
compliance with a set of secure coding rules.

rCs

On Wed, Jan 4, 2017 at 8:31 PM, Kostya Serebryany <kcc at google.com> wrote:

>
>
> On Wed, Jan 4, 2017 at 4:33 PM, Robert Seacord <rcseacord at gmail.com>
> wrote:
>
>> So here is what the first paragraph of the current document says:
>>
>> An essential element of secure coding in the C programming language is a
>>> set of well-documented and enforceable coding rules. The rules specified in
>>> this Technical Specification apply to analyzers, including static analysis
>>> tools and C language compiler vendors that wish to diagnose insecure code
>>> beyond the requirements of the language standard. All rules are meant to be
>>> enforceable by static analysis.
>>
>>
> hah. Indeed, I missed the "enforceable by static analysis" part.
> I assumed that since I (as a specialist in dynamic analysis) was invited
> to the group it cares about dynamic analysis at least a bit.
>
>
>> So the goal is to not produce rules that cannot be diagnosed by static
>> analysis.
>>
> With today's state of affairs, especially in C, you can not achieve
> reasonable safety with just static or just dynamic tools.
>
> Now, replace "fuzzing" with "symbolic execution" in my initial message.
> Since symbolic execution is a form of static analysis, it still fits into
> the group's goals.
>
> --kcc
>
>
>> Again, a good homework assignment for the next meeting is to at least
>> read the beginning of the document at least up through Section 5 (which is
>> relatively short).
>>
>> Code coverage is an interesting question, which may be most related to
>> the conformance clauses I was typing into the chat room during the meeting
>> today.  This is a very important (and difficult to get correct) section of
>> the standard, and any help getting this right would be greatly
>> appreciated.  To a certain extent, however, it is orthogonal to the main
>> purpose of the standard which is to enumerate safety and security rules for
>> C.
>>
>> Thanks,
>> rCs
>>
>>
>> On Wed, Jan 4, 2017 at 3:56 PM, Wheeler, David A via
>> C-safe-secure-studygroup <c-safe-secure-studygroup at lists.trustable.io>
>> wrote:
>>
>>> Dynamic analysis, including fuzzing and traditional testing, requires
>>> that you be able to execute the code.  There are many circumstances where
>>> you have the source code but cannot run it directly (e.g., because you need
>>> special hardware).  In addition, many tool suppliers do only static
>>> analysis, or only dynamic analysis – not both.
>>>
>>>
>>>
>>> I think it does **NOT** make sense to “bundle” these two different
>>> activities in a single spec.
>>>
>>>
>>>
>>> I recommend that dynamic issues, like fuzzing and testing, be handled *
>>> *separately** by a different spec or different group.
>>>
>>>
>>>
>>> --- David A. Wheeler
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> C-safe-secure-studygroup mailing list
>>> C-safe-secure-studygroup at lists.trustable.io
>>> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-safe-s
>>> ecure-studygroup
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/cgi-bin/mailman/private/c-safe-secure-studygroup/attachments/20170104/b9c58764/attachment-0001.html>


More information about the C-safe-secure-studygroup mailing list