My First iOS Security Bug

About an hour ago, I opened bug #18403015 on Radar, Apple’s bug reporting web site.

This is not the first time I’ve reported a bug to Apple:  I recently opened a different bug (#18347673) because iOS has problems handling identify certificates, and I’ve opened other bugs as well in the past, for other stuff.  What makes this bug different is that I’m reporting it as a security bug.

This is interesting to me, because reporting vulnerabilities is always a sensitive topic (there’s a joke in there somewhere…).  Is this something I should announce now?  Should I hold on to this information forever?  Will Apple send their immaculately-dressed and -bewatched iHit (or maybe now it’s now called Hit) team to take me out?  Responsible disclosure is an interesting topic, because (as Perl teaches us), there’s more than one way to do it:  On one side are the people who immediately report every vulnerability to the world, leaving the vendor to deal with the fires that are started.  On the other side are the people who notify the vendor of the problem, and then sit forever in silence as the vendor either ignores the report, or actively decides to do nothing about the problem.  You also have cases of vendors responding to people with hostility, even if the vulnerability was disclosed in a responsible fashion.

I would like to do things properly, but I don’t know what definition of “properly” to use here!  Enter, the Organization for Internet Safety, which doesn’t really have a web site anymore.  If you go to their web site, you get redirected to their “OIS Guidelines for Responsible Disclosure” document (version 2.0) (the Guidelines).  It’s that document that I’m going to follow here.

The Guidelines describes five steps in the responsible disclosure process:  DiscoveryNotificationInvestigationResolution, and Release.  I just completed the Notification step:  I submitted the bug report, and I got my bug number, so I know that Apple has the report.  I’m now waiting for Apple to investigate.  The question is, how long?

Section 2 talks about timelines.  In general, updates from the vendor should come every seven days, and the issue should be resolved within 30 days, followed by a 30-day wait before the details of the vulnerability are released.  Although the issue resolution and release times are highly-variable, I think every seven days is a good frequency for getting updates.

What happens if I don’t hear back from Apple?  Section 3 covers communications breakdowns.  In general, the message is “If you’re going to go public, let the other party know before you do.”  Section 2.3 also mentions that, if you don’t get a response, you should email again, and the other party should respond within three days.

So, now I know what I’m going to do!  If I don’t receive a response by this time next week, I’ll post an update in the bug, as well as emailing Apple directly (they have a public email address for security vulnerability reports).  If I still don’t hear anything by October 1, then I’ll let them know that I’m going public, and I’ll post my information on October 6.  I already have a blank post on Open Radar, and I’ll copy all of my bug details from the Apple Bug Reporter site over to Open Radar once it’s time to go public.

Let’s see what happens!

Leave a Reply

Your email address will not be published. Required fields are marked *