9 ms·

A lot of these "security bugs" are not really "security bugs" in the first place. Denial of service is not resulting in people's bank accounts being emptied or

by arp242 1y ago

A lot of these "security bugs" are not really "security bugs" in the first place. Denial of service is not resulting in people's bank accounts being emptied or nude selfies being spread all over the internet. Things like "panics on certain content" like [1] or [2] are "security bugs" now. By that standard anything that fixes a potential panic is a "security bug". I've probably fixed hundreds if not thousands of "security bugs" in my career by that standard. Barely qualifies as a "security bug" yet it's rated as "6.2 Moderate" and "7.5 HIGH". To say nothing of gazillion "high severity" "regular expression DoS" nonsense and whatnot. And the worst part is all of this makes it so much harder to find actual high-severity issues. It's not harmless spam. [1]: https://github.com/gomarkdown/markdown/security/advisories/GHSA-m9xq-6h2j-65r2 https://github.com/gomarkdown/markdown/security/advisories/G... [2]: https://rustsec.org/advisories/RUSTSEC-2024-0373.html https://rustsec.org/advisories/RUSTSEC-2024-0373.html

nicce 1y ago
> A lot of these "security bugs" are not really "security bugs" in the first place. Denial of service is not resulting in people's bank accounts being emptied or nude selfies being spread all over the internet. That is not true at all. Availability is also critical. If nobody can use bank accounts, bank has no purpose.
- bogeholm 1y ago
  Security and utility are separate qualities. You’re correct that inaccessible money are useless, however one could make the case that they’re secure.
  - nicce 1y ago
    I think you are only considering the users - for the business provider the availability has larger meaning because the lack of it can bankrupt your business. It is about securing operations.
    - leni536 1y ago
      Virtually all bugs have some cost. Security bugs tend to be more expensive than others, but it doesn't mean that all very expensive bugs are security bugs.
    - em-bee 1y ago
      not paying rent can get you evicted. and not paying your medical bill can get you denied care. (in china most medical care is not very expensive, but every procedure has to be paid in advance. you probably won't be denied emergency care so your life would not be in immediate danger, but sometimes an optional scan discovers something life threatening that you weren't aware of so not being able to pay for it can put you at risk)
    - arp242 1y ago
      If a panic or null pointer deref in some library causes your entire business to go down long enough that you go bankrupt, then you probably deserve to go out of business because your software is junk.
      - nicce 1y ago
        I believe you know well that bankrupt is the worst case. Many business functions can be so critical that 24h disturbance is enough to cause high financial damages or even loss of life. A bug in the car's brakes that prevents their usage is also denial of service.
        arp242 1y ago
        Or 24h disturbance. Or indeed taking the entire system down at all. And no one is talking about safety-critical systems. You are moving the goalposts. Does a gas pedal use a markdown or XML parser? No.
        nicce 1y ago
        The point was about the importance of availability. > Does a gas pedal use a markdown or XML parser? No. Cars in general use, extensively: https://en.wikipedia.org/wiki/AUTOSAR https://en.wikipedia.org/wiki/AUTOSAR
  - marcusb 1y ago
    https://www.sentinelone.com/cybersecurity-101/cybersecurity/cia-triad/ https://www.sentinelone.com/cybersecurity-101/cybersecurity/...
  - hsbauauvhabzb 1y ago
    Inability for drug dispensers to dispense life saving drugs due to DoS has failed utility and will cost lives, would you describe that as secure?
  - burnt-resistor 1y ago
    Define what you mean by "security". Control integrity, nonrepudiation, confidentiality, privacy, ... Also, define what you mean by "utility" because there's inability to convert a Word document, inability to stop a water treatment plant from poisoning people, and ability to stop a fire requiring "utility".
- antonymoose 1y ago
  I routinely handle regex DoS complaints on front-end input validation… If a hacker wants to DoS their own browser I’m fine with that.
  - Onavo 1y ago
    Until the same library for their "isomorphic" backend..
    - hsbauauvhabzb 1y ago
      Server side rendering is all the rage again, so yeah it might be.
    - yencabulator 1y ago
      Even then the usual thing about regexp DoS is that "it's possible to write a regexp that is very very slow to process", not about the text being matched. For validation, the programmer typically controls the regexp exactly as much as they control the rest of the source code.
  - nicce 1y ago
    This depends on the context to be fair. Front-end DoS can suddenly expand into botnet DDoS if you can trigger it by just serving a specific kind of URL. E.g. search goes into endless loop that makes requests into the backend.
    - talkin 1y ago
      No. The Regex DoS class of bugs is about infinite backtracking or looping inside the regex engine. Completely isolated component, just hogging CPU inside the regex engine. It may also have ‘DoS’ in its name, but there’s no relation to network (D)DoS attacks. It could still be a security error, but only if all availability errors are for that project. But after triage, the outcome is almost always “user can hang own browser on input which isn’t likely”. And yes, it’s a pity I wrote ‘almost’, which means having to check 99% false alarms.
