Talk:Zero-day vulnerability

Why?

"Unrelated to topic" seems to be a weak excuse. 0-Days can be funneld into your system via add-banners, it should be mentioned as a possible attack vector.

Also;

Physical access is the worst case, as any known and unfixed, unknown or made up instance of a 0-day (wich is unknown, thus 0-days-to-fix) may end up in an active vulnerabillity of the end customer.

Reguarding my typing:

Non-Native-English. Brew this one as however you like. 2003:C7:1F2D:9898:FCBE:F250:9EFE:6C4D (talk) 17:07, 4 May 2023 (UTC)Reply

Zero-day attacks rely on software vulnerabilities (bugs etc). It has nothing to do with physical access to the computer. Ad banners normally come from web pages accessed via a network connection. Again, nothing to do with physical access. CodeTalker (talk) 17:27, 4 May 2023 (UTC)Reply

My original statement mentioned that even thrusted webpages may have includet web-banners, wich may, on purpose or not, contain mallicious code containing 0-days, wich again may or may not be included by maliccious means. THIS part is entirely disconnected from Physical access.

Physical access is the wet dream for any user and any hacker. Twist and turn and solder and readout however you want. Physical access is a privacy-danger in and of itselfe and can not be mentioned often enough, in my opinion. Also; 0-Days that wont work via TCP/IP may very well work with an USB-Stick inside your physical Plug&Play device.2003:C7:1F2D:9898:FCBE:F250:9EFE:6C4D (talk) 17:39, 4 May 2023 (UTC)Reply

The current definition in the page: "A zero-day (also known as a 0-day) is a vulnerability in a computer system that was previously unknown to its developers or anyone capable of mitigating it." does miss some of the key points that (at least I) think are relevant for the term. First, it does not address if the vulnerability is publicly known or not. This would suggest that any vulnerability, at any time of software development, would be a zero-day. Furthermore it does not state that the vulnerability is exploitable, leaving it open if the vulnerability is actually deployed ever. So according to the definition, any development-time SW bugs with security aspects are zero days. Thinking in these terms, it would actually be hard to find a software vulnerability that was not a zero day: any vulnerability, at some point in time, is not known by any developer. What comes to exploitability, I would not state it is a requirement for a 0-day. Note that exploitability is a trait that may change in time, e.g. with new implementations themselves being secure may expose the vuln. Then, the notion that it is not known by any developer; how can you ever know if this is the case? There could very well be people that know there is a problem but did not have the time or means to fix it. Quickly googling the internet, I find a better definition in "https://www.trendmicro.com/vinfo/us/security/definition/zero-day-vulnerability": "A zero-day vulnerability is a vulnerability in a system or device that has been disclosed but is not yet patched." I think that definition escapes many of the problems we have in this wiki definition today. Sure it can be polished, e.g. by stating "...for which there is no patch available yet" instead of possible misunderstanding that a non-patched system would have 0-days, just because an appropriate patch is not applied yet. To me, this discussion of the real and proper definition of a 0-day is important. The term is used often when talking about the security of software systems, and with various meanings. For example, if your strategy to mitigate 0-day (risks) would be to have the latest patches in the system, you would have totally missed the point. In the field of security we should use concise text to disseminate the real(istic) problems and risks, and to have matching mitigations for the risks assessed. 84.249.75.64 (talk) 11:19, 27 October 2023 (UTC)Reply

I'll largely copy my second bullet point from the #Edit request discussion below, for my thoughts on the definition question.

I'm not sure a vulnerability in a system or device that has been disclosed but is not yet patched is really a useful definition from the end-user perspective. A zero-day vulnerability doesn't stop being a zero-day vulnerability when the vendor learns of it, nor when they release a patch.

This article by Paul Ducklin really cuts to the heart of it: zero-days, by definition, are bugs that the Bad Guys found first, so that there were zero days on which you could have patched proactively. What matters is not if the vendor knows about the vulnerability or has patched it. The important thing is when they knew about and patched it. Zero-day vulnerabilities are ones which the vendor was made aware of, and (hopefully!) for which they eventually release a patch, only after users' systems had already been exposed to possible attack. FeRDNYC (talk) 16:02, 6 April 2024 (UTC)Reply

