Re: [tlug] Chasing the GHOST in my machine

[Josh Glover <jmglov@example.com>]

On 30 January 2015 at 10:19, Benjamin Kowarsch <trijezdci@example.com> wrote:

> Let's not pretend there aren't any inherently safe systems out there,
> OpenVMS comes to mind.

I don't see how we're pretending anything. On what do you base your
claim that OpenVMS is inherently safe? I see 16 known vulnerabilities
in the CVE database for HP OpenVMS [1], of which four are privilege
escalations rising from buffer overflows. 16 reported vulnerabilities
in the last 10 years is spectacular, I grant you, but 16 is greater
than 0, and these are just the reported vulnerabilities. There is no
guarantee that no more vulnerabilities exist in the wild. Nor are
there any guarantees that all users patch their systems.

Apropos of this, I came across a really interesting set of slides for
a DefCon presentation on hacking OpenVMS. [2]

> In a world where there is no such discipline in the DNA, more restrictive
> tools are required, such as languages with very strict type regimes,
> compilers that always perform index checking and range checking and never
> allow you to turn it off unless for a debug build.

I think "type safety" is a bit of a misnomer. What are you safe from?
Runtime errors caused by such things as calling increment on a string.
How do types protect you from buffer overflows? I suppose a type
system like Haskell's, which gives you no ability to cast (to the best
of my knowledge, please correct me if I'm mistaken), would eliminate
buffer overflows in *your* program, but as soon as you start accepting
input from the outside world, you have to worry about the
implementation of the compiler and/or runtime of the language in which
your program is implemented. If you allow data to be written to
memory, there is always a chance that the computer can be tricked into
executing that data as instructions. Will you analyse the in-memory
representation of each of your types to ensure that none of that data
corresponds to instructions on each architecture, present and future,
on which your program might run?

I know that operating systems offer stack protection (and some
hardware does as well, right?), but many users don't enable it.

I fail to see how we can consider any system that accepts data to be
inherently secure. I think we must instead assume that all of our
systems are insecure, and preform cost / benefit analyses to determine
how much we care.

> Yet we continue to use the same old stuff that does little to nothing
> of the kind. All due to a testosterone driven culture of "because we can".

On this, we are most certainly agreed. Christina Lopes has a really
nice blog entry about this:

http://tagide.com/blog/2014/04/house-of-cards/

Cheers,
Josh

[1] http://www.cvedetails.com/vulnerability-list/vendor_id-10/product_id-4990/HP-Openvms.html
[2] https://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-oberg-nyberg-tusini.pdf