[Cryptography] Questions of taste on UDF presentation

[Phillip Hallam-Baker]

On Tue, Feb 19, 2019 at 11:26 AM Peter Gutmann <pgut001 at cs.auckland.ac.nz>
wrote:

> Phillip Hallam-Baker <phill at hallambaker.com> writes:
>
> >Stop using C/C++, use Java, C# or any modern language that has array
> bounds
> >checking built in and 99% of the current attack vectors are shut
> immediately.
>
> s/current attack vectors are shut immediately/
>   C-specific attack vectors change to Java-specific attack vectors
> immediately/
>
> Switching from $language_1 to $language_2 just means that all the attacks
> specific to language_1 are swapped for ones from language_2.  A few years
> ago
> (not sure what the current stats are but I assume it hasn't changed that
> much)
> Java was the second-biggest source of 0day after Flash, which I'm not sure
> it's actually possible to beat in terms of security vulns... well,
> WordPress
> perhaps.  In particular, a lot of the Java vulns are in the JVM and
> similar,
> which is an attack vector that doesn't even exist in C.
>

While this is true, it is also true that array bounds checking is a
particularly egregious hole. My college tutor was so concerned about the
security implications of dropping bounds checks that he made them the
subject of his Turing award acceptance speech.

The Java VM is written in C of course, as are most VMs. So it isn't a new
set of vulnerabilities, it is the old vulnerabilities at a higher level
plus some reinventions of the old ones at a different layer of abstraction.

Writing C does not have to mean insecure though. If you use the right set
of macros, you can implement memory management and array bounds checking.
We did this in the CERN libwww, every string manipulation used a macro that
did allocation checks.

At root, any exploit has to affect program control. That means that it has
to manipulate the program counter in some way. Now it is quite possible
that my approach does not close every crack. But I think we can do a lot
better than leaving the front door (buffer overrun) open and the backdoor
(scripting language injection) open.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20190219/6479c7fd/attachment.html>