<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 19, 2019 at 11:26 AM Peter Gutmann <<a href="mailto:pgut001@cs.auckland.ac.nz">pgut001@cs.auckland.ac.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Phillip Hallam-Baker <<a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a>> writes:<br>
<br>
>Stop using C/C++, use Java, C# or any modern language that has array bounds<br>
>checking built in and 99% of the current attack vectors are shut immediately.<br>
<br>
s/current attack vectors are shut immediately/<br>
  C-specific attack vectors change to Java-specific attack vectors immediately/<br>
<br>
Switching from $language_1 to $language_2 just means that all the attacks<br>
specific to language_1 are swapped for ones from language_2.  A few years ago<br>
(not sure what the current stats are but I assume it hasn't changed that much)<br>
Java was the second-biggest source of 0day after Flash, which I'm not sure<br>
it's actually possible to beat in terms of security vulns... well, WordPress<br>
perhaps.  In particular, a lot of the Java vulns are in the JVM and similar,<br>
which is an attack vector that doesn't even exist in C.<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div></div></div>