I've read somewhere, that one can also use alloca() in D, which can be insecure, as it can lead to an exploitable stack overflow, if the amount of data to allocate can be controlled by the user. at least in most implementations. (i've seen a talk, where it was said, GCC's implementation is exploitable, too!)

Another thing is writefln() stuff, as it is also error-prone, if the format-stri
ng is not fixed. (it is in most cases, but if not, that's dangerous)

Maybe one could add compiler-flags, which activate warnings about possible insec ure programming in these cases.

Just an idea :)

Matthias

Hello Matthias,

I think there have been discussions about such kind of switches. Yet, there's actually no reason for not allowing "insecure" (as in: C-like) code. It's not a bug, it's a real feature, to stay compatible to C! And yes, this also implies manual memory management with malloc & friends, as those are meant to be used within time/speed-critical applications (e.g.: games [not so critical, but it's appreciated to have a game running with low latency]) and applications with lots of managed memory. There are approaches with memory pools in that regard, though I don't know if they are open source or available anywhere.

Kind regards,
Alex

Matthias Walter wrote:
> 
> Maybe one could add compiler-flags, which activate warnings about possible insec
> ure programming in these cases.

Personally, this is something I hate about VC 2005.  I feel like it's suggesting that any use of functions without range checking is inherently wrong, and that programmers are idiots who need such reminders to write correct code.  I won't dispute that this does seem to be a common cause of bugs in some companies (such as Microsoft), but I do not believe it is the compiler's job to dictate programming style to the world.

This job is better suited to a style checker that can be loaded with a custom set of rules for each project, and I would expect a restricted function list to be just one facet of its validation mechanism.


Sean

Matthias Walter wrote:
> I've read somewhere, that one can also use alloca() in D, which can be insecure, as it can lead to an exploitable stack overflow, if the amount of data to allocate can be controlled by the user. at least in most implementations. (i've seen a talk, where it was said, GCC's implementation is exploitable, too!)
> 
> Another thing is writefln() stuff, as it is also error-prone, if the format-stri
> ng is not fixed. (it is in most cases, but if not, that's dangerous)
> 
> Maybe one could add compiler-flags, which activate warnings about possible insec
> ure programming in these cases.
> 
> Just an idea :)
> 
> Matthias

1) alloca is as insecure as the programmer is incompetent. If you choose to copy input into it willy-nilly with no regard for the buffer size, that's your problem.
Your comment that GCC's implementation of alloca is also insecure is irrelevent: alloca by its very definition is vulnerable to stack overflow attacks, there's no such thing as a "secure" implementation.

2) writefln uses D-style varargs, D-style varargs are fairly difficult to use in an insecure way.

 - Gregor Richards