At the risk of getting too technical, is it too much to ask that programs not store procedure redirection tables for shared library routines in writable memory, for applications running with privileged credentials? That an access violation is thrown when a process’ runtime registers are overwritten, or maybe that user definable data is never put in an area in memory where the runtime registers can be altered?

Ok, so that last case is a bit far fetched as the programmer is the only one that knows which memory will contain user supplied data, but the fact of the matter remains, if the OS is doing its job, none of these conditions should result in system compromise in the first place.

I mean sure the advent of Perl brought to light the concept of TMTOWTDI, and any hacker will tell you that the same holds true in vulnerability exploitation. This, however, doesn’t change the fact that the majority of system compromises are the result of the same old techniques be used to exploit the same types of vulnerabilities that have existed from the inception of the modern computing base.

The more startling realization one should come to at this point is that Operating System developers have had to use the crutch of PaX, grsecurity, and other system integrity validation software to “stop the bleeding” out of their own lack of motivation to redesign their memory management in a secure fashion themselves. Halvar Flake brought up an excellent point in one of his recent Daily Dave posts by saying the current Cisco IOS heap exploitation techniques are based around a single design flaw in the memory management. This is where 99.9999999% of software vulnerabilities that are widely exploited stem from [flaws in memory management].

Granted we live in a world where database contents need to be made available to publicly accessable web sites, which gives rise to input validation problems; and web-based CGI applications do need to be able to run external applications to support their functionalities, and these are problems which can not be solved at the OS level. The fact remains that, more often than not, a machine is made vulnerable by the design and implementation of its OS and shared libraries than it is by the ignorance and/or incompetence (in terms of secure practices) of the application programmers, system administrators, and end users.

With all that being said, and to summarize a very long and convoluted point here, the only way to mitigate the impact that PUVs have on system integrity is with modifications to the design and implementation of Operating Systems to prevent them from being useful.