- arp242 1y ago
  Many of these issues are not the type of issues that will bring down an entire platform; most are of the "if I send wrong data, the server will return with a 500 for that request" or "my browser runs out of memory if I use a maliciously crafted regexp". Well, whoopdeedoo. And even if it somehow could, it's 1) just not the same thing as "I lost all my money" – that literally destroys lives and the bank not being available for a day doesn't. And 2) almost every bug has the potential to do that in at least some circumstances – circumstances with are almost never true in real-world applications.
  - nicce 1y ago
    > Many of these issues are not the type of issues that will bring down an entire platform; most are of the "if I send wrong data, the server will return with a 500 for that request" or "my browser runs out of memory if I use a maliciously crafted regexp". Well, whoopdeedoo. I wouldn't personally classify these as denial of service. They are just bugs. 500 status code does not mean that server uses more resources to process it than it typically does. OOMing your browser has no impact to others. These should be labeled correctly instead of downplaying the significance of denial of service. Like I said in my other comment, there are two entities - the end-user and the service provider. The service provider/business loses money too when customers cannot make transactions (maybe they had promise to keep specific uptime and now they need to pay compensations). Or they simple get bankrupted because they lost their users. Even customers may lose money or something else when they can't make transactions. Or maybe identification is based on bank credentials on some other service. The list goes on.
    - bawolff 1y ago
      > I wouldn't personally classify these as denial of service. They are just bugs. 500 status code does not mean that server uses more resources to process it than it typically does Not necessarily. 500 might indicate the process died, which might take more resources to startup, have cold cache, whatever. If you spam that repeatedly it could easily take down the site. I agree with your point broadly though that the risk of such things are grossly overstated, but i think we should be careful about going in the opposite direction too far.
- p1necone 1y ago
  I think it's context dependent whether DoS is on par with data loss/extraction, including whether it's actually a security issue or not. I would argue DoS for a bank (assuming it affects backend systems and not just the customer portal) would be a serious security issue given the kinds of things it could impact.
- SchemaLoad 1y ago
  If every single bug in libxml is a business ending scenario for the bank, then maybe the bank can afford to hire someone to work on those bugs rather than pestering a single volunteer.
icedchai 1y ago
Everything is a "security bug" in the right (wrong?) context, I suppose.
- cogman10 1y ago
  Well, that's sort of the problem. It's true that once upon a time, libxml was a critical path for a lot of applications. Those days are over. Protocols like SOAP are almost dead and there's not really a whole lot of new networking applications using XML in any sort of manor. The context where these issues could be security bugs is an ever-vanishing usecase. Now, find a similar bug in zlib or zstd and we could talk about it being an actual security bug.
  - fires10 1y ago
    SOAP is used far more than most people realize. I deal extensively in "cutting edge" industries that rely heavily on SOAP or SOAP based protocols. Supply chain systems and manufacturing.
    - TheCoelacanth 1y ago
      But in scenarios where the person generating the XML is untrusted? I'm aware of plenty of usage of SOAP, but only between companies that have contractual relationships with each other and who could easily sue each other if one of them tried to exploit a security bug. That greatly mitigates the risk of a security bug being exploited, especially something like a DOS attack that is easily noticed.
  - betaby 1y ago
    > there's not really a whole lot of new networking applications using XML in any sort of manor. Quite the opposite. NETCONF is XML https://en.wikipedia.org/wiki/NETCONF https://en.wikipedia.org/wiki/NETCONF and all modern ISP/Datacenter routers/switches have it underneath and most of the time as a primary automation/orchestration protocol.
  - monocasa 1y ago
    Unfortunately stuff like SAML is XML. That being said, I don't think that libxml2 has support for the dark fever dream that is XMLDSig, which SAML depends on.
viraptor 1y ago
> Denial of service is not resulting in ... DoS results in whatever the system happens to do. It may well result in bad things happening, for example stopping AV from scanning new files, breaking rate limiting systems to allow faster scanning, hogging all resources on a shared system for yourself, etc. It's rarely a security issue in isolation, but libraries are never used in isolation.
- ivanjermakov 1y ago
  DoSing autonomous vehicle brake controls...
  - bastawhiz 1y ago
    I hope my brakes aren't parsing xml
