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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice