Earlier quoted context omitted.
Slopster
DevSlops engineer
cURL removes bug bounties
121–130 of 271 posts
Re: cURL removes bug bounties
#122Earlier quoted context omitted.
It's not about securing your device from external threats or bad actors; it's about securing the device from you.
I see it a little differently. I would change your statement to the following: It's not about securing your device from external threats or bad actors; it's about securing the organization from any blame / wrongdoing. Most organizations today are looking high and low to shove the blame to others instead of taking responsibility.
Re: cURL removes bug bounties
#123I just read one of the slop submissions and it's baffling how anyone could submit these with a straight face. https://hackerone.com/reports/3293884 Not even understanding the expected behaviour and then throwing as much slop as possible to see what sticks is the problem with generative AI.
They don't care. They generate large amounts of these, spam them out, and hope for some small success. If they get banned or blocked, they make new accounts. Shame isn't even a factor; it's all about money. They don't even attempt to understand or care about a product. This was partially the case before, where you'd still get weird spammy or extortive reports, but I guess LLMs enable random people to shoot their shot…
That is general trend in society now.
Re: cURL removes bug bounties
#124It seems open source loses the most from AI. Open source code trained the models, the models are being used to spam open source projects anywhere there's incentive, they can be used to chip away at open source business models by implementing paid features and providing the support, and eventually perhaps AI simply replaces most open source code
This is not a technology, but ethics and respect problem.
From the same article:
> Not all AI-generated bug reports are nonsense. It’s not possible to determine the exact share, but Daniel Stenberg knows of more than a hundred good AI assisted reports that led to corrections.
Meaning: developers and researchers who use the tool as it's meant to work, as a tool, are leveraging it to improve curl. But they are not skipping the part of understanding the content of their reports, testing it, and only then submitting it.
Re: cURL removes bug bounties
#125I just read one of the slop submissions and it's baffling how anyone could submit these with a straight face. https://hackerone.com/reports/3293884 Not even understanding the expected behaviour and then throwing as much slop as possible to see what sticks is the problem with generative AI.
Re: cURL removes bug bounties
#126Earlier quoted context omitted.
That anecdote is hilarious and scary in equal measures. Optional passwords are certainly more convenient than required ones, but so are optional PINs. The most convenient UX would be never needing to log in at all! Unless you find it inconvenient for others to have access to your bank account of course
And the counter where the most secure system never allows anyone to log in ever
Re: cURL removes bug bounties
#127A list of the slop if anyone is interested: https://gist.github.com/bagder/07f7581f6e3d78ef37dfbfc81fd1d...
In the second report, Daniel greeted the slopper very kindly and tried to start a conversation with them. But the slopper calls him by the completely wrong name. And this was December 2023. It must have been extremely tiring.
Re: cURL removes bug bounties
#128The company I work for has a pretty bad bounty system (basically a security@corp email). We have a demo system and a public API with docs. We get around 100 or more emails a day now. Most of it is slop, scams, or my new favourite AI security companies sending us an AI generated pentest un prompted filled with false positives, untrue things, etc. It has become completely useless so no one looks at it. I had a sales re…
Re: cURL removes bug bounties
#129An entry fee that is reimbursed if the bug turns out to matter would stop this, real quick. Then again, I once submitted a bug report to my bank, because the login method could be switched from password+pin to pin only, when not logged in, and they closed it as "works as intended", because they had decided that an optional password was more convenient than a required password. (And that's not even getting into the di…
It would also stop a lot of genuine submissions unfortunately, as some literally can't pay not just won't pay (for both technical or financial reasons), and adds complexity¹. Each project working this way will need to process a bunch of payments and refunds on top of the actual bounty payments, which is not admin free nor potential financially cost free.
I can't think of an easy answer that would work for more than a very short amount of time. As soon as there is money involved and an easy way to use tooling rather than actual effort/understanding to be involved, many will try to game the system ruining it for those genuine participants. Heck, even if the reward is just credit² rather than money, that will happen. Many individual people are honest and useful, people as a whole are a bunch of untrustworthy arseholes who will innocence you and the rest of the world for a penny or just for shits & giggles.
> Assuming the host of the bug bounty program is operating in good faith
This is a significant assumption. One that is it harder to not be paranoid about when you are putting money down.
> they closed it as "works as intended", because they had decided that an optional password was more convenient than a required password
This does not surprise me. My primary bank (FirstDirect, UK) switched the way I authenticate from “between 5 and 9 alphanumeric characters”³ to a 5-digit pin, and all their messages about it assured me (like hell!) that this was “just as secure as before”…⁴
--------
[1] Needing a payment processing option that is compatible with both the reporter and reportee, at the point of submission. At the moment that can be arranged after the bounty is awarded rather than something a project like curl needs to have internationally setup and supported before accepting submissions.
[2] ref: people submitting several simple documentation fixes, one misplaced comma or 'postrophe per pull request, to game some “pull requests accepted” metric somewhere.
[3] which wasn't ideal to start with
[4] I would accept the description “no less secure than before” if they admitted that the previous auth requirements were also lax.