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

101–105 of 105 posts

Re: Compromising OpenWrt Supply Chain

#101

Post by internet_points »

hoseja wrote: post #28
internet_points wrote: post #27

Earlier quoted context omitted.

Could it be like a lock pick process where you start from the left and see if you get further or can throw away that guess, so by having the "choices" be at the beginning you don't have to make them again and again? (and for whatever reason doesn't/can't cache the prefix)? Or could it be like when counting 100000000000 010000000000 110000000000 001000000000 most of the variation is at the left and you only rarely see…

Hashing is specifically done to prevent just this. (Just reacting to the comment here, haven't grokked the specifics.)

That just makes it even more confusing that it uses longer to vary the right than the left – is the specific hash algorithm used not "balanced" (or whatever the term of art is) the way it ideally/theoretically should be?

Re: Compromising OpenWrt Supply Chain

#102

Post by pjc50 »

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…

This is defeatist: compilers do not usually use the system RNG to make decisions, so what's happening is entirely accidental introduction of difference which propagates.

There is "intentional input" (contents of the source files), and "accidental input" (source file full paths, timestamps, layout of memory given to you by the OS, and so on). A reproducible build system should give the same output for the same "intentional input".

(the only place where you do see RNG driven optimization is things like FPGA routing, which is a mess of closed toolchains anyway. It has no place in regular software compilers.)

Re: Compromising OpenWrt Supply Chain

#103

Post by aparcar »

Hi, I'm the one who created this services within a "Google Summer of Code" some 7 years ago and been maintaining it since. It's my first "larger" project and while it started as a short Python project, I eventually became a OpenWrt project member since the build system itself required so many changes.

I'd be very happy for further audits and reviews of the code, after multiple years of low interested, it now produces and caches about 1000 individual firmwares a day. I think it's only a question of time until other issues come up...

Re: Compromising OpenWrt Supply Chain

#104

Post by namibj »

Terr_ wrote: post #93
tristor wrote: post #85

Earlier quoted context omitted.

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.

Then use git in sha2 mode. You just have to turn that on.

Re: Compromising OpenWrt Supply Chain

#105

Post by philjglass »

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…

For Google Play: https://developer.android.com/guide/app-bundle/code-transpar...

As far as I know there's no centralised log, it's left up to app developers to publish their key/a log of transparency files.

Post reply on HN