It looks like Al was right, we should all be using Emacs. On the 4th of June, [Armin Razmjou] announced a flaw in Vim that allowed a malicious text file to trigger arbitrary code execution. It’s not every day we come across a malicious text file, and the proof of concept makes use of a clever technique — escape sequences hide the actual payload. Printing the file with cat returns “Nothing here.” Cat has a “-v” flag, and that flag spills the secrets of our malicious text file. For simplicity, we’ll look at the PoC that doesn’t include the control characters. The vulnerability is Vim’s modeline function. This is the ability to include editor options in a text file. If a text file only works with 80 character columns, a modeline might set “textwidth=80”. Modeline already makes use of a sandbox to prevent the most obvious exploits, but [Armin] realized that the “:source!” command could run the contents of a file outside that sandbox. “:source! %” runs the contents of the current file — the malicious text file.

:!uname -a||" vi:fen:fdm=expr:fde=assert_fails("source\!\ \%"):fdl=0:fdt="

Taking this apart one element at a time, the “:!” is the normal mode command to run something in the shell, so the rest of the line is what gets run. “uname -a” is the arbitrary command, benign in this case. Up next is the OR operator, “||” which fully evaluates the first term first, and only evaluates what comes after the operator if the first term returns false. In this case, it’s a simple way to get the payload to run even though the rest of the line is garbage, as far as bash is concerned. “vi:” informs Vim that we have a modeline string. “:fen” enables folding, and “:fdm=expr” sets the folding method to use an expression. This feature is usually used to automatically hide lines matching a regular expression. “:fde=” is the command to set the folding expression. Here’s the exploit, the folding expression can be a function like “execute()” or “assert_fails()”, which allows calling the :source! command. This pops execution out of the sandbox, and begins executing the text file inside vim, just as if a user were typing it in from the keyboard.

[Armin] suggests disabling modelines altogether, and mentions that Debian does this by default. I’ve checked my Fedora desktop, and while I had already updated Vim to the patched version, I was surprised to see modelines still enabled. I quickly opened “/etc/virc” and added “set nomodeline” to the end of that file, and I suggest you do the same.

An Email Bug From Ages Past

The Exim email server has a remote command execution vulnerability, and it takes a week of real time to exploit. The code to be run is embedded in the send-to email address: “run{kcalc}@localhost”, and a certain code path processes that address using “expand_string()”, which helpfully includes a function to run commands. The researchers from Qualys ran into a problem trying to exploit this problem remotely: by default, Exim checks incoming email for valid destination addresses. “run{}” is pretty obviously not a valid username, so the message never interacts with the vulnerable code. The solution to this is clever, to say the least.

By default, when an email server receives a message it can’t successfully deliver, a bounce email is generated, informing the sender that the message failed. This bounce message uses the sender’s reported email address, allowing an attacker to inject commands as a part of that address. This solves one problem, but creates another. Not all messages trigger execution of the vulnerable code, and since the attacker is relying on the bounce message to trigger the exploit, he can no longer manipulate the message’s failure mode. The full exploit is to send an email from “run{…}@attackerdomain.com” to a vulnerable Exim server. When that server attempts to connect to the attacker’s MX server to deliver the bounceback message, the attacker forces the connection open for 7 days, by only sending a new byte every four minutes. Once 7 days have passed, the connection is terminated with a permanent delivery failure. This particular failure state triggers the vulnerable code, running the specified command. There is at least one report that this vulnerability is being actively exploited in the wild, so if you’re running Exim, go install the patch!

The disclosure thread includes two very old Sendmail stories, the WIZ and DEBUG vulnerability. Both are fun reads, and a reminder of the simpler days of computer security.

Your 90 Days are Up!

Google’s Project Zero is no stranger to controversy, and this week is no exception. On Tuesday, [Tavis Ormandy] announced a new Denial of Service vulnerability in a Windows Cryptography routine. You may recognize [Tavis] from last week. At this rate, we’ll need to rename the column in a few more weeks.

This particular bug results in a deadlock when processing a specific X.509 certificate. So far, there is no path to command execution for this bug, but it’s not hard to imagine an attacker taking a Windows server offline by sending this particular certificate in an email or other channel.

When Microsoft was informed of the issue, they requested an extra day, in order to release the patch on Patch Tuesday, the 11th. Even though that was technically the 91st day, the Project Zero team agreed. On the 11th, Microsoft opted not to release the patch, and the vulnerability was announced as scheduled. While some have already condemned the release of the bug, I can only observe that Microsoft was given more than enough time to roll out a fix, and Project Zero has done exactly what they agreed to do.

Hacking Cryptocurrency Wallets to Save Them

Another day, another supply chain attack. A Javascript library, electron-native-notify, was updated to include malicious code. This particular library was used in the Agama cryptocurrency wallet, developed by Komodo. The npm security team gave their perspective on the official npm blog. They discovered the malicious code, and notified projects using that library, including Komodo. This code was uploading wallet information and secrets to the attacker’s server, who were then using that information to drain money from the vulnerable wallets.

In an unexpected plot twist, the server used to store the stolen information was publicly accessible, and the Komodo security team was aware of it. Here is quite the ethical dilemma. They were watching an active attack on their users, but the only immediate solution was legally and ethically questionable. Komodo decided to bite the bullet and jump into action. Yes, they hacked their own customers, using the stolen information to move cryptocurrency out of the now vulnerable digital wallets. Komodo is still working to restore the missing funds to their users. The decision they had to make in such a short amount of time must have been very difficult, and serves as a reminder of the occasional gray area of security work.

It appears that the developer who pushed the malicious code into the library in question had been targeting the Agama wallet for some time, making genuinely useful code contributions to the Agama project. We’ve seen this style of attack in the past — event-stream is the example that first comes to mind. In both cases, a developer appeared to be a helpful contributor and was quickly given too much access to a project, only to push malicious code into the project before disappearing. I’m confident this won’t be the last time this approach is attempted — and when it happens we’ll be sure to tell you about it. Stay Tuned!