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

81–90 of 105 posts

Re: Compromising OpenWrt Supply Chain

#81

Post by sweeter »

TacticalCoder wrote: post #36
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.

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 ha…

That's so satisfying! I want to try the same, it would make for a good blog post lol

Re: Compromising OpenWrt Supply Chain

#82

Post by Groxx »

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…

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

Re: Compromising OpenWrt Supply Chain

#83

Post by Groxx »

barbegal wrote: post #15
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?

2^(12*4) is 281,474,976,710,656 possible 12 character strings so seriously impressive that it can look through that many in an hour.

A bit over 4 hours at 18 billion per second, but yea. Impressively fast and also a completely reasonable amount of time for an attempt - the CPU version was 10m per second, which is most of a year to search the whole space.

Re: Compromising OpenWrt Supply Chain

#84

Post by tgtweak »

beAbU wrote: post #23
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

Maybe make it clear you are being sarcastic here. English is not my native language, and my initial interpretation was that "they" in your post referred to the "business grade closed source stuff", and that OpenWRT is really a dangerous bet because they are guilty of all the things you listed.

The sarcasm was abundantly clear in the first bullet point.

Re: Compromising OpenWrt Supply Chain

#85

Post by tristor »

Groxx wrote: post #82
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…

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

Re: Compromising OpenWrt Supply Chain

#86

Post by nightpool »

beAbU wrote: post #23
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

Maybe make it clear you are being sarcastic here. English is not my native language, and my initial interpretation was that "they" in your post referred to the "business grade closed source stuff", and that OpenWRT is really a dangerous bet because they are guilty of all the things you listed.

Did you read the article? OP was very clear that OpenWRT fixed the issue in under 3 hours.

Re: Compromising OpenWrt Supply Chain

#87

Post by whilenot-dev »

chgo1 wrote: post #33

Is there any way to fix the command injection solely in the Makefile?

If Bash is used as the SHELL for make[0], then it might be possible with the ${parameter@Q} parameter expansion[1]?

I would still rather resort to python's shlex.quote[2] on the python side of things tbh.

[0]: https://stackoverflow.com/questions/589276/how-can-i-use-bas...

[1]: https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.... (at the end of the chapter)

[2]: https://docs.python.org/3/library/shlex.html#shlex.quote

Re: Compromising OpenWrt Supply Chain

#89

Post by deathanatos »

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.

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 of two inputs a & b:

  sha256(','.join(
    [sha256(a), sha256(b)]
  ))
If one is familiar with a git tree or commit object, this shouldn't be unfamiliar.

Now … whether that's why there was an inner hash at that point in TFA's code is another question, but I don't think one should dismiss inner hashes altogether.

Re: Compromising OpenWrt Supply Chain

#90

Post by blueflow »

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'm not dismissing them, inner hashes returning a hexadecimal string fulfills the "the separator should not be able to show up in the inputs" constraint.
Post reply on HN