I often wonder why disclosures of these types of exploits is now, "same day" instead of "Let vendor know you will be reporting this to public in a week."
I wonder if it is out of concern they will be pressured to keep quiet?
There is a good practical reason for not providing advance disclosure at major conference, particularly if you're subject to some kind of NDA, because, more often then not, the security researcher faces the risk of legal action and being shut down.
That pattern, though, "We are going to announce a security hole in major vendor product" followed by, "Shut down by legal action" - happens so frequently that I often wonder whether that's actually part of some larger pattern of entrepreneurial behavior that's opaque to me, it happens so frequently. Maybe it enhances your reputation? Gets you in the news?
I'm all for full disclosure, but, it might be nice to give the vendor a week to have a patch that can roll out at the same time as you let the world know what you found.
In this case it looks like someone is publicly disclosing a vulnerability that is already in circulation, and presumably is in use somewhere. A vulnerability which might have the potential for remote code exploits against multiple operating systems, and there is no guarantee that someone hasn't figured that out and is using it right now. For someone squarely on the full disclosure side of the debate, this would be about the best case to fully disclose everything, immediately.
If a vendor does not have such a policy or is found to have violated it, I would go for immediate full disclosure.
http://www.the4cast.com/apple/apples-flashback-fiasco-what-r...
2 years apart, same outcome. Apple has a terrible track record of fixing bugs. As of so far it seems giving them a minute, week, or month has no difference. In the past other vendors have had issues with timely fixing their bugs or trying to squash disclosers, that's why lists like full disclosure exist to this day.
o First posted: 7:30 am 11-20-12 by Sam Bowne
o Page reorganized with Contents section 11-30-12 10:36 am
o New videos 4 and 5 added 12-5-12
o BayThreat Videos added 12-8-12 11:19 pm
o Attacks on the Mac OS X with simulated routers added 7:45 pm, 12-10-12.
o Apple notified 12-11-12Maybe Sam Bowne (the author) didn't formally notify Apple until he had more solid details, but he certainly made the issue publicly-known before this. It wasn't a surprise attack on anyone.
"The new version of the attack is powerful enough that I decided to formally notify Apple. I don't expect them to care much--Microsoft certainly didn't think this was important to them, and Windows is much more vulnerable."
Its also worth noting that while this vuln has a high availability impact it is also requires very specific network access, ie you can't run this from your cable modem and kill a random box on the internet.
Anyone want to perform a test with me?
I also think that a good compromise would be to pass on the exploit information to some 3rd party, tasked with releasing full details at a certain date (or simply, the responsible release of the exploit). The focus of pressure would then shift from the researcher to this 3rd party, which would presumably have the means to resist the pressure.
http://www.physnet.uni-hamburg.de/physnet/security/vulnerabi...
teardrop?
"... this one crashes the Mac, and it makes [Windows] Server 2012 restart."
http://en.wikipedia.org/wiki/Denial-of-service_attack#Teardr...
Therefore the attack is bounded to the neighbour router(s).
From the RFC [0]
Source Address
MUST be the link-local address assigned to the
interface from which this message is sent.
So the problem is that irresponsible disclosure does not help victims at all, and does help criminals. The only positive thing in irresponsible disclosure is that if vendor is unreasonably slow with issuing patches, and exploits are already known to be in the wild, then the harm is minimal, and disclosure can raise the priority of the fix. But absent this knowledge, responsible disclosure is almost always better for the users.
YYYY-MM-DD HH:MM:SS.ffffff+ZZZZ
I guess because for them the day always comes before month.
Nevertheless, ISO 8601 is clearly the ideal format for its sortability and consistency, cultural imperialism be damned!
Typed, I use YYYY-MM-DD (e.g. 2012-01-10), mainly for its sortability.
They were quite surprised when I told them the actual format that was used in Canada.
That said, Apple's track record on this topic is not exactly stellar.
But people who submit security issues to them say that their turnaround time tends to be very long. Which is bad for their customers if the submitted security issue is being exploited in the wild.