[PLUG-TALK] Exploitable Bug in a Programming Language?
wes
plug at the-wes.com
Tue May 31 19:49:46 UTC 2016
On Tue, May 31, 2016 at 12:23 PM, Rich Shepard <rshepard at appl-ecosys.com>
wrote:
> On Tue, 31 May 2016, Michael Rasmussen wrote:
>
> > Languages are used to express the intent of the programmer/speaker. It's
> > not the language, it's the programming expression of the writer(s). The
> > more complex the expression/program the greater potential for unintended,
> > unforeseen, unimagined, actions when unanticipated conditions occur.
>
> That's what I wrote. A coder could unintentionally include a
> vulnerability, but Brian's post suggested it was the Java language itself
> that was vulnerable. And I asked how a programming language could, itself,
> lead to an exploitable flaw.
>
Programming languages are not special in relation to other components of a
computer system. They were created by mortals, who make mistakes, some of
which are simply not foreseeing what a particular thing could be used for
in the future. I don't have any specific real-world examples for you (also
I am not a programmer), but I can construct a plausible scenario which
fulfills your specific requirement: a way that a programming language
itself _could_ be a vulnerability.
Part of programming is manipulating data. There are countless ways to do
this, each one works slightly differently from its neighbor. The simplest
example is perhaps a string stored in a variable. What if this particular
language or compiler can't handle variables over a particular size? Say,
for example, 2147483647 bytes. If I stuff 2147483648 bytes into a variable,
let's just for the sake of example say, the extra byte gets shuffled into
the beginning of the next variable that gets used. In most cases, this
would cause trivial errors, but from here it should be very easy to imagine
a scenario where it turns into a very serious problem. If I supply this in
a username field, and let's say the application's next variable is to load
the password from the password file before it loads the user's supplied
password, the app will then compare the user-supplied password with the
overflow from the username field. Ok, for this to work, we will also have
to have arbitrary limits on the number of characters each field can be, and
the app would have to enforce this by only reading the first x number of
characters from each input field, during the comparison phase.
Does this seem way too specific to ever be a real thing? Just look at that
price tag - $90,000. That's more than I make in a year, so it would make
sense to hunt for these vulnerabilities as a full time job. Who out there
gets paid this much by software vendors to find these? Nobody, that's who.
There are some who do it part time, maybe the coders themselves are
expected to spend some percentage of their time on it, but the _only_ one
for whom this is full-time work is a black hat hacker.
And this was only a most basic example. Higher level languages pile on more
and more ways to interact with data. Byte arrays, "objects" (whatever those
are), it goes on and on. Each new layer adds another possibility for
exploitation.
-wes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pdxlinux.org/pipermail/plug-talk/attachments/20160531/1f9a5f3a/attachment.html>
More information about the PLUG-talk
mailing list