[Tutor] Value of tracebacks to malicious attackers?

[Danny Yoo]

> How much concern do you give this in designing and implementing your
> production code?  How far do you go in handling exceptions to ensure
> that tracebacks cannot arise for a malicious user?


Hi boB,

We can plan ahead and develop a program to support different modes of
operation . A "debug" or "devel" mode, for example, might be free to
show debugging output to the user in the face of errors.  We can run
our systems in a "debug" mode, but when we deploy such a system to
production, we can change the error handling so that errors don't
spill indiscriminately to the outside world.

We do not usually want verbose programmer-level error messages to
reach lay audiences because it's very possible for someone without
prior knowledge to completely misinterpret what the error is saying.
People have the tendency to attribute malice or blame to messages
that, on a first glance, are accusatory.  "Error: blah blah process
killed blah blah" can be *threatening*, even if someone doesn't
understand all the words there.

So it's not just because we're considering malicious intent here: a
message's interpretation depends much upon the audience receiving the
message, and we have to keep that in mind.

But if there is malicious intent, yes, a traceback can give a lot of
information that we're rather not give freely.  Operating system,
version of the Python runtime, locations of files, etc.  That's all
valuable knowledge.



> Is it even
> possible to prevent this from happening?  I am highly doubtful that it
> is possible to handle all possible exceptions in any reasonably
> complex application.

If we don't handle an exception directly, then we delegate the
handling of that responsibility upward.  There's a "toplevel"
exception handler that handles all uncaught errors.  For Python, this
is the 'sys.excepthook' mechanism:

    https://docs.python.org/3.5/library/sys.html#sys.excepthook

which, by default, prints the exception out to standard error.  We can
think of other things we can do here instead, like quietly logging the
message to a text file for later perusal.  Or maybe it could send an
automated email to the developers.  Or perhaps even start ringing
pagers, if things are serious enough to warrant waking someone up in
the middle of the night.



> Of course for many applications these concerns are probably
> inconsequential.  I don't think I would be gravely concerned if
> someone cracked into my ticktacktoe game deployed to some freebie
> site.

It doesn't hurt too much to practice safe habits, and doing the "right
thing" here is often useful for its own sake, and not just because
it's less risky.  For example, we discourage folks from using eval()
under normal circumstances, not only because it's unsafe (though
that's the high-order bit there), but because it's often a crutch for
not learning to use tools like parsers, or understanding how to use
dictionaries for holding key/value pairs.

Also, the stakes are higher than one might realize at first, because
computation and network resources are not free: being able to compute
something is itself a valuable resource (as the Bitcoin folks know).

Think not just about the breaking of your own program.  Instead, think
about what happens if someone takes over the machine and starts using
it as part of a botnet.  That is often a purpose of a system
compromise: the attacker may not personally care about tic-tac-toe,
but they do care about having root privileges on a computer.



Hope that makes sense.  Best of wishes!