Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Turn Dependabot off

words.filippo.io

Post reply on HN
Print view View original

151–160 of 195 posts

Re: Turn Dependabot off

#151

Post by cedws »

eru wrote: post #134
cedws wrote: post #133

I don’t know why the industry collectively accepted these security scanners (code + containers) that don’t even do the most basic of static analysis to see if the vulnerable code is reachable. Companies are breaking their backs trying to maintain a constant zero vulnerabilities in their container images when 99% of the CVEs don’t actually affect them anyway. The kicker is that updating the dependencies probably just…

> The kicker is that updating the dependencies probably just introduces new CVEs to be discovered later down the line because most software does not backport fixes. I don't understand how the second part of that sentence is connected to the first.

I could have written it more clearly. If you’re forced to upgrade dependencies to the latest version to get a patch, the upgrade likely contains new unrelated code that adds more CVEs. When fixes are backported you can get the patch knowing you aren’t introducing any new CVEs.

Re: Turn Dependabot off

#152

Post by jgalt212 »

The lead example is about the (*Point).MultiScalarMult method (not a golang person so perhaps wrong terminology).

Instead of, in addition to, updating all your dependencies, perhaps it would be better to emit monkey patches that turn unsafe methods into noops, or raise an exception if such methods are invoked. e.g "paste these lines at the beginning of main to ensure are you not impacted by CVE-2026-XXXX."

Re: Turn Dependabot off

#153

Post by prmoustache »

jpollock wrote: post #52
michaelt wrote: post #48

Earlier quoted context omitted.

> If the system is configured to "fail open", and it's something validating access (say anti-fraud), The problem here isn't the DoS, it's the fail open design.

If the majority of your customers are good, failing closed will cost more than the fraud during the anti-fraud system's downtime.

If that is the mindset in your company, why even bother looking for vulnerabilities?

Re: Turn Dependabot off

#154

Post by 8bitme »

The issue with not updating often enough is that if there is a zero day and you're far enough behind you will be forced to go through the pain of working out how to upgrade to the latest patched version where there may be a painful upgrade path in between

Re: Turn Dependabot off

#155

Post by SkiFire13 »

Chris_Newton wrote: post #139
maweki wrote: post #131

Earlier quoted context omitted.

> it is inherently resistant to false positives By Rice's Theorem, I somehow doubt that.

Sorry, I don’t understand the point you’re making. If CodeQL reports that you have a XSS vulnerability in your code, and its report includes the complete and specific code path that creates that vulnerability, how is Rice’s theorem applicable here? We’re not talking about decidability of some semantic property in the general case; we’re talking about a specific claim about specific code that is demonstrably true.

> We’re not talking about decidability of some semantic property in the general case; we’re talking about a specific claim about specific code

Is CodeQL special cased for your code? I very much doubt that. Then it must work in the general case. At that point decidability is impossible and at best either false positives or false negatives can be guaranteed to be absent, but not both (possibly neither of them!)

I don't doubt CodeQL claims can be demonstrably true, that's still coherent with Rice's theorem. However it does mean you'll have false negatives, that is cases where CodeQL reports no provable claim while your code is vulnerable to some issues.

Re: Turn Dependabot off

#156

Post by everforward »

Chris_Newton wrote: post #139
maweki wrote: post #131

Earlier quoted context omitted.

> it is inherently resistant to false positives By Rice's Theorem, I somehow doubt that.

Sorry, I don’t understand the point you’re making. If CodeQL reports that you have a XSS vulnerability in your code, and its report includes the complete and specific code path that creates that vulnerability, how is Rice’s theorem applicable here? We’re not talking about decidability of some semantic property in the general case; we’re talking about a specific claim about specific code that is demonstrably true.

Rice’s theorem applies to any non-trivial semantic property.

Looking at the docs, I’m not really sure CodeQL is semantic in the same sense as Rices theorem. It looks syntactic more than semantic.

Eg breaking Rices theorem would require it to detect that an application isn’t vulnerable if it contains the vulnerability but only in paths that are unreachable. Like

    if request.params.limit > 1000:
         throw error
    # 1000 lines of code
    if request.params.limit > 1000:
         call_vulnerable_code()
I’m not at a PC right now, but I’d be curious if CodeQL thinks that’s vulnerable or not.

It’s probably demonstrably true that there is syntactically a path to the vulnerability, I’m a little dubious that it’s demonstrably true the code path is actually reachable without executing the code.

Re: Turn Dependabot off

#157

Post by everforward »

jpollock wrote: post #52
michaelt wrote: post #48

Earlier quoted context omitted.

> If the system is configured to "fail open", and it's something validating access (say anti-fraud), The problem here isn't the DoS, it's the fail open design.

If the majority of your customers are good, failing closed will cost more than the fraud during the anti-fraud system's downtime.

You are really running with scissors there. If anyone with less scrupulous morals notices, you’re an outage away from being in deep, deep shit.

The best case is having your credit card processing fees like quadruple, and the worst case is being in a regulated industry and having to explain to regulators why you knowingly allowed a ton of transactions with 0 due diligence.

Re: Turn Dependabot off

#158

Post by staticassertion »

eru wrote: post #136
jpollock wrote: post #38

Earlier quoted context omitted.

The severity of the DoS depends on the system being attacked, and how it is configured to behave on failure. If the system is configured to "fail open", and it's something validating access (say anti-fraud), then the DoS becomes a fraud hole and profitable to exploit. Once discovered, this runs away _really_ quickly. Treating DoS as affecting availability converts the issue into a "do I want to spend $X from a shaked…

Also in eg C code, many exploits start out would only be a DoS, but can later be turned into a more dangerous attack.

If you're submitting a CVE for a primitive that seems likely to be useful for further exploitation, mark it as such. That's not the case for ReDOS or the vast majority of DoS, it's already largely the case that you'd mark something as "privesc" or "rce" if you believe it provides that capability without necessarily having a full, reliable exploit.

CVEs are at the discretion of the reporter.

Post reply on HN