[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[LDM #TXB-774930]: LDM Fortify Security Scan



Leo,

> It would be very much appreciated if you would respond to the following 
> questions concerning the LDM code.  Once we receive your answers, we will 
> develop a plan of how to proceed and contact you.  Will that work for you?

Sounds good.

> xmllint.c (lines 2249, 2290, 2332, 2639) and testSAX.c (lines 1018 and 1047) 
> â an attacker is able to pass in an invalidated path parameter such as a 
> path or URL to malicious configurations/data.   These are test programs.
> -- How do we build with the testing modules disabled, or can it be removed 
> after the build safely?  Provide instructions.
> -- If they cannot be disabled/removed, what are your recommendations to 
> mitigate or remove the risk?
> 
> parse4.c (line 120) â an attacker is able to pass in an invalidated path 
> parameter such as a path or URL to malicious configurations/data.
> -- What is this program used for?
> -- What would be the impact if the attacker was able to compromise this 
> program and specify a malicious input parameter?
> -- Is this program required for automated processing of the data?  Can it be 
> disabled/removed from the build safely? Provide instructions.
> -- If it cannot be disabled/removed, what are your recommendations to 
> mitigate or remove the risk?

The problems you mention are due to the the "libxml2" subpackage, which is 
bundled with the LDM package. I'm going to remove that subpackage from the LDM 
because "libxml2" now appears to be either installed or easily installable on 
most platforms. This has the side benefit of obviating the need for me to 
address its security issues. :-)

Having said that, the "libxml2" package is *only* used by the LDM to parse the 
LDM registry (see 
<http://www.unidata.ucar.edu/software/ldm/ldm-current/basics/LDM-registry.html>).
 So "libxml2" security holes can only be exploited by the LDM user (assuming 
that only they can modify the registry). The LDM doesn't use the "libxml2" 
package to parse anything from outside the LDM system.

If you need a version of the LDM without the bundled "libxml2" subpackage and 
can't wait, then you'll need to 1) edit the top-level "Makefile.am" -- removing 
the reference to the "libxml2" subdirectory; 2) edit the other "Makefile.am" 
files in the subdirectories indicated by executing the command "fgrep -l 
libxml2 `find . -name Makefile.am`" in the top-level source-directory -- 
replacing all "libxml2" references with ones that reference the system's 
"libxml2"; and 3) execute the command "autoreconf" in the top-level 
source-directory (assuming you have the GNU automake(1) utilities installed).

> Thanks,
> 
> //SIGNED//
> Leo R. Rivard, Contractor, AFWA/SEMS
> SEMS II Database Architect
> Northrop Grumman Information Systems
> email: address@hidden
> COMM: 402-232-0271 / DSN: 272-0271
> Alternate Email: address@hidden

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: TXB-774930
Department: Support LDM
Priority: Normal
Status: Closed


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.