Question: Can this work as USB over IP solution to connect iPhone #2
Comments
meme
pushed a commit
to meme/usbfluxd
that referenced
this issue
Jun 25, 2021
In `process_recv`, there is no handling for an error on `client_command`, which may interally free the `client` (by calling `client_close`). This results in a UAF: client_command(client, hdr); client->ib_size = 0; Log: [11:26:04.715][3] NOTE: remote 10.11.1.1:5000 is no longer available. [11:37:12.068][4] New client on fd 5 (pid 9809) [11:37:12.069][1] Client 5 command received in the wrong state [11:37:12.069][4] Disconnecting client 0x6080000007a0 fd 5 ASan: ==5624==ERROR: AddressSanitizer: heap-use-after-free on address 0x6080000007c0 at pc 0x5643f34e1b79 bp 0x7ffe58b9f170 sp 0x7ffe58b9f160 WRITE of size 4 at 0x6080000007c0 thread T0 #0 0x5643f34e1b78 in process_recv /usbfluxd/usbfluxd/client.c:981 corellium#1 0x5643f34e26a0 in client_process /usbfluxd/usbfluxd/client.c:1043 corellium#2 0x5643f34f03cb in main_loop /usbfluxd/usbfluxd/main.c:156 corellium#3 0x5643f34f186c in main /usbfluxd/usbfluxd/main.c:477 corellium#4 0x7f3152cffb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) corellium#5 0x5643f34d995d in _start (/usr/local/sbin/usbfluxd+0xa95d) 0x6080000007c0 is located 32 bytes inside of 96-byte region [0x6080000007a0,0x608000000800) freed by thread T0 here: #0 0x7f31530f6f19 in __interceptor_free /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:127 corellium#1 0x5643f34dac29 in client_close /usbfluxd/usbfluxd/client.c:254 corellium#2 0x5643f34ddeac in client_command /usbfluxd/usbfluxd/client.c:642 corellium#3 0x5643f34e1b45 in process_recv /usbfluxd/usbfluxd/client.c:980 corellium#4 0x5643f34e26a0 in client_process /usbfluxd/usbfluxd/client.c:1043 corellium#5 0x5643f34f03cb in main_loop /usbfluxd/usbfluxd/main.c:156 corellium#6 0x5643f34f186c in main /usbfluxd/usbfluxd/main.c:477 corellium#7 0x7f3152cffb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) previously allocated by thread T0 here: #0 0x7f31530f7279 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145 corellium#1 0x5643f34da34c in client_accept /usbfluxd/usbfluxd/client.c:199 corellium#2 0x5643f34f023e in main_loop /usbfluxd/usbfluxd/main.c:149 corellium#3 0x5643f34f186c in main /usbfluxd/usbfluxd/main.c:477 corellium#4 0x7f3152cffb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) SUMMARY: AddressSanitizer: heap-use-after-free /usbfluxd/usbfluxd/client.c:981 in process_recv Shadow bytes around the buggy address: 0x0c107fff80a0: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd 0x0c107fff80b0: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd 0x0c107fff80c0: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd 0x0c107fff80d0: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd 0x0c107fff80e0: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd =>0x0c107fff80f0: fa fa fa fa fd fd fd fd[fd]fd fd fd fd fd fd fd 0x0c107fff8100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c107fff8110: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c107fff8120: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c107fff8130: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c107fff8140: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: 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 cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb Shadow gap: cc ==5624==ABORTING
meme
pushed a commit
to meme/usbfluxd
that referenced
this issue
Jun 30, 2021
Under certain conditions, such as a network failure,
`socket_connect_timeout` will race to call *gethostbyname*(3) and end up
dereferencing NULL:
if ((hp = gethostbyname(addr)) == NULL) {
usbfluxd_log(LL_ERROR, "%s: unknown host '%s'", __func__, addr);
return -1;
}
// Passes, data is fine
if (!hp->h_addr) {
usbfluxd_log(LL_ERROR, "%s: gethostbyname returned NULL address!", __func__);
return -1;
}
// ...
// Another thread calls gethostbyname, hp is now pointing to another instance (data race)
// ...
// BOOM
saddr.sin_addr.s_addr = *(uint32_t *) hp->h_addr;
The man page makes this apparent:
The functions gethostbyname() and gethostbyaddr() may return pointers to static data, which may be overwritten by
later calls. Copying the struct hostent does not suffice, since it contains pointers; a deep copy is required.
ASan:
==28115==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x561c82fb46e6 bp 0x7f8520a20ca0 sp 0x7f8520a20ae0 T357)
==28115==The signal is caused by a READ memory access.
==28115==Hint: address points to the zero page.
#0 0x561c82fb46e6 in socket_connect_timeout /usbfluxd/usbfluxd/socket.c:153
corellium#1 0x561c82fba741 in check_remote_func /usbfluxd/usbfluxd/usbmux_remote.c:949
corellium#2 0x7f85da806258 in start_thread (/usr/lib/libpthread.so.0+0x9258)
corellium#3 0x7f85da5c75e2 in __GI___clone (/usr/lib/libc.so.6+0xfe5e2)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /usbfluxd/usbfluxd/socket.c:153 in socket_connect_timeout
Thread T357 created by T0 here:
#0 0x7f85da889fa7 in __interceptor_pthread_create /build/gcc/src/gcc/libsanitizer/asan/asan_interceptors.cpp:216
corellium#1 0x561c82fbaa4b in usbmux_remote_get_fds /usbfluxd/usbfluxd/usbmux_remote.c:967
corellium#2 0x561c82fc0ef2 in main_loop /usbfluxd/usbfluxd/main.c:129
corellium#3 0x561c82fc2870 in main /usbfluxd/usbfluxd/main.c:477
corellium#4 0x7f85da4f0b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
cooljeanius
referenced
this issue
in cooljeanius/usbfluxd
Oct 13, 2023
In `process_recv`, there is no handling for an error on `client_command`, which may interally free the `client` (by calling `client_close`). This results in a UAF: client_command(client, hdr); client->ib_size = 0; Log: [11:26:04.715][3] NOTE: remote 10.11.1.1:5000 is no longer available. [11:37:12.068][4] New client on fd 5 (pid 9809) [11:37:12.069][1] Client 5 command received in the wrong state [11:37:12.069][4] Disconnecting client 0x6080000007a0 fd 5 ASan: ==5624==ERROR: AddressSanitizer: heap-use-after-free on address 0x6080000007c0 at pc 0x5643f34e1b79 bp 0x7ffe58b9f170 sp 0x7ffe58b9f160 WRITE of size 4 at 0x6080000007c0 thread T0 #0 0x5643f34e1b78 in process_recv /usbfluxd/usbfluxd/client.c:981 #1 0x5643f34e26a0 in client_process /usbfluxd/usbfluxd/client.c:1043 #2 0x5643f34f03cb in main_loop /usbfluxd/usbfluxd/main.c:156 #3 0x5643f34f186c in main /usbfluxd/usbfluxd/main.c:477 #4 0x7f3152cffb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) #5 0x5643f34d995d in _start (/usr/local/sbin/usbfluxd+0xa95d) 0x6080000007c0 is located 32 bytes inside of 96-byte region [0x6080000007a0,0x608000000800) freed by thread T0 here: #0 0x7f31530f6f19 in __interceptor_free /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:127 #1 0x5643f34dac29 in client_close /usbfluxd/usbfluxd/client.c:254 #2 0x5643f34ddeac in client_command /usbfluxd/usbfluxd/client.c:642 #3 0x5643f34e1b45 in process_recv /usbfluxd/usbfluxd/client.c:980 #4 0x5643f34e26a0 in client_process /usbfluxd/usbfluxd/client.c:1043 #5 0x5643f34f03cb in main_loop /usbfluxd/usbfluxd/main.c:156 corellium#6 0x5643f34f186c in main /usbfluxd/usbfluxd/main.c:477 corellium#7 0x7f3152cffb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) previously allocated by thread T0 here: #0 0x7f31530f7279 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145 #1 0x5643f34da34c in client_accept /usbfluxd/usbfluxd/client.c:199 #2 0x5643f34f023e in main_loop /usbfluxd/usbfluxd/main.c:149 #3 0x5643f34f186c in main /usbfluxd/usbfluxd/main.c:477 #4 0x7f3152cffb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) SUMMARY: AddressSanitizer: heap-use-after-free /usbfluxd/usbfluxd/client.c:981 in process_recv Shadow bytes around the buggy address: 0x0c107fff80a0: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd 0x0c107fff80b0: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd 0x0c107fff80c0: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd 0x0c107fff80d0: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd 0x0c107fff80e0: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd =>0x0c107fff80f0: fa fa fa fa fd fd fd fd[fd]fd fd fd fd fd fd fd 0x0c107fff8100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c107fff8110: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c107fff8120: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c107fff8130: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c107fff8140: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: 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 cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb Shadow gap: cc ==5624==ABORTING
cooljeanius
referenced
this issue
in cooljeanius/usbfluxd
Oct 13, 2023
Under certain conditions, such as a network failure,
`socket_connect_timeout` will race to call *gethostbyname*(3) and end up
dereferencing NULL:
if ((hp = gethostbyname(addr)) == NULL) {
usbfluxd_log(LL_ERROR, "%s: unknown host '%s'", __func__, addr);
return -1;
}
// Passes, data is fine
if (!hp->h_addr) {
usbfluxd_log(LL_ERROR, "%s: gethostbyname returned NULL address!", __func__);
return -1;
}
// ...
// Another thread calls gethostbyname, hp is now pointing to another instance (data race)
// ...
// BOOM
saddr.sin_addr.s_addr = *(uint32_t *) hp->h_addr;
The man page makes this apparent:
The functions gethostbyname() and gethostbyaddr() may return pointers to static data, which may be overwritten by
later calls. Copying the struct hostent does not suffice, since it contains pointers; a deep copy is required.
ASan:
==28115==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x561c82fb46e6 bp 0x7f8520a20ca0 sp 0x7f8520a20ae0 T357)
==28115==The signal is caused by a READ memory access.
==28115==Hint: address points to the zero page.
#0 0x561c82fb46e6 in socket_connect_timeout /usbfluxd/usbfluxd/socket.c:153
#1 0x561c82fba741 in check_remote_func /usbfluxd/usbfluxd/usbmux_remote.c:949
#2 0x7f85da806258 in start_thread (/usr/lib/libpthread.so.0+0x9258)
#3 0x7f85da5c75e2 in __GI___clone (/usr/lib/libc.so.6+0xfe5e2)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /usbfluxd/usbfluxd/socket.c:153 in socket_connect_timeout
Thread T357 created by T0 here:
#0 0x7f85da889fa7 in __interceptor_pthread_create /build/gcc/src/gcc/libsanitizer/asan/asan_interceptors.cpp:216
#1 0x561c82fbaa4b in usbmux_remote_get_fds /usbfluxd/usbfluxd/usbmux_remote.c:967
#2 0x561c82fc0ef2 in main_loop /usbfluxd/usbfluxd/main.c:129
#3 0x561c82fc2870 in main /usbfluxd/usbfluxd/main.c:477
#4 0x7f85da4f0b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Can we use this tool to somehow connect the device over IP and act as a USB? If yes, what would be the steps to do it.
The text was updated successfully, but these errors were encountered: