No static buffers. All buffers declared in a static fashion should be replaced by run-time dynamic buffers of the same size. This way all data objects are managed by malloc. This creates a slight performance hit, but not much. This alone nearly eliminates the possibility of buffer overflows resulting in execution because arrays are never on the stack.
This will only stop you from executing code on the stack (the typical 'stack smashing' attacks), your problem now become heap overflows, vulnerabilities where one malloc'd buffer overruns into the next chunk, overwriting management information. When free() is called, the pointers in the management header of the block can be made to do interesting things.
In the classic buffer overflow, the 'buffer' is merely used as a storage space for the arbitrary code -- this is not a requirement, the attacker can store his code in an environment variable, or perhaps even just overwrite important data that is used elsewhere in the programs logic (pointers, function pointers, authentication flags etc etc, use your imagination).
Bounds checking can be difficult, imagine a seemingly safe routine where the coder uses strncat in a loop to add to the end of a buffer, at first glance, the code seems safe since it uses a 'safe' function, however what if the coder neglects to recalculate the last parameter to strncat in each loop iteration (it should reflect the amount of space REMAINING in the buffer, not the actual size of the buffer), you straight away have a buffer overflow here.
The only way to solve this problem is to *teach* coders how to write proper code. Any code branch where user supplied input is processed should be subjected to extremely rigorous sanity checking, preferably through a white list of 'allowed input' rather than a blacklist of 'disallowed input'
Think of this as analogous to firewall rule writing 'that which is not expressly allowed is disallowed' is much safer than 'that which is not expressly disallowed is allowed'.
This is definetely a step in the right direction given the scope for using OSS especially GNU/Linux in a country like India. Microsoft has not done enough to improve its locale support for India, which has one of the largest and fastest growing IT sectors.
As an example of how useful this would be, I used to be a technical consultant and trainer to the Mumbai Cyber Crime Lab. Most of the officers I trained there speak only Marathi, a language spoken in Maharashtra. Their acceptance of information technology would be much better if the operating system was in their own language.
Given that these are all people starting fresh out with computers, they would probably also find it easier to accept an alternate o/s such as GNU/Linux, as opposed to someone who had been weened on Windows.
Wow.. talk about someone with narrow vision. Get a life, read up about Indian culture -- and maybe you'll understand that you live in a *very* small fishbowl my friend.
Slashdot Mirror
fp couldn't resist.
--Sahir
As an example of how useful this would be, I used to be a technical consultant and trainer to the Mumbai Cyber Crime Lab. Most of the officers I trained there speak only Marathi, a language spoken in Maharashtra. Their acceptance of information technology would be much better if the operating system was in their own language.
Given that these are all people starting fresh out with computers, they would probably also find it easier to accept an alternate o/s such as GNU/Linux, as opposed to someone who had been weened on Windows.
Wow.. talk about someone with narrow vision. Get a life, read up about Indian culture -- and maybe you'll understand that you live in a *very* small fishbowl my friend.