C language > Beginner questions

Where to look up info for using C with win32 API?

<< < (2/2)

jj2007:

--- Quote from: frankie on April 18, 2017, 09:48:23 AM ---Yes the old buffer overflow, the real Achille's heel of C, has almost disappeared in its traditional form (see the return attack)
--- End quote ---


--- Quote ---A “return-to-libc” attack is a computer security attack usually starting with a buffer overflow
--- End quote ---

Buffer overflows will always remain a mystery to me. IMHO such attacks start with an incompetent coder 8)

Vortex:
Hi frankie,

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.

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.

frankie:

--- Quote from: jj2007 on April 18, 2017, 05:55:54 PM ---Buffer overflows will always remain a mystery to me. IMHO such attacks start with an incompetent coder 8)

--- End quote ---
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 ! ;D
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.

--- Quote from: Vortex on April 18, 2017, 07:26:10 PM ---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.

--- End quote ---
Vortex the UEFI is exactly what helps the hypervisor exploit...  ;)


--- Quote from: Vortex on April 18, 2017, 07:26:10 PM ---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.

--- End quote ---
Yo're right, but they are trying another way, moving from hardware to software security enforcement.
From singularity description paper:

--- Quote ---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.
--- End quote ---

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...  :'(

Vannessa:
I have the same problem！it has helped me a lot，Thank everyone :D 

Navigation

[0] Message Index

[*] Previous page