Hacker News Reader

Comment by themanmaran | Hacker News Reader

I feel like it's also been overrun by a lot of spam. As someone running a company, I get 2-5 unsolicited "vulnerability reports" per week. Half of them are an LLM finding some bad CSS on our framer splash page. The other half I assume are an extortion attempt so we just mark as spam.

Occasionally I see real security researchers on HN complaining that no one takes the disclosure seriously, or that people reply immediately with a cease and desist. But from the receiving end it's just because the spam is unmanageable.

View on HN

I'm getting CVE fatigue with all of these super ultra critical 10/10 vulnerabilities that are some node package that compiles my frontend can get stuck if I give it a malicious regex.

It's hard to spot the stuff that actually matters.

Yep. I remember years ago seeing the website for some guy who proudly listed all the CVEs he'd discovered. Clearly he'd written some scanning tool to look at regexes in open source projects and was creating CVEs for anything that might result in exponential time execution or whatever.

It sounds like an interesting case study. Do these things get reported with a patch?:

(a) add a new function that does regular expressions searching / matching with a resource checker (eg a timer);

(b) write a local linter that reports an error for any use of the builtin regular expression tools;

(d) commit the linter.

This stuff has been brewing for years, but since technically you could fix all instances with minimal StackOverflow downtime [1] and a slightly different pattern, few people worked on either using engines with data structures less prone to the worst case or adding the generic workarounds for those that have them.

e.g. in cPython, until 3.11, there was no support for atomic grouping (roughly translation: "never backtrack inside of this expression"). There is little useful advice a linter can give, if there is no predictable-runtime way to express what you want within a single match step, because you really do want to unwind the stack and check for repeats (just without any of the exponential runtime stuff, please).

[1]: https://meta.stackoverflow.com/questions/328376/why-does-sta...

No I think he was just looking to raise his profile, not to help.

already exists: https://joshua.hu/comparing-redos-detection-tools. `recheck` and `redos-detector` are definitely the best. there's even an eslint plugin for the latter: https://github.com/tjenkinson/eslint-plugin-redos-detector

That's a real issue, took cloudflare down once...

It's only a real issue if it is in runtime code that parses untrusted input. 99% of the regex lints/CVEs that get flagged our way are in build-time code.

I don't fully get you. Do you mean untrusted regex or untrusted data it operates on?

And to be honest, even if the regex is trusted (came from a developer) and the data as well (something predictable and structured) we are still not protected from the developer using extremely stupid regex and breaking everything

Seriously. We got 116 github dependabot alerts this week. Half of them for dev dependencies.

I got reminded every week that my static site generator "Jekyll" is insecure.

Ok. Hacking me by changing the input to my Jekyll rather involves being on the other side of the airtight hatch.

I tried to raise that with my internal security team recently - don't clutter my vulnerability dashboard with issues in dev dependencies. They somewhat rightly pointed out that malware needs to be dealt even if it's a dev dependency. So my suggestion went nowhere because I guess we can't filter by type of vulnerability.

Working in the EU energy sector where we have to work with NIS2 compliance, I'd argue that your security team rightly pointed it out. I suspect that's what you mean though, and the rightly is just there because you agree with it but don't like it. We work with even more tight dependencies policies than just having alerts. We have a set of pre-approved and yearly vetted packages, like pandas or pyarrow for Python data work. Aside from that we have some isolated development environments where your pipeline can get access to something like SQLC for Go. Which is essentially where your dev dependency lives in it's own environment where it can produce the code it needs to and then submit it for approval into your regular dev environment.

Ironically we'd probably need to run Dependabot itself in a mirrored environment since it too has external dependencies we'd probably not want to vet.

