Please explain how source code can be used to confirm the legitimacy of firmware?

[Deleted member 27741]

I think I am missing something. I know how a checksum confirms that you downloaded the file correctly, but how does source code help us confirm the firmware someone might put out?

How would one go about checking if the firmware download matches the posted source code? Couldn't somebody just gain trust with a "legit" firmware that matches the source code and then change it later? Would it take constant checking to make sure the downloads are always legit?

It just does not seem like posting source code would guarantee legit firmware. On the other hand, not posting source code may raise some red flags.

Of course, actually going through the code and finding anything nefarious is another story altogether.

 

[sfx2000]

You can check the hashes on the source files, and perhaps on packages - but the packages will be dependent on the compiler and toolchain in use - there is some trust involved there...

 

[Deleted member 27741]

Warning- epic run on sentence-

So to REALLY confirm the source code I would have to replicate (for example) rmerlin's compilation steps to compile the firmware from the source code, then make a checksum the same way he did and last compare the checksum calculated from a download against the compiled firmware checksum?

 

[sfx2000]

And I trust rmerlin - he posts his source on gitbub, and the compilied binaries - and I have to trust that he knows/trusts the upstream sources...

 

[sfx2000]

So to REALLY confirm the source code I would have to replicate (for example) rmerlin's compilation steps to compile the firmware from the source code, then make a checksum the same way he did and last check the checksum of the download to confirm the checksum of the compiled source code and the download are the same?

Kinda-sorta - you can download his binaries, hash it, and it should match - and you can download his source, and that should match, hash-wise...

From a build-environment perspective - if you precisely match his, including all patch levels in his tool-chain and dependencies, you should be ok...

 

[Deleted member 27741]

I'm not asking so that I can do it, it is beyond my ken. I just want to know if there is any way to truly verify source code. It seems realistically- there is not.

This sort of blows my mind.

 

[Deleted member 27741]

Yes, I trust rmerlin as well. I would not be using his firmware if I didn't. Apparently I had better trust him because there is NO WAY TO VERIFY SOURCE CODE??!!! Sorry for the caps. I am just astonished by this.

 

[mstombs]

You can download the source and build your own firmware, but the resulting binary will not have the same hash, may not even have exact same size because compiled modules contain timestamps and reference to location/user used to compile, then the filesystem is highly compressed. If you are paranoid the bigger concern is that the source-code is not 100%, there are binary blobs supplied by Asus:- hardware specific wireless/Ethernet drivers from Broadcom, and kernel bypassing modules for hardware acceleration of the nat modules. There are also 3rd party modules included by Asus for example the TrendMicro stuff, to be able to provide malware/parental guidance these companies get to know all about your routers web connectivity....

But surely having bulk of code freely available for expert review is much better than other closed source devices, or other manufacturers that appear to abuse the GPL by clearly using open source code without providing complete compilable source code?

 

[Deleted member 27741]

Indeed I do agree source code is better than no source code, and again I do trust rmerlin and john and andrey!

The binary blobs could be a concern and are also nearly impossible to check for issues on their own and probably very difficult to prove they were even used in the firmware?

There is in fact no 100% way to ensure the source code supplied is actually the source used to create the firmware. I would say that this is true, is that correct?

If I WERE paranoid about the firmware on my router (which I am not) I would probably need to review the code line by line and compile it myself. That would pretty much be the only way to truly know my firmware was indeed compiled from the source code. To quote a modern day scholar- "ain't nobody got time for that."

 

[RMerlin]

You can't use the source code to verify a released binary with such a complex project, unless you were to disassemble and study the code itself. The compiled binary will never directly match between two different build environments.

The best you can do is compile it yourself - only then can you be almost sure that the generated binary does not contain any additions. And with this project it makes it trickier because, as pointed out, some closed source bits are involved.

I always get anything closed source either from Asus's own website, or from a link provided by an Asus employee in a private Email. I've never taken anything from a public source or a forum link. So as far as I'm concerned, it goes down to the chain of trust between myself and Asus (and the chain of trust between Asus and Trend Micro, Tuxera and Broadcom, providers of closed source bits of their own).

Personally, I'm quite confident in the generated code, as I trust everyone involved upstream from myself.

 

[Calisro]