- bastawhiz 1y ago
  An AV system stopping because of a bug in a library is bad, but that's not because the library has a security bug. It's a security problem because the system itself does security. It would be wild if any bug that leads to a crash or a memory leak was a "security" bug because the library might have been used by someone somewhere in a context that has security implications. A bug in a library that does rate limiting arguably is a security issue because the library itself promises to protect against abuse. But if I make a library for running Lua in redis that ends up getting used by a rate limiting package, and my tool crashes when the input contains emoji, that's not a security issue in my library if the rate limiting library allows emails with punycode emoji in them. "Hogging all of the resources on a shared system" isn't a security bug, it's just a bug. Maybe an expensive one, but hogging the CPU or filling up a disk doesn't mean the system is insecure, just unavailable. The argument that downtime or runaway resource use due is considered a security issue but only if the problem is in someone else's code is some Big Brained CTO way of passing the buck onto open source software. If it was true, Postgres autovacuuming due to unpleasant default configuration would be up there with Heartbleed. Maybe we need a better way of alerting downstream users of packages when important bugs are fixed. But jamming these into CVEs and giving them severities above 5 is just alert noise and makes it confusing to understand what issues an organization should actually care about and fix. How do I know that the quadratic time regexp in a string formatting library used in my logging code is even going to matter? Is it more important than a bug in the URL parsing code of my linter? It's impossible to say because that responsibility was passed all the way downstream to the end user. Every single person needs to make decisions about what to upgrade and when, which is an outrageous status quo.
dcow 1y ago
Full disclosure is the only fair and humane way to handle “security” bugs, because as you point out, every bug is a security bug to someone. And adversaries will make their way onto embargo lists anyway. It’s good to see a principled maintainer other than openbsd fighting the fight.
pjmlp 1y ago
Any bug that can be used directly, or indirectly alongside others, is a security bug. A denial of service in a system related to emergency phone calls can result on people's deaths.
nottorp 1y ago
"Security" announcements seem to be of 3 kinds lately: 1. Serious. "This is a problem and it needs fixing yesterday." 2. Marketing. "We discovered that if earth had two moons and they aligned right and you had local root already you could blah blah. By the way we are selling this product that will generate a positive feedback loop for your paranoid tendencies, buy buy buy!". 3. Reputation chasing. Same as above, except they don't sell you a product, they want to establish themselves as an expert in aligning moons. Much easier to do 2 or 3 via "AI" by the way.
codedokode 1y ago
Dereferencing a null pointer is an error. It is a valid bug. The maintainer claims this is caused by allocator failure (malloc returning null), but it is still a valid bug. If you don't want to deal with malloc failures, just crash when malloc() returns null, instead of not checking malloc() result at all. The maintainer could just write a wrapper around malloc that crashes on failure and replace all calls with the wrapper. It seems like an easy fix. Because almost no software can run where there is no heap memory so it makes no sense for the program to continue. Another solution is to propagate every error back to the caller, but it is difficult and there is high probability that the caller won't bother checking the result because of laziness. A quote from a bug report [1]: > If xmlSchemaNewValue returns NULL (e.g., due to a failure of malloc), xmlSchemaDupVal checks for this and returns NULL. [1] https://gitlab.gnome.org/GNOME/libxml2/-/issues/905 https://gitlab.gnome.org/GNOME/libxml2/-/issues/905
- saurik 1y ago
  > It is a valid bug. But is it a high-severity security bug?
  - Quekid5 1y ago
    Considering that it's Undefined Behavior, quite possibly. EDIT: That said, I'm on the maintainer's side here.
    - gpderetta 1y ago
      > Considering that it's Undefined Behavior, quite possibly. Is it thought? Certainly it is according the C and C++ standards, but POSIX adds: > References to unmapped addresses shall result in a SIGSEGV signal While time-traveling-UB is a theoretical possibility, practically POSIX compliant compilers won't reorder around potentially trapping operations (they will do the reverse, they might remove a null check if made redundant by a prior potentially trapping dereference) . A real concern is if a null pointer is dereferenced with a large attacker-controlled offset that can avoid the trap, but that's more of an issue of failing to bound check.
yeyeyeyeyeyeyee 1y ago
A basic definition of a security bug is something that violates confidentiality, integrity or availability. A DoS affects the availability of an application, and as such is a real security bug. While the severity of it might be lower than a bug that allows to "empty bank accounts", and fixing it might get a lower priority, it doesn't make it any less real.
- citrin_ru 1y ago
  The problem is that DoS is the most vaguely defined category. If a library processes some inputs 1000 slower than average one may claim that this is a DoS. What if it is just 10x slower? Where to draw the line? What is the problem domain is such that some inputs just take more time and there is no way to 'fix' it? What if the input comes only from a trusted source?
- thinkharderdev 1y ago
  The CIA triad is a framework for threat modeling, not a threat model in and of itself. And what those specific terms mean will also be very system-specific.
- jcelerier 1y ago
  > A basic definition of a security bug is something that violates confidentiality, integrity or availability. who decided that "availability" was part of security?
