19

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"?

Community
  • 1
Troy Hunt
  • 3,930
  • 4
  • 19
  • 21

6 Answers6

12

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.

Community
  • 1
Troy Hunt
  • 3,930
  • 4
  • 19
  • 21
5

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

iivel
  • 1,583
  • 10
  • 13
  • 3
    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 06:11
  • @TroyHunt When writing in PHP, the stack trace and errors can be sent the client... that's probably the case of other languages too. – Alexis Wilke Apr 11 '16 at 21:42
4

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

makerofthings7
  • 50,090
  • 54
  • 250
  • 536
3

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.

Steve
  • 15,155
  • 3
  • 37
  • 66
  • 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
3

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

nealmcb
  • 20,544
  • 6
  • 69
  • 116
2

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.

Nathan B.
  • 443
  • 2
  • 7
  • 1
    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 09:33