• Matthias Walter (7/7) Mar 23 2007 I've read somewhere, that one can also use alloca() in D, which can be i...
• Alexander Panek (12/12) Mar 23 2007 Hello Matthias,
• Sean Kelly (12/15) Mar 23 2007 Personally, this is something I hate about VC 2005. I feel like it's
• Gregor Richards (10/21) Mar 23 2007 1) alloca is as insecure as the programmer is incompetent. If you choose...

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

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

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

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