Are you confusing the part in the readme where it is commented that OAS exemptions on network drives shouldn't be used as drive letters, but instead as UNC paths? I don't recall seeing the issue above ever noted in a readme or KC etc.
This restriction could have something to do with various DLL attacks that have been discovered in previous times, and sounds like a safety mechanism.
Not had a look at 8.8 - but from a google search its in the beta 1 readme known issues:
Interesting. Must have been dropped from the release notes in later betas and the final product.... Beta 1 was a long time ago!
Knew I'd seen it somewhere, pity it still seems to be applicable.
looks like I won't be rolling 8.8 any time soon then as I'm sure we have hundreds if not thousands of machines with UNC paths in the path statement just off 2 of our hundreds of apps.
oh well roll on patch 1
1 of 1 people found this helpful
oh well roll on patch 1
If it's done for the reason I expect (to prevent DLL injection via UNC path hijacking) then you are unlikely to see it fixed... It's actually quite dangerous. Have a look at http://www.microsoft.com/technet/security/advisory/2269637.mspx - I believe this is one of the causes of the vulnerabilty in VSE 8.5 (https://kc.mcafee.com/corporate/index?page=content&id=SB10013) .
So I can see why McAfee won't play with risky paths as it can't control what is on them.
When an application dynamically loads a dynamic-link library without specifying a fully qualified path name, Windows attempts to locate the DLL by searching a well-defined set of directories in a particular order, as described in Dynamic-Link Library Search Order. If an attacker gains control of one of the directories on the DLL search path, it can place a malicious copy of the DLL in that directory. This is sometimes called a DLL preloading attack or a binary planting attack. If the system does not find a legitimate copy of the DLL before it searches the compromised directory, it loads the malicious DLL. If the application is running with administrator privileges, the attacker may succeed in local privilege elevation.
For example, suppose an application is designed to load a DLL from the user's current directory and fail gracefully if the DLL is not found. The application calls LoadLibrary with just the name of the DLL, which causes the system to search for the DLL. Assuming safe DLL search mode is enabled and the application is not using an alternate search order, the system searches directories in the following order:
- The directory from which the application loaded.
- The system directory.
- The 16-bit system directory.
- The Windows directory.
- The current directory.
- The directories that are listed in the PATH environment variable.
I can see their point...
but it will be interesting to see how they sell Mcafee 8.8 to the education and local gov environment with that kind of restriction, buy our great software that you wont be able to install without getting 2/3rds of your legacy suppliers to rewrite their software packages (half of whom probably no longer exist) that isn't going to do anything for my TCO.
I predict a minimum of 6 months for an opt out option involving a MID package alteration.
Thanks for the point. I did in a computer with XP and after in a computer with 7. In the second I didn't find any reason why it doesn't installed. I erase the UNC shares and installed the product from ePO correctly. After I added again the UNC shares.
I'll try to see the performance of the VSE 8.8 and I'll post it.