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.