background image
· 8 ·
· 11 ·
· 10 ·
in the 1930s, alonzo Church released
his theory of a formal mathematical
model (for expressing computation as
a system of functions and substitutions)
to the academic world in the form of
lambda calculus.
however, despite the beauty and elegance of lambda calculus, a
physical device that implemented it was impossible to build. it
wouldn't be until many years later, and through the research and
theories of Princeton fellows John von neumann and alan Turing,
that a device capable of digital computation would be built and
pressed into service.

now, just shy of a century later, we have advanced to the point
where we can implement the principles of lambda calculus
on stateful machines based on von neumann's architecture in
the form of functional programming. What allows these two,
fundamentally conflicting, models to work in harmony is layers of
programmatic abstraction -- abstraction that has long reached
the sophistication where we can run virtual machines on top of
physical ones and program in styles that fundamentally conflict
with the physical machine underneath. Without reasonable
abstractions, programmers would still be writing in binary and any
hope of manipulating the machine in a functional manner would
remain, just like the theory of lambda calculus, nothing more than
a thought exercise.
despite the importance of abstractions in computer science,
the stacking of system upon system to build new platforms
fundamentally clashes with one of the core principles of security-
conscious programming: minimising the potential attack surface
of the platform being developed. modern smartphone operating
systems are an excellent example of where it could be prudent
to question the merit of placing abstractions on top of each
other. The often cited `modern computer in your pocket' analogy
used to describe smartphones is not far off the mark. Android,
as an example, features a complete GnU/linux implementation,
including shell and traditional userland, that exist far below the
`Dalvik' virtual machine and APIs typically utilised by Android
application developers and core services. despite being very
capable, it is arguable that a smartphone platform does not
benefit from an operating system and userland designed for much
larger systems. The best case scenario is the unused features are
simply bloat, the worst case scenario is that they are used as a
vehicle for exploitation.

To give another example, prior to the BlackBerry 10 operating
system and devices, the operating system that ran on BlackBerry
phones was very tailored to the hardware, and to the planned
functionality of the phone. The result, was a platform that was
generally regarded as very secure, all while managing to retain a
reasonable feature set. Unfortunately BlackBerry 10, now based
on the QnX operating system, does not share its predecessors
reputation for security; one of the first documented exploits
(disclosed by SEC Consult) for BlackBerry 10 targeted the `find'
command-line utility that came with the QnX platform.
This raises the question of whether removing bloat and being
more conscious about building abstractions upon abstractions
should play a bigger role in the secure development lifecycle
process. if the answer to this question is yes, then it falls to each
development team's discretion of what is, and what is not, an
acceptable level of risk in regards to abstractions.

To conclude, it becomes our task as security professionals,
programmers, and computer scientists to start questioning the
merit of layered abstractions in system design. although building
on previously built foundations gives notions of stability and
security, we have to be careful not to end up with a tower of
blocks that is a mere tap away from collapsing.
It becomes our task as security professionals, programmers,
and computer scientists to
start questioning the merit of
layered abstractions in system design.
By Steven Holdway
de Monfort UnIverSIty
s T u d e n T s h o W C a s e