Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 8 Oct 2014 15:48:10 -0700
From: Tim <>
Subject: Re: Thoughts on Shellshock and beyond

> I don't really want to get in the super-existential debate about code
> vs data; I fully recognize that I'm gonna be in the minority on the
> list, and maybe even in the wrong, but I just can't get too passionate
> about this "best practice", having seen how few systems are (or can
> be) designed with it in mind; and how little of a difference it makes
> to them in the end.

I don't want a big debate either.  We're all busy.  We work in
security, afterall.

> In a pragmatic sense, it's just that almost *everything* violates it.
> The CPUs we use, the memory allocators we have running on them, all
> the popular progamming languages and web frameworks. We still need to
> secure these systems, rather than saying "oh well, you should have
> done it differently from the start" =)

Well, I guess, but the way you're interpreting this separation of
code/data and the way that I am is clearly different.  Which means we
should perhaps refine how such a broad concept is stated.  There are
clearly cases where separation is  practical, non-destructive, and
beneficial for security.  There are cases that are grey area.  And
there are cases where there's no way around mixing, because
computation is computation.

For the naive developer, how would you characterize this in a

> Sure. I'm not entirely convinced what the lessons are, though. I mean,
> you expect the next big issue in OpenSSL or Apache. You can probably
> even guess what it may be. You can maybe even make an intelligent
> guess about the language features or coding patterns that will
> contribute to it, or to learn from past bugs. With the bash bug... hm.

To me, it's not about anticipating the next bug, it is about providing
guidance to developers who care only so much about security so that we
can avoid some bugs that we didn't anticipate. 


PS- I'm of two minds on this.  More recently I've decided that educating
    developers isn't nearly as effective as providing developers APIs and
    development environments that make it unlikely they will shoot
    themselves in the foot.  It's not that developers can't be trained,
    it is that they will probably only be developers for a handful of 
    years and move on to other roles later, with a whole new batch of
    green coders coming in to fill their positions.  Anyway...

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.