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

Kostya Serebryany via cfe-dev cfe-dev at lists.llvm.org
Mon Nov 9 12:49:05 PST 2015 

On Mon, Nov 9, 2015 at 12:14 PM, Riyad Parvez <riyad.parvez at uwaterloo.ca>
wrote:

> On Mon, Nov 9, 2015 at 11:52 AM, Kostya Serebryany <kcc at google.com> wrote:
>
>> Intuitively, one may indeed think that some signed integer overflows are
>> more dangerous than others.
>> But scientifically, they are all bugs.
>>
>
> I agree, they are all bugs unless someone using overflows for optimizing
> code. But from security perspective not all bugs are security
> vulnerabilities. Right now I'm interested into security vulnerabilities
> only.
>
> 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?
>>
>>
> In academic security research, what I've seen so far is that dynamic taint
> analysis is done with conjunction with overflow checks. If the operands in
> overflows are tainted by user input and that arithmetic overflow leads to
> crashes etc. i.e., an user has the ability to crash the program by simply
> providing different kinds of input, then it's more interesting. But again,
> things are not that simple. Overflows can change the intended semantics of
> the program which in turn can lead to security vulnerabilities.
>
> Coming back to the original question, is there any API or option to enable
> overflow checks for certain translation units?
>

You can do this by simply adding -fsanitize=* to the units you want to
check and not adding it to others.
You can also use -fsanitize-blacklist=blacklist.txt, see
http://clang.llvm.org/docs/SanitizerSpecialCaseList.html



>
> --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/06f353ca/attachment.html>

More information about the cfe-dev mailing list