viraptor 1y ago
Unfortunately this is timely news: https://news.sky.com/story/patient-death-linked-to-cyber-attack-on-nhs-hospital-trust-says-13388485 https://news.sky.com/story/patient-death-linked-to-cyber-att... > Denial of service is not resulting in ... Turns out they result in deaths. (This was DoS through ransomware)
- holowoodman 1y ago
  Security bugs always have a context-dependent severity. An availability problem in a medical device is far more severe than a confidentiality problem. In a cloud service, the same problems might switch their severity, downtime isn't deadly and just might affect some SLAs, but disclosing sensitive data will yield significant punishment and reputation damage. That is why I think that "severity" and the usual kinds of vulnerability scores are BS. Anyone composing a product or operating a system has to do their own assessment, taking into account all circumstances. In the context of the original article this means that it is hopeless anyways, and the maintainer's point of view is valid: in some context everything is "EXTREMELY HIGH SEVERITY, PANIC NOW!". So he might as well not care and treat everything equally. Absolutely rational decision that I do agree with.
- yencabulator 1y ago
  We're talking about a library the GNOME project wrote to read their config files. If you put that in a pacemaker, it's not GNOME's fault.
cedws 1y ago
Denial of service is a security bug. It may seem innocuous in the context of a single library, but what happens when that library finds it way into core banking systems, energy infrastructure and so on? It's a target ripe for exploitation by foreign adversaries. It has the same potential to harm people as other bugs.
- sigilis 1y ago
  The importance of the system in question is not a factor in whether something is a security bug for a dependency. The threat model of the important system should preclude it from using dependencies that are not developed with a similar security paradigm. Libxml2 simplly operates under a different regime than, as an arbitrary example, the nuclear infrastructure of a country. The library isn't a worm, it does not find its way into anything. If the bank cares about security they will write their own, use a library that has been audited for such issues, sponsor the development, or use the software provided as is. You may rejoin with the fact that it could find its way into a project as a dependency of something else. The same arguments apply at any level. If those systems crash because they balanced their entire business on code written by randos who contribute to an open source project then the organizations in question will have to deal with the consequences. If they want better, they can do what everyone is entitled to: they can contribute to, make, or pay for something better.
  - cedws 1y ago
    None of that addresses the point I made. DoS is a security bug. It doesn't matter with who or where the problem lies.
- arp242 1y ago
  By that standard almost any bug could be considered a "security bug", including things like "returns error even though my XML is valid" or "it parses this data wrong".
  - me_jumper 1y ago
    Well, yes... Differentials in parsing of the same data can definitely lead to security vulnerabilities. Just some random examples: - https://www.ias.cs.tu-bs.de/publications/parsing_differentials.pdf https://www.ias.cs.tu-bs.de/publications/parsing_differentia... - https://www.ndss-symposium.org/ndss-paper/diffcsp-finding-browser-bugs-in-content-security-policy-enforcement-through-differential-testing/ https://www.ndss-symposium.org/ndss-paper/diffcsp-finding-br... - https://www.brainonfire.net/blog/2022/04/11/what-is-parser-mismatch/ https://www.brainonfire.net/blog/2022/04/11/what-is-parser-m...
Tadpole9181 1y ago
A DoS bug is not important for almost anyone. You probably aren't targeted, you probably sanitized correctly anyway, there's not a huge impact potential anyway. But a hospital? A bank? A stock broker? Some part of the military's stack? Context is important, and what is innocuous to you may kill someone or cost millions if exploited in the wild elsewhere. It would be profoundly difficult for a machine or a convention to understand everyone's context and be able to frame it correctly, so it's left to the developers to review what the security issues are and act accordingly. I do agree the system should be improved and there's a lot of spam, but your blasé attitude toward what is or is-not a security issue seems off the mark.
kiitos 1y ago
Particularly for [1], I strongly agree with you. This is so frustrating. The claimed CWE-125 [2] has a description that says "The product reads data past the end, or before the beginning, of the intended buffer." -- which empirically does not happen in the Go Markdown parser issue. It panics, sure, but that doesn't result in any reads past the end, or before the beginning, of the intended buffer. Said another way, *there is no out-of-bounds read* happening here at all. These kinds of false-positive CVE claims are super destructive to the credibility of the CVE system in general. -- [1] https://github.com/gomarkdown/markdown/security/advisories/GHSA-m9xq-6h2j-65r2 https://github.com/gomarkdown/markdown/security/advisories/G... [2] https://cwe.mitre.org/data/definitions/125.html https://cwe.mitre.org/data/definitions/125.html
skissane 1y ago
Example I observed firsthand: a CVE was filed because GNU C Library had a memory corruption bug. Yes, the memory corruption bug was real, but the glibc core developers did not agree that it was a security issue, and I think they are right: https://sourceware.org/bugzilla/show_bug.cgi?id=29444 https://sourceware.org/bugzilla/show_bug.cgi?id=29444 Why? Because the memory corruption only happened if you manually called a semi-undocumented API. And that API was only there to support the profiler (gprof), so it being called manually almost never happened and wasn’t officially supported, in normal use the compiler would insert calls to it automatically in profiler builds and in normal production builds the undocumented API would never be called. So in practice this is impossible to exploit, except for apps which do weird things which almost nobody does (e.g. use profiler builds in production, and then expose a REST API to let a remote user stop/start the profiler at runtime) And yet, now it is listed as a real vulnerability in umpteen security vendor databases. Because the CVE database just accepts anything as a vulnerability if someone claims it is, and if the developers disagree, they just mark it as “Disputed”. But then in my experience a lot of these vendors don’t treat Disputed vulnerabilities any differently, their code analysis tools will still flag them as a “security risk” even though the vast majority of them are BS
tanewishly 1y ago
> A lot of these "security bugs" are not really "security bugs" in the first place. Denial of service ... Ackshually... Security is typically(*) classified as CIA: Confidentiality, Integrity and Availability. Denial of Service is an attack against Availability... so yeah, that kind of is inherently a security bug.

