How Novell brightened my Monday Morning Mono Blues

I thought it was important that I document the interesting morning that I have had. And to show how I am only human, and just as much a liability as the next person when it comes to responsible disclosure *sigh*. I do hope you will learn from my mistakes. ALWAYS look for the security vulnerability reporting page BEFORE using regular reporting mechanisms.

7:25am: Review security audit findings from work done over the weekend.

7:52am: Talk with developer responsible for a vulnerable web service through Mono. Discuss how I was able to download the web service assembly, decompile it and extract the database password for their Oracle server. Give mitigation recommendation to use <Files> directive in Apache to prevent adversaries from accessing web service assemblies, and discuss WHY it's important to NOT store db passwords in code. Grumble about how I wish DPAPI existed on Linux to restrict access to such data.

8:15am: Contacted by client to confirm vulnerability and show product manager who doesn't believe this is possible, because their threat model said so (*groan*).

8:17am: Receive permission to exploit web service to reproduce problem.

8:19am: Perform attack against client's web service, download assembly and decompile code.

8:20am: Read Oracle password over the phone to stunned product manager.

8:22am: Point product manager to XenoCode and explain how obfuscation would be appropriate here to protect business logic that they are worried about.

8:31am: Finished explaining why buying Writing Secure Code, Second Edition for their entire dev team would be a good idea. Understanding how to learn from this incident is just as important as they reflect on how their threat model failed to catch the password problem.

8:35am: Think to myself... maybe I should get into the business of consulting on threat modeling. Then realizing I have a mortgage to pay, and not enough time in the day to educate clients on why threat modeling properly matters, get back to work.

8:45am: Client calls back happy. They took my advice and applied the <Files> directive into the Apache config on their production server.

9:14am: Finished contacting two other clients who have the same problem.

9:24am: Went to Mono site to report vulnerability. Cannot find any information on reporting security bugs. Report bug using Bugzilla, believing unconfirmed bugs are private. WRONG.

9:25am: Quick panic sets in. I realize my bug report (Case 77406) is public for the world to see. Not good. The last thing I want is some script kiddie who is watching Bugzilla for new bugs to prey on such information.

9:36am: Email mono@novell.com to inform them of the bug report in an effort to get a resolution, or the bug pulled from Bugzilla until someone can look into it.

9:40am: Realize Mono is supported by Novell and hunt for their security vulnerability report form. Report incident to Novell directly.

9:54am: Receive response from Platform Security & Mono Team, escalating this to the appropriate people.

10:15am: Bug report RESOLVED by Mono team as a known vulnerability fixed only a few days prior. Talk about good karma. Please see the end of this post on how to fix this issue.

10:17am: Received response from WSS Security Alerts team that they will get in contact with the right department.

10:18am: Respond to WSS Security Alerts team and inform them that the Mono guys have resolved this already, and everything is ok now.

10:32am: Email Mono team asking if I can blog about this, or if I should wait until the fix is more readily available.

10:34am: Realize that now that the vulnerability is in public (thanks to me DOH) that I should consider telling at least the Mono lists.

10:54am: Receive go ahead from Mono team. Given the option to blog about the fix, or wait until the upcoming release which fixes this.

11:00am: Decide its more important to mitigate against this issue NOW, rather than wait until the next release.

11:01am: Blog, blah blah blah.

As you can see, its been an eventful morning. I was extremely satisified with how quickly everyone was in responding to this. I had one low "level one" support person at Novell who couldn't get what I was trying to do when I gave them a quick call (wanting me to pay to talk to an engineer), but I found the email went around much faster anyways. I found the Mono team and Novell to not only be responsive, but quite responsible while I ran around yelling the sky is falling. That's how responsible disclosure is SUPPOSED to work.

So on to the information for the vulnerability that I found.

Vulnerability: The default configuration for Mono and Apache allows an adversary to download the web service assemblies directly. This allows for a potential information disclosure vulnerability as in most cases, these assemblies are NOT obfuscated, giving you complete access to the source code with tools like Reflector. What SHOULD occur is that a "403 Forbidden" message be sent, as it is in Microsoft's .NET implementation on IIS.

Resolution: The official fix for this is to modify the machine.config (typically stored in /etc/mono/1.0/machine.config) and add the following line inside the <httpHandlers> section:

<add verb="*" path="*.dll" type="System.Web.HttpForbiddenHandler, System.Web, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

This fix has been added to the master sources (HEAD) of mono and backported to 1.1.3. It should be available in an upcoming release of mono.

Many thanks to the Mono team for being so quick to respond. I apologize for using Bugzilla when I REALLY should have used Novell's security report form. Perhaps I could recommend you put a link to it on your website?

Damn those Monday mornings. *sigh*

Posted by SilverStr at January 30, 2006 10:54 AM | TrackBack