Full Disclosure

The need for Full, Partial, Responsible and Zero disclosure. Issues with reporting vulnerabilities to vendors.

The MSRC – now and then

It’s amazing to compare how the Microsoft Security Response Center handles vulnerability disclosures versus how things were just 10 or 12 short years ago.

Here’s a typical disclosure process 10 years ago (based on a very true story):

Us: (sending an email to secure@microsoft.com) we’ve discovered a vulnerability in an office product. Here are the technical details. Can you confirm the issue and let us know when it’s patched?
Microsoft: Thanks for reporting, bla bla, we’ll get back to you soon

[about a week passes]

Us: Hi MSRC, any news about our office vulnerability?
[no reply]
[Sending a personal email to an MSRC friend to speed things up]
Microsoft: Oh, thanks for reminding us. We’ll check with the office team

[another few days pass]

Us: Hello? Anybody there?
Microsoft: Oh, yes. That vulnerability thing. Here’s what we decided: (a) It’s not a vulnerability. (b) it’s not a problem with the office product but with the world (or the RFC) (c) The office team can’t recreate it (d) even if the vulnerability was real, it wouldn’t be exploited in real world scenarios
Us: are you kidding us? Did you actually look at the sample code we gave you?
[a few days pass. We are pondering if to go complete full disclosure or give them time to digest]

Microsoft: Ok, this time we actually read your advisory and yes, it seems to work. But it’s just a denial of service. Nobody will ever exploit it because of … [something that heap spraying/DEP bypass/code mutation made look ridiculous about a year later]
Us: [starting the get mad] look guys. We sent you PoC code. You actually want us to write an exploit code for you?
Microsoft: yes, that would help convince our developers

[Us, spending time writing code so that Microsoft is convinced to fix their own products based on free information while wasting our precious time]

Us: here it is
Microsoft: oh, wow, it really does run code. Ok, we’ll fix it in the next release cycle which should be right after the democratic primaries of 2012.

Us: Ok, forget it. We’re going full disclosure

Microsoft: no, wait wait wait. We found your name on the world wide web and now realize you’re legit. Ok, we’ll fix it. Happy now? We might even mention your name in our advisory if/when that happens.

If it sounds familiar, that means you were disclosing vulnerabilities to vendors in the early 2000’s or late 1990’s. If you think I’m exaggerating, it’s only because you didn’t.

But here’s the amazing thing. Just a few years later, some radical changes started to happen. The big dysfunctional dinosaur that was MSRC became an efficient, friendly and if I didn’t know it, I would think it’s a different company altogether. Here’s a real recent discussion:

Us: Hello MSRC, here’s information about an office vulnerability
Microsoft: Hi, thanks for reporting. I checked the information, went over the sample code and have some technical questions [some intelligent questions here, basically they are doubting the findings but being really careful to check all the angles first]

[technical discussion continues for a couple of days with questions and answers going back and forth]

Microsoft: Ok, we get the picture now. Thanks for reporting. Here’s the guy that is going to be responsible for your case.
[a few days pass]
Microsoft: Ok, we now know it’s a […] vulnerability and not a […] one. We’ll pass it to the relevant team, just wanted to keep you posted
[further proactive updates and niceties continue until disclosure time. Credits, the end.]

What could have possibly caused this radical change that made MSRC focus on the technical side instead of the PR, not to mention being so research-friendly? New team? New procedures? Full disclosure forced them to see the truth? Too many beers at defcon finally showed them the light? Whatever they are taking, I wish they could spread some around. Most of the other vendors could use that. Yes, I’m looking at you Google.

Apple Safari Denial Of Service (iPhone, iPad, iPod, OS X, Windows) 0-Day

I’ve spent a lot of time thinking about what to do with this one, and when I say a lot of time, I really mean just over 3 months now. I also informed Apple that I would be writing this article, and asked for an official quote from them, and also a rough date as to when the relevant patches would be disclosed.
I found this one by fuzzing Safari 5.0 on the night that it first came out, I was using Browser Fuzzer 2 (bf2)and then spent a while playing with it to see if I could turn this into more than just a Denial Of Service (DoS), unfortunately I wasn’t able to. This is not to say that it’s not possible to do so, I’m just not too sure on how to do it, it may very well be more than just a DoS with a few tweaks to the code.

I initially tried selling this one to ZDi, but their response to me was fair and to the point:

“Dear xyberpix

We have reviewed your recent case and discovered it was a duplicate of an issue we received in January of this year. We have also determined that this issue is likely non-exploitable. Due to this we are going to pass on the opportunity to pursue acquisition of this vulnerability information through the ZDI program.

Thank you for the submission and we look forward to your future work.

Regards,
The ZDI Team”

So, January 2010 and to date, this still has not been fixed by Apple! People give Microsoft and Adobe a hard time about their time to release patches, but seriously 8 months is really pushing it!

So I figured I’ll see what Apple has to say about this one, and sent it along to their product security team, asking if they were willing to reward vulnerability researchers for their time. I wasn’t asking for anything major at all, maybe the cheap iPad or even just a copy of Logic Studio 9 for my trouble. That’s really not too much to ask really is it? I didn’t have any high hopes though, and well here was their response:

“Hello Xyberpix,

When we address an issue in a Security Update, we give credit to the person who reported the issue to us.  However, Apple does not directly provide financial reward.”

Okay, fair enough, I didn’t go looking for bugs for financial gain, but it would have been a nice token nonetheless. I guess the fact that I’ve been a loyal Apple fan boy for close on 8 years now means nothing to them at all. I guess this is why I’m a firm believer in the No More Free Bugs movement, in the same sense though I can’t sit around idly and wait for what’s been over 3 months since I found this issue, and Apple has not released a patch yet!

