Re: [Libreoffice] link error in comhelper with undefined references from ucbhelper

Hi Eike, Caolan, *

I recall that some exploits in the past have been done by linking to a
symbol that wasn't hidden but should've... in other words the attackers
bypassed the method/function with the argument validity checks.

So here's my follow-up question :)
Anything in that/those module(s) that have some critical operation? Like
password-protecting the file? Any operation considered privileged?
Anything that edits the registry of extensions?

Marc-André Laverdière
Software Security Scientist
Innovation Labs, Tata Consultancy Services
Hyderabad, India

On 08/05/2011 03:22 AM, Eike Rathke wrote:
> Hi Caolán,
>
> On Thursday, 2011-08-04 21:22:54 +0200, Eike Rathke wrote:
>
> > > I don't think moving from dmake to gnumake should affect this.
> > I think it did..
> >
> > But I was lying when I said before the symbols were there, well, they
> > are, but local, nm gives 't' instead of 'T'. Apparently the gnumake
> > transition switched visibility to all-off. Looking at the dmake build
> > there was ucbhelper.flt used to build the ignore list for exports.
>
> Indeed, I rebuilt ucbhelper with HAVE_GCC_VISIBILITY_FEATURE=FALSE and
> now comphelper linked fine. This of course is only a temporary
> workaround and probably needs to be repeated for each module that
> previously used a .flt list, resulting in bloated public symbols tables.
>
>   Eike
>
>
>
>
> _______________________________________________
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice