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

51–60 of 105 posts

Re: Compromising OpenWrt Supply Chain

#51

Post by jojobas »

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…

Using a build service like that is apriori saying "i'm not valuable enough for a targeted attack".

Re: Compromising OpenWrt Supply Chain

#52

Post by jazz9k »

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.

Re: Compromising OpenWrt Supply Chain

#53

Post by ddtaylor »

blueflow wrote: post #49
vsl wrote: post #48

Earlier quoted context omitted.

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

For anyone curious PHP ultimately uses this definition in their introduction portion of the hash extension:

> This extension provides functions that can be used for direct or incremental processing of arbitrary length messages using a variety of hashing algorithms, including the generation of HMAC values and key derivations including HKDF and PBKDF2.

Re: Compromising OpenWrt Supply Chain

#54

Post by lsaferite »

bigiain wrote: post #13
daghamm wrote: post #11

First of all, nice writeup. I am a bit surprised that so much GPU power was needed to find such short collision but it was nice to see his implementation nevertheless. Regarding the last section, is 40k a reasonable price for one month of security analysis? Does this mean that a good security researcher make about 500k/yr?

It means a good security research company might make $500k for a good researcher, if they could bring in enough work to keep them 100% utilised. Less actually, given paid time off.

Which, if past experience still hold, translates to something more like ~$165/yr + benefits.

Re: Compromising OpenWrt Supply Chain

#55

Post by [deleted] »

ddtaylor wrote: post #53
blueflow wrote: post #49

Earlier quoted context omitted.

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

For anyone curious PHP ultimately uses this definition in their introduction portion of the hash extension: > This extension provides functions that can be used for direct or incremental processing of arbitrary length messages using a variety of hashing algorithms, including the generation of HMAC values and key derivations including HKDF and PBKDF2.

[deleted]

Re: Compromising OpenWrt Supply Chain

#56

Post by mnau »

holoduke wrote: post #6
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

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.

Re: Compromising OpenWrt Supply Chain

#57

Post by orra »

cesarb wrote: post #45
orra wrote: post #25

Earlier quoted context omitted.

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 ).

Thanks for the correction and sorry for the mistake. I skimmed the changes but apparently not very well.

Re: Compromising OpenWrt Supply Chain

#58

Post by Thorrez »

blueflow wrote: post #49
vsl wrote: post #48

Earlier quoted context omitted.

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

That page includes an example that shows PHP's incremental hashing is what you describe as "dysfunctional". It hashes "The quick brown fox jumped over the lazy dog." in 1 part, and in 2 parts, and shows that the resulting hashes are equal.

Re: Compromising OpenWrt Supply Chain

#59

Post by blueflow »

Thorrez wrote: post #58
blueflow wrote: post #49

Earlier quoted context omitted.

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

That page includes an example that shows PHP's incremental hashing is what you describe as "dysfunctional". It hashes "The quick brown fox jumped over the lazy dog." in 1 part, and in 2 parts, and shows that the resulting hashes are equal.

I did a mistake.

Re: Compromising OpenWrt Supply Chain

#60

Post by nunez »

dml2135 wrote: post #50
sweeter wrote: post #30

Earlier quoted context omitted.

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?

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.
Post reply on HN