bugGNUstep - Bugs: bug #9169, libgnustep-base 1.7.2 dies due to...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #9169: libgnustep-base 1.7.2 dies due to mprotect() call

Submitted by:  None
Submitted on:  Sun 30 May 2004 11:21:20 PM UTC  
 
Category: LibrariesSeverity: 3 - Normal
Item Group: BugStatus: Invalid
Privacy: PublicAssigned to: Adam Fedor <fedor>
Open/Closed: Closed

Mon 19 Mar 2007 03:32:41 AM UTC, comment #3:

Sorry, this is really a bug in ffcall, and it appeasr to really be fundamental to the way ffcall functions. I'd recommend trying to use libffi as well.

There's a ffcall bug report for this (1531290) at
http://sourceforge.net/tracker/?group_id=1355&atid=101355
if you want to follow this (it's been open for several months with no action though).

Adam Fedor <fedor>
Project AdministratorIn charge of this item.
Thu 03 Jun 2004 10:21:07 PM UTC, comment #2:

Could you please try with libffi instead of ffcall? I am not saying that this will remove the problem, but it is worth trying.

Fred Kiefer <FredKiefer>
Project Member
Sun 30 May 2004 11:24:07 PM UTC, comment #1:

===
PaX appears to not be able to catch the trampolining being done with its trampoline emulation. Although this can be 'fixed' on the PaX side, trampoline emulation is off by default for security reasons; and so far this is the only time I've actually had to enable it on anything. Both the issue of PaX not catching the trampoline, and the issue of libgnustep-base having a trampoline need to be addressed.
===

Sorry, I meant to say, this would be the first time I've had to enable it; I have to turn OFF the mprotect() restrictions to accomodate the trampoline, which means I'm leaving an even bigger security hole until PaX can catch the trampoline if it can at all.

Anonymous
Sun 30 May 2004 11:21:20 PM UTC, original submission:

I'm trying to use the NSObject base class and whenever I do, programs I compile die because of the error:

trampoline: cannot make memory executable

I've checked each and every library that my hello world program is linked to, and only libgnustep-base.so.1 contains the 'cannot make memory executable' string:

bluefox@icebox tests $ grep -iHnr --mmap "cannot make memory executable" /usr/GNUstep/System/Library/Libraries/libgnustep-base.so.1
Binary file /usr/GNUstep/System/Library/Libraries/libgnustep-base.so.1 matches

The issue here is that I'm using a certain security system, called PaX, which deals executable space protection. In this case, it is one of the systems that prevents code injection which is killing it: mprotect() restrictions.

Under PaX' mprotect() policy, no pages may become executable; they must always be created with PROT_EXEC and not PROT_WRITE (i.e. when a shared object is mapped in), or without PROT_EXEC (i.e. malloc()ed ram or mmap()ed anonymous memory, or read/write disk mappings). Pages may lose PROT_EXEC if you so choose.

PaX appears to not be able to catch the trampolining being done with its trampoline emulation. Although this can be 'fixed' on the PaX side, trampoline emulation is off by default for security reasons; and so far this is the only time I've actually had to enable it on anything. Both the issue of PaX not catching the trampoline, and the issue of libgnustep-base having a trampoline need to be addressed.

Please deal with this issue at your leisure; however, I would appreciate it if you did not simply let it rot. For now I can work around it, but this is in no way proper.

Anonymous

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by fedor (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 19 Mar 2007 03:32:41 AM UTCfedorStatusNone=>Invalid
      Assigned toNone=>fedor
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1