Open debate: The Dangers of using Other People's Builds (OPB), Issues and Warnings - (Avoid "Guru" Firmware! It's better to learn from them and how to use your own buildroot-built firmware by yourself)

Welcome to this topic on Dangers of Using Other People's Builds or "Learn and Use your Own BuildRoot"!

I'm the user who was almost banned for trying to make people aware of the dangers of using other people builds.

No I'm not trying to get attention or hijack the community builds category as one admin put it.

By using a simple tool called buildroot made especially for you, you don't have to rely on these 'firmware gurus' with their UNTRUSTED, UNVERIFIED BUILDS, which pose a serious risk to the security of your network.

Yes, this is exactly the same risk that you accept when you stick to using stock firmware instead of compiling your own from open source linux-based OpenWRT/LEDE.

What point is there to use a wiki tutorial to help you security harden some other guys build that you flashed to your router when you can do it on your own? By doing that you just threw security out the window in the first place then halfway back through the window (lol).

I am using this thread to start a discussion on the dangers of using other people's builds and why I believe this to be a serious issue on this forum.

Blindly using other people's builds has become a common trend among users that has dangerous wide-spread security implications in networks around the globe.

To let the unwary users in on this issue, I will repost my comments that were deleted in the topic Optimized build for the TP-Link C2600 / Netgear R7x00 / Linksys EA8500 in the community builds category in response to the creator of his "optimized build".

