5 ms·

A CVE Dispute

nekusar 1mo ago
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.
rwmj 1mo ago
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.
- f311a 1mo ago
  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.
  - bluGill 1mo ago
    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)
- xbmcuser 1mo ago
  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.
cynicalsecurity 1mo ago
Someone must have really wanted to put this on their CV.
- nicce 1mo ago
  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.
- deleted 1mo ago
  [deleted]
- margalabargala 1mo ago
  Or they had a bet in a prediction market.
- fg137 1mo ago
  Or pressure from employer. Some companies can go really hard on these metrics. Rare in the US but not rest of the world.
HackerThemAll 1mo ago
> 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 https://hackerone.com/reports/3455037, it'd be easier and faster to just fix it rather than argue...
- sharkbot 1mo ago
  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.
- ura_yukimitsu 1mo ago
  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.
- tsimionescu 1mo ago
  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.
  - Twirrim 1mo ago
    > 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.
nikanj 1mo ago
” 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
ealready_value 1mo ago
> 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.
- justusthane 1mo ago
  > 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.
  - ealready_value 1mo ago
    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.
  - rotis 1mo ago
    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.
Aurornis 1mo ago
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.
- somat 1mo ago
  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.
  - Gigachad 1mo ago
    Email will just be AI agents arguing with each other. Where the only way to get anything done will be to show up at the office and ask in person.
- rwmj 1mo ago
  There was a recent article in The Economist about people fighting employment disputes with AI (https://archive.ph/mi3zu https://archive.ph/mi3zu). On the one hand, democratizing the system, on the other hand filling it with massive quantities of legally questionable slop.
woodruffw 1mo ago
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.
NoDodgeQuestion 1mo ago
[flagged]
chrisjj 1mo ago
> 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.
- MBCook 1mo ago
  Did you notice the part where Daniel said they had fixed it two months before the first report?
ygouzerh 1mo ago
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.
rurban 1mo ago
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.
henrycoler 1mo ago
[dead]

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.

rwmj 1mo ago

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.

f311a 1mo ago
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.
- bluGill 1mo ago
  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)
xbmcuser 1mo ago
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.

cynicalsecurity 1mo ago

Someone must have really wanted to put this on their CV.

nicce 1mo ago
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.
deleted 1mo ago
[deleted]
margalabargala 1mo ago
Or they had a bet in a prediction market.
fg137 1mo ago
Or pressure from employer. Some companies can go really hard on these metrics. Rare in the US but not rest of the world.

HackerThemAll 1mo ago

> 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 https://hackerone.com/reports/3455037, it'd be easier and faster to just fix it rather than argue...

sharkbot 1mo ago
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.
ura_yukimitsu 1mo ago
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.
tsimionescu 1mo ago
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.
- Twirrim 1mo ago
  > 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.

nikanj 1mo ago

” 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

ealready_value 1mo ago

> 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.

justusthane 1mo ago
> 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.
- ealready_value 1mo ago
  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.
- rotis 1mo ago
  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.

Aurornis 1mo ago

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.

somat 1mo ago
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.
- Gigachad 1mo ago
  Email will just be AI agents arguing with each other. Where the only way to get anything done will be to show up at the office and ask in person.
rwmj 1mo ago
There was a recent article in The Economist about people fighting employment disputes with AI (https://archive.ph/mi3zu https://archive.ph/mi3zu). On the one hand, democratizing the system, on the other hand filling it with massive quantities of legally questionable slop.

woodruffw 1mo ago

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.

NoDodgeQuestion 1mo ago

[flagged]

chrisjj 1mo ago

> 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.

MBCook 1mo ago
Did you notice the part where Daniel said they had fixed it two months before the first report?

ygouzerh 1mo ago

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.

rurban 1mo ago

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.

henrycoler 1mo ago

[dead]