The techniques to guard buffers against overflows.

Hi there, my Friends. :D

here, i'd like to discuss the possible & the best techniques for subj. 1st & foremost, i would like to share my humble approach to protect buffers.

code: https://sourceforge.net/projects/dasofi
description: http://alg0z.blogspot.ru/2014/10/dabofi.html

perhaps, description seems too short, but i hope code is more verbose ;)
======================
Thanks a lot in Advance for your contribution.

Quote:

---

Originally Posted by S@rK0Y

here, i'd like to discuss the possible & the best techniques for subj.

---

Couldn't you start by explaining in simple words what problem you're solving.

The best way not to overflow a buffer must be to not overflow the buffer, isn't it :)

Quote:

---

Originally Posted by razzle

Couldn't you start by explaining in simple words what problem you're solving.

The best way not to overflow a buffer must be to not overflow the buffer, isn't it :)

---

your words are right for everything :rolleyes: check out the problems stack/heap overflow, that's all about buffer overflow. ;) it has pounded C/C++ & c-like languages for decades.

anyway, I think you should clarify your goal, that is, if we're dealing with buffer overflow from the code correctness pov ( ie, does *my* code have buffer overflow issues ? ) or from the security pov ( can an *attacker* exploit my code via a buffer overflow ? );

in the former case, ( at least in c++ ) we already have many ways of preventing such sources of undefined behavior at a higher level of abstraction, so, no, it does NOT pound c++ code anymore since decades.

in the latter case, I don't know ( I'm no expert of security issues, at least not to the extent of authoritatively suggesting anything in this regard ) ...

the problem is the programmer made assumptions that the buffer will be big enough, so he just uses the buffer pointer at will.

the solution.
a buffer also needs a size variable, and every write operation to the buffer needs to be checked if there's enough room remaining in the buffer

Quote:

---

Originally Posted by OReubens

the problem is the programmer made assumptions that the buffer will be big enough, so he just uses the buffer pointer at will.

the solution.
a buffer also needs a size variable, and every write operation to the buffer needs to be checked if there's enough room remaining in the buffer

---

that's exactly what DaBOFi does do. Actually, very question is to provide clear scheme of protection with lowest performance penalty of possible ones. DaBOFi deals w/ 3 parameters:

1. base of buffer (it's written in ToRA).
2. offset within buffer.
3. size of buffer (stored in metadata of buffer).
==============================
So, access Just to arbitrary address ain't acceptable.

Quote:

---

Originally Posted by superbonzo

anyway, I think you should clarify your goal, that is, if we're dealing with buffer overflow from the code correctness pov ( ie, does *my* code have buffer overflow issues ? ) or from the security pov ( can an *attacker* exploit my code via a buffer overflow ? );

in the former case, ( at least in c++ ) we already have many ways of preventing such sources of undefined behavior at a higher level of abstraction, so, no, it does NOT pound c++ code anymore since decades.

in the latter case, I don't know ( I'm no expert of security issues, at least not to the extent of authoritatively suggesting anything in this regard ) ...

---

in fact, w/o fully restricted bounds of buffers, you cannot avoid the problem entirely. For instance, canaries are useful to detect overflows. But such safe code ain't reliable because you just face overflows posteriori. Thereby you must reset spoiled process to prevent abnormal actions, that makes your code vulnerable for GBs (garbage bombs). DaBOFi allows to deal w/ reliable & safe architecture of memory + it has minimal performance penalty.

ASLR is yet another technique to fight versus OFs. it's quite efficient, only if ye have a lot of free VAs (virtual addresses). Otherwise intruder has a juicy chance to gamble there. + this technique makes machine slower & it's by itself serious issue for high-busy servers. + Frankly, static VAs for all stuff (vars, functions etc) are much better from the view of debugging, profiling & optimization as well.

NX bit (non-executed pages/VAs) is very controversial approach because function pointers are deployed in data areas & may be OFed to syscall for malware needs.

In short, the best of bests has been to obsolete OF-troubles from their very roots :D