[Tutor] Value of tracebacks to malicious attackers?

[boB Stepp]

On Sun, Jan 24, 2016 at 12:43 AM, Danny Yoo <dyoo at hashcollision.org> wrote:
>> 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?

> 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.

Is there some standard way of implementing a debug mode?  If I were
thinking procedurally I would probably turn debug mode on and off with
a flag.  And I suppose one or more classes could be written to
accomplish this to provide coherent error processing for the entire
application.

>> 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.

Looking at the reference you referred me to:

sys.excepthook(type, value, traceback)
This function prints out a given traceback and exception to sys.stderr.

When an exception is raised and uncaught, the interpreter calls
sys.excepthook with three arguments, the exception class, exception
instance, and a traceback object. In an interactive session this
happens just before control is returned to the prompt; in a Python
program this happens just before the program exits. The handling of
such top-level exceptions can be customized by assigning another
three-argument function to sys.excepthook.

It is not at all clear to me how to make use of this information.
"...assigning another three-argument function to sys.excepthook" is
about as clear as mud to me right now.  Can you provide an example of
how to redirect uncaught, top-level exceptions to a file?  I'm still
searching for understandable examples, but I have not found any yet.
But I am quite tired now, so things will probably look more reasonable
after some sleep.

>> 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.

> 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.

This possibility occurred to me shortly after sending my email to the
list, that being sloppy could provide an entry point to whatever
server this hypothetical game was being hosted on.


-- 
boB