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

Compromising OpenWrt Supply Chain

flatt.tech

Post reply on HN
Print view View original

41–50 of 105 posts

Re: Compromising OpenWrt Supply Chain

#41

Post by agwa »

blueflow wrote: post #35
BoppreH wrote: post #34

Isn't the "".join also dangerous? get_str_hash( "".join( [ build_request.distro, build_request.version, build_request.version_code, build_request.target, ... You can shift characters between adjacent fields without changing the hash. Maybe you cannot compromise the system directly, but you could poison the cache with a broken image, or induce a downgrade.

Yes, one should use a hmac for hashing multiple inputs, for the reason you explained. Edit: s/hmac/incremental hashing/

What do you mean by "incremental hashing"? Note that the Init-Update-Finalize API provided by many cryptography libraries doesn't protect against this - calling Update multiple times is equivalent to hashing a concatenated string.

Re: Compromising OpenWrt Supply Chain

#42

Post by [deleted] »

micw wrote: post #4

That's why open source can never compete with business grade closed source stuff: - they fixed the in 3 hours instead of making customers wait 6 months for a patch (if any) - they did not try to sue the reporter of the issue - they did not even tell the users to throw away the "outdated" but perfectly working devices, offering a small discount to buy new

[deleted]

Re: Compromising OpenWrt Supply Chain

#43

Post by blueflow »

agwa wrote: post #41
blueflow wrote: post #35

Earlier quoted context omitted.

Yes, one should use a hmac for hashing multiple inputs, for the reason you explained. Edit: s/hmac/incremental hashing/

What do you mean by "incremental hashing"? Note that the Init-Update-Finalize API provided by many cryptography libraries doesn't protect against this - calling Update multiple times is equivalent to hashing a concatenated string.

I mean the same what you call Init-Update-Finalize.

link needed about the dysfunctional implementations.

Re: Compromising OpenWrt Supply Chain

#44

Post by dist-epoch »

dhx wrote: post #31

A vulnerability not mentioned in the article is the normalisation of executing code that has been especially targeted to a specific user or specific device with no validation of reproducibility and no ability for anyone to verify this custom build and download service hasn't been generating backdoored builds. One should want to ensure use of the same build of xz-utils that Andres Freund is using, or at least a build…

> automated/semi-automated scans of open source software builds to check for unexplained high entropy files which could contain hidden malicious code

that's easily defeated though, you just "spread-out" the entropy.

Re: Compromising OpenWrt Supply Chain

#45

Post by cesarb »

orra wrote: post #25
micw wrote: post #4

That's why open source can never compete with business grade closed source stuff: - they fixed the in 3 hours instead of making customers wait 6 months for a patch (if any) - they did not try to sue the reporter of the issue - they did not even tell the users to throw away the "outdated" but perfectly working devices, offering a small discount to buy new

Whilst this is true, it looks like OpenWRT fixed the hash truncation but not the command injection. I hope they're planning on fixing the command injection. As the blog post says, the created images are signed. Even without the signing, it's code execution from untrusted user input. And of course vulnerabilities can be strung together (just like in this hash collision case).

> Whilst this is true, it looks like OpenWRT fixed the hash truncation but not the command injection.

They did fix both AFAIK, the command injection fix is https://github.com/openwrt/asu/commit/deadda8097d49500260b17... (source: https://openwrt.org/advisory/2024-12-06).

Re: Compromising OpenWrt Supply Chain

#46

Post by misiek08 »

djaychela wrote: post #38

I'm getting an error when I try to view this: Secure Connection Failed An error occurred during a connection to flatt.tech. SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG No-one else?

Not even on my company's crappy proxy (not supporting QUIC and having problems with HTTP/2 sometimes). Works, loads rather quickly.

Re: Compromising OpenWrt Supply Chain

#47

Post by agwa »

blueflow wrote: post #43
agwa wrote: post #41

Earlier quoted context omitted.

What do you mean by "incremental hashing"? Note that the Init-Update-Finalize API provided by many cryptography libraries doesn't protect against this - calling Update multiple times is equivalent to hashing a concatenated string.

I mean the same what you call Init-Update-Finalize. link needed about the dysfunctional implementations.

For example, try running this Go program: https://go.dev/play/p/atvS3j8Dzg-

Or see the Botan documentation that explicitly says "Calling update several times is equivalent to calling it once with all of the arguments concatenated": https://botan.randombit.net/handbook/api_ref/hash.html

I've worked with many cryptography libraries and have never seen an Init-Update-Finalize API that works the way you think it does. It does not protect against canonicalization attacks unless you're using something like TupleHash.

Re: Compromising OpenWrt Supply Chain

#48

Post by vsl »

blueflow wrote: post #43
agwa wrote: post #41

Earlier quoted context omitted.

What do you mean by "incremental hashing"? Note that the Init-Update-Finalize API provided by many cryptography libraries doesn't protect against this - calling Update multiple times is equivalent to hashing a concatenated string.

I mean the same what you call Init-Update-Finalize. link needed about the dysfunctional implementations.

No, these APIs are intentionally designed to be equivalent to hashing all data at once - i.e. to make it possible to hash in O(1) space.

There's nothing "disfunctional" about that.

"Incremental hash function" has a very different meaning and doesn't seem to have any relevance to what is discussed here: https://people.eecs.berkeley.edu/~daw/papers/inchash-cs06.pd...

Re: Compromising OpenWrt Supply Chain

#49

Post by blueflow »

vsl wrote: post #48
blueflow wrote: post #43

Earlier quoted context omitted.

I mean the same what you call Init-Update-Finalize. link needed about the dysfunctional implementations.

No, these APIs are intentionally designed to be equivalent to hashing all data at once - i.e. to make it possible to hash in O(1) space. There's nothing "disfunctional" about that. "Incremental hash function" has a very different meaning and doesn't seem to have any relevance to what is discussed here: https://people.eecs.berkeley.edu/~daw/papers/inchash-cs06.pd...

I guess the PHP documentation is wrong then. Look at this: https://www.php.net/manual/en/function.hash-init.php

Re: Compromising OpenWrt Supply Chain

#50

Post by dml2135 »

sweeter wrote: post #30
micw wrote: post #4

That's why open source can never compete with business grade closed source stuff: - they fixed the in 3 hours instead of making customers wait 6 months for a patch (if any) - they did not try to sue the reporter of the issue - they did not even tell the users to throw away the "outdated" but perfectly working devices, offering a small discount to buy new

I have a router that from my ISP I am forced to use that has had a few CVEs ranging from not good to really bad. Most of which are years old. I can get a replacement but it's just the same model. They don't care about security at all and don't care about patching it, even though they have exclusive access rights to the router and can remotely log in to it. It's completely ridiculous.

What forces you to use it? You can’t bring your own router?
Post reply on HN