Changing the runtime gid of the rtld linker

I'm most familiar with AMD's x86. Everything newer than K10 is encrypted in the AMD world. I don't know about anything else.
 
It is an interesting concept, certainly. I toyed with different approaches fur such "deploy and forget" things. And that was with the hands on the verilog source of most of the things involved. Without that, I would suggest something with a soft core and no bios (think oberon station,f.e.)

In your case the next problem will be that X86 support is phased out almost everywhere.
 
mrothfuss said:
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.
Click to expand...
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.
 
mrothfuss said:
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...
Click to expand...
Wait, you are now going to change the opcodes? Are you going to change the instruction set and architecture too?

I wonder what that does to testing. How do you know it doesn't introduce zillions of bizarre bugs? How many places are instructions "hard-coded" in programs (not emitted by the compiler)?

About a dozen years ago, there was lots of interesting work on CPUs that can change their instruction set dynamically, for example at process boundary. Example: one process is doing image processing, another database queries, and one XML decoding/encoding. They all should have different CPU architectures and instruction sets. 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. My neighbor was heavily involved in it, and for a while was CTO of Altera. Ultimately, I don't think it really went anywhere, except for pollinating many other ideas about how to build CPUs.
 
ralphbsz said:
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.
Click to expand...
*raises finger* That was me in that crowd there. Only here it was sunk by politics, not Research.
 
ralphbsz said:
How many places are instructions "hard-coded" in programs (not emitted by the compiler)?
Click to expand...
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?
 
mrothfuss said:
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?
Click to expand...
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.

The only other place I know with hand-coded instructions was something I mentioned here already: 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. It was in embedded code that was never shipped as a software product.
 
mrothfuss said:
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
Click to expand...
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!
 
ralphbsz said:
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.
Click to expand...
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!
 
You must log in or register to reply here.
Back
Top