Usage of C11 Annex K Bounds-checking interfaces on Glibc

Usage of C11 Annex K Bounds-checking interfaces on Glibc

[li zi]

Hi All, 

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.

Thanks. 
li

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

[Yann Droneaud]

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

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

[<Alexander G. Riccio>]

Hey, I mentioned it on libc-help once too:

https://sourceware.org/ml/libc-help/2018-01/msg00005.html

On Tue, Dec 10, 2019, 4:53 AM Yann Droneaud <ydroneaud@opteya.com> wrote:

> 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
>
>
>