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

[Kostya Serebryany]

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-
>> secure-studygroup
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/cgi-bin/mailman/private/c-safe-secure-studygroup/attachments/20170104/3d0a9b64/attachment.html>