Well the blog post said that some other wisdom was conventional wisdom, I'm not sure what the conventional wisdom he was pointing to is, I was just saying, people have known how to build, grow and manage enterprises for a little while now, I'm not sure why Ron Conway was so flabbergasted. Maybe he didn't make notes because he'd read some Patrick Lencioni. ;)
That doesn't say anything like that Lisp knowledge could have prevented the attacks. It does say that reasoning similar to reasoning about computer systems security could have led to better aircraft security.
The code/data rhetoric is not exclusively an earmark of Lisp. A primary concern in security are situations in which what is intended to be data allows for a surprising malicious use whereby it effectively becomes a way to program behaviors into the software which processes the data.
For instance, Winamp being exploited by loading a specially crafted MP3 playlist file is an instance of data becoming code; no Lisp in sight. Code being a flipside of data, in the context of security, is simply the consequence of the Von Neumann model.
Graham is arguing for compartments; exactly why we use containers and such. The main idea is that the passenger cabin should be sandboxed away from the cockpit, which isn't earth-shattering.
Where he mentions Lisp is this:
> The defense that does work is to keep code and data in separate places. Then there is no way to compromise code by playing tricks with data. Garbage-collected languages like Perl and Lisp do this, and as a result are immune from buffer overflow attacks.
This point seems bungled. Garbage collection is no panacea. Bugs in a garbage collected run-time can expose applications to exploitable attacks. The advantage in Perl and Lisp is that the application programmer is not writing low-level buffer manipulation routines from scratch. That stuff is in the language run time, where we debug the low-level implementation code once, and have thousands of applications use the debugged thing. If a hole is found, we fix it once, and close the issue in thousands of apps once they upgrade to the new run-time.
Garbage collected languages do not necessarily keep code and data in separate places. Moreover, non-garbage-collected languages do that. The C language can easily be implemented in a conforming manner such that the data areas (automatic storage (a.k.a. stack) and dynamic (malloc) are not executable. C keeps code and data separate. Functions are not objects. In some C implementations, like certain DSP chips, functions are in a separate space; you cannot cast a function pointer to char * and access the function image, because the resulting pointer will be interpreted in a different memory area. Of course, C data can contain pointers to functions, which can be redirected if overwritten.
Lisp data can also contain function pointers: e.g. a closure object with a pointer to code and to an environment. If that is stored in a heap somewhere where an array is also stored, and the run-time has a bug which allows array overrun, it could perhaps be exploited.
as you know, though, there is a connection between this kind of security and garbage collection. specifically, if you're using a language that bounds-checks all array accesses, so array overruns are impossible, but relies on that same application programmer to free pointers manually, you can have a use-after-free bug, where a function pointer is written into heap space previously occupied by an array (or other data structure) to which a pointer still exists. if the attacker can cause writes to happen via that pointer, they can still break your security
garbage collection is a perfect guarantee against use-after-free bugs, unless of course the garbage collector is buggy. it's not the only possible solution; alternative solutions include statically allocating everything (abjuring dynamic allocation completely, like cobol), linear typing, never deallocating anything, and mlkit's region-based memory allocation are some alternatives which have been used. garbage collection is the most popular and probably the most practical
so it's not just that we have thousands of applications use the same debugged low-level buffer manipulation routines. it's also that we have thousands of applications use the same debugged garbage collector
i want to point out that even without having code and data in the same memory space, there are a variety of things an attacker may be able to do. when non-executable stacks, aslr, and w^x protections started being implemented, attackers started returning into libc; function pointers that point into the middle of libc would work just as well. (return-oriented programming might be more difficult, unless the thing being used-after-freeing was a large stack-allocated variable, which would be unusual.) and of course if there are shell commands, sql commands, java bytecode, or the like in data memory, overwriting them with malicious data may be just as good as uploading malicious machine code
aha, this is awesome! and indeed the solution he suggests (locking the cockpit door) is the only one of the various security measures put in place to prevent a recurrence that is generally agreed to have been effective rather than just security theater
i want to give pg a lot of credit for clear thinking here, but of course if he'd suggested locking cockpit doors in august 02001 instead of september, that would have been significantly more impressive
