-
October 23rd, 2014, 01:43 PM
#1
The techniques to guard buffers against overflows.
Hi there, my Friends.
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.
-
October 25th, 2014, 03:03 PM
#2
Re: The techniques to guard buffers against overflows.
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
-
October 25th, 2014, 03:19 PM
#3
Re: The techniques to guard buffers against overflows.
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 check out the problems stack/heap overflow, that's all about buffer overflow. it has pounded C/C++ & c-like languages for decades.
-
October 27th, 2014, 08:55 AM
#4
Re: The techniques to guard buffers against overflows.
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 ) ...
-
October 27th, 2014, 09:20 AM
#5
Re: The techniques to guard buffers against overflows.
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
-
October 28th, 2014, 02:56 PM
#6
Re: The techniques to guard buffers against overflows.
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.
-
October 29th, 2014, 06:12 PM
#7
Re: The techniques to guard buffers against overflows.
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
Last edited by S@rK0Y; October 29th, 2014 at 06:15 PM.
Tags for this Thread
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|