Re: Stored secrets seem to get corrupted

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

 



On Wed, Jul 04, 2012 at 04:17:39PM +0200, Wido den Hollander wrote:
> 
> 
> On 04-07-12 14:08, Eric Blake wrote:
> >[adding gnulib]
> >
> >On 07/04/2012 02:45 AM, Daniel P. Berrange wrote:
> >
> >>>>==6825==
> >>>>==6825== Invalid read of size 4
> >>>>==6825==    at 0xA57E4B9: base64_encode (in /usr/lib/x86_64-linux-gnu/libroken.so.18.1.0)
> >>>>==6825==    by 0x10DDBC98: base64_encode_alloc (base64.c:140)
> >
> >>>>
> >>>>This one is very interesting. It shows that the 'base64_encode' function
> >>>>is doing an out-of-bounds read. More tellingly though is that it is
> >>>>reporting 'base64_encode' function is in a wierd library:
> >>>>
> >>>>    /usr/lib/x86_64-linux-gnu/libroken.so.18.1.
> >>>>
> >>>>If this were normal, we should expect to see that function present
> >>>>in 'base64.c' since this function code is provided by gnulib itself.
> >>>>
> >>>>So something else libvirt is linking to, directly or indirectly
> >>>>is using  libroken.so which also has a 'base64_encode'symbol
> >>>>defined. This is overriding gnulib's symbol of the same name.
> >>>>
> >>>>I'm willing to bet the API contract of this libroken.so base64_encode.
> >>>>differs from GNULIBS, with crashtastic results
> >>>>
> >
> >>>The library is libroken18-heimdal under Ubuntu 12.04:
> >>>http://packages.ubuntu.com/precise/libroken18-heimdal
> >>>
> >>>When installing ubuntu-virt-server libraries like gnutls depend on
> >>>this library.
> >>>
> >
> >>I expect that this is an internal symbol from libroken.so which
> >>they leak into the public namespace.
> >>
> >
> >>It sounds like we might need to have a workaround in gnulib to
> >>avoid this problem. With other cases where gnulib replaces existing
> >>symbols they use some magic such that the gnulib replacement gets
> >>prefixed with 'rpl_'.
> >
> >Yuck.  Gnulib can't really probe at configure time whether an
> >application will link against a shared library that drags in namespace
> >pollution, so I don't see how to automate any 'rpl_' renaming in gnulib
> >directly.  It would be possible to blindly rename the gnulib functions,
> >but that's an interface change that would affect all clients of the
> >gnulib base64 module.
> >
> >I'm wondering if it is better for libvirt to just #define base64_encode
> >to a different name in config.h.  Meanwhile, we need to open a bug
> >report against heimdal to fix their library namespace pollution through
> >libroken.
> >
> 
> As this is getting a bit out of my league it's safe for me to assume
> somebody else will pick this up?

Yes, we'll sort it out from here.

> Not to take the easy way out, but I don't think I can't provide much
> help here other then testing any patches.

I'll try to remember to let you know when we've got a possible fix.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]