Re: "Trust the OS" - If only it were that simple...
This exploit isn't about buffer overruns as such - that is where you throw too much data at a process and it overwrites executable code with whatever you threw at it. This exploit cannot be detected using memory bounds checking, because it is not violating any memory bound.
When an application allocates memory, this memory is in an "undefined" state. For a cold started system or a block of memory that has never been allocated yet, this memory is usually all zeroes, however there is no guarantee of even this. Hence "undefined".
This exploit allocates 64k of memory, which being "undefined" will generally contain whatever application or process last wrote. Due to deficiencies in the code one byte of memory is copied to this and the whole 64k of memory is returned. It's pot luck what is in this 64k block of memory, but keep on requesting memory and you will eventually get something interesting back.
There are various preventatives for this, such as zeroing the memory on allocation, but for a low level library this is inefficient and as the block of memory should have been overwritten entirely a pointless exercise in wasting processor time. Another is to zero the memory on de-allocation, again for many low level processes this is also inefficient as a relatively simple process could then take 20x longer to complete, multiply a low level task by the number of calls to it and the overall system impact could be disastrous. On the other hand, a code process that stores passwords and private keys should damn well clear the memory after use, but again this is an efficiency argument compared to what can be done on an otherwise "trusted" system.