All Things Microsoft > Microsoft Software

Image File Execution Options

<< < (6/7) > >>

Aloone_Jonez:
The reason why most programs crash is because they're written in C or maybe even some parts assembly. With C it is possible to overdrive code with data and assembly is even worse. This is why I hat C and assembly, the only reason a program should crash is because it ends up in a continuous loop of a stack overflow. Not because the language allows a buffer overrun or pointer error to allow overwriting of code with date and eventual execution of data.

In my opinion a decent programming language should prevent this and to my knowledge Pascal, Basic, Python and Java all do. Hopefully the new 64-bit processors with their new hardware will prevent some of this buffer overun and data execution shit.

Orethrius:
Well really, if you can't figure out how to configure the compiler to treat overrides as errors rather than warnings ("forbid overrides" or whatever it may be), you don't belong anywhere near C.  :p

Aloone_Jonez:
To be honest I've never got that far I learned to program in Qbasic as many people did then moved on to assembly, and I tried pascal and it's ok, but I've nevcer fully got C. SO I suppose you're right. But there again what about all these buffer overrun exploits and why do most C programs crash if it isn't because of data bieng executed?

muzzy:
Pascal doesn't protect from buffer overruns, it's just more uncommon since people don't use pointers so commonly in pascal due to strong typing, builtin strings and range checking and stuff.

Also, Orethrius isn't apparently a programmer, or doesn't know what he's talking about. "forbid overrides" my ass, practically no C compilers have designs that prevent buffer overflows because it'd totally fscking kill all performance. Override isn't proper terminology in this context as well, and further suggests ignorance. Go ahead and prove me wrong, name even one compiler and a compiler flag for it that actually prevents buffer overflows.

muzzy:
Sorry about the above reply, I'm a little irritated, but the point remains. Neither of you seem to truly understand the issue.

Typically, buffer overflows don't overwrite code, they overwrite some important data. Program flow control is managed on the stack, in form of return addresses to points where functions were called. Local variables are also stored on stack, and a buffer that gets overflown on stack gets to overwrite the return addresses on stack. There you go, execution jumps to address of your choice. The traditional attack is to send code in the buffer, and then set execution to jump on stack one way or another. Usually there are bytes somewhere in the application that form a jump to stack, so such a position makes great return address. After that, the execution practically goes to the buffer you just sent, and data gets executed. HOWEVER, it's not necessary to jump there! Buffer overflow can still be extremely dangerous even without data execution. Imagine your application has a code that kills some files, databases, or any cleanup that prompts user if he's really sure. Place the return address right after the prompt has been checked, to where actual work gets done, and the buffer overflow will result is serious damage that NX-flags and such can't prevent. Yay!

The above mentioned stack buffer overflow isn't the only form of buffer overflow, a lot of variations exist. Basically, when attacker gets to overwrite some critical data in unexpected way, there is risk of program flow getting fucked up. Now, memory corruption bugs aren't limited to mere buffer overflows, and C has plenty of them. The very way pointers are defined in C invites compiler writers to implement them in a rather vulnerable fashion. Together with the CPUs being such wimps and raw devices, there's a serious problem. The problem can be solved on language level, but it could also be solved on compiler level, and definitely on CPU level. Designing better languages is the most practical way to approach the problem since you can't really change the CPU.

Microsoft's .NET takes approach at this by defining a virtual execution platform, in a form of bytecode, that things get compiled to. On this level, you can have a VM (kinda virtual cpu) level protection, compiler level protection, and language level protection. All of them, and they're all fscking implemented as well. How's that for security?

Navigation

[0] Message Index

[#] Next page

[*] Previous page