Experimenting with ANSI escape characters on terminal emulators has led to the discovery of several high-severity DoS (Denial of Service) vulnerabilities on Windows devices and Chrome web browsers.
Eviatar Gerzi, security researcher at CyberArk, tested various potential avenues of abuse based on a old notice from 2003 about running code through window title changes and discovered a way to induce quick window title changes on PuTTY.
This atypical attack brought the test machine into a state known as a “white screen of death”, where everything freezes except the mouse cursor.
After testing a similar attack on a local application, the system immediately entered WSOD due to operating system kernel overloading with calls.
The abused function is’SetWindowText, ‘which allows you to change the text of the title bar of the specified window.
The only way out of the WSOD state is to restart the computer, so this simple trick can lead to a DoS state on a range of applications.
Like the researcher specifies, ‘SetWindowText’ is not the only possible lever for hang-ups, as was discovered in the case of MobaXterm.
In one of the cases, I tested the MobaXterm terminal and was surprised that it does not use the SetWindowText function to change the window title but rather a named function GdipDrawString.
The interesting thing in this case is that it didn’t affect the whole computer like SetWindowText. It only affected the app, which ultimately crashed.
Gerzi has confirmed that the following Windows terminals are affected by a DoS issue:
- Putty – CVE-2021-33500 (freezes the whole computer), fixed in version 0.75
- MobaXterm – CVE-2021-28847 (only freezes the application), fixed in version 21.0 preview 3
- MinTTY (and Cygwin) – CVE-2021-28848 (freezes the whole computer), fixed in version 3.4.6
- Git – uses MinTTY, fixed in version 2.30.1
- ZOC – CVE-2021-32198 (only freezes the application), no patch
- XSHELL – CVE-2021-42095 (freezes the whole computer), fixed in version 220.127.116.11
Try it on web browsers
Realizing that almost all GUI applications use the SetWindowText function, the researcher attempted the attack against popular web browsers such as Chrome.
He created an HTML file that would quickly change the title in an infinite loop, forcing the browser to freeze.
The same behavior has been noticed in Edge, Torch, Maxthon, Opera, and Vivaldi, all Chromium-based browsers. Although Firefox and Internet Explorer are immune to it, they still have an impact on performance.
In any case however, the underlying operating system is not affected as modern browsers are sandbox based.
However, while attempting to attack the browser inside a virtual machine, a resource exhaustion issue occurred causing a “blue screen of death” to be displayed.
The researcher notes that the applications affected by this attack could be anything using SetWindowText or GdipDrawString, so the above applications are just a sample of the affected software.
Some applications like Slack, for example, have a rate limiter on function calls, so they are resilient to this type of DoS attack.
Gerzi contacted the affected suppliers and received the following responses:
Google: DoS issues are treated as abuse or stability issues rather than security vulnerabilities. Note: The problem is not observed on Mac but is observed on Linux. We have revisited the problem. We were unable to reproduce the crash in the latest versions of WS 16.1.2 build-17966106 and Chrome 92.0.4515.131. We believe that the behavior you have observed may depend on the version of chrome used, as we have not seen any BSOD issues from our end. Therefore, we consider it not to be a bug.
Vivaldi: This is a design limitation of Windows 10; it does not limit application memory usage and simply uses the paging file (virtual memory) when it runs out of RAM. This is slower to respond because it must be read from disk.
Microsoft: Our team was able to reproduce this issue, but it is not responding to our service bar with an immediate security update. Although this results in a denial of service condition, it can only be triggered locally and is a result of resource exhaustion. An attacker would not be able to trigger additional vulnerable conditions or recover information that would be beneficial in other attacks on the system. We will close this file, but we have opened a bug with our development team, and they might consider fixing this issue in a future version of Windows.
In response to the above, the researcher specifies that it is possible to trigger the attack remotely by creating a malicious file on a remote server and opening it from a vulnerable terminal.