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

[Marc-André Laverdière]

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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice