It was 12 days from his first attempt.

It sounds like he had some trouble reporting it. Looks like he never received a call back so he decided to release it to the public. The timeline reads like he did it out of some spite.

It would be frustrating to go through all of this free highly specialized work and not find someone who cares at McDonalds.

But I'd at least give it a bit more time. Especially considering his first attempt at contact was around Christmas...

I've worked with the McDonald's web team before. They do care about performance and security. I reverse engineered an undocumented (to them) protocol for a game system in order to write tests for it--which was really, super fun to watch run.

McDonald's uses 3rd parties for most of their main development work. In the case above, the developers were in Australia, while McDonald's is in US Central Time and I was in US Eastern time. When I reported problems and provided suggestions, they usually had a conference call with McDonald's, the Aussie devs, and my team within 12 hours. If it was a weekend, it was Monday night. McDonald's core team takes this very seriously.

The difference here was that I had all the right phone numbers and am known to them. I was working for a well known publically traded company, which carried weight by itself. I don't know that if I didn't have the right contacts, hadn't been to their HQ and met with the VP/IT and Director of Online, would they have taken what I said seriously?

Secondly, this was the US Christmas and New Year's holidays. They were running a skeleton crew. As Adrian Cockcroft, former lead cloud architect at Netflix, once said, the time Netflix is the most stable is Christmas and New Year's because there aren't any engineers around.

With all that, they need to take this as a wake-up call and have a security response system, even if they contract a 3rd party for that also. There must exist, or this is a nifty startup idea, 3rd party firms that go through [email protected] emails, including the reams of spam, and there should be an optionally anonymous security problem reporting form with a captcha to get information such as this to the right people.

Lastly, 12 days is extremely short under any circumstance. While I'll admit that it can be extremely frustrating to not get a response, I believe 30-days should be the minimum time before first notification and publication with details. If a security firm wants PR for finding the problem, the post that there IS a problem first and wait the full 30-days from initial contact attempts before disclosing the details.

--Donald

>> It would be frustrating to go through all of this free highly specialized work

Give me a break. He didn't perform "free highly specialized work". If only I could walk uninvited into any business of my choosing, do whatever work I feel like doing without being hired - or even talking to someone first - and then demand attention, recognition, and/or payment.

Anyone who releases security vulnerabilities to the public without acknowledgement from the company is an unprofessional parasite on society. Even moreso with there being less than a month between discovery and public release.

I hate conglomerates, but if McD's has an avenue to sue for damages, I wouldn't bat an eye out of sympathy.

Not the author, but it was absolutely, definitely not removed before this article appeared on HN. It may have been removed afterwards, but when I read this article last night that timeline was there. It was even discussed elsewhere in this thread.

No comment on the timeline itself.

>Extremely unprofessional and irresponsible.

Agreed, especially considering the timing with Christmas and New Years holidays, they probably could not get the word down to their engineering team.

> >Extremely unprofessional and irresponsible.

> Agreed

How ungrateful. Someone puts in free work to make the world safer by fixing someone else's problems and they're a jerk because they didn't pamper them enough in the process.

> considering the timing with Christmas and New Years holidays, they probably could not get the word down to their engineering team.

Then this serves as a notice that they need to be able to - in about 15m, 365 days a year. Reality calling. fwiw, fixing a problem like this is almost always trivial. Not making the product bullet-proof, but simply disabling logins or whatever is needed to keep it from being exploited until it can actually be fixed.

A change of mindset (and stopping blaming the researchers) is all it takes to go from a many-month patch cycle to shipping mitigations inside of 12h.

Can you imagine a real engineer complaining about warnings, for instance that their bridge supports were crumbling, and how the discoverer didn't go through the reporting process.

> Can you imagine a real engineer complaining about warnings, for instance that their bridge supports were crumbling, and how the discoverer didn't go through the reporting process.

In your example the engineer should then proceed to blow up the bridge all while road users are still on it.

I imagine they'd block it off and not let anyone drive on it.

Or you know, murder. Maybe you're right.

What are your thoughts on what a professional and responsible disclosure time is?

Google in their "Disclosure timeline for vulnerabilities under active attack,"[0] states 60 days for disclosure for discovered security vulnerabilities and seven days for critical, currently known in-the-wild security bugs under active exploit.

[0] https://security.googleblog.com/2013/05/disclosure-timeline-...

Much more than 12 days. Below is a copy/paste of a recent security vulnerability timeline:

2015-12-14 | me > dotCMS | 8 SQL injection vulnerabilities

2015-12-14 | dotCMS > me | they were planning fixes in upcoming release, estimated to beginning of 2016

2016-03-16 | dotCMS | dotCMS version 3.3.1 release (CVE-2016-4040 still not fixed)

2016-04-07 | me > dotCMS | what is the situation with reported vulnerabilities?

2016-04-07 | dotCMS > me | CVE-2016-4040 will be fixed in 3.5, which is estimated to be out in mid-April

2016-04-19 | dotCMS | dotCMS version 3.5 release

2016-05-10 | dotCMS | dotCMS version 3.3.2 release

2016-10-31 | me | Full Disclosure on http://security.elarlang.eu

Source: http://seclists.org/fulldisclosure/2016/Nov/0

This timeline from first report to full disclosure was 10.5 months. Note that I did not go looking for a long timeline, this was the first item when I Googled "CVE disclosure timeline."

--Donald

Yeah, and it's absolutely uncorrelated to what the company feels comfortable with.

Maybe 24h? If you can't respond and mitigate within that time frame you aren't operating on internet time.

> From policy quote in sibling post: "[...] currently known in-the-wild security bugs under active exploit."

Nonsense. Every bug you discover could have been discovered by an attacker, and attackers are constantly scanning. If the bug is in release software you have to assume it's known and being exploited.

btw, for the downvoters - I know I speak the truth because I've worked dev in an internet-security company, and in security in a major cloud company. We can turn patches (or mitigations) out in hours and have them canaried and live in 24h. This is absolutely doable and should be expected. This months nonsense is when the company doesn't want to fix the bug.

What it takes is the institutional will to disable a feature you bill for until you secure it. When a $millions/day loss is on the table you find that obstacles evaporate. If a company tries to keep their vulnerabilities under wraps there wouldn't be this cost, and thus no will to fix it, in an ever-worsening spiral.