Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

This is a copy of the original question on Stack Overflow which didn't get much love and is probably more relevant here:

There are plenty of performance reasons why apps shouldn't be run in debug="true" mode (good rundown from Scott Gu), but are there any attack vectors exposed by this practice? It's not a question of "should you or shouldn't you", that much is clear, it's a question of whether it introduces any specific vulnerabilities.

I'm inclined to think that the ability to remotely detect it combined with the known performance issues could lead to an exploit against service availability but I'd like something a bit more definite. Does anyone know of a specific attack that can be orchestrated against an app running debug="true"?

share|improve this question
    
This depends almost entirely on what language, framework and application you're talking about. What are you using? –  nealmcb Dec 16 '10 at 20:24
    
ASP.NET, as per the tag :) –  Troy Hunt Dec 16 '10 at 21:06
add comment

6 Answers

up vote 6 down vote accepted

I've had some interesting feedback on this question both here and on Stack Overflow. There have been lots of responses related to stack traces (a custom errors issue, not a debug issue) and performance (not [directly] a security issue).

The most compelling response is that conditional compilation constants (#if DEBUG...) could cause unexpected behavior, but this again is more of a functionality risk (unintended code being executed in a live environment), than a security risk.

I suspect debug mode may open some pathways to other exploits based on the performance overhead it places on the app and the ability to remotely detect it (service continuity risk, perhaps). I've written up my conclusions as part of OWASP Top 10 for .NET developers part 6: Security Misconfiguration.

So for the sake of completeness, the answer appears to be that there is no clear security risk from running in debug mode, but it certainly isn't a good idea for production apps given the factors mentioned above.

share|improve this answer
add comment

By allowing potential attackers potential access to source code, stack traces, etc. it certainly allows them to focus/narrow an attack to the system.

I'd also assume (though haven't tested it) that since debug=true causes the compilation error rather than the expected site customerror, you could be exposed to the .net customerror crypto bug.

http://blogs.technet.com/b/srd/archive/2010/09/17/understanding-the-asp-net-vulnerability.aspx

share|improve this answer
2  
Thanks for the feedback, but HOW does debug mode expose either source code or the stack trace? Custom errors is a separate topic - let's assume they're on and there's no YSOD or stack trace exposed in the web response. –  Troy Hunt Dec 16 '10 at 6:11
add comment

The biggest thing to keep in mind when debug=true is that the symbols are there. The application can be precompiled with debug=true, but this is part of the deployment process. E.g. you get it built by the build server or on your local machine and transfer the assemblies over. (everyone is precompiling their applications before production deployment right?! :) ) Debug also has certain runtime optimizations turned off. An obvious attack would be a DoS. If custom errors are off you can also find out more information on the call stack -- moreso than if custom errors are off and the symbols are not there.

share|improve this answer
    
I think you're right about the precompiling - I'm pretty sure that's the way it was in v2/earlier, which has been changed (so I removed my answer). –  AviD Dec 16 '10 at 16:53
    
@AviD I believe you are correct, but only if the application is deployed as source code. –  Steve Dec 16 '10 at 17:14
add comment

I would think that if customErrors = off and debug= true, than even more information would be sent to an attacker.

It is safer to say customErrors = on or customErrors = RemoteOnly. That way a remote user will always get the generic ASP.NET error page. More information on MSDN

share|improve this answer
1  
I believe you have that backwards. customerrors should be remoteOnly or on. –  Steve Dec 16 '10 at 17:23
    
Thanks Steve, I was going by memory on that one. –  makerofthings7 Dec 16 '10 at 18:02
add comment

It's bad from information leak point of view, no need to repeat that. Additionally in debug mode request execution timeout is about 5 hours, so you can debug your application without getting timeouts. (Normal timeout value is 110 seconds by default) So if attackers find a code that takes too long to execute this attack may turn into a denial of service.

share|improve this answer
    
Sure, but what are you leaking? Keeping the issue of custom error settings aside, is debug mode alone "leakage"? Ok, that fact the app is in debug can be disclosed by making an HTTP DEBUG request, but other than that, is there really any info leakage? –  Troy Hunt Dec 21 '10 at 22:06
    
You are right you don't leak at lot of information if you configure custom errors. But anyway you are leaking the fact that you debug your applications on production servers, you are unlikely to have a well defined test,release cycle, you are likely to have debug code on your server etc etc. –  Nathan B. Dec 23 '10 at 9:33
add comment

This depends almost entirely on the language/framework/deployment environment.

For python/django, it is very explicitly the case that DEBUG=True is a security issue. See e.g. the notes on not showing configuration variables for 'SECRET', 'PASSWORD', 'PROFANITIES', or 'SIGNATURE' - see http://docs.djangoproject.com/en/dev/ref/settings/#debug

share|improve this answer
    
True, but the context was for ASP.NET which is somewhat different than Python :) –  Steve Dec 16 '10 at 20:45
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.