On Sat, Dec 14, 2019 at 12:36 PM Martin Sebor <mse...@gmail.com> wrote: > > On 12/9/19 8:15 PM, li zi wrote: > > Hi All, > > We are using gcc in our projects and we found some of the C standard > > functions (like memcpy, strcpy) used in gcc may induce security > > vulnerablities like buffer overflow. Currently we have not found any > > instances which causes such issues. > > But we feel better to change these calls to Cll Annex K Bounds-checking > > interfaces like memcpy_s, strcpy_s etc. By defining a secure calls method > > (list of func pointers) and allowing application to register the method. I > > understand that this affects performance because of return value check > > added for xxxx_s calls, but this will relieve overflow kind of issues from > > code. And also currently using bounds-checking interfaces is a general > > industry practice. > > Please share your opinion on it, and if any discussion happened in > > community to do some changes in future. > > GCC's Object Size Checking is a non-intrusive solution to > the problem. It avoids the considerable risk of introducing > bugs while replacing existing calls with those to the _s > functions. The implementation is restricted to constant > sizes so its effectiveness is a limited, but we have been > discussing enhancing it to non-constant sizes as well, as > Clang already does. With that, it should provide protection > with an effectiveness comparable to the _s functions but > without any of the downsides. (Note that GCC's buffer > overflow warnings are not subject to the same limitation.) > > Besides Object Size Checking, I would suggest making use of > the new attribute access. It lets GCC detect (though not > prevent) out-of-bounds accesses by calls to user-defined > functions decorated with the attribute.
The safer functions have three or four security goals. The workarounds don't meet the goals. The safer functions require the destination size to ensure a buffer overflow does not occur. The safe functions always terminate the destination buffer. The safe functions provide a consistent return value. There is only one success code. It is easy to teach a novice user how to use the safe functions correctly because there is only one rule for return values. The safer functions should provide portability across platforms. Write once, run everywhere. Consider, if object size checking were a complete replacement, then glibc should not make so many appearances on BugTraq for out-of-bound reads and writes. Confer, https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=glibc. The glibc folks have done more harm then good with their politics. Jeff
