[cfe-dev] Why does integer overflow sanitizer exits the program with zero exit code

Mon Nov 9 08:52:58 PST 2015

Intuitively, one may indeed think that some signed integer overflows are
more dangerous than others.
But scientifically, they are all bugs.
My favorite real-life example:
http://stackoverflow.com/questions/7682477/why-does-integer-overflow-on-x86-with-gcc-cause-an-infinite-loop

It is totally unclear if we can come up with a reliable heuristic that will
distinguish between less harmful and more harmful int overflows.
E.g. what if the computation of an array index happens in a separate
function?

--kcc

On Mon, Nov 9, 2015 at 7:07 AM, Riyad Parvez via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Sun, Nov 8, 2015 at 11:07 PM, Alexander Potapenko <glider at google.com>
> wrote:
>
>> Can you please give an example of a benign integer overflow?
>>
> Here 'benign' from security perspective is usually defined as arithmetic
> overflows that don't trigger low-level security vulnerabilities e.g. buffer
> overflows. Many arithmetic overflows don't trigger buffer overflows
> eventually. Copy pasted from [1]:
>
> For example, if x is an int type variable, the statement if(x >= -2 && x<=
> 0x7ffffffd) will be translated into such a piece of assembly code by
> GCC-4.2.0 compiler: mov eax, x; // eax = x add eax, 2; // eax = eax+2 js
> target In this case, a large x such as 0x7fffffff causes an overflow in
> above add instruction, but it is harmless as GCC actually uses this
> overflow to reduce a comparison instruction.
>
> Note that by disabling the checks for non-pointer arithmetic you can
>> easily throw the baby out with the bathwater. The compiler can easily take
>> advantage of signed integer overflow being undefined irrespective of it
>> being called "benign" or not.
>>
> There's a good paper on this, you can have a look if you are interested
> [2].
>
> [1] https://www.utdallas.edu/~zxl111930/file/IntScope_NDSS09.pdf
> [2] https://people.csail.mit.edu/nickolai/papers/wang-stack.pdf
>
>> sent from phone
>> On Nov 7, 2015 1:19 PM, "Riyad Parvez via cfe-dev" <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>> Is it possible to enable integer overflow sanitizer for certain cases as
>>> in many cases integer overflows are benign? I'm interested in mainly
>>> integer overflow during pointer arithmetic or memory allocations. Or
>>> enabling sanitizer for certain course files?
>>>
>>> Thanks,
>>> Riyad
>>>
>>> On Tue, Nov 3, 2015 at 7:43 PM, Alexey Samsonov <vonosmas at gmail.com>
>>> wrote:
>>>
>>>>
>>>> On Tue, Nov 3, 2015 at 3:26 PM, Riyad Parvez via cfe-dev <
>>>> cfe-dev at lists.llvm.org> wrote:
>>>>
>>>>> Thanks a lot.
>>>>>
>>>>> I had decided to detect overflow by SIGABRT. The issue SIGABRT is also
>>>>> thorwn by when assertion violation occurs. So SIGABRT is not the perfect
>>>>> indicator of overflow.
>>>>>
>>>>> I see all the arithmetic operations are performed by
>>>>> "__ubsan_handle_*_overflow" built-in functions. If I catch SIGABRT,
>>>>> "__ubsan_handle_*_overflow" functions in the stack, can I safely assume the
>>>>> program is terminated in overflow?
>>>>>
>>>>
>>>> Probably yes: if one of these function was called by the program, it
>>>> will certainly report an overflow. In theory, we don't guarantee that the
>>>> names of these functions will stay the same, or that we always report
>>>> overflows through them (i.e. it's an implementation detail), but in
>>>> practice it would unlikely change soon.
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> Riyad
>>>>>
>>>>> On Fri, Oct 23, 2015 at 3:01 PM, Kostya Serebryany <kcc at google.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Oct 23, 2015 at 11:35 AM, Riyad Parvez <
>>>>>> riyad.parvez at uwaterloo.ca> wrote:
>>>>>>
>>>>>>> Interesting! "UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1" works
>>>>>>> fine, but just "UBSAN_OPTIONS=abort_on_error=1" doesn't work. Is it by
>>>>>>> design?
>>>>>>>
>>>>>>
>>>>>>
>>>>>> sort of.
>>>>>> by default, ubsan simply does not exit, so it does not care about
>>>>>> abort_on_error.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Fri, Oct 23, 2015 at 2:30 PM, Kostya Serebryany <kcc at google.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Oct 23, 2015 at 11:27 AM, Riyad Parvez <
>>>>>>>> riyad.parvez at uwaterloo.ca> wrote:
>>>>>>>>
>>>>>>>>> Thanks! It works on the latest version of clang, but I was using
>>>>>>>>> clang 3.4 where it didn't work.
>>>>>>>>>
>>>>>>>>
>>>>>>>> 3.4 was loooong ago.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On a more related note, SIGABRT better indicator of bugs than
>>>>>>>>> non-zero exit status. So I've tried "ASAN_OPTIONS=abort_on_error=1" option
>>>>>>>>> which works for address sanitizer where program exists with SIGABRT. But
>>>>>>>>> "UBSAN_OPTIONS=abort_on_error=1" doesn't exit with SIGABRT. Is there any
>>>>>>>>> way to make overflow sanitizer exit with SIGABRT similar to address
>>>>>>>>> sanitizer?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Just checked:
>>>>>>>>
>>>>>>>> % clang -fsanitize=address,signed-integer-overflow int-overflow.c
>>>>>>>> && UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1 ./a.out ; echo EXIT
>>>>>>>> STATUS: $?
>>>>>>>> int-overflow.c:5:5: runtime error: signed integer overflow:
>>>>>>>> 1073741824 + 1073741824 cannot be represented in type 'int'
>>>>>>>> SUMMARY: AddressSanitizer: undefined-behavior int-overflow.c:5:5 in
>>>>>>>> Aborted (core dumped)
>>>>>>>> EXIT STATUS: 134
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Oct 23, 2015 at 1:06 PM, Kostya Serebryany <kcc at google.com
>>>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Oct 23, 2015 at 7:08 AM, Riyad Parvez <
>>>>>>>>>> riyad.parvez at uwaterloo.ca> wrote:
>>>>>>>>>>
>>>>>>>>>>> Thanks for the reply.
>>>>>>>>>>>
>>>>>>>>>>> I am developing a fuzzer and interested to find overflows.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So am I :)
>>>>>>>>>> llvm.org/docs/LibFuzzer.html
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Is there any way to detect when errors are detected? To explain
>>>>>>>>>>> more, I have instrumented the binary to see which functions are called in
>>>>>>>>>>> run-time. What are the functions that are called when overflow is detected?
>>>>>>>>>>> When these functions are called I will know overflow is detected.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Oct 22, 2015 at 8:08 PM, Kostya Serebryany <
>>>>>>>>>>> kcc at google.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Oct 22, 2015 at 11:52 AM, Riyad Parvez via cfe-dev <
>>>>>>>>>>>> cfe-dev at lists.llvm.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>
>>>>>>>>>>>>> With "-fsanitize=integer" flag, when an overflow is detected
>>>>>>>>>>>>> the program is terminated with zero exit code.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> You can change this behavior by using env. var.
>>>>>>>>>>>> UBSAN_OPTIONS=halt_on_error=1
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> I've tried this; didn't work.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> What exactly do you run?
>>>>>>>>>>
>>>>>>>>>> Here is what works for me:
>>>>>>>>>>
>>>>>>>>>> % cat int-overflow.c
>>>>>>>>>> #include <stdio.h>
>>>>>>>>>> int x;
>>>>>>>>>> int main(int argc, char **argv) {
>>>>>>>>>>   x += 1 << 30;
>>>>>>>>>>   x += 1 << 30;
>>>>>>>>>>   printf("%d\n", x);
>>>>>>>>>>   return 0;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> % clang -fsanitize=signed-integer-overflow int-overflow.c &&
>>>>>>>>>> ./a.out ; echo EXIT STATUS: $?
>>>>>>>>>> int-overflow.c:5:5: runtime error: signed integer overflow:
>>>>>>>>>> 1073741824 + 1073741824 cannot be represented in type 'int'
>>>>>>>>>> -2147483648
>>>>>>>>>> EXIT STATUS: 0
>>>>>>>>>> % clang -fsanitize=signed-integer-overflow int-overflow.c &&
>>>>>>>>>> UBSAN_OPTIONS=halt_on_error=1 ./a.out ; echo EXIT STATUS: $?
>>>>>>>>>> int-overflow.c:5:5: runtime error: signed integer overflow:
>>>>>>>>>> 1073741824 + 1073741824 cannot be represented in type 'int'
>>>>>>>>>> EXIT STATUS: 1
>>>>>>>>>> %
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> (Not sure if this is properly documented anywhere. Alexey? )
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> But with "-fsanitize=address" flag, the program terminates
>>>>>>>>>>>>> with non-zero exit code. I think the address sanitizer behavior of non-zero
>>>>>>>>>>>>> exit code is more intuitive since the program did exit in error. Is there
>>>>>>>>>>>>> any reason integer overflow sanitizer exits the program with zero exit code?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> One of the reasons, maybe:
>>>>>>>>>>>> Programs are more often ubsan-unclean than asan-unclean, and
>>>>>>>>>>>> halting on every ubsan message makes it harder to deploy the tool.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Riyad
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> cfe-dev mailing list
>>>>>>>>>>>>> cfe-dev at lists.llvm.org
>>>>>>>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> cfe-dev mailing list
>>>>> cfe-dev at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Alexey Samsonov
>>>> vonosmas at gmail.com
>>>>
>>>
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151109/0df90012/attachment.html>