Any sane attacker in that scenario won't try gaining root at all, they will quietly steal the data that the compromised service has access to (and, assuming it has any value at all, sell it on black market). A custom exploit has to be profitable in some way and I don't see why anyone would bother.The scenario I am trying to address with shared object permissions is when a service implemented in a scripting language (ie: python, js, etc) becomes exploited. Scripting languages could easily be used to dump/analyze ELF files in the system to gain the knowledge needed to correctly build an exploit targeting another vulnerability in the system for proper privilege escalation.
Excuse my brevity: I mean x86_64In your case the next problem will be that X86 support is phased out almost everywhere.
Wait, you are now going to change the opcodes? Are you going to change the instruction set and architecture too?Will you know how to correctly interact with the CPU registers if all the ISA opcodes have been randomly reassigned? MOV is ADD, ADD is MUL, PUSH is POP, RETN is DIV...
*raises finger* That was me in that crowd there. Only here it was sunk by politics, not Research.Folks that were working on the edge between traditional CPUs and programmable chips (such as FPGAs) were thinking this would be the solution to many efficiency problems.
I have only seen that implemented in assembly, which could still be handled gracefuly. Have you seen cases of actual machine code being implemented as a byte array within the FreeBSD tree?How many places are instructions "hard-coded" in programs (not emitted by the compiler)?
No, not within FreeBSD. I've seen it done in error handlers: You catch an error, look at the PC where the machine check was raised, and hand-decode the instruction to find out what it attempted to do. On a CISC machine, that is typically quite simple, as you only need to decode the instruction partially. This was in a commercial file system, not an open-source product.I have only seen that implemented in assembly, which could still be handled gracefuly. Have you seen cases of actual machine code being implemented as a byte array within the FreeBSD tree?
This sounds very very similar to what we did in 2003 for a startup (I was a co-founder). Filed a bunch of patents too, to cover a variety of techniques. Your problem is much simpler than ours since you have control over the compiler chain & the OS!This is a solution to prevent code injection on a server environment. To be specific, all of the ~500 system call numbers are randomly reassigned for each machine in the fleet. If statically linked code is successfully injected into the system via a memory exploit, for instance, the attacker will not even be able to call malloc or fopen reliably
We did this in our Unix V7 based workstation (1981-82 timeframe). Using this scheme we were able to read/write four 9600 baud terminals at full speed (this on a 5.6Mhz Moto 68K & no-cache then! Memory access was 4 cycles or about 1.4M 16 bit words/sec). This was too fast for people to read scrolling output so we ended up putting in page-mode in the tty line-discipline to pause every N lines!We pre-compiled code, stored it in the C source as an array of bytes, hand-patched it to have the correct constants and address offsets in the instruction stream, and then executed it.