by arp242 1y ago

nicce 1y ago

> A lot of these "security bugs" are not really "security bugs" in the first place. Denial of service is not resulting in people's bank accounts being emptied or nude selfies being spread all over the internet. That is not true at all. Availability is also critical. If nobody can use bank accounts, bank has no purpose.

bogeholm 1y ago
Security and utility are separate qualities. You’re correct that inaccessible money are useless, however one could make the case that they’re secure.
- nicce 1y ago
  I think you are only considering the users - for the business provider the availability has larger meaning because the lack of it can bankrupt your business. It is about securing operations.
  - leni536 1y ago
    Virtually all bugs have some cost. Security bugs tend to be more expensive than others, but it doesn't mean that all very expensive bugs are security bugs.
  - em-bee 1y ago
    not paying rent can get you evicted. and not paying your medical bill can get you denied care. (in china most medical care is not very expensive, but every procedure has to be paid in advance. you probably won't be denied emergency care so your life would not be in immediate danger, but sometimes an optional scan discovers something life threatening that you weren't aware of so not being able to pay for it can put you at risk)
  - arp242 1y ago
    If a panic or null pointer deref in some library causes your entire business to go down long enough that you go bankrupt, then you probably deserve to go out of business because your software is junk.
    - nicce 1y ago
      I believe you know well that bankrupt is the worst case. Many business functions can be so critical that 24h disturbance is enough to cause high financial damages or even loss of life. A bug in the car's brakes that prevents their usage is also denial of service.
      - arp242 1y ago
        Or 24h disturbance. Or indeed taking the entire system down at all. And no one is talking about safety-critical systems. You are moving the goalposts. Does a gas pedal use a markdown or XML parser? No.
        nicce 1y ago
        The point was about the importance of availability. > Does a gas pedal use a markdown or XML parser? No. Cars in general use, extensively: https://en.wikipedia.org/wiki/AUTOSAR https://en.wikipedia.org/wiki/AUTOSAR
- marcusb 1y ago
  https://www.sentinelone.com/cybersecurity-101/cybersecurity/cia-triad/ https://www.sentinelone.com/cybersecurity-101/cybersecurity/...
- hsbauauvhabzb 1y ago
  Inability for drug dispensers to dispense life saving drugs due to DoS has failed utility and will cost lives, would you describe that as secure?
- burnt-resistor 1y ago
  Define what you mean by "security". Control integrity, nonrepudiation, confidentiality, privacy, ... Also, define what you mean by "utility" because there's inability to convert a Word document, inability to stop a water treatment plant from poisoning people, and ability to stop a fire requiring "utility".
antonymoose 1y ago
I routinely handle regex DoS complaints on front-end input validation… If a hacker wants to DoS their own browser I’m fine with that.
- Onavo 1y ago
  Until the same library for their "isomorphic" backend..
  - hsbauauvhabzb 1y ago
    Server side rendering is all the rage again, so yeah it might be.
  - yencabulator 1y ago
    Even then the usual thing about regexp DoS is that "it's possible to write a regexp that is very very slow to process", not about the text being matched. For validation, the programmer typically controls the regexp exactly as much as they control the rest of the source code.
- nicce 1y ago
  This depends on the context to be fair. Front-end DoS can suddenly expand into botnet DDoS if you can trigger it by just serving a specific kind of URL. E.g. search goes into endless loop that makes requests into the backend.
  - talkin 1y ago
    No. The Regex DoS class of bugs is about infinite backtracking or looping inside the regex engine. Completely isolated component, just hogging CPU inside the regex engine. It may also have ‘DoS’ in its name, but there’s no relation to network (D)DoS attacks. It could still be a security error, but only if all availability errors are for that project. But after triage, the outcome is almost always “user can hang own browser on input which isn’t likely”. And yes, it’s a pity I wrote ‘almost’, which means having to check 99% false alarms.
