Follow us on Twitter at http://twitter.com/blogCACM
The Communications Web site, http://cacm.acm.org,
features more than a dozen bloggers in the BLOG@CACM
community. In each issue of Communications, we’ll publish
selected posts or excerpts.
The problem is particularly acute
in object-oriented programming languages, where x.f is the major computational mechanism. Every single
execution of this construct (how
many billions of them occurred in
running programs around the world
since you started reading this?)
faces that risk. Compilers for many
languages catch other errors of a
similar nature—particularly type
errors, such as assigning the wrong
kind of value to a variable—but they
do nothing about prohibiting null
This fundamental brittleness threat-
ens the execution of most programs
running today. Calling it a “billion-
dollar mistake” as Tony Hoare did1 is
not an exaggeration. In his recent Ph. D.
thesis2, Alexander Kogtenkov surveyed
the null-pointer-derefencing bugs in
the Common Vulnerabilities and Expo-
sures (CVE) database, the reference re-
pository of information about Internet
attacks. The resulting chart, showing
the numbers per year, is edifying:
Beyond the numbers stand real ex-
amples, often hair-raising. The descrip-
tion of vulnerability CVE-2016-9113
( http://bit.ly/2mafdkJ) states:
There is a NULL pointer dereference in function imagetobmp of
convertbmp.c:980 of OpenJPEG 2. 1. 2.
image->comps.data is not assigned a
value after initialization(NULL). Impact
is Denial of Service.
Yes, that is for the JPEG standard.
Try not think of it when you upload
your latest pictures. Just for one month
(November 2016), the CVE database
contains null pointer vulnerabilities
affecting products of the Gotha of the
IT industry, from Google (http://bit.
ly/2mfdAD2) and Microsoft (http://
bit.ly/2muJImD) (“theoretically everyone could crash a server with just a single specifically crafted packet”) to Red
Hat ( http://red.ht/2lXB5xS) and Cisco
( http://bit.ly/2mMcueo). The entry
for an NVIDIA example (at http://bit.
For the NVIDIA Quadro, NVS, and Ge-Force products, NVIDIA Windows GPU
Display Driver R340 before 342.00 and
R375 before 375.63 contains a vulnerability in the kernel mode layer (
nvldd-mkm.sys) handler where a NULL pointer
dereference caused by invalid user input
may lead to denial of service or potential
escalation of privileges.
We keep hearing complaints that
“the Internet was not designed with
security in mind.” What if the problem
had far less to do with the design (TCP/
IP is brilliant) than with the languages
that people use to write tools implementing these protocols?
In Eiffel, we decided that the situation was no longer tolerable. After
the language had eradicated unsafe
casts through the type system, memory
December 20, 2016
As an earlier article5 emphasized, code matters; so do programming languages. While Eiffel is best
known for its Design by Contract techniques, they are only part of a systematic
design all focused on enabling developers to realize the best of their abilities—
and eradicate from their code the sources of crashes and buggy behavior.
Talking about sources of crashes,
one of the principal plagues of modern
programs is null-pointer dereferencing.
This term denotes what happens when
you call x.f, meaning apply f (a field access or an operation) to the object that x
references. If you want to define meaningful data structures, you need to allow
“null,” also known as Nil and Void, as
one of the possible values for reference
variables (for example, to terminate
linked structures: the “next” field of the
last list element must be null, to indicate there is no next element). But then
you should make sure that x.f never gets
called for null x, since there is in that
case no object to which we can apply f.
Void safety, says Bertrand Meyer, relies on
type declarations and static analysis.
DOI: 10.1145/3057284 http://cacm.acm.org/blogs/blog-cacm