I am by no means an owner of this forum or "Guru" 4th party firmware (community-build) developer (aka sheep herder) but have been with OpenWRT since the early days (whiterussian not the "to save face remerger" so don't get cheeky jow). Listen, nothing personal. Take it with a grsin of salt. It's just an opinion.

I am and always will be a seriously devoted to network security issues as well as you all should be. I, by no means consider myself a black or white hat but aren't we all capable of being either.

Can you as a user of community builds based on OpenWRT be sure that what you are downloading and installing on your router is safe to use or free from security holes or "back doors"?
Well mine works and I know nobody logs in but me but do you? Sheeps can't know.

Consider this because your network is at stake.

Let's begin.

We welcome all your input and support to educate people and become more aware of the dangers of using Other Peoples Builds or OPB for short.

My opinion here is only to stimulate discussion and open people's conciousness on the matter.
The point is to promote 'learning your stuff" while helping people to get away from a "sheep-like" or blind firmware flasher mentality.
I can't stress the "sheep" syndrome anymore than jow will let me!

P.S. I will not participate in this discussion as to not let people think that I'm hijacking the topic as the admin said to me in a private message with the intent of warning me to stick to the rules of "being nice" and "stay on topic' or get banned.

Make up your own mind about what this means to you.
Your opinion and contribution is important here whether you're for or against but I believe it's in the best interest of OPENWRT/LEDE in general to discuss this.

Thanks for being here and a big salute to all my OPENWRT/LEDE comrades and fellow new users and veteran users alike.

1 Like

While in general you should not blindly trust external sources, you can also be pragmatic about security. This means yes custom build FW, could be manipulated. The problem is openwrt, the feeds and custom patches never go through any external security audit. So all you can do is "trust" the maintainers with write access, to review all changes/commits and patches. Especially patches can be quite hard to review, usually the write-commiter has very little knowledge of packages he does not maintain and can only check for general "soundness".

The same is true for external build fw by the community, the best they can do is upload there tools/scripts/seeds+hashes to github/lab. So "if" someone wants to check them they can, but that assumes reproduce-able builds fully work, so hashes can be compared.

In the end the normal "openwrt" user has no choice, but to decide, if you never want to trust external builds or grant some sources good faith. That's because not everyone is a linux pro or programmer and can review scripts, code or build pipelines.

There is no solution to this problem unless, building your own FW/packages from official sources becomes super easy, especially for Windows users.

PS: I actually try to partially solve a piece of this problem myself, since i'm working on a absolute "idiot" proof way to let everyone compile custom packages for there device/sdk. The problem is this still entails creating a usb-stick with linux, a persistent overlay-fs and installing docker on it. I think that's workable, but far from "super easy".
I still have hope that docker on windows will some day have a compatible filesystem, so i can skip the usb-stick part.

1 Like

When you compile your own firmware, do you verify that each source file does not contain anything malicious by going over the code of all source files?

Because if you don't, you're being a "sheep-like" as it's pretty much the same as grabbing the pre-compiled image from the OpenWrt server.

And if you do, howcome you've missed the heartbleed bug in openssl?

3 Likes

Of course, and I reverse engineer all BLOBS.:wink:

3 Likes

The wiki page on custom builds is pretty good, but of course there's always room for improvement.

While being security conscious is great, I don't think the "idiot proof" way you mentioned helps much though, since it's not really improving the trust factor -- people would be relying on you that your build environment doesn't do anything nefarious.

A few of the custom builds are fairly transparent and include instructions on how to duplicate the work, so it's not really different than downloading the standard build. Compared to closed-source vendor firmware, we can at least see what's going on and attempt to fix issues.

I think what would help boost security is code auditing and penetration testing. I'm still new to OpenWRT so I don't know how much work has been done on this already, but I'm inclined to trust the upstream projects from where patches are pulled. From what I can tell the OpenWRT project is in a pretty good place with its modern tooling, so I'm optimistic about the future.

We are mixing three things here: trust “Guru’s”, security and learn how to compile from source yourself.

Starting with the last: I think everyone should learn how to do this, but on the other hand I am realistic and a lot of people flash “a stable version” only once. They “set-it and forget-it”, maybe they upgrade “next year”. I think this is a very large group of users who will never take the time to “learn how to build”.

“Security”: the OpenSSL example above is a good one: it’s open source, a lot of people are using it and a lot of people read the code. Still this bug was missed for a long time. The point about it being open source is that eventually someone catches it. Would it be closed source, nobody would have noticed it “ever”.

“Trust Guru’s”: well don’t trust any Guru is probably sound advice. There are a few popular devices with their own community build custom firmware on this forum. They support their builds, make updates when someone finds something broken. They provide “config.seeds” and other pointers how to build yourself. Is it dangerous to trust them?? Everyone should make that assessment for themselves. If you feel like you don’t trust it: learn to build yourself, learn to read “the entire source code”.

We all have “smart” phones/tv/kitchen appliances/whatever. Did we see any of their code?? Do we trust them?? Is it dangerous or 100% secure?? You could step that up to the next level: do you trust the hardware?? Maybe there is a bug in the hardware. It happened to the best of them. Even Intel had long time ago a problem with some floating point part of their processor.

Long story short: if someone feels he/she doesn’t like a project/specific build: don’t use it. Nobody is forcing you!

2 Likes

In all fairness to the OP, the researcher who discovered the KRACK vulnerability looked over the code "a hundreds times" before he realized a sequence added to the 4-way handshake maliciously may pose an risk...and that code was/is used in virtually all non-Windows wireless clients on Earth.

Code review is not easy.

If only someone told all those people on earth not to trust the “Guru” who made the code in the first place :stuck_out_tongue_winking_eye:

2 Likes

And lends to your point and theme of the OP - at least as I espouse and support a healthy and hearty discussion in this thread:

:+1:

This is why I support OpenWrt. Having been involved in the threads, I see and understand the process from: code, bug reports, versioning, etc.

2 Likes

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

That's my boy! Keep up your great work on irradicating the ratz.

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

Somehow I knew you or someone was going to say that.

You should qualify your statements. Some might assume you are accusing OpenWRT of having deliberate security vulnerabilities. Which I am sure is not your intention but you should choose your words more wisely

Compared to closed-source vendor firmware, we can at least see what's going on and attempt to fix issues.

I think what would help boost security is code auditing and penetration testing. I'm still new to OpenWRT so I don't know how much work has been done on this already, but I'm inclined to trust the upstream projects from where patches are pulled. From what I can tell the OpenWRT project is in a pretty good place with its modern tooling, so I'm optimistic about the future.

Totally agree.

While being security conscious is great, I don't think the "idiot proof" way you mentioned helps much though, since it's not really improving the trust factor -- people would be relying on you that your build environment doesn't do anything nefarious.

I got that. Not hard at all to make a 64bit linux on USB. WTF Noobs. Actually it is the easiest way to use buildroot and was part of the advice I gave on the erased post/tutorial on the Guru's 4th party firmware with repo with missing modules and packages page!

The whole community may read/review the source even while it is still a pull request.
In any case trust is always earned whether it is an official OpenWrt release or a community build.

Like everyone else here I trust the Official release. I choose not use the community build since I am happy with the official release and it meets my requirements. If I had had to use a community release I think like the rest of the community I know what the risks and benefits are. No the community is not blind and any rogue community build would get flagged very quickly.

If only someone told all those people on earth not to trust the “Guru” who made the code in the first place :stuck_out_tongue_winking_eye:

Lol! Did I start something here. A discussion.

Mate.... make up your mind

3 Likes

Code review is not easy.

I know. But you are missing the point. I tried anyways.

I'm not saying GNU linux or OpenWRT is totally free from security holes. But it can be hardened locally on your own machine and it is surelu safer to manually compile from generally trusted sources than to blindly flash a binary blob.

I said this was something for you and others to debate on. Do not debate it with me. I do not want to participate since I'm holding my ground.

In other words, it's my humble opinion and you are not changing it. Trusting community builds is a no no and all changes must be documented as per the free software foundation way.

Like the reboot issue with ac2600 or hardware NAT support. Get it into mainline code, don't keep churning out firmware. If you don't at least provide a full repositorio, not like that FW Guru type who keeps you dependent on handicapped firmware versions that falls short of even an ImageBuilder.

At least what he could have done is provide us an Imagebuilder with all modules but he didn't becsuse he's a noob. Plain and simple.

(Select all kernel modules. Duh.)

I'm mean security holes like preinstalled ssh public keys in authorized-keys and ddns enabled to chinese servers are a more obvious threat.

Or a closed-source web gui and binary blobs used for auto-updates, remote spying and who knows what else.

I trust OpenWrt because it's open source.

A communitu git can have anything in it.

I think your just trying to make a point but are you reaching a bit about being a sheep if I blindly use the OFFICIAL build root. It's all we got.

Any serious intentional backdoor would be found soon and when did, would make the OPENWRT project lose credibility real fast so I don't think that would happen. That's why it's open and free to modify, so it can be audited too.

And if you do, how come you've missed the heartbleed bug in openssl?

Patched it as soon as it came out.

Because if you don't, you're being a "sheep-like" as it's pretty much the same as grabbing the pre-compiled image from the OpenWrt server.

I compile my own from buildroot like the wiki says.

I am a sheep. OK you win.

In all fairness to the OP, the researcher who discovered the KRACK vulnerability looked over the code "a hundreds times" before he realized a sequence added to the 4-way handshake maliciously may pose an risk...and that code was/is used in virtually all non-Windows wireless clients on Earth

True. If their code looks ugly, even harder!

Please think harder and then encourage learning buildroot and getting people interested in code review so we have a bigger army of contributors that can help eliminate the RATZ from OpenWRT. That is, if they do exist.

These come across as educated points but with some too obvious noob-like examples like the heartbleed bug. Let me say I didn't find the bug nor did I write the patch for it. I didn't run a web server so I didn't feel affected by it. But I did recompile the OpenSSL with it since I used Freeradius at the time and still do. I don't develop or bugfix OpenSSL. That's their job although it could be mine or yours too.

When I finally perfected my Freeradius server config to my needs, that bug was already patched. But I get your point.

Now they say 802.11x is vulnerable thanks to the wpe patch. It is, as in anything man-made.

Your point is ...?

People still believe in Security through Obscurity?

Anything can be hacked but let's make it harder on them by start being more knowledgable about your own firmware AND code too.

I trust GNU linux more than non-free but I'm fully capable of code review. That's why to avoid that I just keep my build to a minimum and don't activate services I don't need. I read logs and sniff my own network and interfaces. 802.11 is vulnerable at the handshake as far as preventing one to complete as in jamming.

I am aware of it and so are the chinese and Wikipedia.

I don't even use or need LuCI.

Your point is?

I've never seen a firewall backdoor or vague opened port or other dubious rules in the stock firewall from vanilla OpenWRT.

Are you kidding me? I've discovered many binary blobs on dozens of manufacturer and community (3rd party?) firmwares.

Community builds are a shadowy dark part of OpenWRT because they make it too easy for someone's privacy or network security to be compromised. Are you really serious about not admitting that?

Do you like to be laughed at by the whole Infosec / pentesting community?

If you do, then let some firmware "Guru" configure your own linux router. The whole point is to build your OWN FIRMWARE to FIT YOUR NEEDS and yours only.

Noone else can decide those needs for you.

Have a nice day.

First of all I ask you kindly to stop referring to people as „newbs“, „sheeps“ or „gurus“ - this neither adds anything to the discussion, nor is it helping your own credibility.

The takeaway here seems to be that you would like to educate people to not trust binaries and to build their own images from source. This point has now been conveyed multiple times in multiple threads.

I suppose the conclusion is that people shall not trust precompiled firmwares and roll their own, regardless of the person or organization behind the precompiled blob.

This is a valid opinion and a good overall goal to strive for, yet it is not always practical in the real world.

Custom builds by community people are an important part in the OpenWrt ecosystem as they help to get wider test coverage, to bring features to the people early, to identify requirements, common problems and optimization potential.

Implying that their creators are unskilled gurus is derogatory and arrogant, especially considering (the lack of) your track record in this forum so far.

6 Likes