Multiple vulns detailed in ExtremeXOS, the operating system used for Extreme Networks managed switches. The bulk of the issues stem from the Chalet application, which is the main web app using the CherryPy framework in python that runs as root. Of particular interest was the /terminal endpoint which can allow authenticated users a limited terminal for management and diagnostics.

Issue 1: Arbitrary File Read as Root While login is needed to access the terminal commands, the /terminal/_static route is an unauthenticated endpoint used to load static files, and doesn’t properly sandbox or prevent path traversal. This can be used to obtain arbitrary file read as root, and can be used to read config files to obtain password hashes and such.

Issue 2: SSRF + Permissive Auth Escalation to Admin Once authenticated as a read-only user (presumably by cracking one of the password hashes), they wanted to see if escalation to admin could be obtained. The endpoint used for authentication is /auth/token, which upon receiving valid credentials will reply with a JWT token. In order to facilitate Inter-Process Communication (IPC), the localhost is exempt from credential check and can obtain an admin token. One of the commands a read-only user can access is telnet, which can be used to perform Server Side Request Forgery (SSRF) and send requests to the /auth/token endpoint on behalf of localhost to obtain a token.

Issue 3: ‘Shell Injection’ Escalation to Root The jsonrpc endpoint can be used to execute shell commands, and by sending a cli request to that endpoint with params provided via json, it’s possible to get arbitrary data passed in to commands ran in the shell. By passing the -d or debug flag, these commands would be ran as root. It’s worth noting this requires admin capability that would be obtained with the previous chain of issues, and the vendor doesn’t consider admin to root to be a security boundary, and so didn’t issue a CVE for this issue.

A series of issues in the Sonos Era 100 speaker that was exploited for pwn2own by nccgroup. During some initial recon on the speaker, they discovered breakout pads for serial/UART, as well as pins for Embedded MultiMedia Card (EMMC) communication, which allowed them access to the flash which stored firmware. While most of the data on this flash is encrypted and verified, the boot logs they obtained over UART suggested that this speaker is similar to other sonos devices that were researched in the past, and so they looked for vulns in the U-Boot image using plaintext binaries from other devices as a guide.

Issue 1: Arbitrary environment config Due to the CONFIG_ENV_IS_NOWHERE flag not being set in the U-Boot image, it will attempt to load the environment from the flash at 0x500000. By writing to this offset as an attacker, control over the environment can be obtained for critical variables such as bootcmd. This essentially bypasses the intent of the password-protected console.

Issue 2: Unchecked return on setenv() One of the environment variables that eventually makes its way to the linux kernel command line args is bootargs, and the bootcmd=sonosboot handler will try to ensure this variable is set properly. The problem is, they never check if this setenv() call succeeded, and it’s possible to make it fail as an attacker by marking the bootargs variable as a read-only variable in the bootcmd flags, which they could do by passing .flags=bootargs:sr. An attacker could now have control over kernel cmdline args, including the ability to set a custom initrd (ramdisk) offset to get code execution.

Issue 3: Improper header validation on firmware image While the first two issues can allow code exec, getting arbitrary data at a known location is still somewhat difficult due to the firmware images being encrypted and signed. However, the header is in plaintext, and contains a field for where the kernel binary is via kernel_offset. While this kernel_offset field is usually 0x40, it’s not validated, and so by increasing it, you can give yourself a ‘cave’ so to speak of data that won’t be validated against the kernel binary signature check.

Putting these issues together can be used to obtain code execution on the speaker.