Re: Usage of C11 Annex K Bounds-checking interfaces on Glibc

[Yann Droneaud <ydroneaud at opteya dot com>]

Hi,

Le mardi 10 décembre 2019 à 07:41 +0000, li zi a écrit :
> 
> We are using glibc in our projects and we found some of the C
> standard functions (like memcpy, strcpy) used in glibc 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 C11 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.

You might want to compile with -D_FORTIFY_SOURCE=2 to enable best
effort bound checking on the standard functions at compile and run
time.

You might want to compile with -fstack-protector-strong to enable stack
overflow checking on runtime.

One of GLIBC maintainer made a nice blog post about those and more
https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/

Then this is ASan, address sanitizer (and other sanitizers), see 
https://developers.redhat.com/blog/2014/12/02/address-and-thread-sanitizers-gcc/

So GNU has the tool to develop hardened programs.

C11 Annex K is optional, and seen by some people as a Microsoft Windows
only feature.

Anyway, have a look to the archives:

https://sourceware.org/ml/libc-alpha/2007-05/msg00027.html
https://sourceware.org/ml/libc-alpha/2012-10/msg00915.html
https://sourceware.org/ml/libc-alpha/2014-08/msg00133.html
https://sourceware.org/ml/libc-help/2019-01/msg00035.html

Regards.

-- 
Yann Droneaud
OPTEYA