Your debugging code can be a security hole

Applications and DLLs don't have privileges; users do

The Old New Thing — Fri, 18 Aug 2006 17:00:31 GMT

The Windows security model is based on identity.

re: Your debugging code can be a security hole

Jay B — Wed, 14 Dec 2005 23:32:49 GMT

Certainly I would agree with you that logs should go into the user's profile directory. The Event Log isn't really suited for a wide spectrum of logging output.

However, since there is no facility that leads developers down the righteous path (such as my post about CSIDL_LOGFILES for use with SHGetSpecialFolderPath, but ideally a more robust logging solution as yet unseen), the standard/best practice isn't going to be conformed too.

Make it easy to do it the right way, and the "clueless" will follow.

re: Your debugging code can be a security hole

Mark Steward — Wed, 14 Dec 2005 04:29:49 GMT

How about the geniuses at my University's computer services department, who have a huge virtual infrastructure for their "clusters" (rooms full of ICA clients)? These are network booted to W2k, with locked cases and a special shell that only allows you to connect, change volume, etc.

And then they leave the ICA configuration file writeable, so anybody can turn on key logging.

re: Your debugging code can be a security hole

kbiel — Wed, 14 Dec 2005 01:32:50 GMT

"There's no standard for where log files get put"

I disagree, there's the Event Log service. I understand that some programs that must run older (non-NT kernel) Windows systems can not rely on the event log being available, but device drivers certainly don't fall into that category.

re: Your debugging code can be a security hole

Paul Coddington — Tue, 13 Dec 2005 09:13:43 GMT

"There's no standard for where log files get put, which is why you see some of them in C:\Windows\System32\LogFiles, some in C:\, some in the Program Files application directory, some in My Documents, etc..."

There is actually, but too many programmers are clueless about it - anything the user produces (including log files) in general goes into their profile, in this case, in a custom folder under 'application data'.

It has to be this way, because anything run by the user does not necesssarily have the rights to write a file anywhere else - which brings us back to the other cardinal sin of programming "always assume the user is an administrator".

re: Your debugging code can be a security hole

JamesW — Tue, 13 Dec 2005 09:11:42 GMT

Steve: 'I also can't forgive ANYTHING for creating something in the root'

There's a well known office suite that dumps its install log files to / on OS X.

re: Your debugging code can be a security hole

Raymond Chen - MSFT — Tue, 13 Dec 2005 02:58:11 GMT

If you're the admin, then you don't need to go to all that trouble. Just install your own keylogger.

re: Your debugging code can be a security hole

Mihai — Tue, 13 Dec 2005 02:47:37 GMT

"Actually there is no issue (from a security standpoint) at the application level since there is no privilege elevation"
Counter-example: an application is used for passwords management. The logging feature dumps the password in clear text somewhere.
As an admin, I can set the registry key on the machine shared by several users, and as a result I get all their private data (Amazon, CitiBank, credit card numbers, etc.)
This is stuff I cannot get even if I am admin.
So, NEVER is better!

re: Your debugging code can be a security hole

Stu — Mon, 12 Dec 2005 21:37:06 GMT

How about if you do something like using a public/private key to varify that the debug information request is from an authorized debugger?

re: Your debugging code can be a security hole

Daev — Mon, 12 Dec 2005 20:59:55 GMT

One of the points Peter Seibel makes in his compulsively readable book on Common LISP is about the programming convenience of a language based around an interactive "read-evaluate-print loop." Even LISP applications running "in the wild" have this feature, which he illustrates with a story:

"An even more impressive instance of remote debugging occurred on NASA's Deep Space 1 mission. A half year after the spacecraft launched, a bit of Lisp code was going to control the spacecraft for two days while conducting a sequence of experiments. Unfortunately, a subtle race condition in the code had escaped detection during ground testing and was already in space. When the bug manifested in the wild -- 100 million miles away from Earth -- the team was able to diagnose and fix the running code, allowing the experiments to complete. One of the programmers described it as follows:

'Debugging a program running on a $100M piece of hardware that is 100 million miles away is an interesting experience. Having a read-eval-print loop running on the spacecraft proved invaluable in finding and fixing the problem.'"

My thought upon reading this: it's a good thing for you guys that hackers don't have radio-telescope dishes yet.