It's all about transparency. If the source code if available, you can compile it and run it and you know that there are eyes on the changes. You cannot verify a compiled binary is represented exactly from the source but, again, you can compile it yourself.

There is some trust in using compiled binaries but that is a *personal* decision to use a compiled binary vs compiling it yourself based on your trust level of the source and the binary.

 

[Deleted member 27741]

@RMerlin What would it take to disassemble and study the code? Download the source code and then? I guess john and andrey have done this.

@Calisro Transparency is good. But what I am pointing out is that providing the source code is potentially a false transparency- it will never equal the download checksum so it can never truly be proven that the downloads were compiled from the source code. It would not be difficult to provide source code that is clean and downloads that are not.

I do have to say I have never seen a project as utterly transparent as rmerlin/forks. We and all asus router owners benefit so much from this firmware (I get so much use out of openvpn, for instance). I am going to have to send him some beer money.

 

[Magnesium_CW]

The two don't go together. You either download the source code, dependencies, etc, and compile it yourself because you don't trust the binary firmware package, or you download the binary firmware package and validate with the hashes that no one has modified them. Even reverse engineering the binaries into source code will not assure signature match.

 

[RMerlin]

@RMerlin What would it take to disassemble and study the code?

A lot of advanced skill, and a lot of patience. Very few programmers know ARM ASM. The kind of thing that security audit companies would do for a few thousand dollars I would say...

 

[HallStevenson]

Magnesium nailed it. You either trust the "finished product" as it's provided or you compile it yourself.

Many companies, for example, use Linux as the underlying OS for their hardware. For instance, Dish Network, uses Linux for their receivers. They don't take a distribution from company "x" and add what they need. They take the source from Linus, add their own stuff, add modules from their hardware vendors (or maybe they receive source code for it too), and build from there.

 

[lancethepants]

Reminded me of this.
https://madiba.encs.concordia.ca/~x_decarn/truecrypt-binaries-analysis/

This process definitely would not be practical for a project like Asuswrt. Timestamps ruin everything when it comes to comparing hashes (who knows how many in this project), and looking through a bunch of hex to figure those out would take a ridiculous amount of time. Plus you need a nearly identical setup to the creator.

 

[Deleted member 27741]

Seeing that this is a giant black hole in security for anyone and everyone that uses open source programs, is there any way this could be improved on a global level?

Edit- I guess people are trying. I suppose one could compile on third party servers with specific settings/compilers (that would also be published), but such a process still has reproducibility issues (timestamp?).

This guy thinks like I do, how on earth could this kind of hole not be plugged?
https://air.mozilla.org/why-and-how...n-infrastructure-for-safer-software-releases/

“We often speak as if open source software can't contain backdoors or malware because its source code is 'published', rendering any potentially malicious code visible. But real-world software release processes have major transparency gaps that aren't addressed by most existing open source development practices. The biggest such gap is that compilation and packaging processes aren't reproducible. Trying to recreate these processes typically yields a different result. That means users can't directly verify that the binary releases they download and use were actually created from the purportedly corresponding source trees."

 

[L&LD]

I am one of many that do not understand the source code (released or not). We do need to trust at some point.

All I can do is see if the benefit potential is greater than the known issues and the, if the known issues (discovered daily) are still not outweighing the benefits.

Even using Asus 'official' firmware is no guarantee; there are actual people involved in the coding and what their state of mind is on any given release is up to anyone to guess at.

As such, this still deserves further discussion to make this issue a moot point in the future.

But for me and my customers today, we have to use what we have available and that includes RMerlin's fork of the Asus firmware and also, fork's based off of that firmware like john9527's and hggomes too.

And all three are used where they are most applicable in.

 

[RMerlin]

It all boils down to trust. If you don't trust someone (or the chain that exists between you and that someone), then the *ONLY* way to be sure is to develop and build your own hardware, write your own software, write your own compiler, etc...

Do you trust gcc? Who's to say that the gcc compiler you use to compile code doesn't insert malicious code? So, you should write your own compiler, or at the very least compile your own compiler, using a compiler that you wrote and compiled, using a compiler that ... well, you get the idea - it's a chicken-and-egg situation.

Complete, 100% assurance is *impossible*. You need to put your trust in at least someone, at some point in the chain.

 

[HallStevenson]

Just curious, and this is addressed to the OP, do you run any non-open-source software ?