www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Warnings / Compiler switch for secure programming

reply Matthias Walter <walter mail.math.uni-magdeburg.de> writes:
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
Mar 23 2007
next sibling parent Alexander Panek <a.panek brainsware.org> writes:
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
Mar 23 2007
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
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
Mar 23 2007
prev sibling parent Gregor Richards <Richards codu.org> writes:
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
Mar 23 2007