The techniques to guard buffers against overflow.

In the 1980's when I programmed in Forth professionally, I created a package that implemented text strings manipulations.

The first byte contained the maximum length of the string buffer, and the second byte the actual length of the stored string. The string was stored immediately after these two bytes. Then I implemented routines like taking a substring of concatenating strings. I never had a string buffer overflow ;)
 
J65nko said:
In the 1980's when I programmed in Forth professionally, I created a package that implemented text strings manipulations.

The first byte contained the maximum length of the string buffer, and the second byte the actual length of the stored string. The string was stored immediately after these two bytes. Then I implemented routines like taking a substring of concatenating strings. I never had a string buffer overflow ;)
Click to expand...
Yes, it's the best format for strings plus it makes operations faster. However, strings aren't the only data to run into overflow troubles. Actually, I have developed a uniform solution against overflows and always have wondered why such schemes have not been implemented from the very start of IT. They are nothing extraordinary to take that long.
 
Actually, I would like to see the happy end of this funny and doleful story about overflow troubles. The bad side of my solution is, it takes a lot of legwork to re-write the bulk of all unsafe code. Meanwhile, here we can get in some kind of compromise: for instance, it seems quite workable to use so-called proxy daemons to perform ToRAs (table of right addresses) through them. In the original approach, it needs to pass the base address of an array to the writing function in order to calculate a safe length for operation. Classical codes use arbitrary addresses. So, a base address could be estimated as being the closest one from an arbitrary address to ToRA's record.

Let's say we have function write(char *src, char *dst) and ToRA consists of bases {0x12, 0x40, 0xA5B}. Thereby the proxy daemon takes dst (for example, 0x27) and tries it against records in ToRA. Then, in our case, the base will be taken at 0x12. Obviously, some binaries shall fail entirely because a developer may use bases that are too far far calculating offsets and/or bases from different directions. In other words, a developer could be a true anarchist with memory :D
 
You must log in or register to reply here.
Back
Top