Experimentation with ANSI desertion characters on terminal emulators has led to the inventory of multiple high-severity DoS (denial of service) vulnerabilities on Windows Terminals and Chrome-based web browsers.

Our security investigators at Xiarch have tried out numerous probable harm pathways based on an old 2003 advisory on code execution through window title modifications and discovered a way to activate rapid window title changes on PuTTY.

This is a typical attack that caused the test machine to enter a state known as the “White Screen of Death”, where everything freezes except for the mouse cursor. Upon testing a similar attack on a local application, the system entered WSOD immediately due to overburdening the OS kernel with calls.         

The affected function is ‘SetWindowText,’ which permits changing the text of the specified window’s title bar. 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.  

As the researcher points out, ‘SetWindowText’ isn’t the only possible leverage for hung ups, as discovered in the case of MobaXterm. In one of the cases, I tested the MobaXterm terminal, and I was surprised that it didn’t use the SetWindowText function to change the window title but, rather, a function named GdipDrawString.

The interesting thing, in this case, is that it didn’t affect the whole computer like SetWindowText. It affected only the application, which eventually crashed.

Gerzi confirmed the following Windows terminals are affected by the DoS issue:

• PuTTY – CVE-2021-33500 (freezes whole computer), fixed in version 0.75
• MobaXterm – CVE-2021-28847 (freezes only app), 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 (freezes only app), no fix
• XSHELL – CVE-2021-42095 (freezes whole computer), fixed in version 7.0.0.76

How to Trying it out on web browsers?

Realizing that almost all GUI applications use the SetWindowText function, the researcher tried out the attack against popular web browsers such as Chrome. He created an HTML file that would cause the title to change rapidly in an infinite loop, forcing the browser to freeze.

The same behavior was noticed in Edge, Torch, Maxthon, Opera, and Vivaldi, all Chromium-based browsers. Though Firefox and Internet Explorer are immune to it, they still take a performance hit.

In all cases though, the underlying OS remains unaffected because modern browsers are based on sandboxes. However, when trying the browser attack inside a virtual machine, a resource depletion issue occurred causing the virtualized system to display a ‘Blue Screen of Death.’

What are the Response from vendors?

The researcher notes that the applications affected by this attack could be anything using either SetWindowText or GdipDrawString, so the above apps are only a sample of the affected software. Some applications like Slack, for example, feature a rate limiter on the calls of the functions, so they’re resilient to this kind of DoS attack.

Gerzi contacted the affected vendors and received the following responses:

Google: DoS issues are treated as abuse or stability issues rather than security vulnerabilities. Note: The issue is not observed on Mac but is observed on Linux. We have reviewed the issue again. We were not able to reproduce the crash in the latest versions of WS 16.1.2 build-17966106 and Chrome 92.0.4515.131. We view that the behavior you observed might be dependent on the chrome version used as we didn’t see any BSOD issues on our end. Hence, we consider this not a bug.

Vivaldi: This is a design limitation of Windows 10; it does not limit application memory usage, and simply uses pagefile (virtual memory) when it runs out of RAM. This is slower to respond to because it must be read from the disk.

Microsoft: Our team was able to reproduce this issue, but it does not meet our bar for servicing with an immediate security update. While this results in a denial of service condition, this can only be triggered locally and is the result of resource exhaustion. An attacker would not be able to trigger any additional vulnerable conditions or retrieve information that would be beneficial in other attacks on the system. We will be closing this case, but we have opened a bug with our development team, and they may consider addressing this in a future release of Windows.

In reply to the above, the investigator indicates 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.