radareorg radare2 version 5.5.2 is vulnerable to NULL Pointer Dereference via libr/bin/p/bin_symbols.c binary symbol parser.
cpe:2.3:a:radare:radare2:*:*:*:*:*:*:*:*
28076B4E-2508-49E1-8807-9507B43F8A1E
5.5.4
OR
# NULL pointer dereference in ``symbols()``

I have discovered a NULL / Invalid pointer dereference
bug, that gets triggered while parsing the symbols of a binary.

## Environment
```
shad3@ubuntu:~/Desktop/$ uname -ms
Linux x86_64

shad3@ubuntu:~/Desktop/$ r2 -v
radare2 5.5.2 27243 @ linux-x86-64 git.5.5.0
commit: 79effabdf5db431e40ea2aafc7f322ca32edb876 build: 2021-12-07__12:18:24

shad3@ubuntu:~/Desktop/$ date
Tue Dec  7 14:07:20 PST 2021
```
## ASAN
Stack Trace from an ASAN build while triggering the bug

```
ASAN:DEADLYSIGNAL
=================================================================
==128487==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fbb0d3f2db3 bp 0x7ffd0bd70d50 sp 0x7ffd0bd70cf0 T0)
==128487==The signal is caused by a READ memory access.
==128487==Hint: address points to the zero page.
    #0 0x7fbb0d3f2db2 in symbols /home/shad3/Desktop/radare2/libr/..//libr/bin/p/bin_symbols.c:372
    #1 0x7fbb0d2bc308 in r_bin_object_set_items /home/shad3/Desktop/radare2/libr/bin/bobj.c:325
    #2 0x7fbb0d2bb9c0 in r_bin_object_new /home/shad3/Desktop/radare2/libr/bin/bobj.c:168
    #3 0x7fbb0d2b9231 in r_bin_file_new_from_buffer /home/shad3/Desktop/radare2/libr/bin/bfile.c:560
    #4 0x7fbb0d2a9558 in r_bin_open_buf /home/shad3/Desktop/radare2/libr/bin/bin.c:286
    #5 0x7fbb0d2a9850 in r_bin_open_io /home/shad3/Desktop/radare2/libr/bin/bin.c:346
    #6 0x7fbb0dc5f0fc in r_core_file_do_load_for_io_plugin /home/shad3/Desktop/radare2/libr/core/cfile.c:434
    #7 0x7fbb0dc5faa8 in r_core_bin_load /home/shad3/Desktop/radare2/libr/core/cfile.c:635
    #8 0x7fbb1187f0b8 in r_main_radare2 /home/shad3/Desktop/radare2/libr/main/radare2.c:1176
    #9 0x561b2af7db4e in main /home/shad3/Desktop/radare2/binr/radare2/radare2.c:96
    #10 0x7fbb1076dbf6 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21bf6)
    #11 0x561b2af7d579 in _start (/home/shad3/Desktop/validcrashes/radare2-asan/binr/radare2/radare2+0x1579)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/shad3/Desktop/radare2/libr/..//libr/bin/p/bin_symbols.c:372 in symbols
==128487==ABORTING

````



## Explanation of the vulnerability


The vulnerability lies in the ``symbols`` function that
is responsible for parsing the symbols of the binary file.

The function can be found out at:
```
/radare2/libr/bin/bin_symbols.c
```

Please consider the following code 
bellow  bellow which has been simplified for readability:
```c
static RList *symbols(RBinFile *bf) {
	RCoreSymCacheElement *element = bf->o->bin_obj;
	...
	// Parse symbols to a hash table
	for (i = 0; i < element->hdr->n_symbols; i++) {
		RCoreSymCacheElementSymbol *sym = &element->symbols[i]; // 1
		ht_uu_find (hash, sym->paddr, &found);					// 2
		if (found) {
			continue;
		}
		RBinSymbol *s = bin_symbol_from_symbol (element, sym);
		if (s) {
			r_list_append (res, s);
		}
	}
	ht_uu_free (hash);
	return res;
}
```

The ``element->symbols`` array, is an array of symbols for an object of the
file that is being loaded for analysis. In case were the pointer ``element->symbols[0]`` 
is empty, which is possible, since it is directly controlled through,the binary
file (``bf->o->bin_obj``) at point 1 the ``sym`` variable will be set to ``0``. Thus,
in point 2 the programm with crash with a NULL pointer dereference while 
trying to dereference the ``paddr`` struct member of the ``RCoreSymCacheElementSymbol``
structure at ``sym->paddr``. 
Please note that the ``bf`` reaches this function unsanitized (since its the structure describing
a binary file) . If we trace up the functions on the stack we can see that it doesnt
get sanitized anywhere above.

## Proposed fixes

Add a check right after the retrieve of the value (Point 1) to sanitize invalid
values. 

## Notes

- Please check the attached binary that crashes
  the radare2 binary and reproduces the vulnerability
  by running the following command e.g. in an ASAN build
  ``r2 -qq -AA crash``

- I would highly appreciate if that bug qualifies for a
  CVE for you to request it for me.
  	
[crash.zip](https://github.com/radareorg/radare2/files/7672086/crash.zip)


NULL pointer dereference in ``symbols()``
This is a GitHub Issue
repo:radare2
owner:radareorg
Title : NULL pointer dereference in ``symbols()``
Issue date:

--- start body ---
# NULL pointer dereference in ``symbols()``

I have discovered a NULL / Invalid pointer dereference
bug, that gets triggered while parsing the symbols of a binary.

## Environment
```
shad3@ubuntu:~/Desktop/$ uname -ms
Linux x86_64