I do think external dependencies are among our biggest security threats though. It's so hard to vet them, and compliance basically comes down to "We trust the apache software foundation enough, and pyarrow is vital to our business, so we accept the risks", and then you lock versions and aren't the first to update except for vulnerabilities. Shadow AI is obviously the number one security threat right now, especially in enterprise with people who are very tech savvy. This makes dependencies so much worse though, because now everyone can (if their systems aren't locked down tight) do so many crazy things. Both with the "non-sanctioned" AI but also with the code it can generate for them.

> compliance basically comes down to "We trust the [third party] enough, and [third party component] is vital to our business, so we accept the risks"

This is the beginning and end of reasonable security. This is what it's always about, and if you go beyond it, you risk practicing art for the sake of art, at the expense of customers and other stakeholders.

Security is about understanding and managing risk. Not about achieving some mathematical perfection (which is actually only achievable by making your system an inert piece of rock, but people realize that way too late, after piling on way too many pointless "security improvements").

I've almost always gotten everything I want from security teams over my career. Usually a quick and honest chat with them gets you pretty far. I always lead with some flavor of "In my perfect world, I have 100% access and ability to everything, everywhere all the time. In your perfect world, I don't even have a computer. Here's why I need X permission / Y user group / z application"

From the perspective of big corporate security - developers are a wild nuisance who file the lions share of the tickets and soak up an inordinate amount of resources. Being able to at least explain to them that you understand their objectives and are not overrequesting just for the sake of overrequesting goes a long way.

Asking out of curiousity - how would you or how does your org handles this right now?

I'm not the previous poster, but in my experience you can get a lot of mileage out of having dev teams (tediously, at least the first time) go through all potential vulnerabilities, decide how risky each one is based on likelihood and impact, and then get them to address the high/highs somehow (e.g. by upgrading a dependency, or writing extra code to guard against the issue, or fixing the issue if it's a home-grown vulnerability).

Yeah I completely understand their intent, but I might get 30 vulnerabilities across a multiple repos flagged in a week. It is already tedious to check them all and assess if they're worth worrying about let alone having to update them. These are 99% Javascript though - I suspect other ecosystems are much more manageable.

It's easier to keep stuff up to date these days. If you have a project with typescript, unit tests, and end to end tests like cypress you can just have dependabot create the PRs to update packages. If everything passes you just have to hit the merge button.

Just updating everything is probably easier than assessing if it's possible to trigger an exploit with the way you use the package.

This is exactly how developers of malware want you to behave. Update without really thinking about it.

I do wonder how long it will take before an attack is developed by submitting a semi-genuine vulnerability, shortly followed by a ‘fix’ including malicious code.

Dependency cooldowns fix most of those problems.

The cooldown setting in dependabot solves this attack vector. By setting it you give security vendors time to scan new packages.

Notably this does nothing to "solve" the attack vector. You've got a live bomb in front of you and you're adding 10s to the countdown hoping that _others_* find it and defuse it in that time period.

I would challenge anyone proposing this to define more than one party doing security checks on packages to prove the point that many projects are waving their hands nebulously around saying "security vendors" and then YOLO'ing code into their codebase because they didn't here the muses wailing.

Alternatively from the other direction - Point to any dependency in your project. How can you get *POSITIVE SIGNAL* that security vendors _did_ look at it and okay it? How much scrutiny did they put into it? At what version did they last inspect it?

With today's AI glut of tokens, multiple someones are scanning security checks against the changed code. The real problem, as was before, was getting anybody anywhere to pay enough attention for long enough.

Only if their scanning detects it though. Malware authors have incentive to figure out how to fool the tool. They don't even need to be right all the time, any attack that survives works for them, and creating accounts is easy.

Yep this is what has happened to small teams. You really only have time to approve the dependabot changes and go go go. Otherwise you'll never get anything productive done.

The other option is to simply ignore updates and do them on a schedule, e.g. once every 1-2 months.

Or you take the alternative approach of flattening and minimizing your dependency graph. Having so many dependencies you can't reasonably field bug reports in them is a chosen tradeoff, even if it doesn't feel that way.

In agreement with frodd above.

Dependencies and supply chain attacks are probably the greatest risk to a lot of software orgs, as they run them across all their environments: Development (with secrets and other valuable artefacts on developer VMs), CI/CD pipelines which may have access tokens to production (and other) environments, and production itself.