arp242 1y ago
Many of these issues are not the type of issues that will bring down an entire platform; most are of the "if I send wrong data, the server will return with a 500 for that request" or "my browser runs out of memory if I use a maliciously crafted regexp". Well, whoopdeedoo. And even if it somehow could, it's 1) just not the same thing as "I lost all my money" – that literally destroys lives and the bank not being available for a day doesn't. And 2) almost every bug has the potential to do that in at least some circumstances – circumstances with are almost never true in real-world applications.
- nicce 1y ago
  > Many of these issues are not the type of issues that will bring down an entire platform; most are of the "if I send wrong data, the server will return with a 500 for that request" or "my browser runs out of memory if I use a maliciously crafted regexp". Well, whoopdeedoo. I wouldn't personally classify these as denial of service. They are just bugs. 500 status code does not mean that server uses more resources to process it than it typically does. OOMing your browser has no impact to others. These should be labeled correctly instead of downplaying the significance of denial of service. Like I said in my other comment, there are two entities - the end-user and the service provider. The service provider/business loses money too when customers cannot make transactions (maybe they had promise to keep specific uptime and now they need to pay compensations). Or they simple get bankrupted because they lost their users. Even customers may lose money or something else when they can't make transactions. Or maybe identification is based on bank credentials on some other service. The list goes on.
  - bawolff 1y ago
    > I wouldn't personally classify these as denial of service. They are just bugs. 500 status code does not mean that server uses more resources to process it than it typically does Not necessarily. 500 might indicate the process died, which might take more resources to startup, have cold cache, whatever. If you spam that repeatedly it could easily take down the site. I agree with your point broadly though that the risk of such things are grossly overstated, but i think we should be careful about going in the opposite direction too far.
p1necone 1y ago
I think it's context dependent whether DoS is on par with data loss/extraction, including whether it's actually a security issue or not. I would argue DoS for a bank (assuming it affects backend systems and not just the customer portal) would be a serious security issue given the kinds of things it could impact.
SchemaLoad 1y ago
If every single bug in libxml is a business ending scenario for the bank, then maybe the bank can afford to hire someone to work on those bugs rather than pestering a single volunteer.

icedchai 1y ago

Everything is a "security bug" in the right (wrong?) context, I suppose.

cogman10 1y ago
Well, that's sort of the problem. It's true that once upon a time, libxml was a critical path for a lot of applications. Those days are over. Protocols like SOAP are almost dead and there's not really a whole lot of new networking applications using XML in any sort of manor. The context where these issues could be security bugs is an ever-vanishing usecase. Now, find a similar bug in zlib or zstd and we could talk about it being an actual security bug.
- fires10 1y ago
  SOAP is used far more than most people realize. I deal extensively in "cutting edge" industries that rely heavily on SOAP or SOAP based protocols. Supply chain systems and manufacturing.
  - TheCoelacanth 1y ago
    But in scenarios where the person generating the XML is untrusted? I'm aware of plenty of usage of SOAP, but only between companies that have contractual relationships with each other and who could easily sue each other if one of them tried to exploit a security bug. That greatly mitigates the risk of a security bug being exploited, especially something like a DOS attack that is easily noticed.
- betaby 1y ago
  > there's not really a whole lot of new networking applications using XML in any sort of manor. Quite the opposite. NETCONF is XML https://en.wikipedia.org/wiki/NETCONF https://en.wikipedia.org/wiki/NETCONF and all modern ISP/Datacenter routers/switches have it underneath and most of the time as a primary automation/orchestration protocol.
- monocasa 1y ago
  Unfortunately stuff like SAML is XML. That being said, I don't think that libxml2 has support for the dark fever dream that is XMLDSig, which SAML depends on.

viraptor 1y ago

> Denial of service is not resulting in ... DoS results in whatever the system happens to do. It may well result in bad things happening, for example stopping AV from scanning new files, breaking rate limiting systems to allow faster scanning, hogging all resources on a shared system for yourself, etc. It's rarely a security issue in isolation, but libraries are never used in isolation.

ivanjermakov 1y ago
DoSing autonomous vehicle brake controls...
- bastawhiz 1y ago
  I hope my brakes aren't parsing xml
bastawhiz 1y ago
An AV system stopping because of a bug in a library is bad, but that's not because the library has a security bug. It's a security problem because the system itself does security. It would be wild if any bug that leads to a crash or a memory leak was a "security" bug because the library might have been used by someone somewhere in a context that has security implications. A bug in a library that does rate limiting arguably is a security issue because the library itself promises to protect against abuse. But if I make a library for running Lua in redis that ends up getting used by a rate limiting package, and my tool crashes when the input contains emoji, that's not a security issue in my library if the rate limiting library allows emails with punycode emoji in them. "Hogging all of the resources on a shared system" isn't a security bug, it's just a bug. Maybe an expensive one, but hogging the CPU or filling up a disk doesn't mean the system is insecure, just unavailable. The argument that downtime or runaway resource use due is considered a security issue but only if the problem is in someone else's code is some Big Brained CTO way of passing the buck onto open source software. If it was true, Postgres autovacuuming due to unpleasant default configuration would be up there with Heartbleed. Maybe we need a better way of alerting downstream users of packages when important bugs are fixed. But jamming these into CVEs and giving them severities above 5 is just alert noise and makes it confusing to understand what issues an organization should actually care about and fix. How do I know that the quadratic time regexp in a string formatting library used in my logging code is even going to matter? Is it more important than a bug in the URL parsing code of my linter? It's impossible to say because that responsibility was passed all the way downstream to the end user. Every single person needs to make decisions about what to upgrade and when, which is an outrageous status quo.

