Code Safety and The .Net CLR & Java Runtime
-
Apologies if this subject has already been discussed before. After stumbling upon last September's Best C# Article NET-CLR-Injection-Modify-IL-Code-during-Run-time and learning about endless security issues with the Java Runtime. Are these platforms actually safer than conventional compiled executables? Isn't the whole point of Data Execution Prevention (DEP) meant to stop run-time modification of running code? The CLR/JAVA Runtime engines have the only *native* code that DEP has any direct control of, but they are allowed to run without question, because of some dubious assumption that code for a virtual cpu/machine can do no real damage. Maybe I'm wrong, but I can't help thinking that code under direct control of the 'real' cpu is safer than these virtualized runtime environments. :suss: I'm not fully versed in .NET or Java coding. Anyone care to shed more light on the subject.
-
Apologies if this subject has already been discussed before. After stumbling upon last September's Best C# Article NET-CLR-Injection-Modify-IL-Code-during-Run-time and learning about endless security issues with the Java Runtime. Are these platforms actually safer than conventional compiled executables? Isn't the whole point of Data Execution Prevention (DEP) meant to stop run-time modification of running code? The CLR/JAVA Runtime engines have the only *native* code that DEP has any direct control of, but they are allowed to run without question, because of some dubious assumption that code for a virtual cpu/machine can do no real damage. Maybe I'm wrong, but I can't help thinking that code under direct control of the 'real' cpu is safer than these virtualized runtime environments. :suss: I'm not fully versed in .NET or Java coding. Anyone care to shed more light on the subject.
dusty_dex wrote:
The CLR/JAVA Runtime are the only executable code DEP has any direct control of
Nope not true at all. It has full control over native code too. Also, don't forget that these runtimes are written in native code. Just as a point of interest, some CPU's have a hardware based DEP[^]
.-. |o,o| ,| \_\\=/\_ .-""-. ||/\_/\_\\\_\\ /\[\] \_ \_\\ |\_/|(\_)|\\\\ \_|\_o\_LII|\_ \\.\_./// / | ==== | \\ |\\\_/|"\` |\_| ==== |\_| |\_|\_| ||" || || |-|-| ||LI o || |\_|\_| ||'----'|| /\_/ \\\_\\ /\_\_| |\_\_\\ -
dusty_dex wrote:
The CLR/JAVA Runtime are the only executable code DEP has any direct control of
Nope not true at all. It has full control over native code too. Also, don't forget that these runtimes are written in native code. Just as a point of interest, some CPU's have a hardware based DEP[^]
.-. |o,o| ,| \_\\=/\_ .-""-. ||/\_/\_\\\_\\ /\[\] \_ \_\\ |\_/|(\_)|\\\\ \_|\_o\_LII|\_ \\.\_./// / | ==== | \\ |\\\_/|"\` |\_| ==== |\_| |\_|\_| ||" || || |-|-| ||LI o || |\_|\_| ||'----'|| /\_/ \\\_\\ /\_\_| |\_\_\\Sorry, my wording could have been clearer. :doh: [I've made a minor modification to the original post] I know that the DEP handles *all* native code, but that's what I was getting at. The runtimes are native code but I wanted to know whether the MSIL code/ Java Bytecode is kept in the dcache or icache along with native code. I thought native code, unless specifically marked as shared would otherwise be read-only and not modifiable at runtime. Which led me to wonder about the location .NET/Java bytecodes and the whole self-modifying code (code injection) problem, with the apparent side-stepping of DEP protection. :)
-
Apologies if this subject has already been discussed before. After stumbling upon last September's Best C# Article NET-CLR-Injection-Modify-IL-Code-during-Run-time and learning about endless security issues with the Java Runtime. Are these platforms actually safer than conventional compiled executables? Isn't the whole point of Data Execution Prevention (DEP) meant to stop run-time modification of running code? The CLR/JAVA Runtime engines have the only *native* code that DEP has any direct control of, but they are allowed to run without question, because of some dubious assumption that code for a virtual cpu/machine can do no real damage. Maybe I'm wrong, but I can't help thinking that code under direct control of the 'real' cpu is safer than these virtualized runtime environments. :suss: I'm not fully versed in .NET or Java coding. Anyone care to shed more light on the subject.
Wrong forum.
-
Wrong forum.