Notably even security companies are being impacted by this[0]. The scale of these attacks has amplified quite significantly the past three years, but are not solely exclusive to the javascript ecosystem [1] or even just namesquatting/typosquatting [2].

The resolution is broader security awareness, "onion layered" security controls and implementing simple non-burden inducing processes and policies. Sometimes not updating (what was wrong with the previous version of a dependency if there was no immediate vulnerability or production issue caused by it?) or having a two week cool down for updates (which some supply chain tooling natively supports) can appease some security functions through clear communication of the supply chain risk etc.

If anyone has interest in courses aligned to your org on improving developer and broader engineering management awareness on this, e-mails in my profile :).

[0] - https://socket.dev/blog/ongoing-supply-chain-attack-targets-...

[1] - https://orca.security/resources/blog/hades-pypi-supply-chain...

[2] - https://checkmarx.com/zero-post/python-pypi-supply-chain-att...

I unironically think the solution is vibecoding your own Javascript blobs that use no frameworks and have no (or minimal) external dependencies. At this point it is entirely feasible for many kinds of projects.

Sure, so you'll be vulnerable to all sort of things because vibe code is really insecure (as I've personally seen).

First, this is great reply with lots of real world experience to share.

    > I do think external dependencies are among our biggest security threats though.

This sounds like a good business opportunity. I know that Sonatype has a business to vet Java dependencies. Does your company use it? I am guessing that Sonatype may be expanding into other open source ecosystems.

Companies like Sonatype would be an issue since they are owned by USA private equity. We would not give "Vista Equity" access to anything with the current EU US relationship. It's bad enough that we're so tied into Microsoft, which the EU might task us with leaving if they deem it critical enough for the security of the European energy sector. That's a risk we live with though, there isn't a realistic alternative.

That being said, our current strategy is more along the lines of building thind within standard libraries. We really wanted to adopt Go company wide, but it's proven impossible for non-SWE staff to use AI to create their projects in anything but Python. So instead we've created AI configurations that know our security policies, the tools we want them to use and we've setup security policies which won't even allow you to run a Python executionable inside a virtual environment unless your devices is sepcifically allowed to do so in that specific folder. Similarily we've completely limited what VSCode extensions they can use down to the named folder version. Which sort of sucks, and I doubt a lot of it would be possible if it wasn't because the c-levels are personally liable for security under EU law.

We'll see what happens after september when the summer holidays are over and the real token cost of AI will kick in.

> First, this is great reply with lots of real world experience to share.

I know how they came about with this setup, but I think that's the wrong way of approaching the problem.

Their problem is legacy and trickle-in features in an otherwise unmaintainable code.

With AI, they can rewrite their software to minimize dependencies and in general reduce the attack surface by allowing the business to automate more on their own.

But it requires bold management decisions and people in position of authority that can pick the right battles for the advancement of their careers.

Of course, all the generated code has to reviewed and vetted for by a senior developer. Of course, this has to be re-done every now and then when new classes of vulnerabilities appear that the previous generation didn’t have in mind.

Or do you just trust the AI that was trained on a lot of bogus code?

The latter, of course.

Dev dependencies is how they compromised SolarWinds and thereby most of the US federal government.

> The attackers used a supply chain attack. The attackers accessed the build system belonging to the software company SolarWinds, possibly via SolarWinds's Microsoft Office 365 account, which had also been compromised at some point. SolarWinds was using build management and continuous integration server TeamCity provided by the Czech company JetBrains. In 2021 The New York Times stated that unknown parties apparently embedded malware in JetBrains' software and through this way compromised also SolarWinds.

https://en.wikipedia.org/wiki/2020_United_States_federal_gov...

I don’t know what kind of software you write, how valuable your company’s infrastructure is, etc. But supply chain and insider threat in security/infrastructure is a big topic — that I’m sure they’re concerned about because that’s their area of responsibility.

Even if I’m personally sympathetic to not wanting to deal with the churn of dev dependency updates.

This is very real, but such CVEs are such a tiny fraction in relation to denial-of-service-due-to-regex that it’s hard to take the system seriously.