dcow 1y ago

Full disclosure is the only fair and humane way to handle “security” bugs, because as you point out, every bug is a security bug to someone. And adversaries will make their way onto embargo lists anyway. It’s good to see a principled maintainer other than openbsd fighting the fight.

pjmlp 1y ago

Any bug that can be used directly, or indirectly alongside others, is a security bug. A denial of service in a system related to emergency phone calls can result on people's deaths.

nottorp 1y ago

"Security" announcements seem to be of 3 kinds lately: 1. Serious. "This is a problem and it needs fixing yesterday." 2. Marketing. "We discovered that if earth had two moons and they aligned right and you had local root already you could blah blah. By the way we are selling this product that will generate a positive feedback loop for your paranoid tendencies, buy buy buy!". 3. Reputation chasing. Same as above, except they don't sell you a product, they want to establish themselves as an expert in aligning moons. Much easier to do 2 or 3 via "AI" by the way.

codedokode 1y ago

Dereferencing a null pointer is an error. It is a valid bug. The maintainer claims this is caused by allocator failure (malloc returning null), but it is still a valid bug. If you don't want to deal with malloc failures, just crash when malloc() returns null, instead of not checking malloc() result at all. The maintainer could just write a wrapper around malloc that crashes on failure and replace all calls with the wrapper. It seems like an easy fix. Because almost no software can run where there is no heap memory so it makes no sense for the program to continue. Another solution is to propagate every error back to the caller, but it is difficult and there is high probability that the caller won't bother checking the result because of laziness. A quote from a bug report [1]: > If xmlSchemaNewValue returns NULL (e.g., due to a failure of malloc), xmlSchemaDupVal checks for this and returns NULL. [1] https://gitlab.gnome.org/GNOME/libxml2/-/issues/905 https://gitlab.gnome.org/GNOME/libxml2/-/issues/905

saurik 1y ago
> It is a valid bug. But is it a high-severity security bug?
- Quekid5 1y ago
  Considering that it's Undefined Behavior, quite possibly. EDIT: That said, I'm on the maintainer's side here.
  - gpderetta 1y ago
    > Considering that it's Undefined Behavior, quite possibly. Is it thought? Certainly it is according the C and C++ standards, but POSIX adds: > References to unmapped addresses shall result in a SIGSEGV signal While time-traveling-UB is a theoretical possibility, practically POSIX compliant compilers won't reorder around potentially trapping operations (they will do the reverse, they might remove a null check if made redundant by a prior potentially trapping dereference) . A real concern is if a null pointer is dereferenced with a large attacker-controlled offset that can avoid the trap, but that's more of an issue of failing to bound check.

yeyeyeyeyeyeyee 1y ago

A basic definition of a security bug is something that violates confidentiality, integrity or availability. A DoS affects the availability of an application, and as such is a real security bug. While the severity of it might be lower than a bug that allows to "empty bank accounts", and fixing it might get a lower priority, it doesn't make it any less real.

citrin_ru 1y ago
The problem is that DoS is the most vaguely defined category. If a library processes some inputs 1000 slower than average one may claim that this is a DoS. What if it is just 10x slower? Where to draw the line? What is the problem domain is such that some inputs just take more time and there is no way to 'fix' it? What if the input comes only from a trusted source?
thinkharderdev 1y ago
The CIA triad is a framework for threat modeling, not a threat model in and of itself. And what those specific terms mean will also be very system-specific.
jcelerier 1y ago
> A basic definition of a security bug is something that violates confidentiality, integrity or availability. who decided that "availability" was part of security?

viraptor 1y ago

Unfortunately this is timely news: https://news.sky.com/story/patient-death-linked-to-cyber-attack-on-nhs-hospital-trust-says-13388485 https://news.sky.com/story/patient-death-linked-to-cyber-att... > Denial of service is not resulting in ... Turns out they result in deaths. (This was DoS through ransomware)

holowoodman 1y ago
Security bugs always have a context-dependent severity. An availability problem in a medical device is far more severe than a confidentiality problem. In a cloud service, the same problems might switch their severity, downtime isn't deadly and just might affect some SLAs, but disclosing sensitive data will yield significant punishment and reputation damage. That is why I think that "severity" and the usual kinds of vulnerability scores are BS. Anyone composing a product or operating a system has to do their own assessment, taking into account all circumstances. In the context of the original article this means that it is hopeless anyways, and the maintainer's point of view is valid: in some context everything is "EXTREMELY HIGH SEVERITY, PANIC NOW!". So he might as well not care and treat everything equally. Absolutely rational decision that I do agree with.
yencabulator 1y ago
We're talking about a library the GNOME project wrote to read their config files. If you put that in a pacemaker, it's not GNOME's fault.

