Yes - but the basic technique of separating executable code from control values and manipulated data is not enforced when the exe's etc are created by combining the sub-modules, nor is it enforced by the OS and processors on PC's
JimB ----- Original Message ----- From: "Marc Sims" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, January 06, 2006 6:11 PM Subject: Re: WMF security patch released Microsoft developers develope the patches using managed code in one of many languages including C# based on the CLR (Common Language Runtime) model in the .NET Platform in Visual Studio.NET. The languages all share a common unified set of class libraries that can be encoded into IL (Intermediate Language). A runtime-aware compiler compiles the IL into native executable code within a managed execution environment that ensures type safety, array bound and index checking, exception handling, and garbage collection. Using managed code tends to be secure becuase managed code can't be reversed engineered so easily unlike that of p-code becuase the managed code is obuscated (encrypted). Programmers can avoid the many mistakes that they make in using unmanged code like incorrect type casting, out of bound errors and not deleting unused objects correctly from memory by not using Object.delete() method template (garbage cleanup). This managed code use in Microsoft .Net Framework allows developers using Managed code to spend much less time in worrying about non-logical issues and focus on the managed code security methods and best practices using fewer lines of code with .NET Framework than they ever could using the method that mainframe and assembly programmers used over 30 years ago. Marc Sims Data Technician I Prince George's Community College >>> [EMAIL PROTECTED] Friday, January 06, 2006 >>> Sorry to have to disagree somewhat Microsoft need to code and assemble their executable modules in a properly secure manner Most of the current software is written as sub-modules which are then assembled into an executable set for distribution, but that distributable file then contains intermixed blocks of code data and workingspace buffers Then when loaded into memory, a similar process happens What is needed is for the technique used 30 years ago in mainframes to be adopted. modules created in at least 4 distinct sections, and those sections handled differently by the OS program loader, and the CPU Part 1 - code, and constants loaded into memory, and cannot be changed Part 2 - working control data loaded into memory and can only be changed by the code Part 3 - inter-program communication areas for passing on data and API requests - code will not be executed from this area Part 4 - buffer and storage areas - allocated by the OS - code will not be executed from this area Each sub-module's parts will be assembled into 4 separate parts in any distributable dll, com, exe etc The 4 (or more) sections are managed separately by the hardware and only the stuff in the Part 1 can be processed as instructions And only the OS loader can put stuff into a memory area designated as a Part 1 zone NO BUFFER Exploits possible JimB -- ---------------------------------------- To unsubscribe, mailto: [EMAIL PROTECTED] Is your picture included in the Official Win-Home List Members Profiles Page? http://www.besteffort.com/winhome/Profiles.html If not, write to: [EMAIL PROTECTED] -- ---------------------------------------- To unsubscribe, mailto: [EMAIL PROTECTED] Is your picture included in the Official Win-Home List Members Profiles Page? http://www.besteffort.com/winhome/Profiles.html If not, write to: [EMAIL PROTECTED]
