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

31–40 of 105 posts

Re: Compromising OpenWrt Supply Chain

#31

Post by dhx »

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 of xz-utils that other security researchers can later obtain to figure out whether supply chain implants are present in open source software[1].

There's a write up at Mozilla[2] from years ago describing an abandoned attempt by Mozilla to ensure their release builds are publicly logged in a Merkle tree. Google has written up their implementation for Pixel firmware builds but apps delivered through the Google Play Store seem to be vulnerable (unless there is another log I have been unable to find).[3] Apple is seemingly worse than Google on binary transparency with Apple's firmware and app distribution system targeting builds to individual devices with no transparency of builds.

For an example of binary transparency done well, Gentoo's ebuild repository (being a single Git repository/Merkle tree containing source checksums) possibly remains the largest and most distributed Merkle trees of open source software.

[1] Post xz-utils backdoor, some researchers (including some posting to oss-security about their efforts) undertook automated/semi-automated scans of open source software builds to check for unexplained high entropy files which could contain hidden malicious code. This is not possible to achieve with customised per-user/per-device builds unless every single build is made publicly available for later analysis and a public log (Merkle tree) accompanies those published builds.

[2] https://wiki.mozilla.org/Security/Binary_Transparency

[3] https://developers.google.com/android/binary_transparency/ov...

Re: Compromising OpenWrt Supply Chain

#32

Post by PoignardAzur »

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

Not gonna lie, you had me in the beginning.

Re: Compromising OpenWrt Supply Chain

#34

Post by BoppreH »

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.

Re: Compromising OpenWrt Supply Chain

#35

Post by blueflow »

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/

Re: Compromising OpenWrt Supply Chain

#36

Post by TacticalCoder »

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.

The one I use looks scary too. And it came by default with a dumb password too. I wouldn't be surprised if it had a few CVEs hanging too.

> I have a router that from my ISP I am forced to use...

A friend of mine did impersonate the ISP's router's MAC address and used wireshark to sniff the traffic when the modem started. He then configured the ONT (which is physically inside a SFP plug, it's tiny) to establish the handshake/send the credentials.

I don't think the ISP has any idea at all :)

Re: Compromising OpenWrt Supply Chain

#37

Post by BoppreH »

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/

Not quite. HMAC helps to prevent length extensions attacks (if the underlying hash was vulnerable in the first place), and the secret prevents attackers from predicting the hash value (like OP did).

But HMAC doesn't help against ambiguously encoded inputs:

  hmac(key, 'aa'+'bb') == hmac(key, 'aab'+'b')
You want a way to unambiguously join the values. Common solutions are:

- prepending the length of each field (in a fixed number of bytes);

- encoding the input as JSON or other structured format;

- padding fields to fixed lengths;

- hashing fields individually, then hashing their concatenation;

- use TupleHash, designed specifically for this case: https://www.nist.gov/publications/sha-3-derived-functions-cs...

Re: Compromising OpenWrt Supply Chain

#38

Post by djaychela »

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?

Re: Compromising OpenWrt Supply Chain

#39

Post by blueflow »

BoppreH wrote: post #37
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/

Not quite. HMAC helps to prevent length extensions attacks (if the underlying hash was vulnerable in the first place), and the secret prevents attackers from predicting the hash value (like OP did). But HMAC doesn't help against ambiguously encoded inputs: hmac(key, 'aa'+'bb') == hmac(key, 'aab'+'b') You want a way to unambiguously join the values. Common solutions are: - prepending the length of each field (in a fix…

Yeah i confused hmac's with incremental hashing, i use both at once.
Post reply on HN