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:
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.
A malicious .dll is placed in the same folder as the self-extracting archive.
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.
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?
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!!
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.
I’ve come to the forum after reaching the same conclusions you have @Jake.
Recently, I raised my concerns with our scanning vendor asking that they approach Greenbone about the rule. I raised concerns similar to what you identified. The scanning vendor responded, after consulting with the corporate entity they are contracted to, and instructed me to take ownership of all instances of iexpress.exe and delete the file. I was informed that this will resolve the vulnerability. I don’t agree.
I am concerned that the values set in the scanning rule for tags title, summary, and affected will lead some people to the conclusion that a host is vulnerable if iexpress.exe exists on the host. I know I started down this path until I read the supporting documentation contained in CVE description.
I came here hoping to find a process to have this rule reviewed to avoid confusion and clarify if iexpress.exe must be present on the host for it to be vulnerable.
@cfi or @Lukas, what is the process for requesting the removal of a VT? We created an override as suggested, but I think that solution overlooks the fact that the VT itself is flawed.
Buy a Greenbone appliance and open a customer ticket, then support will check this request or wait until our feed team can evaluate it any time from now.
GCF does not have any SLA compared to the GSF and support is only available to paying customers.
To put this statement into the right direction, of course all of our teams are noticing comments in this forum and are caring about user issues. This is how free software works. But sometimes our developers are working on other topics and can’t react or fix issues reported by the community directly.
Thanks for the clarification, @bricks. That’s helpful in understanding the process here. To reiterate what I had hoped to communicate, we’ve already dealt with this situation internally in a satisfactory way. I had returned to this post in an attempt to help the project by sharing what I had learned, not with expectations of instant support for a free service.
Aside, I think the ultimate goal of our team is to learn enough to become code-contributors to both the VTs and the project itself, though we’re not quite sure where the repos are or, what the etiquette is, or if that is something allowed to the public.
While this is a quite uncommon vulnerability the vulnerable component is still IExpress installed / running on the host (which this VT is testing for):
IExpress allows to create malicious self-extracting archives which can be used to either attack users of the affected host (e.g. put such a malicious archive into a shared folder accessible by an admin) or the user of an arbitrary remote host. In both cases a user-interaction is required.
This is some kind of a “client-side” attack similar to Cross-Site Scripting (XSS) attacks where the host running the web application and allowing the XSS is not affected directly (e.g. no RCE, …). With a XSS you’re only able to attack a user/client of the web application (e.g. trying to trick the user to open a specific link sent by email).
For client-side attacks you need to have a different view on such vulnerabilities because the software/application where the client-side attack is originating from needs to be evaluated and not the client (e.g. the Browser executing the JavaScript of the XSS attack) being attacked.
Nevertheless from the above a CVSSv2 score of 9.3 (Vector: AV:N/AC:M/Au:N/C:C/I:C/A:C) is too high for such a vulnerability. You could contact the NVD via https://nvd.nist.gov/info to get this re-analyzed and the severity of the VT would get automatically corrected.