Hacker News Reader

Comment by riadsila | Hacker News Reader

For more context: https://www.metabase.com/blog/security-advisory

They say they’ll be releasing the patch publicly, but isn’t this OSS, can’t anyone just do a diff and with a little “elbow grease” find the patch?

They haven't released the source, and the compiled versions are non-trivial to diff (e.g. there are nondeterministic numbers from the clojure compiler that seem to have changed from one to the other, and .clj files have been removed from the jar).

The old version has `hash=1bb88f5`, which is a public commit: https://github.com/metabase/metabase/commit/1bb88f5

Whereas the new version has `hash=c8912af`, which is not: https://github.com/metabase/metabase/commit/c8912af

I could be wrong (and often am), but I am seeing updates related druid client authentication.

I didn't even know you could have a "private" commit on GitHub/an open source repo like that.

Oh, I didn't mean to imply you can, just that it's 404... presumably it exists in a repo checked out on someone's machine, and maybe in a separate private Github repo.

This is silly on my end (I woke up early and have time to kill)...

Also like, note: I would never publicly disclose whatever I find, I'm just curious

I observed exactly what you said about the Clojure filenames not matching up, etc. etc.

    #!/bin/bash
    
    # Variables
    DIR1=~/metabase-v0.46.6.jar.src # decompiled with jd-cli / jd-gui (java decompiler)
    DIR2=~/metabase-v0.46.6.1.jar.src # decompiled with jd-cli / jd-gui (java decompiler)
    
    # Function to create fuzzy hash for each file in a directory
    create_fuzzy_hashes() {
      dir=$1
      for file in $(find $dir -type f)
      do
        ssdeep -b $file >> ${dir}/hashes.txt
      done
    }
    
    # Create fuzzy hashes for each file in the directories
    create_fuzzy_hashes $DIR1
    create_fuzzy_hashes $DIR2
    
    # Compare the hashes
    ssdeep -k $DIR1/hashes.txt $DIR2/hashes.txt

How far do you think this gets us (fuzzy hashing)?

I was thinking this, or binary diffing the .class (instead of the "decompiled" .java)?

I found something which is clearly a security fix, using the same idea but more naive: just diffing at the lengths of the decompiled files. It's not at all clear how the issue I found would be triggered by an unauthenticated user though.

> Yes, we’ll be releasing the patch publicly, as well as a CVE and an explanation in two weeks. We’re delaying release to give our install base a bit of extra time before this is widely exploited.

Unfortunately that means it's not possible to deploy this without violating the AGPL...

No one cares. It's a two week violation and no one is going to hunt anyone down who released this early internally.

Even though this is technically a violation, licenses aren't black & white. The objective and intent of the AGPL is not being violated by delaying release by a couple weeks to give time for security patches to be applied.

https://github.com/metabase/metabase/compare/v0.46.6...v0.46...

I can't tell if that's it?

edit: I've looked at it a few times, I don't think that's it?

The only thing that seems remotely interesting is the "private key" part - I don't know Clojure but it doesn't seem like that's it.

They backported it to v0.45x and those changes don't seem to be included: https://github.com/metabase/metabase/compare/v0.45.4...v0.45...

aka, It isn't checked in to source control publicly yet. Interesting.

I tried to "decompile" the jars and loop over the files but it didn't yield much/wasn't clean enough to be of help.

Reply on news.ycombinator.com