the bad security reputation of textproc/libxml2

20180810:
AFFECTS: databases/postgresql??-server
AUTHOR: girgen@FreeBSD.org

The PostgreSQL server packages are no longer built with support for the XML
datatype per default. To retain support for the XML datatype you should build
the port and check the XML option in the option dialog. The reason for this
is the bad security reputation of libxml2.
To be clear: I'm not going to lament on that move. I love consequence, and I love it even more when it comes to IT-security. So there is no but ...

The port textproc/libxml2 is heavily depend on. pkg query %ro libxml2 gives a nice output here, and probably you might get also a nice list.
And yeah pkg delete libxml2 won't be the fix. ;)

The question is, why should I have such a port with a bad reputation on nearly all of my systems. Shouldn't that be substituted by something better? What to do?

Gently inviting for a security oriented discussion.
 
The real question, in my opinion, is why you allow yourself to be led by the opinion of one party? And why conclude that this also has an effect on the entire OS?

Code:
peter@zefiris:/home/peter $ pkg audit textproc/libxml2
0 problem(s) in the installed packages found.

Then I searched bugs.freebsd.org for problems with libxml2:

https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=libxml2

I got 3 results: 177059, 224902 and 222580.

Of course if you look for problems with libxml2 in combination with PostgreSQL then you see a different picture; there are plenty of problems noticed there. Just check Google. They even seemed to have issues with libxml2 on Windows(!).

But is this really a problem with libxml2? Or the way it has been used by the PostgreSQL project?

(edit) Just because PostgreSQL has a problem here doesn't imply that the same is true for all others.
 
The real question, in my opinion, is why you allow yourself to be led by the opinion of one party? And why conclude that this also has an effect on the entire OS?
ARGH! Don't care about what others allow, care about yourself. Don't play the opinion game with me. And who has concluded that this affects th entire OS?

Just try pkg audit libxml2 and see the facts.
 
Just try pkg audit libxml2 and see the facts.
A very good suggestion. Interesting because I didn't realize that pkg audit would simply treat any argument as valid to check for in its database. Granted I mixed up package and port names, but even so...

Anyway... I'm still not a believer without knowing the precise cause of past issues. Quantity doesn't make quality. Sure, there have been a lot of issues but is that because the library was that bad or because it is being heavily used which also makes it a legit target for testing after which issues pop up?

My problem with arguments like "don't we need something better?" is that it's always easy to look at these issues in hindsight. What guarantees are there that another project won't be causing the same (or different) problems? With the added risk that due to the smaller user base (assumption on my part) several of those problems could easily go unnoticed.

Code:
peter@zefiris:/home/peter $ pkg audit apache24 | wc -l
     120
peter@zefiris:/home/peter $ pkg audit libxml2 | wc -l
     134
I believe libxml2 was even longer around than Apache 2.4, so does this make Apache a bad web server which is best not used anymore because of the amount of discovered vulnerabilities?

It's not like its competitor www/nginx isn't without it's collection of problems also:

Code:
peter@zefiris:/home/peter $ pkg audit nginx | wc -l
      82
So here's the noodle: is that smaller number the cause of less bugs in the system, or because the project hasn't been as extensively used / attacked as its counterpart?

In my opinion it's far too narrow minded to think "less audit reports = better product".
 
Quantity doesn't make quality. Sure, there have been a lot of issues but is that because the library was that bad or because it is being heavily used which also makes it a legit target for testing after which issues pop up?
You don't get it right. It's about Common Vulnerabilities and Exposures (CVE). They are by nature quality items and they are quantifiable.

My problem with arguments like "don't we need something better?" is that it's always easy to look at these issues in hindsight. What guarantees are there that another project won't be causing the same (or different) problems? With the added risk that due to the smaller user base (assumption on my part) several of those problems could easily go unnoticed.
Regarding your personal problem I'd suggest reading Voltaire. He came up with "The better is the enemy of the good." Spend some time thinking about that.

Regarding "hindsight" I'd like to point to the reputation of OpenSSL. It was and still is a frequent cause for patching. And then came LibreSSL and made a difference.
Code:
peter@zefiris:/home/peter $ pkg audit apache24 | wc -l

120

peter@zefiris:/home/peter $ pkg audit libxml2 | wc -l

134

I believe libxml2 was even longer around than Apache 2.4, so does this make Apache a bad web server which is best not used anymore because of the amount of discovered vulnerabilities?


It's not like its competitor www/nginx isn't without it's collection of problems also:


Code:
peter@zefiris:/home/peter $ pkg audit nginx | wc -l

82
You could have done better. Counting lines makes little sense if a line is irrelevant. You need to count the items of interest and these are the CVE events.

I want to stay with my OpenSSL/LibreSSL example. As we all (should) know, LibreSSL was started for the purpose of writing a better code with security in mind. For comparing both we look on the common timespan only which is from 2014 on.

Code:
> pkg audit openssl | grep 'CVE-201[4-8]' | wc -l
89

> pkg audit libressl | grep 'CVE-201[4-8]' | wc -l
31
My noodle: So far LibreSSL outperformed OpenSSL by far with a quote of roughly 1:3 for needing a patch.

Your noodle:
So here's the noodle: is that smaller number the cause of less bugs in the system, or because the project hasn't been as extensively used / attacked as its counterpart?
It's about the quality of the coding, isn't it?
In my opinion it's far too narrow minded to think "less audit reports = better product".
One can easily ruin one's own reputation with the last sentence. So I leave it to the audience for making up their own mind.
 
obligatory xkcd for this.
And remember, when someone shoots himself in the foot, you don't necessarily blame the gun.

Just my 2¢.
 
You could have done better. Counting lines makes little sense if a line is irrelevant. You need to count the items of interest and these are the CVE events.
True, it's not a solid measurement, but still somewhat usable because I applied this for all my examples.

It's about the quality of the coding, isn't it?
But who's coding? And does it really?

Code:
peter@zefiris:/usr/ports/textproc/libxml2 $ make all-depends-list
/usr/ports/ports-mgmt/pkg
/usr/ports/devel/gmake
/usr/ports/devel/gettext-runtime
/usr/ports/converters/libiconv
/usr/ports/print/indexinfo
/usr/ports/devel/pkgconf
/usr/ports/devel/kyua
/usr/ports/devel/atf
/usr/ports/devel/lutok
/usr/ports/lang/lua52
/usr/ports/devel/libedit
/usr/ports/databases/sqlite3
/usr/ports/devel/readline
Of course some of these dependencies (such as ports-mgmt/pkg) are not relevant for this argument and others such as devel/gmake only partially.

Still: modern projects often rely on tons of 3rd party stuff. And each of those individual components can create problems for the main project. The actual cause could be anything of course. It could definitely be a specific way in which the components were (mis)used. But at the same time it's also not unthinkable that a compiler set up code in a way which was exploitable. Or that a used library doesn't really work too well with another.

ShelLuser said:
In my opinion it's far too narrow minded to think "less audit reports = better product".
One can easily ruin one's own reputation with the last sentence.
Hardly, unless people take it out of context, or are actually gullible enough to believe that every exploitable problem will be easily and quickly found. The Debian OpenSSL disaster has clearly debunked that idea.
 
Back
Top