So far as I’m concerned the solution is to isolate everything as much as possible. I’d love to see something on the CVE classification side to also address the signal to noise problem but I don’t see it happening.

Pretty much - I don't know too much about the CVE process but if ReDoS stuff was flagged at the CVE level as "exploitable only with unconstrained inputs" then great - I know my tests have sane inputs, so I'll close thanks.

These DoS Regex 10/10 CVEs in some minor helper function in some package that is used once in some random side code pathway are so damn annoying.

If I could filter out DoS CVEs‚ I would.

So I have a library and its ultimate purpose is converting globs to regexes. Someone sent me a ReDoS vulnerability report with a 4.0 CVSS score because if you write an obscene glob pattern you'll get a correspondingly obscene (and inefficient) regex. What else would you have it do!?

Vulnerable dependencies are very different to compromised or backdoored dependencies though. Noone's taking over Solarwinds because their build tools had a ReDOS involving input from their own config files.

Everyone talking about malware in dev dependencies as if dependabot only raises issues about that, but it does not. It raises warnings about all sort of "vulnerabilities" irrespective of the threat model.

Even worse, it incentivizes randomly updating dependencies, which is what actually allows supply chain attacks.

A lot of the recent npm attacks have been exfiltration from dev machines, which would just as likely from dev dependencies.

Developer's machines and cicd systems are high value targets. They were absolutely right to point that out.

Only in the castle and moat security model popularized by Microsoft and the various "security" vendors that leech off it.

And the money wasted on the security theatre around this outdated concept is astonishing.

It's even worse if you're SOC2 because then you actually have to go through and mark them as "not exploitable." The noise is insane right now.

CVE 10 if you use you current version of Python to serve files over ftp, and parse the incoming files using the most obscure file type found in the forbidden libraries of the Vatican

And your ISO etc certificates make this CVE mandatory priority 1 action point

I think this one has more to do with excessive dependencies, and lack of splitting into individually installable packages and/or static linking.

I have already avoided having to evaluate whether I am affected by some issue because I added patches at startup that crash before certain unused-yet-installed modules are to be loaded. Also, for those Python packages that still have a pure version that defers to stdlib and a separate muh-performance binary option with statically linked dependencies, I can generally just install the former and skip the version bumps for dependencies. The performance advantage may be negligible or negative outside of benchmarking 100k calls.. of code actually called 11 times a day, on a non-critical path.

Yeah. We used to get a bunch for OS things inside containers (the ones that had OSes in there) like "Perl regex has exploitable something-or-other". They always came in at high priority so we had to fix them, but realistically they were irrelevant.

Not sure what dumbass out there is marking those as 10/10. A 10 should be an auth bypass or RCE. Not a crashed build in my CI.

Time to start banning those that submit fake or superficial reports. Maybe with enough bans these people will start actually reading their own vulnerabilities.

CVE 10.0 if you happen to use one specific functionality in the library. Non-CVE if you do not, and because it's an old bug, you cannot just downgrade to get a non-red result from Trivy.

we killed the curators.

(besides cve, nist, et al drop in criteria) searching for an indepth analisys, you find one million (after scrolling the Ai summary) results that are either copy-pastrle or Ai rewording of the cve announcement.

...and don't get me started on the proofs that stop after smelling the attack vector. you can't evaluate if your setup is DoSable at most or full remote shell.

there's still tons of good analisys and reports. but the noise....

The common thread of late really seems to be the node ecosystem

Same experience here. I've run a successful vulnerability disclosure program for over a decade and paid out thousands of dollars in bounties for scanii.com (a malware identification API service), but recently (since the beginning of the year), we went from receiving maybe 5 per month to receiving 5 per day. These are clearly AI-generated and extremely low quality (albeit well-written). The rules of the program aren't read, and it's clearly a “point-and-click to a website" and file a report. I'm now considering just shutting down the program since, as the OP pointed out, if you found this vulnerability using an AI tool, they are inherently public. I haven't gone that far yet but have instituted some new rules aiming at filtering out most of the reports: 1- No AI-generated report and 2 - Reports must include a video of the exploit. You can see our program rules here: https://docs.scanii.com/article/131-does-scanii-have-a-secur...

