|0.00 2010-08-30 -11:30 -0700|
Category: Security Exposure Incident ID: X100801 Priority: 7 - Warning Status: Under Investigation Component: ODMA Integration Generally
- Repaired in: tbd
Assigned To: none
- Reported By:
- Dennis E. Hamilton, 2010-08-29
Date Logged: 2010-08-29
Date Recorded: 2010-08-29
Date Closed: none
There is recently-heightened concern for the way that DLLs are loaded on the Windows platform. The concern is that a malicious dynamic link library can be substituted for an authentic one by installing the counterfeit in a path that has the malicious version be found and loaded. Once the DLL is loaded, other applications may end up using the same DLL because it is thought to already be loaded and available.
Generally, this vulnerability requires that the desktop computer have been compromised in order for the malicious DLL to be loaded. However, if applications are run from shared directories on networks, a subverted DLL can be loaded from the network location.
ODMA-aware software packages that load ODMA32.dll may be vulnerable to DLL hijacking when the loading of the DLL is by name searching instead of by loading from a safe system-protected location. Any software package that installs an ODMA32.dll in its own directory is likely to be vulnerable to this situation by design.
Libraries that provides support for application-software integration with ODMA may use vulnerable built-in methods.
The distributed versions of ODMJNI beta packages load ODMA32.dll in a manner that allows substitution anywhere in the DLL search path (with default location being that of the Java version that is running). This vulnerability is in the OdmNative100.lib used in the construction of odjni100.dll.
In addition, odmjni100.dll, which is always located in the same directory as the ODMJNI-using application, makes use of the Java system's awt.dll file by name. This DLL cannot be hijacked if it is only installed in the directory of the java installation that loads the application.
ODMA 2.0 loads DMS integration software based on registry settings. These registry settings, below the HKEY_CLASSES_ROOT\ODMA32 key, should always load DLLs by absolute paths. Failure to use an absolute file-system path is unlikely.
The following steps are recommended to minimize vulnerability:
- Do not execute applications that access internal document-management systems from network-shared filesystem locations.
- On client systems, do not install ODMA32.dll anywhere but the Windows System directory. Copies should not be carried in the same directory as applications and copies used in testing and for setup of ODMA should not be where applications could accidently load them.
- Ensure that DMS integration DLLs loaded by ODMA are always registered with absolute path names to files on the local system.
No software updates or special releases are planned as further mitigation. Any future production release of OdmNative100.lib and ODMJNI will limit ODMA32.dll loading to use only safe system locations. There is no plan for such a release at this time..
- Dennis Hamilton
- created this incident report.
- X100801a: Diary & Job Jar
ODMA Interoperability Exchange.
created 2010-08-29-20:21 -0700 (pdt) by orcmid