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