Environment ubuntu
Run with clion
#include<stdio.h>
# include <stdlib.h>
int main(void){
char*old_string, *new_string;
old_string = malloc(sizeof(char)));
inti;
for(i=0;i<10000;i++){
old_string[i] = i%10;
// new_string = realoc(old_string, i+2);
// old_string = new_string;
printf("Index: %d Content: %d\n", i, old_string[i]);
}
free(old_string);
return 0;
}
Results
Index: 1 Contents: 1
Index: 2 Contents: 2
Index: 3 Contents: 3
Index: 4 Contents: 4
Index: 5 Contents: 5
Index: 6 Contents: 6
Index: 7 Contents: 7
・・・
Index: 9999 Contents: 9
At first, I thought I would try to expand the array area with malloc() and realoc(), leaving a comment out.Actually, it worked.
However, the results will be the same even if you comment out, that is, you still have size 1 space.
I think it's too rough, but is it a C language specification?
I think I'll run into something if I turn it around 1G.
c
Try to compile and run the publishing source code as heap_overflow.c and the -fsanitize=address option in gcc.
gcc(1)
-fsanitize=address
Enable AddressSanitizer, a fast memory error detector.Memory access instructions are instrumented to detect out-of-bounds and use-after-free bugs.The option enables -fsanitizes-address-use-after-scope.See&core>The remote.TIONS environment variable.When set to "help=1", the available options are show at startup of the instrumented program.See <https://github.com/google/sanitizers/wiki/AddressSanitizerFlags#run-time-flag> for all list of supported options.The option cannot be combined with
$gcc-std=gnu2x-fsanitize=address-Wall-geap_overflow.c-o heap_overflow&./heap_overflow
Index: 0 Contents: 0
=================================================================
==118931 == ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000011 at pc0x563844e782bc bp0x7ffdd177b0sp0x7ffdd177b0a0
WRITE of size 1 at 0x602000000011 thread T0
# 00x563844e782bb in main heap_overflow.c:12
# 10x7ff235322564 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x28564)
#20x563844e7816d in_start(heap_overflow+0x116d)
0x602000000011 is located 0 bytes to the right of 1-byte region [0x602000000010, 0x602000000011]
allocated by thread T0here:
# 00x7ff23559ac47 in__interceptor_malloc../../../ src/libsanitizer/asan/asan_malloc_linux.cpp: 145
# 10x563844e7823e in main heap_overflow.c: 7
# 20x7ff235322564 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x28564)
SUMMARY:AddressSanitizer:heap-buffer-overflow heap_overflow.c:12 in main
Shadow bytes around the buggy address:
0x0c047ffff7fb0:0000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0x0c047ffff7fc0:00000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0x0c047ffff7fd0:00000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0x0c047ffff7fe0:000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0x0c047ffff7ff0:000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
=>0x0c047ff8000: fa fa[01] fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047ffff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047ffff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047ffff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047ffff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047ffff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte presents 8 application bytes):
Addressable:00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Fried heap region: fd
Stack left redzone: f1
Stack midredzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user —f7
Container overflow: fc
Array cookies:ac
Intraobject redzone: bb
ASan internal:fe
Left alloca redzone: ca
Right alloca redzone:cb
Shadow gap:cc
==118931 == ABORTING
I think it's too rough, but
Is it specifications for C language?
Yes, it is the programmer's responsibility to control the border.
In addition, by default, the C language does not have a boundary check function.
As metropolis replied, it is possible to include additional checking functions.
Another way to do this is to use the code analysis function with Visual C++ on hand to alert you to the following so you can identify the problem before you run it.Of course, you can also use the -fsanitize=address introduced by metropolis, so you can detect it at runtime.
warning C6200: Index '9999' is out of valid index range '0' to '0' for non-stack buffer 'old_string'.
I think I'll run into something if I turn it around 1G.
For malloc, the specification is to retrieve the memory block with brk and return the appropriate separation.As a result, you will be able to access the size you reserved in brk.Access to a larger size should stop the process due to an access violation.
The following malloc realloc/realloc/free may still be corrupted.
© 2024 OneMinuteCode. All rights reserved.