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

71–80 of 105 posts

Re: Compromising OpenWrt Supply Chain

#71

Post by kccqzy »

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…

Yeah I remember Google's certificate transparency team basically designing firmware transparency for all of Linux (not just Android) as well.

Re: Compromising OpenWrt Supply Chain

#72

Post by rrr_oh_man »

srmatto wrote: post #70

OpenWrt is also very difficult to safely upgrade on some devices which I would also consider as a huge downside. I finally gave up and bought an old Dell off eBay and installed OpnSense and am much happier.

https://opnsense.org/wp-content/uploads/2024/07/OPNsense%C2%...

That looks so goofy

Re: Compromising OpenWrt Supply Chain

#73

Post by not2b »

CorrectHorseBat wrote: post #69
tristor wrote: post #67

Earlier quoted context omitted.

This is a nice idea, and one I also advocate for, however it's important to keep in mind that the idea of reproducibility relies on determinism. So much of what goes into a build pipeline is inherently nondeterministic, because we're making decisions at compile time which can differ from compilation run to compilation run, setting aside flags. In fact, that's the point of an optimizing compiler, as many reproducible…

Counterpoint: Archlinux is 89% reproducible with optimizations enabled. The only thing I see which is difficult to make reproducible is optimizations with a timeout.

Instead of using a timeout, an optimization that can must be cut off if the cost is excessive can keep some kind of operation or size count, where the count is strictly a function of the input. For example, an optimization based on binary decision diagrams (BDDs) can put a ceiling on the number of nodes in the BDD.

Re: Compromising OpenWrt Supply Chain

#74

Post by surfaceofthesun »

nunez wrote: post #60
dml2135 wrote: post #50

Earlier quoted context omitted.

What forces you to use it? You can’t bring your own router?

Routers supplied by AT&T here in the US for their fiber gigabit service do RADIUS authentication with the carrier gateway using certs built into the device. There used to be an older version of this router that had known vulnerabilities which made extracting those certs possible but they've since been patched and those certs have been invalidated.

Note that you can still downgrade an existing gateway, extract certs[0], then bypass the device [1]. I had to do this with OPNsense to avoid the latency buildup issue, which has been ongoing for months[2].

---

0 -- https://www.dupuis.xyz/bgw210-700-root-and-certs/

1 -- https://github.com/MonkWho/pfatt

2 -- https://www.reddit.com/r/ATTFiber/comments/1eqfouo/psa_att_n...

Re: Compromising OpenWrt Supply Chain

#75

Post by srmatto »

rrr_oh_man wrote: post #72
srmatto wrote: post #70

OpenWrt is also very difficult to safely upgrade on some devices which I would also consider as a huge downside. I finally gave up and bought an old Dell off eBay and installed OpnSense and am much happier.

https://opnsense.org/wp-content/uploads/2024/07/OPNsense%C2%... That looks so goofy

Sure does, but I don't evaluate firewalls based on the quality of their marketing materials.

Re: Compromising OpenWrt Supply Chain

#76

Post by TiredOfLife »

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

>they did not even tell the users to throw away the "outdated" but perfectly working devices, offering a small discount to buy new

Because they simply brick the device when updating and it's easier, faster, cheaper to buy a new device than to unbrick.

Re: Compromising OpenWrt Supply Chain

#77

Post by ssl-3 »

srmatto wrote: post #70

OpenWrt is also very difficult to safely upgrade on some devices which I would also consider as a huge downside. I finally gave up and bought an old Dell off eBay and installed OpnSense and am much happier.

Some devices are hard to upgrade in large part because they were never intended to be used with things like OpenWRT.

To that end: While it can be nice that OpenWRT runs on a quirky compact all-in-one MIPS-based consumer router-box (or whatever), the software also runs just fine on used Dells from eBay.

Re: Compromising OpenWrt Supply Chain

#78

Post by __david__ »

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…

Wouldn’t “x”.join(…) be enough?

Re: Compromising OpenWrt Supply Chain

#79

Post by blueflow »

__david__ wrote: post #78
BoppreH wrote: post #37

Earlier quoted context omitted.

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…

Wouldn’t “x”.join(…) be enough?

Possibly not:

  "x".join({'aa'+'bxb'}) == "x".join({'aaxb','b'})
The separator should not be able to show up in the inputs.

Re: Compromising OpenWrt Supply Chain

#80

Post by naasking »

nrvn wrote: post #8

Loving this. I wonder how people even come up with an idea of truncating hashes. For what purpose or benefit?

For when you need a smaller payload:

    According to @Reid's answer in [2] and @ThomasPornin's answer in [3], the idea of truncating hashes is fully supported by NIST, in fact SHA-224 is just SHA-256 truncated, SHA-384 is just SHA-512 truncated, etc.
https://security.stackexchange.com/a/97389
Post reply on HN