> Every CVE thus has this huge cost tied to it. A cost that does not land on us and we don’t really see or feel it, but a cost on the ecosystem I believe we should not ignore.
I really appreciate this attitude towards this because it recognizes that there are a lot of security teams out there that don't take a nuance view of CVEs. For instance, one time we had a security team that required us to patch a vmware support package that was installed by default on ubuntu, but the CVE required being ran on vmware when we were running on EC2. Arguing with them was pointless because they were not interested in determining if the CVE applied to us, only that it needed fixed.
Lots of teams that are supposed to be in charge of security don't ask "does this CVE affect us", but simply shift the burden of patching downward and outward. In some cases, like in the case of easy to update and centrally deploy SaaS products, that burden is more annoying and frustrating than difficult. In some cases, like when you have complicated deploy or have customer-controlled updates, those mandates cause a huge burden on teams not producing the decision to patch every low CVE.
Yes, I’ve also experienced this kind of attitude. Some scanning tools can detect that certain CVEs do not apply because the specific functionality is not used.
I hope your team was OK with you uninstalling the VMware package manually (this is actually not a bad outcome if you don’t use that package)
There are also ridiculous CVEs like CVE-2018-20225 for pip, which will not get fixed as that behaviour is by design (but here as well it might be a good idea to strip pip if it’s not used)
> An issue was discovered in pip (all versions) because it installs the version with the highest version number, even if the user had intended to obtain a private package from a private index.
To be fair this behavior + extra-index-url definitely allowed for dependency confusion attacks. Now it's a bit silly for the CVE as written, but IIRC this was before you could use index-url to point exclusively to an internal package host so there were (and in other ecosystems still are) dependency confusion attacks going on in the wild where attackers are publishing "internal-package-a@999.9.9" on any public package host (NPM, PyPi, etc) to try to compromise companies that have internal packages of the same name.
For the attack you mentioned (reusing internal packages in a public repository) prefix reservation is one possible solution. Unfortunately PyPI does not support it.
I don't understand what's ridiculous about that pip CVE, could you explain? Just because something is by design that doesn't mean it's not a vulnerability or somehow unexploitable.
Maybe I was too harsh. It’s the CVE in conjunction with its high severity, the maintainers’ decision and the bundling of pip with CPython. In the end what can you do about it as a dev given that the pip maintainers have decided not to fix it? The only option is not to use pip at all (and sure, you can see the CVE as a critique of pip in a way), or discuss with your security team in hope for some exclusion. And since pip or at least ensurepip are part of Python you get a lot of these scan results
E: and if you decide not to use pip I don’t think there’s an official way to remove ensurepip, I typically rm -rf inside of site-packages, it works but doesn’t feel correct
The CVE looks relevant to me. If you're trying to get a package from a private repo, and someone publishes version 999 of that package on a public repo, then you're executing their code instead of your own. Just because the pip maintainers refuse to fix it doesn't mean it isn't a security vulnerability that could lead to remote code execution and needs to be controlled for in some other way.
One could argue that this is not an issue with pip, the software, but of the index used. I mean, if you control both index and extra-index there is no problem (and one solution to this is to use your own mirror with a set resolution order). This could very well be addressed in PyPI, for example NuGet allows to reserve package prefixes.
We also do not create a CVE for curl because you can use it to download the wrong bash script. If this was an alert for suspicious usages of pip instead of pip itself, I’d be less critical of it.
One could argue that, certainly, but I think it's a little disingenuous. Pip makes it impossible to use extra-index-url safely, in the ~only use-case that option has. There is no world where you use extra-index-url and you're not vulnerable in some way or another to dependency confusion.
Our internal "security team" actually put gcc (yes, that gcc) on the banned software list. It was overturned in short order when the entire engineering org suddenly wasn't allowed to compile software. Luckily I don't have to deal with that team directly, but it definitely means I have zero respect for that entire team and anything they have to say.
> I really appreciate this attitude towards this because it recognizes that there are a lot of security teams out there that don't take a nuance view of CVEs
This is true, but also: needless CVEs place a burden even on security teams who do take a nuanced view of CVEs - it requires some amount of effort to evaluate every CVE and determine whether it's applicable or not.
In many (most?) companies it also takes nontrivial amount of time to patch potentially affected systems. In my company half IT department got recently an email that we need to urgently patch all Windows servers because of some critical CVE. I checked it. The description was maybe 3 lines and it said this affected domain controllers only. I raised this with security team and they said that in this case we don't need to patch everything. Now if we had to do this, it would force us to spend nontrivial time on unplanned patching. That this in itself disorganizes our operations can not be ignored. So comparatively me doing some legwork and checking the CVE was trivial effort and saved a lot of busywork for the department as a whole. That time we got lucky.
If something is hard do it more often so you get good at it.
While this time you avoided something, it sounds like you need to figure out your patching process ASAP. There is every reason to believe a major issue will affect everything in the near future.
Absolutely. I was focused on the burden CVEs place on everyone downstream of teams that don't take a nuance view, but even when teams do look at all the CVEs reported in scans, the proliferation of CVEs just adds workload to determine if they are affected. Unless teams say they will not look at lows (or lower-than-lows if the category existed) then what amounts to busy-work just piles up.
There's an upcoming talk at the OpenSSL conference next month on the cost of bogus CVEs to open-source projects that covers similar ground. It also lists some particularly ridiculous CVEs that, despite being jawdroppingly stupid, still need to be responded to by project maintainers who really have better things to do with their lives.
> Lots of teams that are supposed to be in charge of security don't ask "does this CVE affect us", but simply shift the burden of patching downward and outward
Unfortunately, I've had many a frustrating session with compliance auditors who do not care that it couldn't affect you, you're required to meet the PCI-DSS deadlines of 90 days for low, etc, and I've seen security groups force to accept that this is what they have to do, and then get the unfortunate task of dealing with engineers pissed off that them for forcing them to what security is being forced to do. Everyone's a whole big bundle of happy joy joy, all because of some stupid auditor following a stupid (but well intentioned) checklist.
At least it's got slightly less bad recently, it used to be 30 days critical, 90 days everything else, now you're required to perform a targeted risk analysis but it's still a lot of work to do.
The problem of CVE inflation is not just that you might be forced to patch a CVE that is not applicable to your product. Even investigating to understand whether a CVE is applicable or not takes time, and is simply not worth it for obscure issues like the one in this bug.
Even if the CVE doesn't currently apply to you, how can you be sure? Is the CVE in code that only runs on vmware; or does the code also run on EC2 - it will just be a few more weeks before someone figures out how to exploit it there.
Which is why the default answer for everybody should be fix the CVE. You should only ask "does this CVE affect us" in the case where the fix in some way is a negative to you.
Of course one downside might be risks of upgrading and so if you determine this affects us it means you would risk updating with less verification even though the update might break something else. If the issues doesn't affect you a longer process to verify nothing breaks is safe.
This becomes fun if you start to prioritize security work on CVEs rated higher, not affecting you, over security work on CVEs rated lower and affecting you.
Or prioritizing chasing CVEs currently not affecting you over architectural work improving security.
The CVE should be fixed, I fully agree, but where does it land as a priority? Less competent security teams push /all/ CVEs as Sev0 over /all/ other topics.
I don't have a good answer to this problem. The reality is security is becoming very important - for good reasons. If you (as an organization) are spending all your time chasing CVEs instead of the other useful things (such as what you named) you have a problem, but not fixing CVEs right away is a terrible answer. There is some hope that LLMs have found most of the existing issues and things will settled down - but only time will tell if this becomes true or not.
As someone who has to respond for this kind of stuff at work, I am regularly in a situation where I am pushing back on a CVE, or telling them that our product neither uses nor installs that package (or its for a different OS entirely).
Our product is run in a moated environment, most systems have the same username and passwords (customers never change the defaults), so I only really care about RCE's even if it is an effected package.
> most systems have the same username and passwords (customers never change the defaults)
That is horrifying and 100% on your dev team. You should not ship default credentials, instead require unique creds to be set at install. Ship an update which required default creds to be changed.
Our flagship product is not a SaaS, customers install it in their own cloud environments, and as a result, they scan us with Wiz, Prisma, basically anything that supports agentless scanning, and then send us reports demanding answers and remediations.
Half the time, they're running versions that are over a year old. Sometimes, the version they're running is 3 years old and end-of-support. Then tell us they don't want to upgrade. It's the dog-wanting-the-frisbee meme, except it's "Patch CVEs? NO UPGRADE! ONLY PATCH CVEs!"
And every time there's a new CVE with its own web page, logo, and TikTok dance, we get dozens of tickets from customers asking if we're affected and what the workaround is. Like, yeah, I get that an easy-to-exploit LPE like DirtyFrag seems scary, but the system has SSH disabled on production deployments. If an attacker has shell, you've already lost.
Terrapin was especially infuriating. Customers were acting like it was an authentication bypass.
Unfortunately, while cybersecurity is a real thing with real concerns and there are some amount of highly competent people, it's mostly, as a field, full of box-checkers and grifters. That lack of nuance or even attempt to understand if you are affected by a CVE or have other mitigations is unfortunately par for the course, even though its far below basic expectations.
It would be revealing to see some of the e-mail communications this person was sending to MITRE while trying to fight this issue.
We’re all familiar with how some use LLMs to write code and submit PRs, but there’s a growing problem of people using LLMs to tirelessly fight issues with communications like e-mails and even suggesting physical paperwork too.
Now that the effort to argue something against an institution is approaching zero, more people are getting the idea to have their LLM and harness fight some battles for them. It feels like it costs them very little but if there’s a non-zero chance of personal gain they do it. I’m hearing a lot of stories about everything from local governments to university administration offices being overwhelmed by requests that just keep coming in from relentless senders who figure asking for anything is worth a try even if there’s no chance it would be granted.
I think we’re going to have to rethink a lot of our communication and request systems that previously relied on the fact that most people wouldn’t take the effort to argue for something that they didn’t deserve. When the cost of arguing approaches zero, the machine can keep trying to get the non-zero chance of success for them.
Reading the messages in the original bug report reminded me of LLMs.
But I don’t know if it was. Because it ALSO reminded me of dealing with people who will just keep bringing up the same point as if you’re an idiot while completely ignoring what you’re trying to say. They don’t have a conversation with you so much as just talk at you until you (hopefully) give up.
“Yes, I agree (thing you said to refute my claim), but (my exact claim you’ve already poked holes in multiple times).” until the heat death of the universe.
It sounds like the only end result of this is them making the bureaucracy even more bureaucratic by employing their own agents, where the only way to get anything done is to have your agents fight their agents.
Frankly, it feels like Kafka was actually an optimist.
There was a recent article in The Economist about people fighting employment disputes with AI (https://archive.ph/mi3zu). On the one hand, democratizing the system, on the other hand filling it with massive quantities of legally questionable slop.
I’ve seen people (and even doctors) advocate doing that for fighting medical rejections too. If the insurance company wants to dump tons of paperwork and demand responses to nonsense, why not send them large piles of nonsense that they have to respond to. Even out the burden.
It’s a lovely system we’ve invented for ourselves.
The incentives here are really bad at the moment. Traditionally, your name on a CVE against an important project like curl have a certain cachet in the community. You might even leverage that to get a raise or a better job, so money was definitely part of this.
Now lots of people are throwing code against LLMs and then copy/pasting whatever comes out into "security" reports.
We decided for our projects that any LLM-generated security reports are simply copied to the public list. Everyone has access to LLMs so presumably if one LLM instance found it, then all users of LLMs have already or shortly will find it. We'll fix them if they're important, but the signal to noise is pretty bad.
I think this will, eventually, result in more secure services as the low hanging problems are found and fixed. But unfortunately I don't see the flood of LLM-generated nonsense ending any time soon.
Unless it's a critical CVE, they're worth very little now for your career.
Same for a lot of side projects or small contributions to OSS, people are still chasing them and wasting everyone's time for nothing. They wouldn't even work on them before AI.
If there is a CVE is has value to your career. You have public recognition that you found one which means someone looking for someone to hire will find you. In turn you are more valuable because a few people are looking. If you company wants to keep you they better give you a proactive raise.
Until it is common to verify the quality of the CVE the above will remain true. Perhaps the CVE system needs a "shame" system so that potential hiring manages find you on the list of incompetent people not to hire. (undoubtedly libel laws will make this impossible)
In a way I think the false promise of open source that someone else would have gone through the code is actually going to come true as LLM would have gone through the code.
First thing that came to my mind... why people are so self-centric... and yet, somehow, you feel bad because the same people flex with these CVEs while you can't tell a single huge one you had found under NDAs, while they keep downplaying or ignoring you. I think its better to treat these people as less professional, and try to influence the common reception what is actually professional and what is not.
I think all this goes to the joke/not-a-joke about "you aren't a real hacker until you have a CVE to your name". Its also a form of forced social proof.
I had to tag bogus CVE's with invalid_cve, but I didn't care to complain to MITRE 3 times to get the CVE's rejected. That's not worth it. Eg people were filing CVE's against unreleased versions, and such.
Quite interesting the response from MITRE: `It is not considered a security vulnerability because of how it requires a local attacker with privileges present to make it so`.
I didn't knew about that rationale. I thought Defense-in-Depth was all about that, preventing security incidents even when an attacker start to get some elevated privileges on the system?
If not, that's quite a practical reference for future CyberSec meetings.
This kind of hellish experience is a great example of the CVE system trying to have it both ways: when on the offense it’s a rich source of information for defenders, and when on the defense it’s just an opaque ID for coordination that implies nothing about the quality or correctness of the underlying report.
> it means that every CVE we publish trigger activities in many security teams all over the world, leading to a significant number of patches and subsequent software updates.
If it's just about that, fix those low priority issues and bundle them along with the next higher-priority fix pack, i.e. "lower than low" -> fix but not release immediately; "medium" or higher -> release with any earlier unreleased "lower than low" fixes.
Seeing how much energy you spent in dismissing the person's report on the "lower than low" vuln in https://hackerone.com/reports/3455037, it'd be easier and faster to just fix it rather than argue...
According to the linked article, that’s exactly what they did. It was a legitimate bug, but the security consequences were lower than low. It’s a code quality issue, not a security issue, but both are worth fixing.
I don't see how that correlates, and that's already pretty much what they do anyway. The reporter's issue wasn't that it didn't get fixed (it did), but that it wasn't given a CVE.
If one person can spend 2 days fighting to prevent 1h of useless work for all of the people running curl, that person has saved the software industry millions of dollars worth of developer time. So it's very much worth it, and I, for one, am very grateful for it.
And make no mistake - havin every user of curl spend time to read this CVE and decide that it doesn't affect that would be 10000% wasted effort for each and every one of them.
> If one person can spend 2 days fighting to prevent 1h of useless work for all of the people running curl, that person has saved the software industry millions of dollars worth of developer time.
Working in a large company, that used to be one of the ways I'd measure my annual business impact. "Look, through my reviews I reduced the work of 70 tasks that were going to go out to most engineering teams for an average reduction from 2 hours to 30 minutes. With 300 teams in scope, that saved us approximately of 31,500 hours of headcount, the equivalent of 15 full time employees"
One thing that has proven remarkably effective is making SVPs sign off on tasks that impact more than a certain number of teams, and/or take more than a certain length of time. Yet to see a single one argue the point when they see the task being asked.
> Every CVE thus has this huge cost tied to it. A cost that does not land on us and we don’t really see or feel it, but a cost on the ecosystem I believe we should not ignore.
I really appreciate this attitude towards this because it recognizes that there are a lot of security teams out there that don't take a nuance view of CVEs. For instance, one time we had a security team that required us to patch a vmware support package that was installed by default on ubuntu, but the CVE required being ran on vmware when we were running on EC2. Arguing with them was pointless because they were not interested in determining if the CVE applied to us, only that it needed fixed.
Lots of teams that are supposed to be in charge of security don't ask "does this CVE affect us", but simply shift the burden of patching downward and outward. In some cases, like in the case of easy to update and centrally deploy SaaS products, that burden is more annoying and frustrating than difficult. In some cases, like when you have complicated deploy or have customer-controlled updates, those mandates cause a huge burden on teams not producing the decision to patch every low CVE.
Yes, I’ve also experienced this kind of attitude. Some scanning tools can detect that certain CVEs do not apply because the specific functionality is not used.
I hope your team was OK with you uninstalling the VMware package manually (this is actually not a bad outcome if you don’t use that package)
There are also ridiculous CVEs like CVE-2018-20225 for pip, which will not get fixed as that behaviour is by design (but here as well it might be a good idea to strip pip if it’s not used)
> An issue was discovered in pip (all versions) because it installs the version with the highest version number, even if the user had intended to obtain a private package from a private index.
https://nvd.nist.gov/vuln/detail/cve-2018-20225
Because I'm sure the public wants to know.
To be fair this behavior + extra-index-url definitely allowed for dependency confusion attacks. Now it's a bit silly for the CVE as written, but IIRC this was before you could use index-url to point exclusively to an internal package host so there were (and in other ecosystems still are) dependency confusion attacks going on in the wild where attackers are publishing "internal-package-a@999.9.9" on any public package host (NPM, PyPi, etc) to try to compromise companies that have internal packages of the same name.
For the attack you mentioned (reusing internal packages in a public repository) prefix reservation is one possible solution. Unfortunately PyPI does not support it.
I don't understand what's ridiculous about that pip CVE, could you explain? Just because something is by design that doesn't mean it's not a vulnerability or somehow unexploitable.
Maybe I was too harsh. It’s the CVE in conjunction with its high severity, the maintainers’ decision and the bundling of pip with CPython. In the end what can you do about it as a dev given that the pip maintainers have decided not to fix it? The only option is not to use pip at all (and sure, you can see the CVE as a critique of pip in a way), or discuss with your security team in hope for some exclusion. And since pip or at least ensurepip are part of Python you get a lot of these scan results
E: and if you decide not to use pip I don’t think there’s an official way to remove ensurepip, I typically rm -rf inside of site-packages, it works but doesn’t feel correct
The CVE looks relevant to me. If you're trying to get a package from a private repo, and someone publishes version 999 of that package on a public repo, then you're executing their code instead of your own. Just because the pip maintainers refuse to fix it doesn't mean it isn't a security vulnerability that could lead to remote code execution and needs to be controlled for in some other way.
One could argue that this is not an issue with pip, the software, but of the index used. I mean, if you control both index and extra-index there is no problem (and one solution to this is to use your own mirror with a set resolution order). This could very well be addressed in PyPI, for example NuGet allows to reserve package prefixes.
We also do not create a CVE for curl because you can use it to download the wrong bash script. If this was an alert for suspicious usages of pip instead of pip itself, I’d be less critical of it.
One could argue that, certainly, but I think it's a little disingenuous. Pip makes it impossible to use extra-index-url safely, in the ~only use-case that option has. There is no world where you use extra-index-url and you're not vulnerable in some way or another to dependency confusion.
Our internal "security team" actually put gcc (yes, that gcc) on the banned software list. It was overturned in short order when the entire engineering org suddenly wasn't allowed to compile software. Luckily I don't have to deal with that team directly, but it definitely means I have zero respect for that entire team and anything they have to say.
> I really appreciate this attitude towards this because it recognizes that there are a lot of security teams out there that don't take a nuance view of CVEs
This is true, but also: needless CVEs place a burden even on security teams who do take a nuanced view of CVEs - it requires some amount of effort to evaluate every CVE and determine whether it's applicable or not.
In many (most?) companies it also takes nontrivial amount of time to patch potentially affected systems. In my company half IT department got recently an email that we need to urgently patch all Windows servers because of some critical CVE. I checked it. The description was maybe 3 lines and it said this affected domain controllers only. I raised this with security team and they said that in this case we don't need to patch everything. Now if we had to do this, it would force us to spend nontrivial time on unplanned patching. That this in itself disorganizes our operations can not be ignored. So comparatively me doing some legwork and checking the CVE was trivial effort and saved a lot of busywork for the department as a whole. That time we got lucky.
If something is hard do it more often so you get good at it.
While this time you avoided something, it sounds like you need to figure out your patching process ASAP. There is every reason to believe a major issue will affect everything in the near future.
Absolutely. I was focused on the burden CVEs place on everyone downstream of teams that don't take a nuance view, but even when teams do look at all the CVEs reported in scans, the proliferation of CVEs just adds workload to determine if they are affected. Unless teams say they will not look at lows (or lower-than-lows if the category existed) then what amounts to busy-work just piles up.
There's an upcoming talk at the OpenSSL conference next month on the cost of bogus CVEs to open-source projects that covers similar ground. It also lists some particularly ridiculous CVEs that, despite being jawdroppingly stupid, still need to be responded to by project maintainers who really have better things to do with their lives.
> Lots of teams that are supposed to be in charge of security don't ask "does this CVE affect us", but simply shift the burden of patching downward and outward
Unfortunately, I've had many a frustrating session with compliance auditors who do not care that it couldn't affect you, you're required to meet the PCI-DSS deadlines of 90 days for low, etc, and I've seen security groups force to accept that this is what they have to do, and then get the unfortunate task of dealing with engineers pissed off that them for forcing them to what security is being forced to do. Everyone's a whole big bundle of happy joy joy, all because of some stupid auditor following a stupid (but well intentioned) checklist.
> auditor following a stupid (but well intentioned) checklist.
I once heard that the worst thing you can run into is someone who is both well intentioned and bad at their job.
At least it's got slightly less bad recently, it used to be 30 days critical, 90 days everything else, now you're required to perform a targeted risk analysis but it's still a lot of work to do.
The problem of CVE inflation is not just that you might be forced to patch a CVE that is not applicable to your product. Even investigating to understand whether a CVE is applicable or not takes time, and is simply not worth it for obscure issues like the one in this bug.
Even if the CVE doesn't currently apply to you, how can you be sure? Is the CVE in code that only runs on vmware; or does the code also run on EC2 - it will just be a few more weeks before someone figures out how to exploit it there.
Which is why the default answer for everybody should be fix the CVE. You should only ask "does this CVE affect us" in the case where the fix in some way is a negative to you.
Of course one downside might be risks of upgrading and so if you determine this affects us it means you would risk updating with less verification even though the update might break something else. If the issues doesn't affect you a longer process to verify nothing breaks is safe.
This becomes fun if you start to prioritize security work on CVEs rated higher, not affecting you, over security work on CVEs rated lower and affecting you.
Or prioritizing chasing CVEs currently not affecting you over architectural work improving security.
The CVE should be fixed, I fully agree, but where does it land as a priority? Less competent security teams push /all/ CVEs as Sev0 over /all/ other topics.
I don't have a good answer to this problem. The reality is security is becoming very important - for good reasons. If you (as an organization) are spending all your time chasing CVEs instead of the other useful things (such as what you named) you have a problem, but not fixing CVEs right away is a terrible answer. There is some hope that LLMs have found most of the existing issues and things will settled down - but only time will tell if this becomes true or not.
As someone who has to respond for this kind of stuff at work, I am regularly in a situation where I am pushing back on a CVE, or telling them that our product neither uses nor installs that package (or its for a different OS entirely).
Our product is run in a moated environment, most systems have the same username and passwords (customers never change the defaults), so I only really care about RCE's even if it is an effected package.
> most systems have the same username and passwords (customers never change the defaults)
That is horrifying and 100% on your dev team. You should not ship default credentials, instead require unique creds to be set at install. Ship an update which required default creds to be changed.
Who do you think you are, Cisco?
> customer-controlled updates
This is a huge one where I'm at.
Our flagship product is not a SaaS, customers install it in their own cloud environments, and as a result, they scan us with Wiz, Prisma, basically anything that supports agentless scanning, and then send us reports demanding answers and remediations.
Half the time, they're running versions that are over a year old. Sometimes, the version they're running is 3 years old and end-of-support. Then tell us they don't want to upgrade. It's the dog-wanting-the-frisbee meme, except it's "Patch CVEs? NO UPGRADE! ONLY PATCH CVEs!"
And every time there's a new CVE with its own web page, logo, and TikTok dance, we get dozens of tickets from customers asking if we're affected and what the workaround is. Like, yeah, I get that an easy-to-exploit LPE like DirtyFrag seems scary, but the system has SSH disabled on production deployments. If an attacker has shell, you've already lost.
Terrapin was especially infuriating. Customers were acting like it was an authentication bypass.
I have the email response explaining what a backport is saved as a template because i have to send it so many times :)
Unfortunately, while cybersecurity is a real thing with real concerns and there are some amount of highly competent people, it's mostly, as a field, full of box-checkers and grifters. That lack of nuance or even attempt to understand if you are affected by a CVE or have other mitigations is unfortunately par for the course, even though its far below basic expectations.
It would be revealing to see some of the e-mail communications this person was sending to MITRE while trying to fight this issue.
We’re all familiar with how some use LLMs to write code and submit PRs, but there’s a growing problem of people using LLMs to tirelessly fight issues with communications like e-mails and even suggesting physical paperwork too.
Now that the effort to argue something against an institution is approaching zero, more people are getting the idea to have their LLM and harness fight some battles for them. It feels like it costs them very little but if there’s a non-zero chance of personal gain they do it. I’m hearing a lot of stories about everything from local governments to university administration offices being overwhelmed by requests that just keep coming in from relentless senders who figure asking for anything is worth a try even if there’s no chance it would be granted.
I think we’re going to have to rethink a lot of our communication and request systems that previously relied on the fact that most people wouldn’t take the effort to argue for something that they didn’t deserve. When the cost of arguing approaches zero, the machine can keep trying to get the non-zero chance of success for them.
Reading the messages in the original bug report reminded me of LLMs.
But I don’t know if it was. Because it ALSO reminded me of dealing with people who will just keep bringing up the same point as if you’re an idiot while completely ignoring what you’re trying to say. They don’t have a conversation with you so much as just talk at you until you (hopefully) give up.
“Yes, I agree (thing you said to refute my claim), but (my exact claim you’ve already poked holes in multiple times).” until the heat death of the universe.
It sounds like the only end result of this is them making the bureaucracy even more bureaucratic by employing their own agents, where the only way to get anything done is to have your agents fight their agents.
Frankly, it feels like Kafka was actually an optimist.
There was a recent article in The Economist about people fighting employment disputes with AI (https://archive.ph/mi3zu). On the one hand, democratizing the system, on the other hand filling it with massive quantities of legally questionable slop.
I’ve seen people (and even doctors) advocate doing that for fighting medical rejections too. If the insurance company wants to dump tons of paperwork and demand responses to nonsense, why not send them large piles of nonsense that they have to respond to. Even out the burden.
It’s a lovely system we’ve invented for ourselves.
The incentives here are really bad at the moment. Traditionally, your name on a CVE against an important project like curl have a certain cachet in the community. You might even leverage that to get a raise or a better job, so money was definitely part of this.
Now lots of people are throwing code against LLMs and then copy/pasting whatever comes out into "security" reports.
We decided for our projects that any LLM-generated security reports are simply copied to the public list. Everyone has access to LLMs so presumably if one LLM instance found it, then all users of LLMs have already or shortly will find it. We'll fix them if they're important, but the signal to noise is pretty bad.
I think this will, eventually, result in more secure services as the low hanging problems are found and fixed. But unfortunately I don't see the flood of LLM-generated nonsense ending any time soon.
Unless it's a critical CVE, they're worth very little now for your career.
Same for a lot of side projects or small contributions to OSS, people are still chasing them and wasting everyone's time for nothing. They wouldn't even work on them before AI.
If there is a CVE is has value to your career. You have public recognition that you found one which means someone looking for someone to hire will find you. In turn you are more valuable because a few people are looking. If you company wants to keep you they better give you a proactive raise.
Until it is common to verify the quality of the CVE the above will remain true. Perhaps the CVE system needs a "shame" system so that potential hiring manages find you on the list of incompetent people not to hire. (undoubtedly libel laws will make this impossible)
In a way I think the false promise of open source that someone else would have gone through the code is actually going to come true as LLM would have gone through the code.
” On June 15, we were again contacted by MITRE asking for the reasoning behind our decision to not give a CVE for this issue.
We replied with similar wording again. Linking to the same issue, again.
This seems like a great system.”
Looks like MITRE is using the Microsoft model of consent: Yes, or Ask Me Again Tomorrow
Someone must have really wanted to put this on their CV.
First thing that came to my mind... why people are so self-centric... and yet, somehow, you feel bad because the same people flex with these CVEs while you can't tell a single huge one you had found under NDAs, while they keep downplaying or ignoring you. I think its better to treat these people as less professional, and try to influence the common reception what is actually professional and what is not.
Or pressure from employer.
Some companies can go really hard on these metrics. Rare in the US but not rest of the world.
Or they had a bet in a prediction market.
I think all this goes to the joke/not-a-joke about "you aren't a real hacker until you have a CVE to your name". Its also a form of forced social proof.
I had to tag bogus CVE's with invalid_cve, but I didn't care to complain to MITRE 3 times to get the CVE's rejected. That's not worth it. Eg people were filing CVE's against unreleased versions, and such.
Quite interesting the response from MITRE: `It is not considered a security vulnerability because of how it requires a local attacker with privileges present to make it so`.
I didn't knew about that rationale. I thought Defense-in-Depth was all about that, preventing security incidents even when an attacker start to get some elevated privileges on the system?
If not, that's quite a practical reference for future CyberSec meetings.
This kind of hellish experience is a great example of the CVE system trying to have it both ways: when on the offense it’s a rich source of information for defenders, and when on the defense it’s just an opaque ID for coordination that implies nothing about the quality or correctness of the underlying report.
[flagged]
> A series of highly unlikely conditions that all need to be fulfilled for this to become a vulnerability.
Poor thinking. A vulnerability is a vulnerability regardless. The conditions apply to the exploit.
Did you notice the part where Daniel said they had fixed it two months before the first report?
> it means that every CVE we publish trigger activities in many security teams all over the world, leading to a significant number of patches and subsequent software updates.
If it's just about that, fix those low priority issues and bundle them along with the next higher-priority fix pack, i.e. "lower than low" -> fix but not release immediately; "medium" or higher -> release with any earlier unreleased "lower than low" fixes.
Seeing how much energy you spent in dismissing the person's report on the "lower than low" vuln in https://hackerone.com/reports/3455037, it'd be easier and faster to just fix it rather than argue...
According to the linked article, that’s exactly what they did. It was a legitimate bug, but the security consequences were lower than low. It’s a code quality issue, not a security issue, but both are worth fixing.
I don't see how that correlates, and that's already pretty much what they do anyway. The reporter's issue wasn't that it didn't get fixed (it did), but that it wasn't given a CVE.
If one person can spend 2 days fighting to prevent 1h of useless work for all of the people running curl, that person has saved the software industry millions of dollars worth of developer time. So it's very much worth it, and I, for one, am very grateful for it.
And make no mistake - havin every user of curl spend time to read this CVE and decide that it doesn't affect that would be 10000% wasted effort for each and every one of them.
> If one person can spend 2 days fighting to prevent 1h of useless work for all of the people running curl, that person has saved the software industry millions of dollars worth of developer time.
Working in a large company, that used to be one of the ways I'd measure my annual business impact. "Look, through my reviews I reduced the work of 70 tasks that were going to go out to most engineering teams for an average reduction from 2 hours to 30 minutes. With 300 teams in scope, that saved us approximately of 31,500 hours of headcount, the equivalent of 15 full time employees"
One thing that has proven remarkably effective is making SVPs sign off on tasks that impact more than a certain number of teams, and/or take more than a certain length of time. Yet to see a single one argue the point when they see the task being asked.