How to build a paxctl (or chpax) for other ABI's ELF files?

Discuss and suggest new grsecurity features

Moderators: spender, PaX Team

How to build a paxctl (or chpax) for other ABI's ELF files?

Postby Neokernsec » Fri Feb 20, 2015 7:53 am

I'm trying to build a version of paxctl (or chpax) that will let me change PaX ELF flags for any ABI's binaries, without success.

I've tried a variety of "cross compilation" and different embedded "hosting" solutions, but at the end of the day, I can't get an x86 version that accepts MIPS 32bit ELF files as "valid".

I am building MIPS binaries under x64, and for a variety of reasons a "native" (MIPS) version of paxctl/chpax won't work for me - paxctl's reliance upon mmap() and friends precludes its use on filesystems like jffs, etc.

Do you have any suggestions as to where I might start to build a "cross-hosted" tool whereby I could alter MIPS ELF binaries on an x64 host?
Neokernsec
 
Posts: 16
Joined: Sun Dec 30, 2012 8:53 am

Re: How to build a paxctl (or chpax) for other ABI's ELF fil

Postby PaX Team » Fri Feb 20, 2015 9:10 am

paxctl should work fine on any ABI but it has very strict checks on the target files. i just checked busybox on a random openwrt/MIPS box and even 'file' itself reports it as having a 'corrupted section header size'. so either fix your binaries or relax the paxctl checks (but if it then breaks your binaries you get to keep both pieces ;)).
PaX Team
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm

Re: How to build a paxctl (or chpax) for other ABI's ELF fil

Postby Neokernsec » Fri Feb 20, 2015 10:01 pm

Ah, so they are. It turns out the culprit is OpenWRT's use of sstrip (versus strip), which seems to slightly damage the ELF binaries, even if it does reduce their size a bit better than strip does.

Thanks for the heads up. I didn't even think to check their validity, doh.
Neokernsec
 
Posts: 16
Joined: Sun Dec 30, 2012 8:53 am

Re: How to build a paxctl (or chpax) for other ABI's ELF fil

Postby PaX Team » Sat Feb 21, 2015 3:15 am

PaX Team wrote:paxctl should work fine on any ABI but it has very strict checks on the target files.
actually, this is not quite true, paxctl ignores endianness (the manpage explicitly mentions the amd64/mips case) so the host and target must be the same otherwise the results won't be good... (and yes, patches are accepted ;))
PaX Team
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm

Re: How to build a paxctl (or chpax) for other ABI's ELF fil

Postby Neokernsec » Sat Feb 21, 2015 8:18 pm

Ah yes. Switching to strip doesn't address the problem., but it does make file happy.

$ file randheap1
randheap1: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked (uses shared libs), stripped
$ chpax -v randheap1
randheap1: Unknown file type (passed)
$ paxctl -v randheap1
file randheap1 is not a valid ELF executable

Rats.

I'll throw some time at the problem to see if there's a straightforward fix.

My main reason for doing this is that paxctl's use of mmap() causes it to be broken when ELF files are on filesystems that do not support writably mmap()ed files.

So it'll probably come down to which is the speediest-to-deploy: de-mmap()ing paxctl or adding MIPS32 ELF support for the x86/x64 hosted tool.

I realise the Final Solution is to add support for all of the ELF flavours to it, but that sounds like a Big Job(tm) that is thoroughly UnSexy(tm) and Thankless(tm).
Neokernsec
 
Posts: 16
Joined: Sun Dec 30, 2012 8:53 am

Re: How to build a paxctl (or chpax) for other ABI's ELF fil

Postby PaX Team » Sun Feb 22, 2015 4:59 am

the quickest approach is definitely to replace mmap/munmap with malloc/read/write/close or so. fixing up the endian-sensitive accesses is a whole lot more work (perhaps a gcc plugin one day to automate it ;)).
PaX Team
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm


Return to grsecurity development