[IlikeKitties]

Responsible Disclosures and their consequences have been a disaster for the human race. Companies need to feel a lot more pain a lot more often in order for them to take the security of their customers a lot more serious. If you just give them month to fix an issue and spoon-feed them the solution it's just another ticket in their Backlog. But if every other security issue becomes enough news online that their CEOs are involved and a solution must be find in hours not month, they will become a lot more proactive. Of course it's the end users that would suffer most from this. But then again, they buy ASUS so they suffer already...

[jeroenhd]

I think ASUS' turnaround time on this was quite good, I don't see the problem here. ASUS didn't deny the bug, didn't threaten to prosecute anyone for reverse engineering their software, and quickly patched their software. I have no doubt that before the days of responsible disclosure, this process would've taken months and might have involved the police.

Normal people don't care about vulnerabilities. They use phones that haven't received updates in three years to do their finances. If you spam the news with CVEs, people will just get tired of hearing about how every company sucks and become apathetic once there's a real threat.

The EU is working on a different solution. Stores are not permitted to sell products with known vulnerabilities under new cybersecurity regulations. That means if ASUS keeps fucking up, their motherboards become dead stock and stores won't want to sell their hardware anymore. That's not just computer hardware, but also smart fridges and smart washing machines. Discover a vulnerability in your dish washer and you may end up costing the dish washer industry millions in unusable stock if their vendors haven't bothered to add a way to update the firmware.

[ycombinatrix]

>They say “This issue is limited to motherboards and does not affect laptops, desktop computers”, however this affects any computer including desktops/laptops that have DriverHub installed

>instead of them saying it allows for arbitrary/remote code execution they say it “may allow untrusted sources to affect system behaviour”.

Sounds like Asus did in fact deny the bug.

[bayindirh]

I call this "save the face" move. I once reported suspected card skimming at an ATM. The skimmer was integrated, so it would be an inside job. The bank said ATMs can malfunction sometimes, but both ATMs are replaced with different ones in a couple of days.

[buzer]

> Stores are not permitted to sell products with known vulnerabilities under new cybersecurity regulations.

What are the specifics on that? Like does the vulnerability need to be public or is it enough if just the vendor knows about it? Does everyone need to stop selling it right away if new vulnerability is discovered or do they some time patch it? I'm pretty sure software like Windows almost definitely has some unfixed vulnerabilities that Microsoft knows about and is in process of fixing every single day of the year. Currently even if they do have a fix, they would end up postponing it until next patch Tuesday.

And what even is "vulnerability" in this context? Remote RCE? DRM bypass?

[chillax]

Probably refering to CRA - Cyber Resilience Act

https://schjodt.com/news/the-cyber-resilience-act-enters-int...

https://digital-strategy.ec.europa.eu/en/policies/cyber-resi...

https://ec.europa.eu/commission/presscorner/detail/en/qanda_...

[jeroenhd]

The full legal text doesn't fit in a HN comment, but I believe this is the meat of the description: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:...

Note that in the legal text above there is language stating what requirements from the annexes applies to what hard/software.

