Mailing List Archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tlug] Chasing the GHOST in my machine



Yes, type safety protects you from buffer overflows.

This is so because in a type safe language a buffer is never untyped and the type determines the boundaries. If the index or range in which a read or write is to be made can be determined during compile time then any attempt to read or write outside the type's boundaries will cause a compile time error and no executable code will be generated. If the index or range in which a read or write is to be made cannot be determined during compile time then the compiler inserts a runtime boundary check into the code. Any attempt to read or write outside a type's boundaries is then caught at runtime. You cannot have type safety without boundary checks, any language that purports to be type safe but doesn't maintain boundary information as part of the type  is mislabeled. Likewise if it does maintain the information but doesn't act upon it.



On 31 January 2015 at 21:22, Josh Glover <jmglov@example.com> wrote:
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

--
To unsubscribe from this mailing list,
please see the instructions at http://lists.tlug.jp/list.html

The TLUG mailing list is hosted by ASAHI Net, provider of mobile and
fixed broadband Internet services to individuals and corporations.
Visit ASAHI Net's English-language Web page: http://asahi-net.jp/en/


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links