cedws 1y ago

Denial of service is a security bug. It may seem innocuous in the context of a single library, but what happens when that library finds it way into core banking systems, energy infrastructure and so on? It's a target ripe for exploitation by foreign adversaries. It has the same potential to harm people as other bugs.

sigilis 1y ago
The importance of the system in question is not a factor in whether something is a security bug for a dependency. The threat model of the important system should preclude it from using dependencies that are not developed with a similar security paradigm. Libxml2 simplly operates under a different regime than, as an arbitrary example, the nuclear infrastructure of a country. The library isn't a worm, it does not find its way into anything. If the bank cares about security they will write their own, use a library that has been audited for such issues, sponsor the development, or use the software provided as is. You may rejoin with the fact that it could find its way into a project as a dependency of something else. The same arguments apply at any level. If those systems crash because they balanced their entire business on code written by randos who contribute to an open source project then the organizations in question will have to deal with the consequences. If they want better, they can do what everyone is entitled to: they can contribute to, make, or pay for something better.
- cedws 1y ago
  None of that addresses the point I made. DoS is a security bug. It doesn't matter with who or where the problem lies.
arp242 1y ago
By that standard almost any bug could be considered a "security bug", including things like "returns error even though my XML is valid" or "it parses this data wrong".
- me_jumper 1y ago
  Well, yes... Differentials in parsing of the same data can definitely lead to security vulnerabilities. Just some random examples: - https://www.ias.cs.tu-bs.de/publications/parsing_differentials.pdf https://www.ias.cs.tu-bs.de/publications/parsing_differentia... - https://www.ndss-symposium.org/ndss-paper/diffcsp-finding-browser-bugs-in-content-security-policy-enforcement-through-differential-testing/ https://www.ndss-symposium.org/ndss-paper/diffcsp-finding-br... - https://www.brainonfire.net/blog/2022/04/11/what-is-parser-mismatch/ https://www.brainonfire.net/blog/2022/04/11/what-is-parser-m...

Tadpole9181 1y ago

A DoS bug is not important for almost anyone. You probably aren't targeted, you probably sanitized correctly anyway, there's not a huge impact potential anyway. But a hospital? A bank? A stock broker? Some part of the military's stack? Context is important, and what is innocuous to you may kill someone or cost millions if exploited in the wild elsewhere. It would be profoundly difficult for a machine or a convention to understand everyone's context and be able to frame it correctly, so it's left to the developers to review what the security issues are and act accordingly. I do agree the system should be improved and there's a lot of spam, but your blasé attitude toward what is or is-not a security issue seems off the mark.

kiitos 1y ago

Particularly for [1], I strongly agree with you. This is so frustrating. The claimed CWE-125 [2] has a description that says "The product reads data past the end, or before the beginning, of the intended buffer." -- which empirically does not happen in the Go Markdown parser issue. It panics, sure, but that doesn't result in any reads past the end, or before the beginning, of the intended buffer. Said another way, *there is no out-of-bounds read* happening here at all. These kinds of false-positive CVE claims are super destructive to the credibility of the CVE system in general. -- [1] https://github.com/gomarkdown/markdown/security/advisories/GHSA-m9xq-6h2j-65r2 https://github.com/gomarkdown/markdown/security/advisories/G... [2] https://cwe.mitre.org/data/definitions/125.html https://cwe.mitre.org/data/definitions/125.html

skissane 1y ago

Example I observed firsthand: a CVE was filed because GNU C Library had a memory corruption bug. Yes, the memory corruption bug was real, but the glibc core developers did not agree that it was a security issue, and I think they are right: https://sourceware.org/bugzilla/show_bug.cgi?id=29444 https://sourceware.org/bugzilla/show_bug.cgi?id=29444 Why? Because the memory corruption only happened if you manually called a semi-undocumented API. And that API was only there to support the profiler (gprof), so it being called manually almost never happened and wasn’t officially supported, in normal use the compiler would insert calls to it automatically in profiler builds and in normal production builds the undocumented API would never be called. So in practice this is impossible to exploit, except for apps which do weird things which almost nobody does (e.g. use profiler builds in production, and then expose a REST API to let a remote user stop/start the profiler at runtime) And yet, now it is listed as a real vulnerability in umpteen security vendor databases. Because the CVE database just accepts anything as a vulnerability if someone claims it is, and if the developers disagree, they just mark it as “Disputed”. But then in my experience a lot of these vendors don’t treat Disputed vulnerabilities any differently, their code analysis tools will still flag them as a “security risk” even though the vast majority of them are BS

tanewishly 1y ago

> A lot of these "security bugs" are not really "security bugs" in the first place. Denial of service ... Ackshually... Security is typically(*) classified as CIA: Confidentiality, Integrity and Availability. Denial of Service is an attack against Availability... so yeah, that kind of is inherently a security bug.