Hacker News Reader

Comment by olliej | Hacker News Reader

It's not a zero day, it's a 91 day. Some bugs can be complex to do root cause, fix, and verify a bug. But 3 months for what appears to be a validation failure seems more than sufficient.

Obviously we'll need to wait until the actual fix comes out to see if the fix was more substantial.

View on HN

I've been around infosec for 21 years and this is still a 0day. That term has no strong definition, certainly not one that would allow precise interpretation as above, but in this case even a vague sense of what it means covers the situation easily: _users_ have had no time to patch

Can confirm. "Zero day" means you've had zero days to patch. The term has been used this way since, IIRC, the late 1990s. See Phrack 53 for an example:

http://www.textfiles.com/magazines/PHRACK/PHRACK53

If the bug was found 91 days before the fix and was released one day before the fix. Others might argue that it is a 91-days or a 1-day :))

Tl;dr: it doesn't matter. A low-severity bug was found, and then was fixed.

Wrong. "zero day" means the _vendor_ has had zero days notice. Few companies and even users patch the same day a fix comes out.

Words are used to communicate, and language is fluid and changes over time. Clearly, zero-day is being used and understood by many to mean simply "unpatched", and so that is a reasonable definition. If ever you're arguing that a significant proportion of people are using language incorrectly, you're probably on the wrong side of history.

Don’t you just love it when people pull out their dusty tomes to prove to you that you’re wrong? It’s so pedantic yet also incredibly ignorant of how dynamic languages are.

I got yelled at once for using the word “cheap” to mean “inexpensive” once and wish you had been there with me.

I think a "zero day" threat model and terminology is from the point of view of the blue team type of people running the system, not the vendor.

From someone running a system, it doesn't matter if the vendor had 0 prior knowledge of the vuln or if they had made 25%, 50% or even 99% progress towards a patch. The point is there is still no patch available for the vulnerability and your only defense strategies are the same as if the vendor hadn't known at all, so it's still a 0day.

If the vendor has had zero days notice then nobody has had any time to patch, so my statement stands.

Zero day is almost always used in the context of “the bug was unknown and first seen during an attacks”.

The alternative definition (that zero day means purely day of publicizing) would mean that if you had two bugs in a product and you notified the vendor of one. Then three months later published both, they would both be zero days, and should be treated as such.

A 0day means publicizing a bug without the vendor themselves having the potential to have a fix.

Very simply: if a virus comes out attacking a known but unfixed bug in MS software no one would call it a zero day. Every article would say it was a bug that Microsoft knew about but hadn’t fixed.

As GP said, lots of people use this amorphous term differently. Antivirus company ESET, for one, explicitly disagrees with your example:

'...The name “zero-day” comes from the fact that no patch yet exists to mitigate the vulnerability being exploited.'

https://www.welivesecurity.com/2015/02/11/security-terms-exp...

Some bugs are just really hard to find, diagnose, verify, fix and then verify the fix.

At a previous employer, I was responsible for a very long running service that usually had an uptime of about 9-10 months. At one point we noticed we had a memory leak that was directly related to the number of requests the service processed. The kicker: it leaked less than a single byte per request in an x64 C++ service. It took us about a year to find the cause. Turned out to be a bug in an in house logging lib that failed to create a rolled log file in case of a filesystem full or disk usage quota exceeded condition, which we rarely ever encountered in development because we wiped logs every week in dev, but on a more relaxed schedule in prod.

Agreed, like I said it will be interesting see what the final patch set will be.

Diagnosing some bugs can take a huge amount of time, work, and luck (I had a bug one time where the repro steps required a specific google reader account and a stapler resting on the space bar for an hour or so).

But for a bug that has a trivial test case, especially in the context of parsing/validating bugs generally, isolating the bug should not be hugely challenging (a few days).

Much more likely in my experience is that the nature of the specific flaw indicates that there is a pattern in your code base that is potentially unsafe - at that point you want to fix all instances of the pattern, because when you release the patch you’re documenting the flawed pattern.

Reply on news.ycombinator.com