Please replace the content of this page with User:Buidhe paid/zeroday.

To fix the issue in the tag—unsourced text—as well as outdated sources, I've rewritten according to reliable sources. I also expanded the article with more information about the zero-day market, how the danger of exploits changes over the window of vulnerability. I replaced the US government section with a history section to be less US-centric, and added two public domain charts to illustrate the article. Buidhe paid (talk) 07:12, 5 April 2024 (UTC)Reply

There are some definite improvements in that version of the article. However, I feel there are some issues with it that should be addressed before it's adopted:

• Extraordinary claims like "States are the primary users of zero-day vulnerabilities" really need to be cited, the fact that this statement is made in an entirely citation-free lead section is troubling.

• With respect to the cited sources (primarily the Rand Corp. authors), I'm not sure a vulnerability in software or hardware that is typically unknown to the vendor and for which no patch or other fix is available is really a useful definition from the end-user perspective — nor does the timeline graphic in the proposed version of the article really bear that definition out. A zero-day vulnerability doesn't stop being a zero-day vulnerability when the vendor learns of it, nor when they release a patch.

  This article by Paul Ducklin really cuts to the heart of it: zero-days, by definition, are bugs that the Bad Guys found first, so that there were zero days on which you could have patched proactively. That definition jibes with the timeline chart. What matters is not if the vendor knows about the vulnerability or has patched it. The important thing is when they knew about and patched it. Zero-day vulnerabilities are ones which the vendor was made aware of, and for which they released a patch, only after users' systems had already been exposed to possible attack.

• Speaking of the charts — while I have no trouble accepting that commons:Threshold of originality#Charts says that those images are freely available for our use, since they're PNG images of primarily-textual data they're still not ideal for inclusion.
  • The timeline chart would be far better re-created in {{Graphical timeline}}, so that its information is accessible to more readers.
  • The pricing chart could also benefit from a vector re-creation, at a minimum, but that's kind of a secondary issue. I'm not convinced it belongs in this article at all. (Because...)
• I kind of feel like the whole "Market" section is excessively detailed, and given WP:UNDUE prominence — especially since there's an entire Market for zero-day exploits article. That means that most of the information should live there instead; what appears in this article should be focused on how it relates to zero-day vulnerabilities. Anything that's more about the market itself (characteristics of the buyers and sellers, for example) should be in the other article instead.

FeRDNYC (talk) 15:53, 6 April 2024 (UTC)Reply

Hi, thanks for restonding.

