Writing and generating secure code in ASN1C is something that we consider regularly, both internally and through the occasional chat with our customers. In response to recent feedback, we now generate C/C++ code with stricter memory copying checks (this functionality appears in version 6.7.2). We are testing bounds checking in our print functions for octet strings, too; we expect these changes to appear in version 6.7.3.
We're motivated by a common observation about memcpy and its cousins: they don't check the size of the destination buffer, and so calls to these functions may be used as a vector for buffer overflow or overread attacks. (An older, but accessible, article from Linux Journal is a good resource for those new to the subject; information on buffer overflows is readily available elsewhere online, too.)
While ASN1C does not generate code that will overflow or overread memory internally, it's conceivable that someone might craft malicious messages or otherwise compromise the integrity of an application that uses ASN1C-generated code. In recent versions of ASN1C we have replaced the calls to OSCRTLMEMCPY with calls to OSCRTLSAFEMEMCPY, which performs a bounds check on the destination buffer size. Our common runtime library also includes safer implementations of common string functions (like strncpy and strncat) that guarantee that C-style strings are null terminated, which helps to prevent common buffer attacks on those functions. We have also added in bounds checks on statically sized arrays in our print functions to help prevent buffer overreads; we're testing this functionality now.
Our generated code will always use these functions to ensure that bounds on memory and strings are appropriately checked, but we would hasten to remind readers that such checks are ineffective in the presence of programmer error (the recent Heartbleed security flaw in OpenSSL being a prominent example).
As always, if you have questions or comments, feel free to contact us; we'll be glad to hear from you.