Discussion on avoiding security vulnerabilities in C++

BCS ao at pathlink.com
Thu Jul 12 17:08:30 PDT 2007


Reply to Lutger,

> Walter Bright wrote:
> 
>> http://www.matasano.com/log/914/c-a-cautionary-tale-or-1-hour-of-your
>> -black-hat-trip-is-spoken-for/
>> 
> Interesting post, particularly the comment about iterators. It raises
> the question what security related bug classes can be found in D and
> are to be aware of. I'm no expert on this matter at all but what comes
> to mind:
> 
> - inappropriate use of delegates (messing with the stack)
> - array slices / array bounds errors
> - inappropriate use of destructors (but probably not common)
> Or to put it another way, if D will get popular enough via what
> language constructs will software written in it most likely be
> exploited?
> 
> The garbage collector implementation may have some issues? But this is
> not part of the language I suppose. And the objection that bare-metal
> (pointers) access is possible is not that relevant imho, since 1) D is
> a systems programming language after all and 2) this feature is not
> something that is the default nor is it dressed up as in C++.
> 
> Any other concerns / thoughts / recommendations?
> 

Safe(er) delegate could be made by implicitly adding guards to stuff

this

|void fn()
|{
| void nested fn(){}
|
| void delegate() dg = &fn;
|}

becomes this

|void fn()
|{
| long now = CPUTime;
| struct Use
| {
|  long then
|  void* pt
|  void nested fn()
|  {
|   assert(now == then);
|
|   this = pt; // sudo code
|   goto _fn; // "
|
|  }
| }
| Use* u = new Use;
| u.then = now;
| u.pt = StakFrame;
| scope(exit) now = 0;
|
|
|
| void nested _fn(){}
|
| void delegate() dg = &u.fn;
|}

Replace delegates with function that do a chained call to the real thing 
after checking to see that a sentinel is correct.





More information about the Digitalmars-d mailing list