Just a rumour of a bug is enough to find a security exploit these days

27 points by pushcx

pushcx

I quietly opened cohttp#1145 publicly to get more eyes⁠ on it... Within about ten minutes (!) this website was fielding probes for percent-encoded traversal sequences

This caught my eye as it nearly meets a prediction I made.

freddyb

A lot of people in the industry agree. I think the website https://zerodayclock.com/ was announced at the unprompted conf in February this year?
- avsm
  
  Oh that's a (depressingly) cool graph! I wonder if there's sufficient metadata in the CVE database to partition the zero days by programming language mix as well (or indeed, by other dimensions about the project such as dependency graph depth).
mw

How did you make the link to the text? I understand mechanically, I'm asking from a usage perspective. Copy/paste text into the text= url hash? Did you copy or hand write the comment permalink? Is there a browser feature that just does this?

bediger4000

Why is the rumor even necessary? Can't some nation-state hacker with a budget turn a model loose on a code base (Apache portable runtime comes to mind) and reap the benefits?

apromixately

3.1 Super sekrit private patch development

The text in this section is a bit odd. I think this is a reasonable strategy and the only arguments against it seem to be

inconvenience because it's not well supported in the tooling now and
that it's difficult to decide who should get access in an open source world, but I don't see how that is different from the initial advisory.

avsm
(author here) Both of those points are big blockers in reality.
1. If GitHub has a sucky private repo feature, then the only option is to move away to a different provider. But shifting CI and repo metadata is a very, very big cost for most projects.
2. And it was totally broken for the old advisory mechanism as well! Why should security issues get a completely separate workflow from every other task in a project? The answer used to be because they were relatively rare and high impact. Nowadays, security issues are a dime a dozen and we're all getting overwhelmed with reports about them. Something's got to change.
- apromixately
  
  I agree that something has to change, I just thought maybe the thing to change is to support this workflow.
  
  If public work leads to exploits, what options do you have but to work in private?
Student

One thing that occurs to me is that as soon as a security patch is released attackers should probably analyse the patched version for new exploits, and the next regular release, because clearly it’s a project that let through one exploit and only fixed that specific one. I imagine I’m not the first to think this.
- addison
  
  Yes, this is called patch diffing and is quite common for vulnerability research of closed-source programs. Useful for building n-day exploits, but this new exploit timeline massively disfavours OSS. I kind of hope that we see more aggressive sandboxing and mitigations in the future as a response, because clearly patching isn't enough.
  - Student
    
    In theory kubernetes should provide most of what is needed - most processes should be capable of being locked down to talk to only exactly what they need to talk to. From what little I’ve seen the tooling to easily define the horizons of the little world of each pod isn’t really there.