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

91–100 of 105 posts

Re: Compromising OpenWrt Supply Chain

#91

Post by screcth »

tristor wrote: post #67
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…

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…

Why does an optimizing compiler introduce nondeterminism?

In my mind an optimizing compiler is a pure function that takes source code and produces an object file.

Re: Compromising OpenWrt Supply Chain

#92

Post by __david__ »

blueflow wrote: post #79
__david__ wrote: post #78

Earlier quoted context omitted.

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.

Thanks—that makes sense. I was struggling to come up with an example that would fail but I was just unconsciously assuming the separator wasn’t showing up naturally in the individual parts instead of explicitly considering that as a prerequisite.

Re: Compromising OpenWrt Supply Chain

#93

Post by Terr_ »

tristor wrote: post #85
Groxx wrote: post #82

Earlier quoted context omitted.

"Reproducible" isn't necessary for "not modified from what everyone else gets", and that still makes some attacks FAR harder (and easier to identify, as you know what the "normal" one is). And a published Merkle tree just makes it easier to verify "none of this has changed", as opposed to SHAs on a website that could change any time.

For sure, which is one of the big benefits of git + git tagging, but the issue is even if you know you received the same binary as someone else, without reproducible and auditable builds, you have no idea if that binary originated from the same code in the case of a targeted attack.

> For sure, which is one of the big benefits of git + git tagging

That's not enough for serious security though, because git is (still) using SHA1 instead of SHA256. You would need something extra, like a signed commit.

There's also the much simpler pitfall of an attacker just creating a branch named the same as a commit, in the hopes that people will accidentally check it out instead.

Re: Compromising OpenWrt Supply Chain

#94

Post by Terr_ »

__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?

Only if you can guarantee it that possible for someone to sneak in an input that already contains those "x" characters.

Re: Compromising OpenWrt Supply Chain

#95

Post by 1vuio0pswjnm7 »

The title uses the term "supply chain" but it appears nowhere in the blog post. I keep seeing this term used by "cybersecurity" researchers and software developers in ways that seem to differ from the definition I learned in school. .

From Wikipedia:

"A supply chain is a complex logistics system that consists of facilities that convert raw materials into finished products and distribute them^[1] to end consumers^[2] or end customers.^[3]"

    1. ^ Ganeshan, R. and Harrison, T. P., An Introduction to Supply Chain Management, updated 22 May 2005, accessed 29 June 2023

    2. ^ ^a ^b Ghiani, Gianpaolo; Laporte, Gilbert; Musmanno, Roberto (2004). Introduction to Logistics Systems Planning and Control. John Wiley & Sons. pp. 3-4.  ISBN 9780470849170. Retrieved 8 January 2023.

    3. ^ ^a ^b ^c Harrison, A. and Godsell, J. (2003), Responsive Supply Chains: An Exploratory Study of Performance Management, Cranfield School of Management, accessed 12 May 2021
Was https://sysupgrade.openwrt.org set up for commercial suppliers of OpenWRT. How about https://firmware-selector.openwrt.org

I always assumed commercial suppliers compiled from source to add their own modifications, and then created their own images.

As a consumer of OpenWRT, I compile from source or use "official" images.

Re: Compromising OpenWrt Supply Chain

#96

Post by chromanoid »

1vuio0pswjnm7 wrote: post #95

The title uses the term "supply chain" but it appears nowhere in the blog post. I keep seeing this term used by "cybersecurity" researchers and software developers in ways that seem to differ from the definition I learned in school. . From Wikipedia: "A supply chain is a complex logistics system that consists of facilities that convert raw materials into finished products and distribute them^[1] to end consumers^[2]…

The device updates can be supplied by a supplying service. The device (and its user as the end consumer) is not attacked directly but through its update supply chain. This is why it's called supply chain attack.

When somebody intercepts your Christmas presents to add a bomb to your new pager, it is also a supply chain attack. Even if you use the pager for work and the bomb targets your business partner. If somebody throws the bomb directly at the target it is not a supply chain attack.

Supply chains are often less secured than direct attack vectors.

Re: Compromising OpenWrt Supply Chain

#97

Post by stevefan1999 »

screcth wrote: post #91
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…

Why does an optimizing compiler introduce nondeterminism? In my mind an optimizing compiler is a pure function that takes source code and produces an object file.

Well, lot of things can influence here. Multithreaded build, PGO, or even the different access order of the hash table inside the code optimizer can be a factor. Things are getting probalistic and thus somewhat nondeterministic: the build itself is nondeterministic but the runtime/final execution is deterministic

Re: Compromising OpenWrt Supply Chain

#98

Post by paledot »

mnau wrote: post #56
holoduke wrote: post #6

Earlier quoted context omitted.

Home assistant and vlc anyone?

Ha was very user unfriendly when I last tried it ~3 years ago. Yaml was necessary and it required a lot of fiddling to make z-wave work. Each blind was detected as ~5 things (2 useless or no idea what for)... Checking what was position, what power, ect was rather annoying. I made work and something broke about a year later. I just replaced it with off the shelf stuff.

HASS configuration has gotten a lot better in the past few years. Almost everything can now be done via the UI, including automation and scripting, and it's one of the smoothest scripting GUIs I've used. It even supports cut/paste for visual blocks. And for those 5% cases, there's an inline YAML editor which will open (and validate) only the pertinent block of what I'm sure is a 1000-line YAML file for editing in-browser.

Z-Wave is still dodgy, but the migration to zwavejs has been an improvement and probably is as good as things will get with the state of Z-Wave being what it is.

It's still not perfect, but HASS has become one of my user-facing open-source success stories. Most of the remaining annoyances are out of their control at this point.

Re: Compromising OpenWrt Supply Chain

#99

Post by bmicraft »

deathanatos wrote: post #89
blueflow wrote: post #79

Earlier quoted context omitted.

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

This is why I raised an eyebrow when TFA wrote, > When I saw this, I wondered why it has several inner hashes instead of using the raw string. The inner hash constrains the alphabet on that portion of the input to the outer hash, thus easily letting you use a separator like "," or "|" without having to deal with the alphabet of the inner input, since it gets run through a hash. That is, for a very simplistic use case…

I could see an attack vector here based on file/directory names or the full path. Different inputs could lead to the same order of enumerated checksums.

Re: Compromising OpenWrt Supply Chain

#100

Post by bmicraft »

jazz9k wrote: post #52
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

This only works for a handful of open source projects with corporate backing and the resources to fix these issues quickly. For most OSS projects, the maintainers are either too overworked or just don't feel like fixing security issues.

> For most OSS projects, the maintainers are either too overworked or just don't feel like fixing security issues.

Surely you can't be serious about "most" (= a clear majority) oss projects not fixing vulnerabilities in a reasonable time frame?

Post reply on HN