What if... on the vulnerability report rules page there's an image of some text saying something like "your report must include the text: turtle123". Reports without that text get automatically deleted.

Sure - modern AI can figure that out, but I bet in a vast majority of cases they won't.

Reminds me of someone (well known in their field) who charged $0.05 for using their “contact me” page. A trivial amount for someone who genuinely wanted to contact them, but just high enough to prevent any kind of scaled abuse

If I've stumbled across what I think is a security issue in your systems, there is zero chance that I'm going to get out my credit card and pay you for the privilege of responsibly disclosing it to you. Especially if it's the vulnerability is in the site hosting the contact form.

I don’t participate in bounties at all unless I believe there is a moral obligation or I’m set to make thousands of dollars. In each case, $0.05 is fine.

For a typical commercial entity? $0.05 is not a deterrent; the companies legal team is and has been for a decade.

In most cases I'd think it's more of a deterrent for commercial entities, because spending money create complexity. Most employees are not in a position to just directly spend their organisation's money, so that $0.05 will often mean needing to get approval, purchase orders, deciding which cost centre it comes from, needing an invoice, etc, etc.

Very few people are going to invest that much effort when they're trying to do the company that they're reporting to a favour.

That actually great idea. What payment method or processor used?

I know some professors who have started doing something similar to combat students using AI for their work. Even going as far as to hide the "your report must include XYZ obscure word 3x" prompt instructions in small invisible text. It's gotten pretty bad, with some students turning in papers with the original ChatGPT prompt LEFT IN THE TURNED IN ASSIGNMENT.

Have you considered requiring a small payment for vulnerability disclosure? Refund it on payout. This should be very effective at deterring spammers. It also sucks for real reports, but beats shutting down the program entirely.

Why would anyone pay money to have a chance of being arrested?

If a vulnerability disclosure program has a good track record of paying out, and legitimate reports get refunded, why not?

Again, the alternative might be shutting down the program entirely.

Those are 2 big "ifs". The incentives are completely misaligned and the platforms work for the companies. They would now have an even bigger incentive to stonewall and close valid issues than they did before.

They already like blurring the lines by rejecting reports that have clear reproduction scripts, videos, demonstrable (but not critical) impact. They'll close it as "not a bug" but then also forbid disclosure and stonewall mediation requests. Reports are supposed to be kept private until the issue is fixed but the system gets abused to cover up issues long after they've been fixed.

In some cases I strongly suspect it's to evade liability for financial damages that their customers might've suffered. Platform mediation always takes their side and if you want to do what's right, you will get banned.

It's not a horrible idea... the challenge there would be making that payment/refund flow totally transparent in order to build trust and be fair to the researchers.

Making, payment/refund setup is more complicated than „set and forget”.

First question: Do you keep money for shit reports?

Well no, you have to pay it back like credit card validation. There is no pain for posting shit report just inconvenience. There is no legal way where you can keep the money.

Why not?

Because you are not providing any service not selling anything. There is no real way as a company to withhold someone’s money and that it goes through accounting.

I am not an accountant so ask some accountants why not.

To participate in the bug bounty program, you must pay ACME Inc. $1 (one U.S. dollar) per submission. This payment is non-refundable as it covers our triage costs and bounty payment processing fees. You may submit a vulnerability without paying, but you will not be eligible for receiving any bounty payments under this program.

If your disclosure otherwise meets all of the guidelines of the program, but is not eligible for a bounty, we may, in our sole discretion, award you a bounty of $1.

it's not illegal to ask people to send you money and then keep the money they send you

it is if you can’t explain it to tax authorities, especially if you are a business

    > chance of being arrested

I am not involved with security research in any way. Can you explain the threat here?

There is a history of companies and organisations threatening legal action against security researchers when they report vulnerabilities in their systems or products.

Sometimes even when the testing has been completely offline - I know people who have downloaded some software, carried out testing against a local copy of it, and then faced legal threats when they tried to report serious security vulnerabilities to the vendor.