shad3@ubuntu:~/Desktop/$ r2 -v
radare2 5.5.2 27243 @ linux-x86-64 git.5.5.0
commit: 79effabdf5db431e40ea2aafc7f322ca32edb876 build: 2021-12-07__12:18:24

shad3@ubuntu:~/Desktop/$ date
Tue Dec  7 14:07:20 PST 2021
```
## ASAN
Stack Trace from an ASAN build while triggering the bug

```
ASAN:DEADLYSIGNAL
=================================================================
==128487==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fbb0d3f2db3 bp 0x7ffd0bd70d50 sp 0x7ffd0bd70cf0 T0)
==128487==The signal is caused by a READ memory access.
==128487==Hint: address points to the zero page.
    #0 0x7fbb0d3f2db2 in symbols /home/shad3/Desktop/radare2/libr/..//libr/bin/p/bin_symbols.c:372
    #1 0x7fbb0d2bc308 in r_bin_object_set_items /home/shad3/Desktop/radare2/libr/bin/bobj.c:325
    #2 0x7fbb0d2bb9c0 in r_bin_object_new /home/shad3/Desktop/radare2/libr/bin/bobj.c:168
    #3 0x7fbb0d2b9231 in r_bin_file_new_from_buffer /home/shad3/Desktop/radare2/libr/bin/bfile.c:560
    #4 0x7fbb0d2a9558 in r_bin_open_buf /home/shad3/Desktop/radare2/libr/bin/bin.c:286
    #5 0x7fbb0d2a9850 in r_bin_open_io /home/shad3/Desktop/radare2/libr/bin/bin.c:346
    #6 0x7fbb0dc5f0fc in r_core_file_do_load_for_io_plugin /home/shad3/Desktop/radare2/libr/core/cfile.c:434
    #7 0x7fbb0dc5faa8 in r_core_bin_load /home/shad3/Desktop/radare2/libr/core/cfile.c:635
    #8 0x7fbb1187f0b8 in r_main_radare2 /home/shad3/Desktop/radare2/libr/main/radare2.c:1176
    #9 0x561b2af7db4e in main /home/shad3/Desktop/radare2/binr/radare2/radare2.c:96
    #10 0x7fbb1076dbf6 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21bf6)
    #11 0x561b2af7d579 in _start (/home/shad3/Desktop/validcrashes/radare2-asan/binr/radare2/radare2+0x1579)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/shad3/Desktop/radare2/libr/..//libr/bin/p/bin_symbols.c:372 in symbols
==128487==ABORTING

````



## Explanation of the vulnerability


The vulnerability lies in the ``symbols`` function that
is responsible for parsing the symbols of the binary file.

The function can be found out at:
```
/radare2/libr/bin/bin_symbols.c
```

Please consider the following code 
bellow  bellow which has been simplified for readability:
```c
static RList *symbols(RBinFile *bf) {
	RCoreSymCacheElement *element = bf->o->bin_obj;
	...
	// Parse symbols to a hash table
	for (i = 0; i < element->hdr->n_symbols; i++) {
		RCoreSymCacheElementSymbol *sym = &element->symbols[i]; // 1
		ht_uu_find (hash, sym->paddr, &found);					// 2
		if (found) {
			continue;
		}
		RBinSymbol *s = bin_symbol_from_symbol (element, sym);
		if (s) {
			r_list_append (res, s);
		}
	}
	ht_uu_free (hash);
	return res;
}
```

The ``element->symbols`` array, is an array of symbols for an object of the
file that is being loaded for analysis. In case were the pointer ``element->symbols[0]`` 
is empty, which is possible, since it is directly controlled through,the binary
file (``bf->o->bin_obj``) at point 1 the ``sym`` variable will be set to ``0``. Thus,
in point 2 the programm with crash with a NULL pointer dereference while 
trying to dereference the ``paddr`` struct member of the ``RCoreSymCacheElementSymbol``
structure at ``sym->paddr``. 
Please note that the ``bf`` reaches this function unsanitized (since its the structure describing
a binary file) . If we trace up the functions on the stack we can see that it doesnt
get sanitized anywhere above.

## Proposed fixes

Add a check right after the retrieve of the value (Point 1) to sanitize invalid
values. 

## Notes

- Please check the attached binary that crashes
  the radare2 binary and reproduces the vulnerability
  by running the following command e.g. in an ASAN build
  ``r2 -qq -AA crash``

- I would highly appreciate if that bug qualifies for a
  CVE for you to request it for me.
  	
[crash.zip](https://github.com/radareorg/radare2/files/7672086/crash.zip)


--- end body ---

comments :
--- start comments ---

--- end comments ---