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

29 points by pushcx a day ago on lobsters | 19 comments

[OP] pushcx | a day ago

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 | 18 hours ago

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?

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

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?

[OP] pushcx | 12 hours ago

Select, right click, "Copy Link to Highlight". I used to have an extension for this but it now ships in firefox. I think I had to enable dom.text_fragments.enabled in about:config.

Along these lines, display anchors is a very handy extension.

strugee | 11 hours ago

I think I had to enable dom.text_fragments.enabled in about:config.

The feature is on by default for me without having touched about:config, but I'm running a (recent) Firefox Nightly.

It was on for me without fiddling with configuration at all in stock (but latest?) Firefox.

apromixately | 10 hours ago

u make the link t

Select, context menu > Copy Link to Highlight (in Firefox)

bediger4000 | 13 hours ago

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 | 16 hours ago

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

  1. inconvenience because it's not well supported in the tooling now and
  2. 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.

(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 | 16 hours ago

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 | 16 hours ago

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 | 16 hours ago

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 | 13 hours ago

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.

apromixately | 12 hours ago

Yes, but there is a lot of wouldacouldashoulda.

  • certainly, sandboxing by app is much better on mobile and desktop is just dragging its feet
  • certainly Docker could actually provide decent security (and should)
  • certainly everybody should be using programming languages that make it harder to make mistakes
  • ...

but here we are, with software which has easily exploitable memory errors, not enough defense in depth, operating systems that don't even understand what an app or a publisher is and just deal with processes, container solutions which don't properly contain things ...

work to do...let's fire all the people and wait for AI to do it!

k749gtnc9l3w | 11 hours ago

Defense in depth wise, I think there is a scary split.

On desktop, you can spend like a couple of weeks learning the concepts and tooling and end up with a personal, command-line-competence-dependent setup which uses Firejail-class isolation, treats things that mobile won't let you have as trivial table stakes, probably doesn't lack much compared to mobile, etc. Maybe you spend a couple of weeks of work over a couple years.

Or one can try to do GUI-manageable and user-friendly things, that ends up needing many person-years to get to usability, and is pretty bad at half-measures. All that I see tells me it is a literal two-decimal-orders-of-magnitude difference in effort, and it looks like there is enough design and compatibility and spec negotiation work that you cannot really shave even one full decimal order of magnitude even if you can magically instantly search all the literature in the world or materialise precise implementations of requirements with reasonable-ish choices of unspecified part.

And of course one-week-setups suffer from Lisp curse — they are easy enough and personalised enough that they often stay very personal tools, even if published. Although this also means that they have quirks where you cannot just use standard Docker exploits or whatever. Nobody promised that breaking out of Firejail leaves you under a UID which can write the main user's .ssh, you still need to do full LPE outside.

(Myself, I ended up using nsjail for stuff like Firefox or LibreOffice, although I am optimistic enough about better languages that I run HTML muncher in Common Lisp without carefully jailing it. I did recently panic and make sure running curl jailed is slightly more comfortable to make myself stop running it unjailed. Maybe it's time to use microVMs… Speaking of Lisp curse, my version of setting up nsjail does coordinate some of the work in Common Lisp.)

apromixately | 10 hours ago

Right, but solutions that only work for experts don't solve the problem which applies to everyone.

k749gtnc9l3w | 9 hours ago

Worse, the gap kind of makes the universal part of the problem harder, because there is no ladder to climb. Solving a problem you have better does not lead to the point where pushing for the general solution finally feels feasible, it just leads to the point where the problem is solved as good as the available components allow. Now what.

Although I guess some companies have the theoretical option to go back, where having a computer connected simultaneously to the Internet and the local net with non-public data was limited to experts (and higher-ups on systems individually monitored by experts)?

Looking at «expert» solutions highlights, though, just how many glaring omissions the mobile isolation solutions have, compared to any competent-user-assuming solution.

ETA: but Kubernetes providing decent security is also an expert solution anyway.