• First of all the lead is not cited because all the information is cited in the body. See WP:CITELEAD.
• Second, while neither of the graphics are perfect, I think they are better than no having them. Improvements to the graphics can occur at a later date.
• If the software is not released (or the bug is discovered by a vendor?) it does not have the same security risk and therefore may not be called a vulnerability. Zero day vulnerabilities are a subset of vulnerabilities and there are two main definitions found in published sources:
• Based on patch status:
  • "A zero-day vulnerability is one for which no patch has been developed" Defender's Dilemma p. xvi
  • "a vulnerability in the software that has never been made public and for which there is no known fix." (O'Harrow)
  • " a zero-day is a software or hardware flaw for which there is no existing patch " (Perlroth)
  • "Zero-day vulnerabilities are vulnerabilities for which no patch or fix has been publicly released" (Ablon & Bogart 2017)
• Based on knowledge status:
  • Zero-day vulnerabilities are "ones that are not publicly known" Sood & Enbody p.40 or "unknown to vendors and the general public" (116)
  • A zero-day vulnerability is "a security vulnerability that is not known to the software vendor or the wider security community." (Dellago, Simpson & Woods 2022)

Only one or two of the sources cited in the article suggest that the vulnerability must be discovered by someone other than the vendor to qualify.

The market section is prominent because that is an aspect dealt with at length in most of the sources, so I don't think it is UNDUE. In my view, it would make more sense to expand other parts of the article given that it is overall not long. Buidhe paid (talk) 19:41, 6 April 2024 (UTC)Reply

@Buidhe paid: Apologies for not responding sooner, I lost track of this until Jericho347 fortuitously bumped it a month ago. Responding to a couple of specific things:

1. I'm very familiar with WP:CITELEAD — have you read it? Although the presence of citations in the lead is neither required in every article nor prohibited in any article, there is no exception to citation requirements specific to leads. And as I said, a claim as extraordinary as States are the primary users of zero-day vulnerabilities warrants a citation wherever it appears.

   (I also was not able, on quick examination, to find that information cited or even presented anywhere in the article body, although it's very possible that I missed it. — If I did, and there had been a citation for that claim in the lead, locating the corresponding use of the same cite in the body would be a helpful way to connect those dots.)

   The closest thing to a corroboration I could find was the claim, in the markets section, that gray-hat purchasers (mostly state entities) represent the largest market for zero-day vulnerabilities. But if that's what the lead is meant to be summarizing, changing it from "the largest market for purchasing zero-day vulnerabilities" to "the primary users of zero-day vulnerabilities" makes it a very different claim.

2. The market section is prominent because that is an aspect dealt with at length in most of the sources But sources don't dictate the content of a Wikipedia article, its editors do. You're working primarily from book sources. (Plus at least one journal article, Dellago et al., that's entirely about the exploits market, so that's certainly going to focus heavily on it.) Of course any book about cybersecurity is going to cover the market for trading vulnerabilities, and likely at considerable length. They'd be doing their readers a disservice not to. But this article is about one specific topic those books cover (out of dozens, no doubt), and as a topic article it should be as focused as possible on that topic.

   We (using the royal "we") clearly agree that the market for vulnerabilities is an important topic. So important, in fact, that there's a whole separate article about that topic. Which is why that article is the {{Main}} article about that other topic. While there will always be some overlap, covering the same ground at length in multiple articles risks both redundancy and contradiction.

   Discussing the market as it pertains to vulnerabilities themselves has relevance to an article on vulnerabilities. But anything even somewhat tangential is better left to the dedicated article on the topic. An example what I feel is largely tangential:

   In 2015, the markets for government and crime were estimated at at least ten times larger than the white market. Sellers are often hacker groups that seek out vulnerabilities in widely used software for financial reward. Some will only sell to certain buyers, while others will sell to anyone. White market sellers are more likely to be motivated by non pecuniary rewards such as recognition and intellectual challenge. Selling zero day exploits is legal. Despite calls for more regulation, law professor Mailyn Fidler says there is little chance of an international agreement because key players such as Russia and Israel are not interested.

   The sellers and buyers that trade in zero-days tend to be secretive, relying on non-disclosure agreements and classified information laws to keep the exploits secret. If the vulnerability becomes known, it can be patched and its value consequently crashes. Because the market lacks transparency, it can be hard for parties to find a fair price. Sellers might not be paid if the vulnerability was disclosed before it was verified, or if the buyer declined to purchase it but used it anyway. With the proliferation of middlemen, sellers could never know to what use the exploits could be put. Buyers could not guarantee that the exploit was not sold to another party. Both buyers and sellers advertise on the dark web.

   Aside from the last two sentences of the first paragraph, and maybe a couple of the middle sentences about the usability of purchased vulnerabilities from the second paragraph, most of that is mainly or entirely about the market and the entities trading on it, not about the vulnerabilities themselves, which I still maintain makes it off-topic.
3. Also, something I hadn't noticed originally, but speaking of sources — on this one:
   • Perlroth, Nicole (2021). This Is How They Tell Me the World Ends: Winner of the FT & McKinsey Business Book of the Year Award 2021. Bloomsbury Publishing. ISBN 978-1-5266-2983-8.

The subtitle of the book is not "Winner of the FT & McKinsey Business Book of the Year Award 2021". (How would that even work?!) The correct title+subtitle, as can be seen at its Amazon page, is This Is How They Tell Me the World Ends: The Cyberweapons Arms Race.

FeRDNYC (talk) 23:17, 6 July 2024 (UTC)Reply

The edits made by Buidhe paid (talk | contribs) at 02:03, 4 June 2024, contain many poor choices in wording that introduce confusion and errors. There are two definitions for 'zero day' really, and using the term in the context of any vuln not known to the vendor means that a significant portion of vulns are zero days at some point in their lifecycle (any not discovered by the vendor). That dilutes the other meaning, used in many circles where a zero day is one that is not known to the vendor at time of exploitation. In your talk above, even asking the question "or the bug is discovered by the vendor?" in the context of being called a vulnerability is completely wrong. Fundamentally, a vulnerability is a flaw that allows crossing of privilege boundaries. Clearly defining both definitions is essential for this page. Why? Because saying "States are the primary users of zero-day vulnerabilities" is absolutely false, as a majority of computer criminals are not nation state actors, yet use zero day vulnerabilities (by either definition). While nation state TAs tend to get more press, by volume, they represent a much smaller group than the larger computer criminal category. Saying things like "the significant cost of writing the attack software" is also wrong, in the aggregate, because if you factor in every "zero day" XSS, writing the exploit takes seconds typically. You simply cannot make these blanket statements without a lot more clarification and qualification. I recommend all of the prior changes be reverted in favor of adding smaller bits at a time, so there are easier reverts or edits to improve the quality of this article. Overall, I feel that the quality of this page went down. Additionally, unrelated to the last edit, the section on RAND needs to include citations of those who call into question some of their findings. That paper has flaws. Jericho347 (talk) 03:41, 4 June 2024 (UTC)Reply

My definition of zero-day closely follows that found in the scholarly sources that I cited. There may be other definitions, however, I believe that if found in sources of equivalent quality, they should be added rather than deleting the existing definitions provided, which are in widespread use in RS. While I would agree that the term "zero day" is usually used when the vulnerability is exploited prior to discovery, unless that stipulation is found in reliable sources we cannot use original research to add it ourselves.

As for definitions of vulnerability, the one I was able to find in several sources is that it is a bug that weakens the system security. It may be that some sources define it as crossing a privilege boundary, and if so, that definition could be mentioned in the article.

The other statements that you identified as inaccurate simply reflect what it says in the cited source. In order to remove this information, we would need to find other sources that contradict these statements or establish that the sources I cited are not reliable.

I do think the article can be improved with more sources and I welcome any specific suggestions of sources to add. However, citing one source doesn't automatically mean that we must also cite other sources that disagree; depending on the circumstance this could violate WP:Reliable sources, WP:Neutral point of view, and WP:Fringe guidelines.

Reverting my edit should not be done because the previous version is so poorly sourced that most of it would be subject to deletion under the verifiability policy. Buidhe paid (talk) 03:53, 4 June 2024 (UTC)Reply

That's a strange claim. Other than for Biographies of Living Persons, there is no deletion mandate attached to WP:V. In fact, quite the opposite:

Whether and how quickly material should be initially removed for not having an inline citation to a reliable source depends on the material and the overall state of the article. In some cases, editors may object if you remove material without giving them time to provide references. Consider adding a citation needed tag as an interim step. When tagging or removing material for lacking an inline citation, please state your concern that it may not be possible to find a published reliable source, and the material therefore may not be verifiable. If you think the material is verifiable, you are encouraged to provide an inline citation yourself before considering whether to remove or tag it.
— WP:PROVEIT

Information isn't deleted from Wikipedia for being unsourced. Information is deleted for being wrong and/or unsource-able. (Or for involving WP:BLP, because nobody likes to get sued for libel or defamation.) Otherwise, the information simply needs to be cited. FeRDNYC (talk) 23:30, 6 July 2024 (UTC)Reply

I think that text has lagged behind common practice. If there is no source, an editor or reader has no way of knowing if it's sourceable or not. If I don't know if it's sourceable, I can challenge it in good faith by removing the content and it should not be restored unless someone can find a source, thus proving that it is verifiable. Buidhe paid (talk) 01:33, 7 July 2024 (UTC)Reply

At the very least, would you please consider reverting it, then doing one edit per section for easier discussion and further editing? re: Citations.. by only citing one flawed study, and not citing industry pushback, that too is not neutral. To me, WP:Neutral point of view means showing two sides of a point if there is a difference of opinion and valid citations for both. re: Your definition, cited or not, of "a bug that weakens the system security", then are default admin credentials a vulnerability or not? Because they aren't a bug to many vendors, yet it clearly allows full admin access to the system if they aren't changed. That leads down the rabbit hole of "does the vendor document them? does the vendor say to change them? does the vendor force you to change them during install?" and you get shades of whatever. InfoSec has a parroting problem, and there are cases where one hundred citations can be provided to back a choice of wording, but it doesn't mean they are correct either. Jericho347 (talk) 04:21, 4 June 2024 (UTC)Reply

Let's see the sources. Which ones specifically criticize the Rand paper? Buidhe paid (talk) 04:52, 4 June 2024 (UTC)Reply

https://blog.hboeck.de/archives/882-Zero-Days-and-Cargo-Cult-Science.html Being the first that comes to mind, not sure how that got missed. Hanno is well-respected in the industry. I cite his blog as prior work in my criticism of the paper as well (https://jericho.blog/2017/07/24/analysis-of-the-random-report-on-zero-days-and-vulnerability-rediscovery/) and further cite a different paper (https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2928758) that comes to very different conclusions than RAND. It is critical to note that RAND's paper is based on a dataset that they do not publish, so there was no direct peer review. Any review had to be on a different dataset generated to try to mimic theirs. Out of curiosity, I know you are paid to edit Wikipedia articles, but are you working in this world day to day? Jericho347 (talk) 04:20, 1 July 2024 (UTC)Reply

To be honest the reason I never came across these sources is because I didn't check for blogs or white papers not indexed on Google Scholar. Although these might qualify for WP:SPS, I'm not sure that it would make sense to cite them.

You may be right about the weaknesses in the report's methodology, but it was widely and approvingly cited in the literature. I checked sources citing the RAND paper that are published in peer-reviewed medium. I did not find any caveats about methodology. In fact, one of these referred to the RAND study as "the most sophisticated analysis of vulnerability rediscovery to date."

Some sources I found didn't mention the vulnerability overlap, but those that did were:

• How does the offense-defense balance scale? Ben Garfinkel and Allan Dafoe Taylor & Francis 2021
• Coburn, A.; Leverett, E.; Woo, G. (2018). Solving Cyber Risk: Protecting Your Company and Society. Wiley. p. 283. ISBN 978-1-119-49093-7. Retrieved 2024-07-01.
• Leal, Marcelo M.; Musgrave, Paul (2023). "Backwards from zero: How the U.S. public evaluates the use of zero-day vulnerabilities in cybersecurity". Contemporary Security Policy. 44 (3): 437–461. doi:10.1080/13523260.2023.2216112. ISSN 1352-3260.

Of these, only the last mentions another study that found a different result. Still, it is reasonable to add it to the article.

My paid editing gig (which technically ended a month ago) is in addition to a normal full time job. Buidhe paid (talk) 05:30, 1 July 2024 (UTC)Reply

My paid editing gig (which technically ended a month ago) is in addition to a normal full time job. Whereas the majority of us are entirely volunteers who contribute on our free time, without pay. FeRDNYC (talk) 23:20, 6 July 2024 (UTC)Reply

Summary of changes as a result of the Wiki99 project (before, after, diff):

• Complete rewrite from reliable sources, fixing citation needed banner
• New sections, such as definition section explaining what the topic is and varying ways of defining it according to reliable sources
• Rewrite parts of the article to be less US-centric when it comes to state actors and the stockpiling, disclosure, and/or use of zero-day vulnerabilities

Further possibilities for improvement:

• Continue to expand the article (it is about the same size as before, circa 1500 words, which leaves much room for additional details)
• Get the article to good article status

Buidhe paid (talk) 06:16, 5 August 2024 (UTC)Reply

@Buidhe paid, can the above edit request be closed? (I am doing some housecleaning of old COI edit requests). Rusalkii (talk) 18:02, 16 August 2024 (UTC)Reply

@Rusalkii Oh, it can definitely be closed, @Buidhe paid just went ahead and did it anyway after deciding they'd waited long enough that the COI somehow reached its expiration date or something. FeRDNYC (talk) 15:26, 23 August 2024 (UTC)Reply