Voici un article écrit par Hackaday qui contient une partie sur de nouveaux problèmes de sécurité chez QNAP
(Pour l'achat de mon NAS, j'avais fait e tour des marques et immédiatement éliminé QNAP pour cette raison de failles récurrentes....)
https://hackaday.com/2024/05/24/thi...evel-escape-injection-and-audits/#more-681163
QNAP has had its share of problems over the years. The fine folks at Watchtowr decided to pitch in and try to find a few more, and then do a responsible disclosure to try to fix them the right way. And they didn’t disappoint. The unofficial audit found fifteen issues, but this write-up focuses on CVE-2024-27130, an unauthenticated overflow leading to Remote Code Execution (RCE).
Given the history of vulnerabilities, this shouldn’t be a big surprise, but the source of QNAP OS is a mess. The underpinnings are a Linux system, but the web interface on top of that is a tangle of a custom web server written in C, CGI scripts also written in C, strange leftover code bits in languages like PHP, and at least one code snippet that looks suspiciously like a backdoor.
And that’s all before we get to the real vulnerability. The cgi-bin/filemanager/share.cgi endpoint segfaults when providing a valid “ssid” and then an overlong file name. Inside the vulnerable code, it’s a simple strcpy() call, that copies an arbitrary, user-provided string into a fixed-length buffer. Write past the end of it, and you overwrite local variables, and then the return address, too. And because of how returns work, you also get to set some registers, like r0, the traditional first argument register. So… what if you just set the return address to the system() function, and put a pointer to shellcode in r0? It’s pretty much that easy, except a real exploit would also need to overcome Address Space Layout Randomization (ASLR). Watchtowr researchers opted to leave that step out, to hopefully give QNAP users a few extra days before attacks happen in the wild.
(Pour l'achat de mon NAS, j'avais fait e tour des marques et immédiatement éliminé QNAP pour cette raison de failles récurrentes....)
https://hackaday.com/2024/05/24/thi...evel-escape-injection-and-audits/#more-681163
QNAPping At The Wheel
QNAP has had its share of problems over the years. The fine folks at Watchtowr decided to pitch in and try to find a few more, and then do a responsible disclosure to try to fix them the right way. And they didn’t disappoint. The unofficial audit found fifteen issues, but this write-up focuses on CVE-2024-27130, an unauthenticated overflow leading to Remote Code Execution (RCE).
Given the history of vulnerabilities, this shouldn’t be a big surprise, but the source of QNAP OS is a mess. The underpinnings are a Linux system, but the web interface on top of that is a tangle of a custom web server written in C, CGI scripts also written in C, strange leftover code bits in languages like PHP, and at least one code snippet that looks suspiciously like a backdoor.
And that’s all before we get to the real vulnerability. The cgi-bin/filemanager/share.cgi endpoint segfaults when providing a valid “ssid” and then an overlong file name. Inside the vulnerable code, it’s a simple strcpy() call, that copies an arbitrary, user-provided string into a fixed-length buffer. Write past the end of it, and you overwrite local variables, and then the return address, too. And because of how returns work, you also get to set some registers, like r0, the traditional first argument register. So… what if you just set the return address to the system() function, and put a pointer to shellcode in r0? It’s pretty much that easy, except a real exploit would also need to overcome Address Space Layout Randomization (ASLR). Watchtowr researchers opted to leave that step out, to hopefully give QNAP users a few extra days before attacks happen in the wild.
