4 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 o

• 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
            • int_19h 1y ago
              Great, then we have someone with both resources and an incentive to write and maintain an XML parser with strict availability guarantees.
              • fodkodrasz 1y ago
                Automotive companies pay big buck to vendors who supply certified tools/libraries, because getting stuff certified is lot of work/time. This also means that those stuff are often outdated, and a pain to work with, yet their vendors are not expected to function as charities, as often expected by FLOSS authors, esp. when releasing their code under BSD/MIT licenses and then getting eaten by the sharks.
            • fodkodrasz 1y ago
              AUTOSAR xml-s are compile-time/integration time toolchain metadata mostly in my memory. Yet this is off topic for the libxml funding/bug debate. For embedded mission critical C libxml is surely unsuitable, just like 99.99% of the open source third party code. Also unneeded. If crashes the app on the developer machine or in the build pipeline if it runs out of memory? Who cares (from a safety point of view)? That has nothing to do with availability of safety critical systems in the car.
  • 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.