Apple also came back to me stating that they had addressed this vulnerability in iOS 3.2 and iOS 4.0, well, erm, dunoo how to tell you guys this but, nope you didn’t. So being the nice guy that I am I sent them the relevant crash logs as requested. Their response was the following:

“Hello xyberpix,

Thank you for forwarding this issue to us.  We take any report of a potential security issue very seriously.

After reviewing the issue, it appears that this denial of service issue results in the unexpected termination of MobileSafari, but not of the host operating system or a system service.  For our internal tracking purposes, this will be classified as a “Crash / Hang” issue. Although we do not see additional security concerns, we do consider this to be an important issue, and are working with the engineering team to address it.

If you have reason to believe that the issue has ramifications beyond terminating Safari (such as terminating the operation of the host operating system or system service, or executing arbitrary code), we would appreciate the steps to reproduce this, or crash logs from when you observed it.”

I then replied asking about this issue on platforms other than iOS, namely Windows and OSX, to which I recieved the following response:

“Hello xyberpix,

The crash is still a security issue on platforms on which it has not been addressed.  So far, it has only been addressed on iOS.

For the protection of our customers, we ask that you do not disclose details of this vulnerability until it has been addressed on all platforms.

When we release an update to address this issue on other platforms, you will be credited for the vulnerability.”

Okay, so let me get this straight, this is not a security issue on iOS, it’s a crash/hang issue, which they have apparently addressed in iOS 4, and I had to bug Apple about the Windows and OS X Safari issues, even after I informed them that it was possible to crash Safari on all platforms, not just iOS? Something’s not quite right here…

When I asked for a rough timescale on when a patch for this is going to be released, I was given the following response:

“The following information should be considered confidential.  We are sharing this information as a status update on an issue you reported.  Please do not share this information with others.

This issue has already been assigned CVE-20xx-xxxx, when it was fixed on iOS.

The issue is currently planned for our next available software update.  I don’t have a date for you yet, but we will coordinate with you closer to the release of the udpate.

I completely understand confidentiality, but I also believe that security researchers should get more than just credit for discovering a vulnerability that Apple’s testers should have found in the first place.

Oh wait, it seems they did find it, but they just claimed to have fixed it, instead of actually fixing it, did I get that right?

My last attempt at contacting Apple was on the 2nd August 2010 to ask if they could please give me an official statement on this issue that I could include in this post, and if there was still no chance at all of getting some sort of reward for this finding. Their response was this:

“Hello xyberpix,

We do appreciate the time you took to find and report the issue to us.

As mentioned, it is not our policy to provide financial compensation for issues.”

I really don’t want this post to be taken the wrong way, yes I was looking for compensation for the vulnerability, but not thousands of dollars, just a little something to make the time spent on this one worthwhile. I also wanted to have an official statement from Apple on this one as to when they are likely to release a patch, neither of which they were willing to do. Personally I don’t feel that either of these things were too much to ask at all from a company that is growing in leaps and bounds each year.

If any Apple employee’s would like to discuss this one further with me, the case number for this issue is 111476071, and you have all my contact details.

As a matter of courtesy and security I will not be publishing the code for this DoS, as I do not believe that would be responsible, once a patch that works has been released by Apple, I will upload the code. I have also removed the CVE number and also the specific function that causes the crash.
I’m really looking forward to all your comments on this one people, as I’d love to hear your views.

Apple iPhone/iPod Touch/iPad Security Update

Yesterday Apple released a security update that patches the Jailbreakme vulnerabilities to stop people Jailbreaking their Apple devices.

Okay, so maybe I’m looking at this the wrong way around, but it seems that when a vulnerability gets a lot of media attention, Apple work the backsides off to get this one patched. I understand that we are talking serious vulnerabilities here, but still. I’ve personally been in contact with Apple for a couple of months now in regards to a DoS vulnerability that I discovered, and still have no time line on when a patch for this will be released, so maybe all that’s needed is to turn this into some media hype, hmmm.

So the vulnerabilities that this patches are the following:

  • FreeTypeCVE-ID: CVE-2010-1797

    Available for: iOS 2.0 through 4.0.1 for iPhone 3G and later, iOS 2.1 through 4.0 for iPod touch (2nd generation) and later

    Impact: Viewing a PDF document with maliciously crafted embedded fonts may allow arbitrary code execution

    Description: A stack buffer overflow exists in FreeType’s handling of CFF opcodes. Viewing a PDF document with maliciously crafted embedded fonts may allow arbitrary code execution. This issue is addressed through improved bounds checking.

  • IOSurfaceCVE-ID: CVE-2010-2973

    Available for: iOS 2.0 through 4.0.1 for iPhone 3G and later, iOS 2.1 through 4.0 for iPod touch (2nd generation) and later

    Impact: Malicious code running as the user may gain system privileges

    Description: An integer overflow exists in the handling of IOSurface properties, which may allow malicious code running as the user to gain system privileges. This issue is addressed through improved bounds checking.

Sonicwall Vulnerability Fixed

A month ago I complained about Sonicwall and google brushing us off when we reported vulnerabilities to them. The good news: Sonicwall has since contacted us, acknowledged the problem and is now rolling out a fix.

Was I too harsh on Sonicwall? It was hard to get their initial attention, but once we did they cooperated in an exemplary way. I’m not fooling myself to think any researcher that will notify them of a problem will get the same level of attention, but obviously they do give a damn, and maybe security@sonicwall will be open for notifications from now on.