[libvirt] conftest segfault

[Gene Czarcinski]

On 03/16/2013 11:08 PM, Eric Blake wrote:
> On 03/16/2013 02:02 PM, Gene Czarcinski wrote:
>
>>> In fact, just in typing that, I though of at least one glibc CVE bug in
>>> re_compile_pattern, that still has not been fixed as of the glibc
>>> currently in Fedora 18.  Furthermore, I know that this bug was reported
>>> only recently, and that the version of gnulib used in v1.0.2 did not
>>> check for this bug, while the version in v1.0.3 does (see libvirt commit
>>> d09949e29 for where I updated to newer gnulib, precisely to work around
>>> that glibc CVE).  So sure enough, I looked through my config.log and
>>> found:
>>> Libvirt is immune to that bug, but the CVE still affects other glibc
>>> clients that use re_compile_pattern without being aware of the problems,
>>> so you may want to put some pressure on the right people to fix
>>> https://bugzilla.redhat.com/show_bug.cgi?id=905877.
>>>
>> I did a little testing and the problem begins occurring with this commit:
>>
>>> commit d09949e29386c38443c82a2231240cc1e3954a5d
>>> Author: Eric Blake <eblake at redhat.com>
>>> Date:   Sat Jan 26 13:41:31 2013 -0700
>>>
>>>      maint: update to latest gnulib
>>>
>>>      CVE-2013-0242 in glibc's regex() can cause a DoS in any daemon
> Bingo - you found the very commit that I was just describing above.
>
>> If do a ./autogen with the previous commit, no problem.  Move along to
>> this commit and "bang" ... the segfault message in syslog.
> And as I've already told you, this is GOOD, and will continue to happen
> as long as glibc is vulnerable to the CVE.  The segfault in configure is
> INTENTIONAL - it is gnulib probing whether glibc is broken, in order to
> decide whether to rely on glibc or provide its own alternate regex
> implementation.  If glibc coredumps, then gnulib uses its alternate, and
> libvirtd is a few kilobytes larger but immune to the glibc bug.  If
> glibc does not core dump, then gnulib uses glibc, and libvirtd will be
> slightly smaller.  Either way, libvirtd is immune to the glibc CVE,
> _because_ the configure test was intentionally trying to tickle a
> segfault.  Libvirt 1.0.2, on the other hand, is vulnerable to the glibc
> bug, because it was not probing for that particular failure.
>
>> So, it appears the this version of gnulib fixes something important but
>> also causes a segfault when ./configure is run with the new gnulib.
>> What I do not know is if this segfault has any meaning.
> The segfault DOES have meaning - it means that glibc is broken, but that
> the brokenness of glibc will not impact the rest of libvirtd.  Quit
> worrying about it.
>
> Meanwhile, if you are wondering about glibc, just read
> https://bugzilla.redhat.com/show_bug.cgi?id=905877 (which you can easily
> find by searching for CVE-2013-0242, the very CVE mentioned in the
> commit message that you bisected as being the source where ./configure
> first tickles a segfault).  It looks like an updated glibc will be
> hitting updates-testing of Fedora 18 early next week, at which point,
> the segv during ./configure should disappear.
I thought I had checked bugzilla but I searched the comment fields 
rather than the subject line for CVW-2013-242 ... I will need to 
remember to do both next time.

Since libvirt uses gnulib for some/many/most/all of what it needs from 
libc and gnulib specifically has its own copy/version of regexec.c which 
has exactly the same patch as the one that goes against glibc, you are 
correct in saying that libvirt does not suffer from the problem.  Maybe 
something should be done to have configure use gnulib instead of glibc 
for its tests.

One other little thing ... libvirt has a test named "conftest" ... very 
confusing in this case.  I just may submit a patch to rename that 
particular test.

Gene