It's one of the reasons that some researchers don't bother trying to talk to the vendors and just go straight to full disclosure, or if they do report to vendors they do so anonymously. But if you have to pay, that's creating a link back to yourself which makes the latter much harder.

Yikes. Thanks for the good faith reply. Does EFF help to defend some of these cases?

When you report a vulnerability in a product that means you hacked the product. Hacking is illegal. If it's something that runs on your own computer you might get away but if it runs on a server then it's 100% a felony.

Sure, it sounds dumb when you say it like that.

But do you know how many people are doing things that are even dumber right this very minute? I don't know either, but I'm sure it's larger than either of us would like to admit.

why would anyone accept bounty money to have a chance of being arrested?

Yeah, I help review security reports for a small FOSS organization, and someone reported a "critical" vulnerability about a publicly-accessible SVN server. Like yes, that is indeed the purpose of hosting open source software. But at least that report was obviously bogus; much worse are the ones that look legitimate at first, so you have to read through dozens of AI-generated paragraphs to make sure that there's nothing valid hidden in there.

I use AI to read such emails!

I believe the term is Beg Bounties and they are constant and annoying.

> As someone running a company, I get 2-5 unsolicited "vulnerability reports" per week. Half of them are an LLM finding some bad CSS on our framer splash page. The other half I assume are an extortion attempt so we just mark as spam.

I don't think that is unique to the LLM era. The company I work for has been getting some form of spam vulnerability reports years before LLMs were a thing. Often similar to what you mention about 'bad CSS'.

Maybe the volume has increased a bit, but we've added in a filtering solution and I'm more distant from the reports now, so hard to be sure.

Vulnerability reports are a voluntary service to help a vendor or software project. It’s often an annoyance for the security researcher. I understand people are getting slammed and it sucks, but the main result of rejecting them is going to be an increase in full disclosure. As a note: if you have a bug (that isn’t devastating but you’d like to talk about) having an LLM write up the disclosure is a great way to check the “we disclosed responsibly and they didn’t care” box.

> I understand people are getting slammed and it sucks, but the main result of rejecting them is going to be an increase in full disclosure.

Right, what I'm saying is that letting those bugs go to full disclosure (aka being filed as public issues, like every other bug) would have been a significant damage to user safety a year ago, and it's not anymore.

I think that’s an assumption. Just because an LLM might be able to find some bugs does not mean every attacker has a packaged attack, or the right prompting. The easiest way to find a vuln is just to Google for it.

Its been like that for half a decade across all software. People act like finding a linux kernel bug is a big deal, completely ignoring the fact that in order to exploit that bug, the attacker has to be able to run code on your computer in the first place, which is extremely hard to do these days remotely.

Also people ironically just DGAF that much. The last actual bad exploit was log4shell in java, which given how it was introduced (i.e someone purposefully at Apache made it so a log statement can execute code, and nobody questioned it before pushing it to prod), should have been the signal for everyone to completely remove all Apache libraries from their services, but yet all the software is still being used.

These bugs are indeed important, you need them once you‘ve found a bug in an application.

If someone manages to get remote code execution at user space on a machine, the amount of damage that they can do with just that versus having a kernel level exploit is about the same.

Ah yes, just move away from all apache libraries, should only take a day or two.

No I agree, its a pain, but its necessary if you care about security and don't want to audit every single release for potential vulnerabilities. People don't do this, so they really don't care that much.

We also get unsolicited vulnerability reports from companies trying to poach our annual pentest contract, which is... a tad grey ethically-speaking

I hated these low-effort reports, so I created a simple automation that checks my security inbox, mentions me in #security on Slack for things that look legitimate so I see them quickly, and marks things that seem entirely automated as spam.

I still check the spam folder for legitimate emails, but so far there haven't been any false positives.

but why would you answer with a C&D if you are overwhelmed? provided, it's not always the same person?

Have you considered having an agent, or just a model, classify/triage them for you? Modern problems require modern solutions.

Reply on news.ycombinator.com