As far as I know (I haven't read the text fully) selling stuff is fine if the end user can update their software.

There is no clear description of what "vulnerability" entails. The definitions do include things like:

    ‘vulnerability’ means a weakness, susceptibility or flaw of a product with digital elements that can be exploited by a cyber threat;
    ‘cyber threat’ means a cyber threat as defined in Article 2, point (8), of Regulation (EU) 2019/881;
    ‘cybersecurity risk’ means the potential for loss or disruption caused by an incident and is to be expressed as a combination of the magnitude of such loss or disruption and the likelihood of occurrence of the incident;

[buzer]

Thanks. I tried to look into this a bit more and it sounds quite a few places are interpreting "be made available on the market without known exploitable vulnerabilities" as that there cannot be any known vulnerability at the release date. Germany's Federal Office for Information Security (BSI, https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publicat...) seems to be even looser with the definition, on 5.3.2.3 they actually say it's just "SHOULD", not "MUST". No clue what they are basing that on.

The "including the possibility to reset the product to its original state" is interesting one, would that prevent manufacturers from not allowing user to downgrade to original version (via eFuses)? 5.3.3.1 on those guidelines does say "initial or newest version", but that doesn't really sound like original state.

[Polizeiposaune]

"Stores are not permitted to sell products with known vulnerabilities under new cybersecurity regulations."

Do stores have to patch known vulnerabilities before releasing the product to customers or can customers install the patch?

[jeroenhd]

I believe it's okay to let customers install the patch. The regulation itself can be found here: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML

Basically, the manufacturer has to issue a patch, and the distributor has to ensure that the patch is available before selling the vulnerable devices. Without secure software, the product is essentially CE-incompliant, which means it practically isn't allowed to be sold.

IANAL though.

[MrBuddyCasino]

This sounds like another bureaucratic nightmare. Who is going to track this?

[geoffpado]

Grocery stores everywhere have the ability to pull recalled products off their shelves pretty quickly. I did it fairly regularly at my first job as a shelf-stocker for a small local store in rural MO. Somehow we made it work, so clearly someone figured out how to deal with that "bureaucratic nightmare". I see no reason why hardware products that are on a list due to known issues would be any different.

[MrBuddyCasino]

Thats actually a good analogy, well said!

An immediate sales stop and recall is certainly appropriate when food endangers people's health, I'm not sure it is the right decision in this case. You could give manufacturers some time to fix it, and only then stopping the sales. This way they would still be incentivised to quickly make a fix, but avoid the potentially huge economic downside, which will lead to higher barriers of entry and probably further consolidation, hurting consumers in a different way. Remember that regulation always benefits the incumbents.

[mschuster91]

You know, vendors could just do the right thing and invest into security so that they don't ship vulnerable stuff from the start...

[MrBuddyCasino]

I'll pass the message on, if you kindly sign this contract to never have a car accident for the rest of your life. Just do the right thing and invest in your driving skills.

[aspenmayer]

Stores don’t have the capability to do this. These aren’t car dealerships we’re talking about here, more like Walmart or Best Buy. It would take a recall/RMA or online firmware updates, both of which already exist and are widely used.

[jillyboel]

It's still hilarious how the police will get involved for you tinkering with your own computer inside your own home.

[holowoodman]

"Responsible" disclosure is paradoxically named because actually it is completely irresponsible. The vast majority of corporations handle disclosures badly in that they do not fix in time (i.e. a week), do not attribute properly, do not inform their users and do not learn from their mistakes. Irresponsibly delayed limited disclosure reinforces those behaviors.

The actually responsible thing to do is to disclose immediately, fully and publically (and maybe anonymously to protect yourself). Only after the affected company has repeatedly demonstrated that they do react properly, they might earn the right for a very time-limited heads-up of say 5 work days or something.

That irresponsibly delayed limited disclosure is even called "responsible disclosure" is an instance of newspeak.

[stavros]

I make software. If you discover a vulnerability, why would you put my tens of thousands of users at risk, instead of emailing me and have the vulnerability fixed in an hour before disclosing?

I get that companies sit on vulnerabilities, but isn't fair warning... fair?

[ang_cire]

> why would you put my tens of thousands of users at risk, instead of emailing me and have the vulnerability fixed in an hour before disclosing

You've got it backwards.

The vuln exists, so the users are already at risk; you don't know who else knows about the vuln, besides the people who reported it.

Disclosing as soon as known means your customers can decide for themselves what action they want to take. Maybe they wait for you, maybe they kill the service temporarily, maybe they kill it permanently. That's their choice to make.

Denying your customers information until you've had time to fix the vuln, is really just about taking away their agency in order to protect your company's bottom line, by not letting them know they're at risk until you can say, "but we fixed it already, so you don't need to stop using us to secure yourself, just update!"

[renmillar]

You're making an assumption that doesn't match reality - vulnerability discovery doesn't work like some efficient market. Yes, intelligence agencies and sophisticated criminal groups might find 0-days, but they typically target selectively, not deploying exploits universally.

The real threat comes from the vast number of opportunistic attackers who lack the skills to discover vulnerabilities themselves but are perfectly capable of weaponizing public disclosures and proof-of-concepts. These bottom-feeders represent a much larger attack surface that only materializes after public disclosure.

Responsible disclosure gives vendors time to patch before this larger wave of attackers gets access to the vulnerability information. It's not about protecting company reputation - it's about minimizing the window of mass exploitation.

Timing the disclosure to match the fix release is actually the most practical approach for everyone involved. It eliminates the difficult choice customers would otherwise face - either disrupt their service entirely or knowingly remain vulnerable.

Most organizations simply can't afford the downtime from abruptly cutting off a service, nor can they accept the risk of continuing with a known vulnerability. Providing the fix simultaneously with disclosure allows for orderly patch deployment without service interruption.

This coordinated approach minimizes disruption while still addressing the security issue - a balanced solution that protects both the security and continuity needs of end users.

[ang_cire]

I understand the arguments for the current system, I just don't agree that disruption is worse than loss of agency. Your position inevitably ends up arguing for a paternalistic approach, as you are when you say

> It eliminates the difficult choice customers would otherwise face - either disrupt their service entirely or knowingly remain vulnerable.

You decided they are better off not having to make that choice, so you make it for them whether they like it or not.

In fact, you made the worst choice for them, because you chose that they'd remain unknowingly vulnerable, so they can't even put in temporary mitigations or extra monitoring, or know to be on the lookout for anything strange.

> Most organizations simply can't afford the downtime from abruptly cutting off a service, nor can they accept the risk of continuing with a known vulnerability.

Now this is an interesting part, because the first half is true depending on the service, but bad (that's a BCDR or internet outage issue waiting to happen), and the second half is just wrong (show me a company that doesn't know and accept that they have past-SLA vulns unpatched, criticals included, and I'll show you a company that's lying either to themselves or their customers).

> This coordinated approach minimizes disruption while still addressing the security issue - a balanced solution that protects both the security and continuity needs of end users.

This is not a balanced approach, this is a lowest-common-denominator approach that favors service providers over service users. You don't know if it protects someone's security needs, because people have different security needs: a journalist being targeted by a state actor can have the same iphone as someone's retired grandma, or infotainment system, or home assistant, etc.

I've managed bug bounty and unpaid disclosure programs, professionally, and I know firsthand that it's the company's interests that responsible disclosure serves, first and foremost.

[rvnx]

Let’s imagine you found how to steal funds from a bank, best is to let them know that you are concerned (as a customer) for the safety of your own funds.

If they do nothing after a reasonable amount of time, escalate to regulators or change bank. Then once they release information that some processes are changed: “thanks to XXX working at YYY for helping us during it”. You win, they win, clients win, everybody wins.

Unwanted public disclosure directly leads to public exploitation, there is nothing good at all about it.

For example, there is a RCE in Discord (totally statistically certain due to the rendering engine, just not public yet), and this is going to be exploited only if someone shares the technical details.

If you don’t disclose it, it’s not like someone else will discover it tomorrow. It’s possible, but not more likely than it was yesterday. If you disclose it, you make sure that everybody with malicious intent knows about it.

[leoqa]

A middle ground: announce that Discord is insecure and you’ve found a zero-day. Perhaps a trusted 3rd party exists that can attest publicly (Mitre?) after you show a demo.

Then customers are aware, Discord is pressured to act/shamed, and then you proceed with your private disclosure with a window.

[holowoodman]

You report that to the bank, the bank pays off you and the robbers to keep things quiet. 5 years later, things are discovered and you go to jail for aiding and abetting.

Or you report immediately to the press, press reports, police secures bank building, investigates sloppy practices, customers win, you are a hero, inept banksters and robbers go to jail.

[fastball]

Increasing the chance of a bad actor actually doing something with a vulnerability seems bad, actually. You're effectively shifting responsibility to consumers, who are probably not going to see a CVE for one of the dozens of softwares they use every day.

[ang_cire]

> You're effectively shifting responsibility to consumers, who are probably not going to see a CVE for one of the dozens of softwares they use every day.

Which is again, a problem created by the companies themselves. The way this should work is that the researcher discloses to the company, and the company reaches out to and informs their customers immediately. Then they fix it.

But instead companies refuse to tell their customers when they're at risk, and make it out to be the researchers that are endangering people, when those researchers don't wait on an arbitrary, open-ended future date.

> Increasing the chance of a bad actor actually doing something with a vulnerability seems bad, actually.

Unless you know who knows what already, this is unprovable supposition (it could already be being exploited in the wild), and the arguments about whether POC code is good or bad is well tread, and covers this question.

You are just making the argument that obscurity is security, and it's not.

[layer8]

> The way this should work is that the researcher discloses to the company, and the company reaches out to and informs their customers immediately. Then they fix it.

If that was common practice, bad actors would make sure to be a registered customer of all interesting targets, so that they get informed early about vulnerabilities before there is a fix. And it would create a black market for that information.

When someone gets the information “Asus BIOS has an RCE vulnerability related to driver installation”, they’ll be able to figure out the details quickly with high probability, like OP did.

[fastball]

You are shopping at a store along with some other customers. When entering the store, you notice that an employee of the store has left a large knife outside, under a trashcan. A shady character is wandering around the store, looking for someone to steal from, but hasn't figured out the right angle of attack yet. At some point, you (ever the responsible citizen) stand up on a table in the store and yell "Hey! Just wanted to let everyone know that there is a large, scary looking knife under the trash can outside. You have been warned." You then climb down from the table and leave the store. Knives are dangerous, after all. Immediately after your announcement the shady character goes and grabs the knife, which they then use to stab a customer on their way out of the store and steal their stuff. Unfortunately the customer didn't hear your announcement about the impending danger because they were in the toilet at the time.

Whew, thank god for public disclosure with no prior warning to the people who would've been best equipped to retrieve their knife.

---

This was clearly not the best way to handle the situation.

Sure, you didn't know that the thief was unaware of the knife before your announcement, but he sure as shit was aware afterwards. You not knowing what they know is not a good reason to indiscriminately yell to no one in particular.

I did not make the argument that obscurity is security. The knife being under a trashcan is a risk and should be addressed by management. But that doesn't mean non-obscurity automatically improves security.

[strken]

Why should it work that way? Disclosing the vuln before fixing it seems like a surefire way for my mum to lose her life's savings. Why do you hate my mum so much?

[lelanthran]

I disagree. The vast majority of script kiddies don't know about the zero day.

Instead of just one bad actor using that vulnerability on Andrew select targets, your proposal will have a few tens of thousands bots performing drive by attacks on millions of victims.

[neilv]

I think one point being made is that (in this example) you would've been much less careless about shipping the vulnerability, if you knew you'd be held accountable for it.

With current practice, you can be as sloppy and reckless as you want, and when you create vulnerabilities because of that, you somehow almost push the "responsibility" onto the person who discovers it, and you aren't discouraged from recklessness.

Personally, I think we need to keep the good part of responsible disclosure, but also phase in real penalties for the parties responsible for creating vulnerabilities that are exploited.

(A separate matter is the responsibility of parties that exploit the vulnerabilities. Some of those may warrant stronger criminal-judicial or military responses than they appear to receive.)

Ideal is a societal culture of responsibility, but in the US in some ways we've been conditioning people to be antisocial for decades, including by elevating some of the most greedy and arrogant to role models.

[haswell]

> you would've been much less careless about shipping the vulnerability, if you knew you'd be held accountable for it

I have a problem with this framing. Sure, some vulnerabilities are the result of recklessness, and there’s clearly a problem to be solved when it comes to companies shipping obviously shoddy code.

But many vulnerabilities happen despite great care being taken to ship quality code. It is unfortunately the nature of the beast. A sufficiently complex system will result in vulnerabilities even a careful person could not have predicted.

To me, the issue is that software now runs the world, despite these inherent limitations of human developers and the process of software development. It’s deployed in ever more critical situations, despite the industry not having well defined and enforceable standards like you’d find in some engineering disciplines.

What you’re describing is a scenario that would force developers to just stop making software, on top of putting significantly more people at risk.

I still believe the industry has a problem that needs to be solved, and it needs a broad culture shift in the dev community, but disagree that shining a bright light on every hole such that it causes massive harm to “make devs accountable” is a good or even reasonable solution.

[neilv]

I think that culture shift will have to come from the top in business -- the CEO and the board.

At this point, the software development field is about operating within the system decided by those others, with the goal of personally getting money.

After you've made the CEO and board accountable, I think dev culture will adapt almost immediately.

Beware of attempts to push engineering licensing or certifications, etc. as a solution here. Based on everything we've seen in the field in recent decades, that will just be used at the corporate level as a compliance letter-but-not-spirit tool to evade responsibility (as well as a moat to upstart competitors), and a vendor market opportunity for incompetent leeches.

First you make CEO and board accountable, and then let the dev culture change, and then, once you have a culture of people taking responsibility, then you'll have the foundation to add in licensing (designed in good faith) as an extra check on that, if that looks worthwhile.

[pixl97]

>What you’re describing is a scenario that would force developers to just stop making software, on top of putting significantly more people at risk.

Good. I work in code security/SBOM, the amount of shit software from entities that should otherwise be creating secure software should worry you.

Businesses care very little about security and far more about pushing the new feature fast. And why not, there is no real penalty for it.

[haswell]

What is your position on open source projects? Should someone who writes software in their spare time who decides to share it publicly be forced to stop doing so?

I’m more open to harsher limits on commercial software, especially in certain categories. But underneath all of this we’re discussing an ecosystem and a culture which can’t be cleanly separated.

Some of the binary thinking I see in this thread would be deeply damaging to parts of that ecosystem with potentially major unintended consequence. Open source software is critically important for human rights/freedom. Taken at face value, many of the comments here directly threaten that freedom.

I’m not assuming that’s your stance, but I’m curious how you see the open source aspect of this considering how significant its role is - especially in the security space.

[fulafel]

> A sufficiently complex system will result in vulnerabilities even a careful person could not have predicted.

I think as a field we're actually reasonably good at quantifying most of these risks and applying practices to reduce the risk. Once in a blue moon you do have "didn't see that coming" cases but those cause a very minor part of the damage that people suffer because of sw vulnerabilities. Most harm is caused by classes of vulnerabilities that are boringly pedestrian.

[technion]

The problem with a fair warning is that once I email you such a warning, I'll never be able to anonymously publish it no matter how much you ignore the report. Then the fair thing becomes I never go public I'm confident you'll call lawyers.

[SahAssar]

So can't you disclose it anonymously? I'm pretty sure most people who are savvy enough to find zero-days know how to get an email address anonymously.

[technion]

All ill say is: try it in practice. You'll quick find it dismissed as "not professional" and people will quickly claim its "irresponsible" for that reason.

[layer8]

Why would you care, if you publish it anonymously?

[frainfreeze]

Can't you just send it from anon email?

[beeflet]

Because there is an information disparity I could profit from instead of doing free work for you. Even if that disparity is just "posting the vuln to my blog" to get e-famous.

[rakoo]

According to the post above, if you earned enough reputation then you might be given that one-hour window for fixing before disclosing. The issue isn't so much about whether or not there should be a "private" window but how long it lasts, especially when the editor is a multi-billion company

[haswell]

Let’s not forget the end users in this scenario, who will not be able to react to this as quickly as a billion dollar company regardless of how well they notify their customers.

[rakoo]

Absolutely, which is yet another reason why this abstraction from the conditions of creation of anything tech-related is something that should be eliminated

[holowoodman]

Fair warning through "responsible" disclosure was abused again and again and again. Why should I trust company no 1000 after 999 have mislead bug reporters, the public, their customers and the rest of the world about their own "just an hour"?

[v3ss0n]

You made the software, you have your paid customers, you are responsible for security of your customers. If you have an RCE that's your problem and you gotta fix it.

[JonChesterfield]

An hour, sure. Frequently companies sit on it for months.

[b112]

Many types of vulnerabilities cannot be resolved in one hour. Some require complex thought to resolved.

One hour is absurd for another reason, what timezone are you in? And they? What country, and therefore, is it a holiday?

You may say "but vulnerability", and yes. 100% no heel dragging.

But all companies are not staffed with 100k devs, and a few days, a week is a balance between letting every script kiddie know, and the potenital that it may be exploited in the wild currently.

If one is going to counter unreasonable stupidity, use reasonable sensibility. One hour is the same as no warning.

[stavros]

Yes but responsible disclosure should be "you have a week (or whatever) from my first email, then I go public".

[chii]

what if the vulnerability cannot be easily fixed within the week, even if the company stops all work and focus completely on the problem?

If the reason for responsible disclosure is to ensure that no members of the public is harmed as a result of said disclosure, should it not be a conversation between the security researcher and the company?

The security researcher should have an approx. idea of how or what to do to fix, and give a reasonable amount of time for a fix. If the fix ought to have been easy, then a short time should suffice, and vice versa.

[stavros]

If the vulnerability can't be fixed within the week, maybe the company should be SOL. This will incentivize companies to build their software better, as they'll know that any vulnerability that is hard to fix will mean consequences.

Maybe the mitigation is for the company to take its service down while it works on the problem. Again, a good incentive to avoid that in the first place. Also an incentive to not waste any time after a report comes in, to see and act on it immediately, etc.

At some point, we have to balance customer risk from disclosing immediately with companies sitting on vulnerabilities for months, vulnerabilities that may be actively exploited.

[NegativeK]

For any timeline the company can't hit, whether it's a week or 90 days, they should come up with compensating controls, detections, etc that users can implement. Managing vulnerable software isn't a new science.

> The security researcher should have an approx. idea of how or what to do to fix

Any expectation put on the security researcher beyond "maybe don't cause unnecessary shit storms with zero days" needs to be met with an offer of a fat contract.

[delusional]

The security researcher should have an approx. idea of how or what to do to fix.

How is that in any way the responsibility of independent randos on the internet?

If you truly believe these issues should be fixed, the right answer would be to hold companies accountable for timely security patches, overseen and managed by a government department.

I'm not sure thats a good idea, but expecting random security researchers to somehow hold massive billion dollar Enterprises accountable is silly.

[throw0101d]

> what if the vulnerability cannot be easily fixed within the week, even if the company stops all work and focus completely on the problem?

A week is an example and not a definitive value dictated by law, statute, or regulation.

When you report the vulnerability you give the developer a timeline of your plans, and if they can't make the deadline they can come back to you and request more time.

[b112]

You can always have a conversation if they provide justification.

[cenamus]

You already put your tens of thousands of users at risk. The people putting bugs in the software, not the ones discovering them.

[stavros]

Please enlighten me on how you've managed to never write any bugs.

[pixl97]

Well, not sure DJB posts here, but he has kept it to a minimum.

And this is mostly BS too. People don't write bug free software, they write features.

Other industries had to license professional engineers to keep this kind of crap from being a regular issue.

[holowoodman]

"Licensed professional engineers" are a software-development myth.

If all our software was as simple as a bridge, then we could have that. A bridge is 5 sheets of plans, 10 pages of founding checks, 30 pages of calculations, 100 pages of material specs. You can read all those in a day. Check the calculations in a week. Next bridge will be almost the same.

Now tell me about any software where the spec is that short and simple. /bin/cat? /bin/true? Certainly not the GNU versions of those.

Software is different because we don't build 1000 almost-identical bridges with low complexity. We always build something new and bespoke, with extremely high complexity compared to any kind of building or infrastructure. Reproduction is automatic, so there will never be routine. Totally different kind of job, where a licensed professional will not help at all.

[cenamus]

Didn't say that. But I can't blame the ones publicising the bugs we put in there.

[efdee]

Strange wording. You are the one that put tens of thousands of your users at risk. Not the one who discovers the problem.

[stavros]

If you forget your shop's door open after hours, and someone starts shouting "HEY GUYS! THIS DOOR IS OPEN! LOOK!", I have a hard time putting 100% of the blame on you.

[pixl97]

If I point out the bridge is cracking and you get angry about it, I'm blaming the idiots that engineered a crap bridge and didn't maintain it.

Maybe it's time we get professional standards if this is how we are going to behave?

[haswell]

This seems like a fallacious analogy to me.

Why is a cracked bridge dangerous? Because anyone traveling over it or under it is at risk of being hurt if the bridge collapses. Warning people that it is cracking does not increase the likelihood of a collapse.

Why is a software vulnerability dangerous? Because anyone who knows about it and has nefarious intent can now use it as a weapon against those who are using the vulnerable software, and the world is full of malicious actors actively seeking new avenues to carry out attacks.

And there are quite a few people who would exploit the knowledge of an unlocked door if given the chance.

There’s a very clear difference in the implications between these scenarios.

[efdee]

They didn't "forget" to lock the door that one time. They just never lock it. The guy yelling it out loud is pissing off all the people who already knew you didn't. He is not the one to be angry at.

[giantg2]

That's because nobody actually cares about security nor do they want to pay for it. I'm a security champion at my company and security related work gets pushed off as much as possible to focus on feature work. If we actually wanted security to be a priority, they would employ security champions who's only job was to work on security aspects of the system instead of trying to balance security and feature work, because feature work will always prevail.

[Retr0id]

It's such a loaded term that I refuse to use it. "vendor-coordinated disclosure" is a much better term, imho

(and in the world of FOSS you might have "maintainer-coordinated" too)

[delusional]

> "Responsible" disclosure is paradoxically named because actually it is completely irresponsible.

It's only paradoxical if you've never considered the inherent conflicts present in everything before.

The "responsible" in "responsible disclosure" relates to the researchers responsibility to the producer, not the companies responsibility to their customers. The philosophical implication is that the product does what it was designed to do, now you (the security researcher) is making it do something you don't think it should do, and so you should be responsible for how you get that out there. Otherwise you are damaging me, the corporation, and that's just irresponsible.

As software guys we probably consider security issues a design problem. The software has a defect, and it should be fixed. A breakdown in the responsibility of the corporation to their customer. "Responsible disclosure" considers it external to the software. My customers are perfectly happy, you have decided to tell them that they shouldn't be. You've made a product that destroys my product, you need to make sure you don't destroy my product before you release it.

The security researcher is not primarily responsible to the public, they are responsible to the corporation.

It's not a paradox, it's just a simple inversion of responsibility.

[einsteinx2]

> The security researcher is not primarily responsible to the public, they are responsible to the corporation.

Unless the researcher works for the corporation on an in-house security team, what’s your reasoning for this?

Why are they more responsible to the corporation they don’t work for than for to the people they’re protecting (depending on the personal motivations of the individual security researcher I guess).

[drowsspa]

With "simple reversion of responsibility" do you mean your twisted logic of "everyone should think first and foremost about my profits"?

[rfl890]

What about damage control? I would argue your "anonymous, immediate disclosure" to the public (filled with bad actors) would be rubbing salt in the wound (allow more people to exploit the vulnerability before it's fixed). That's why nobody publishes writeups before the vuln is fixed. Even if corporations don't fix vulns in time, I can only see harm being done from not privately reporting them.

[pixl97]

>I can only see harm being done from not privately reporting them

Because you need to take a look at the fuller picture. If every vuln was published immediately the entire industry would need to be designed differently. We wouldn't push features at a hundred miles per hour but instead have pipelines more optimized for security and correctness.

There is almost no downside currently for me to write insecure shit, someone else will debug it for me and I'll have months to fix it.

[IlikeKitties]

I mean, to be a bit more reasonable, there's a middle ground here. Maybe disclosing a massive RCE Vulnerability in software used by a lot of companies on 25th of December is not a good Idea. And perhaps an Open Source Dev with a security@project mail deserves a tad more help and patience than a megacorp with a record of shitty security management. And if you are a company that takes security serious and is responsive to security researchers inquiries they deserve at least the chance to fix it fast and before it becomes public.

It's just that there are some companies EVERYONE knows are shitty. ASUS is one of them.

[holowoodman]

You are right about open source developers who do this on the side, as a hobby, and even if they don't are usually underpaid and understaffed. They do deserve more time and a different approach.

But corporations making big bucks from their software need to be able to fix things quickly. They took money for their software, so it is their responsibility. If they cannot react on a public holiday, tough luck. Just look at their payment terms. Do they want their money within 30 days or 25 work days? Usually it is the former, they don't care about your holidays, so why should anyone care about theirs? Also, the bad guys don't care about their victims' holidays. You are just giving them extra time to exploit. The only valid argument would be that the victims might not be reading the news about your disclosure on a holiday. But since you are again arguing about software used by a lot of companies (as opposed to private users), I don't see a problem there. They also have their guards on duty and their maintenance staff on call for a broken pipe or something.

What's most important is that I'm saying we should revert the "benefit of the doubt". A vast majority of corporations have shitty security handling. Even the likes of Google talk big with their 90 day time window from private irresponsible disclosure to public disclosure. And even Google regularly fails to fix things within those 90 days. So the default must be immediate public and full disclosure. Only when companies have proven their worth by correctly reacting to a number of those, then they can be given the "benefit of the doubt" and a heads up.

Because otherwise, when the default is irresponsible private disclosure, they will never have any incentive to get better. Their users will always be in danger unknowingly. The market will not have information to decide whether to continue buying from them. The situation will only get worse.

[throw0101d]

> But corporations making big bucks from their software need to be able to fix things quickly. They took money for their software, so it is their responsibility. If they cannot react on a public holiday, tough luck.

Because it is not corporations who are reacting on public holidays, but developer human beings.

It is not corporations that are reacting to install patches on a Friday, but us sysadmins who are human beings.

[holowoodman]

Companies will act out of greed and use their customers and developers as "human shields" to get out of their responsibility. Your on-call duty should be paid by the hour just as any duty, doubling the pay on weekends, holidays and nights. "But the poor developers" is just the "we will hurt this poor innocent puppy"-defense. The evil ones are the ones inflicting the hurt, the greedy companies. Not the reporters.

[IlikeKitties]

Overall, I share your reasoning and would concur mostly but there are some rather important caviats, especially regarding this one:

> The only valid argument would be that the victims might not be reading the news about your disclosure on a holiday. But since you are again arguing about software used by a lot of companies (as opposed to private users), I don't see a problem there.

Let's say MegacorpA is a big Software Vendor that makes some kind of Software other Companies use to manage some really sensitive user data. Even if MegacorpA fixes their stuff on the 25th 2 hours after they got an e-mail from you, all their clients might not react that fast and thus a public disclosure could cause massive harm to end users, even if MegacorpA did everything right.

Ultimately, I guess my argument is that there's not a one size fits all solution. But "responsible disclosure" should be reserved for companies acting responsibly.

[oezi]

The problem is just one of legislation of liability. Car manufacturers are ordered to recall and fix their cars, but software/hardware companies face just too little pressure. I think customers should be able to get full refund for broken devices (with unfixed CVE for example).

[mjevans]

The devices and core functionality (including security updates, which are fixes to broken core functionality) must survive the manufacturer and should not require ongoing payments of any type*. (new updates being created? maybe, access to corrections to basic behavior? Bug / security fixes should remain free.)

[oezi]

Yes. I would envision that it is at least 5 years of such updates fixes and another 5 years available for purchase capped at 20% of device price.

All manufacturers must pay an annual fee to an insurance scheme which covers the case of insolvency of manufacturers.

[okanat]

Citing CGPGrey: Solutions that are the first thing you can think of are terrible and ineffective.

Good safety/security culture encourages players to not hide their problems. Corporations are greedy bastards. They'll do everything to hide their security mistakes.

You are also making legitimate, fixable in a month issues available for everyone which increases their chances to be exploited a lot.

[IlikeKitties]

> You are also making legitimate, fixable in a month issues available for everyone which increases their chances to be exploited a lot.

I don't think you can fathom the amount of people that have phones with roughly 3 years of no android updates as their primary device with which they use all the digital services they use, Banking, Texting, Doomscrolling, Porn, ...

Users, especially the most likely to be exploited are already vulnerable to so much shit and even when there's a literal finished fix available, these vendors do shit about it. Only when their bottomline is threatened because even my mom knows "Don't buy anything with ASUS on it, your bank account gets broken into if you do" will we see change.

[okanat]

> I don't think you can fathom the amount of people that have phones with roughly 3 years of no android updates as their primary device with which they use all the digital services they use, Banking, Texting, Doomscrolling, Porn, ...

I do. I'm an embedded software developer in a team that cares about having our software up-to-date a lot.

> Users, especially the most likely to be exploited are already vulnerable to so much shit and even when there's a literal finished fix available, these vendors do shit about it. Only when their bottomline is threatened because even my mom knows "Don't buy anything with ASUS on it, your bank account gets broken into if you do" will we see change.

Yes individuals are quite exploitable. That's why I really like EU's new regulations Cyber Resiliency Act and new Radio Equipment Directive. When governments enforce reasonable disclosure and fixing timelines, then threaten your company's ability to sell things in a market alltogether, if you don't comply, it works wonders. Companies hate not being able to make money. So all the extra security policies and vulnerability tracking we have been experimenting with and secure-by-default languages are now the highest priority for us.

EU regulation makes sure that you're not going to be sold a router that's instantly hackable in a year. It will also force chip manufacturers to have meaningful maintenance windows like 5-10 years due to pressure from ODMs. That's why you're seeing all the smartphone manufacturers have extended support timelines, it is not pure market pressure. They didn't give fuck about it for more than 10 years. When EU came with a big stick though...

Spreading word-of-mouth knowledge works until a point. Having your entire product line being banned entering a market works almost every time.

[einsteinx2]

I’m not sure that’s a great example as they would be vulnerable to many responsibly disclosed and previously fixed issues anyway since they never update.

In fact they would be just as vulnerable to any new responsibly disclosed issues as they would if they were immediately “irresponsibly” disclosed because again, they never update anyway.

[layer8]

The fact about people running outdated OS versions is totally true, but it also indicates that the risk of being vitally harmed by those vulnerabilities is quite low in reality, if you’re not an individually targeted person. And that’s why not a lot of people care about them.

[int_19h]

In this day and age, you're just as likely to be targeted by a large-scale ransomware operation that just happens to find your vulnerable device by network scanning, for example.

[Avamander]

> Good safety/security culture encourages players to not hide their problems. Corporations are greedy bastards. They'll do everything to hide their security mistakes.

This is why I despise the Linux CNA for working against the single system that tries to hold vendors accountable. Their behavior is infantile.

[hamandcheese]

Business idea. Maybe this already exists. A disclosure aggregator/middle man which:

- protects the privacy of folks submitting

- vets security vulns. Everything they disclose is exploitable.

- publishes disclosures publicly at a fixed cadence.

- allows companies to pay to subscribe to an "early feed" of disclosures which impact them. This money is used to reward those submitting disclosures, pay the bills, and take some profit.

A bug bounty marketplace, if you will. That is slightly hostile to corporations. Would that be legal, or extortion?

[hashstring]

Thought of something along the lines of this too before.

I think there is serious potential for this.

[ajcp]

It does indeed already exist in many sectors as trade publications and journalism.

[darkwater]

Isn't that basically HackerOne?

[Avamander]

No, HackerOne gets paid by the companies, so they're heavily incentivized to work for their benefit.

I've had three really bad experiences with unskilled H1 triagers that the next vuln I find from a company that uses H1 will go instantly public. I'm never going to spend that much effort again, to get a triager that would actually bother to triage.

[_cenw]

except there you spend several months walking an underpaid person in india who can barely use a shell though reproduction steps, get a confirm after all that work and the vendor still ignores you

[xmodem]

HackerOne, BugCrowd, et al don't appear to make any serious effort to vet reports themselves.

[hashstring]

Is that true? I thought you could pay for a H1 service that basically had professionals triaging the vulnerabilities and only pass on the correct ones?

[ycombinatrix]

Our company pays for one of these third party triage services for H1.

The quality is seriously lacking. They have dismissed many valid findings.

[hashstring]

Ah thank you for the info!

From what I understood, the service is also (very) expensive. Wild.

[pjmlp]

As I keep saying, liability like in any other industry.

Most folks don't put up with faulty products unless by decision, like those 1 euro/dollar shops, so why should software get a pass.

[curiousgal]

> a disaster for the human race.

This is a prime example where a hyperbole completely obliterates the point one is trying to make.

[IlikeKitties]

> This is a prime example where a hyperbole completely obliterates the point one is trying to make.

This is a prime example of someone not getting the joke everyone else got. [0] [0] https://www.washingtonpost.com/wp-srv/national/longterm/unab...

[lofaszvanitt]

Just post it next day, when found. That will be the proper incentive and losing face also contributes to better security next time.

[fulafel]

Or we could just have regulation or at least the same product liability for software as everything else.