Buffer overflows will always remain a mystery to me. IMHO such attacks start with an incompetent coder 
Hello JJ.
Of course there is also some programmer incompetence for a BO exploit, but it is a natural product of the C language habit to make a promiscuous use of the stack for data and return address. This indeed is the base for at least 2 important characteristics of C language: the variable number of arguments and the code reentrancy (recursion). Put this together with missing protections of memory access (read execute code in stack or data area) and you'll get an explosive mix ready to blast even with the best care you can take in your coding.
To contrast the traditional BO (return address overwrite and code injection) has been developed countermeasures, HW and SW. The DPE (Data Prevention Execution) enforce memory access control in HW and SW using the NX/XD (Intel/AMD) bit in paging tables to block code execution on that memory.
In this case you cannot execute code in stack space, but you can still override return address. This could help hackers by loading address of a routine hidden in other code, a DLL or other static code. That code have loaded in an executable memory area and the CPU will have no problems to execute it.
Then they introduced the Address space layout randomization (ASLR) to make more difficult for attackers to know where the malicious code was loaded.
Then again more difficult to inject code, but not enough to detect address of some standard libraries which code can be used in chunks. This is the so called
return attack, it consist in the use of pieces of existing code, tipically in runtime libraries. The attacker isolates pieces of code that performs the wanted instructions and ends with a return instruction. injecting on the stack an array of malicious return addresses, each pointing to an instruction block, the processor will jump between all of them returning to the stack to fetch the next return address that will drive it to another instruction.
Then another idea to prevent attacks was introduced: sandbox the whole OS and it applications through virtualization. Practically create a protected environment where the OS and applications can run under an higher level SW, called
Hypervisor, that can control each instruction and behavior under it. This technique is used by the majority of the available virtual machines.
Only problem, especially on the IAPX32 platform, is that much unprivileged operations can trouble virtualization exposing processor privilege level to user code. A trial solution was found trapping the offending instructions and reproducing them in software concealing the processor privilege level bits. This solution could work for uncommon instructions that are supposed to be very rarely used, but the whole system could slowdown if you have to trace the very common
MOV instruction. Yes you understood well, who works with assembler knows that using MOV on segment registers in protected mode expose the processor privilege level bits. In this case a virtualized OS will detect that it is running at user level and fail.
Once again the hardware was tweeked to introduce the virtual-machine extensions (VMX) that take care of the problematic 18 instructions only when needed trapping execution when required.
But once again this solution opened another door to attackers: the first one that gain control over the virtualization can control everything !
He can virtualize the whole machine OS!!!
This bug affected even Apple desktops (and are included in hacking kits revealed on wikileaks) where connecting a ROMMED device (the ROM holds the code) could allow the loading of malicious code before running OS.
The UEFI is a useless and bad design to make more difficult the life of Linux users. And not to forget that new BCD based boot loader crap. Here is where UNIX\Linux are excelling, everything in simple plain text files. Just let's consider how UEFI makes unusable the good grub4dos loader. Of course, those giant tech companies would not be "satisfied" with simple designs better than complicated ones.
Vortex the UEFI is exactly what helps the hypervisor exploit...
The problem is that managed code gained a lot of popularity and the .NET crap consuming a lot of system resources is already a part of the latest Windows releases.
Yo're right, but they are trying another way, moving from hardware to software security enforcement.
From
singularity description paper:
The Singularity project started in 2003 to re-examine the design decisions and increasingly obvious shortcomings of existing systems and software stacks.
These shortcomings include: widespread security vulnerabilities; unexpected interactions among applications; failures caused by errant extensions, plug-ins, and drivers, and a perceived lack of robustness.
We believe that many of these problems are attributable to systems that have not evolved far beyond the computer architectures and programming languages of the 1960’s and 1970’s. The computing environment of that period was very different from today.
My personal conclusions:
- Each time someone enforced a technique to increase software security someone else found an hole.
- Each time a software technique seemed working it slowed the system and hardware was called to help.
- Any hardware modification introduced potentially another hole in security.
- A lot of processor power is lost in control over control, the processor consume energy, the environment is at danger...
