[cfe-dev] Why does integer overflow sanitizer exits the program with zero exit code
Riyad Parvez via cfe-dev
cfe-dev at lists.llvm.org
Mon Nov 9 07:07:55 PST 2015
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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151109/76b55f1e/attachment.html>
More information about the cfe-dev
mailing list