[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOfWR+G6j3ki4q1SfFSMRm1OLWaOevqGcRiRobWa6dpgSXjPHg@mail.gmail.com>
Date: Tue, 14 Oct 2014 20:21:09 -0400
From: Robert Watson <robertcwatson1@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Thoughts on Shellshock and beyond
My first post so I'll keep it short...
I think dwheeler is right. Secure systems require secure practices, which
can be done in most any language. Some are just easier than others.
Having programmed on Unix/Linux since the mid-80s with everything from
COBOL to C, I have to say that most of it has been in shells like bash.
We haven't seen the last of shellshock. What created the vulnerability is
inappropriate use of a design pattern that has been a staple of Unix/Linux
"gurus" since the early days... writing programs that write programs.
Most awk programming is done this way. Awk is a Turing-complete interpreted
language that's exceptionally fast at pattern-matching. But usually, shell
scripts just feed it snippets of code for things where the scripting
language would be too slow.
Another example: As an Oracle DBA, most of my time was spent writing shell
scripts that generated extensive sqlplus (Oracle's commandline interpreter)
SQL scripts.
A DBA often needs to make changes like adding a timestamp field to every
table in a 400-table database on a system where, legally, downtime is not
an option. Too error-prone to do manually.
Every change was scripted and examined by several sets of eyes. It was
tested numerous times on a testing database. Only when perfected, was it
allowed to run on production.
Easily passing data from one program to become the code of another is a
required part of managing complex installations. Using C or some other
"formal" language is much more cumbersome and time-consuming.. Have done
that too...
Even after Y2K, we still ran a mainframe for certain legacy
functionalities. Changes there had to be coded in COBOL. Why do you think
it takes so many COBOL programmers to do anything? (there's got to be a
joke in there somewhere :-)
There are two main problems that led to shellshock...
1. Web developers thinking that the system would not allow users to do
anything except what there was explicit programming for.
Security in any Unix/Linux system (or derivatives) is not in any way
enforced by code. Security is enforced by ownership, groups, permissions
and optionally, by ACLs like SELinux or AppArmor.
It is not actually bash's job to limit access. That's the job of the
program that establishes the session, such as telnet, login, ssh, ftp and
... the program that manages http connections: the web server.
2. Misunderstanding the "flexible syntax" of bash. The PoC code line that
is now burned into our brains is not interpreted as a lot of people expect
it to be. The variable X is being set to a string containing 2 or more
distinct commands separated by semicolons which is then being executed...
just as it is supposed to be.
The documentation for this functionality is there, but you have to mentally
put together statements made in several different, unobvious places.(Not
good.)
The first command is the function definition, which deviates from expected
context due to the "clever hack" of creating a function from the variable
name. Subsequent commands follow the semicolon after the the function.
The subsequent commands are NOT executed by the function in the subshell
(bash -c ...). They are executed by the calling process (also bash in this
case).
Depending on race-conditions, complexity of the command and other factors,
their output may actually FOLLOW the output of the executing function.
( It's taken a good bit of experimentation and some involved bash coding to
verify this much. Still trying to find a practical technique to close the
vulnerability though. Maybe this tidbit will help someone more skilled than
I fashion a permanent solution for shellshock and the many other
code-injection vulnerabilities like it out there. )
("... keep it short": Oh well. Forget that. Sorry for being long winded.
Thoughtful disagreement enthusiastically invited.)
Robert
*Trust in truth keeps hope alive*
* <http://www.nationalpartnership.org/issues/health/HIT/>*
On Tue, Oct 14, 2014 at 5:45 PM, David A. Wheeler <dwheeler@...eeler.com>
wrote:
> On Wed, 15 Oct 2014 02:10:41 +0800, Pavel Labushev <
> pavel.labushev@...box.no> wrote:
> > By "Haskell" I mean any technology, its scientific basis and the
> > other aspects altogether, that I think have the potential of
> > significantly shifting the paradigm.
>
> A rose by any other name will smell as sweet, but calling it a
> "pig" inhibits communication. If you mean
> "significantly better tools", just say that. Or create a new name and
> define it.
>
>
> > I know that many would disagree and say that the devil is in the details.
>
> I'm one of those who disagrees. The devil, as well as the rest of the
> universe,
> *is* in the details. In particular, I think a lot of tools are hideously
> oversold,
> leading to serious problems. All tools have limitations; knowing those
> limitations
> is key to developing (more) secure software.
>
> That said, tools that make it *easy* to write secure code (or at least
> eliminate certain mistakes) often produce more secure code, simply because
> developers are people who make mistakes.
>
>
> > Imagine you're writing a shell and decide to introduce the high level
> > distinguished concepts of code, data, data source, and derive the
> > concepts of trusted|untrusted data|code [source].
>
> That might help, though that's simply *one* approach
> (among many) for stronger separation of code and data.
> What we need are examples of such approaches, and experimental data
> to show that they're really better.
>
> > > I don't think Haskell is a magic bullet. I do think type-rich
> > > languages (and languages with memory safety) have a lot to offer, but
> > > writing secure software in them is still hard.
> >
> > And I'm convinced that "Haskell", in a broader sense and together with
> > the other factors, is a part of a solution, capable of making a
> > qualitative change.
>
> I agree that better tools can be part of a solution, and in some cases
> (especially together) could produce a qualitative change.
>
> The most obvious example of an underused tool is memory-safe languages.
> Shellshock would not have been countered by them,
> but Heartbleed (and many others) *would* have been countered.
> But many people are not willing to pay the runtime costs, and the
> developer-retooling effort, to switch to a memory-safe language for
> low-level components like operating systems, runtimes, crypto libraries,
> image processing libraries, and the like. We *have* languages like Ada
> which run at the same speed as C, and other languages are relatively close
> (e.g., D, Go, Rust, Nimrod), but as yet there has
> been no big switch. For a variety of reasons, it's hard to change.
>
> --- David A. Wheeler
>
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.
