IExpress vulnerability... miscategorized?

windows

#1

I’ve been reading up on the IExpress vulnerability described in 1.3.6.1.4.1.25623.1.0.813808. It seems the issue with IExpress is that it can create packages which can be exploited by a vulnerability in some unpacker in the wild, but IExpress in itself is not vulnerable. The problem, as I understand it, is as follows:

  1. IExpress creates a self-extracting program which allows files to be extracted to locations outside of the current working directory, and includes a set of instructions for executing the files once they’re extracted.
  2. A malicious .dll is placed in the same folder as the self-extracting archive.
  3. When the archive is executed, it first extracts the files and then runs them as required by the onboard instructions. The problem is that when it looks for a specific file, it searches in the current working directory before it checks the absolute path specified by the instructions.
  4. If a malicious .dll resides in the same directory as a self-extracting archive created by IExpress, and shares a filename with one of the archived files, but not its path, that malicious .dll may be executed by the archive upon extraction.

In that way, IExpress is able to create a package that can be exploited on some far-away computer, but it does not constitute a vulnerability on the computer being scanned because it itself does not extract the package. A design flaw, definitely, but not actually something that makes the computer vulnerable.

Is there anything that can be done to eliminate or recategorize this vulnerability?

Sources

https://blogs.technet.microsoft.com/srd/2018/04/04/triaging-a-dll-planting-vulnerability/

https://packetstormsecurity.com/files/135252/Microsoft-IExpress-DLL-Hijacking.html

https://jvn.jp/en/jp/JVN72748502/index.html

https://en.wikipedia.org/wiki/IExpress


#2

Just create a override, define the scope of the override and the new CVSS Score. Easy as that.


#3

Thanks Lukas!

I’d considered creating an override as you suggested, but I guess the reason I posted here was to see if anyone agreed with my assessment, and if so, if there was any venue for changing this globally in the feed, and what that would be.

Do you have any thoughts about my interpretation of this vulnerability? Thank you!!


#4

I think the vulnerability referenced here is legitimate, but the VT is testing for the wrong thing. The current VT tests for the presence of IExpress, which itself is not the vulnerability. It should be testing for, if anything, the PreferSystem32 setting described at https://blogs.technet.microsoft.com/srd/2018/04/04/triaging-a-dll-planting-vulnerability/, which would mitigate the exploitability of a package created with IExpress.