On LBC SecurityWhen we speak about "novel and unorthodox" approaches, the LBC security concept is certainly in that category. From the newest FAQ entry:
https://lbc.cryptoguru.org/about#i-heard-the-server-can-remote-execute-code-on-my-client-wtf-I heard the Server can Remote-Execute Code on my Client? WTF?
Yes, the server can do that and the server uses that only for client consistency checks and dealing with client inconsistencies. Despite security-experts turning blue in their face, this is actually a security feature: namely security of the server and validity of the data sent to the server. In order to ensure this data consistency in this specific use case, the server has to have the power to execute turing-complete checks on clients to trust them. As proof of validity, the client submits itself to the server. Let us rephrase it in simple terms: If you want to board a plane, for the planes' - and thus also your security, you have to undergo certain scanning procedures and comply to restrict some of your freedom or you will not board that plane. Same story.
Please also see the big warning on the download page:
https://lbc.cryptoguru.org/download to account for this.
Now, while the FAQ in our opinion pretty much explains our point of view, there is more explanation to be done. In some recent shitstorm the LBC client has been titled "Rootkit" and "Security Nightmare" and probably many similar names. Some addressed issues have their justification like possible man-in-the-middle attacks on FTP updates, shell injection (meanwhile very very hypothetical) and are being worked on for the next release - see LBC News above.
The infamous remote code execution is not something we consider a security flaw, but a security necessity. As stated in the FAQ entry above, for us the security of the server operation is paramount. We do not want malicious clients to pollute the "work-done" database on server with fake submissions of searched keyspace. Now there is something called proof-of-work from the client when a certain key interval has been searched, but this proof-of-work is ensured only programmatically, not by some PoW mathematical concept as e.g. in mining.
This means, that a malicious client setup could basically tell the server to have done work without actually having done it. This would be quite devastating for the pool operation: Not only would this put this client in a favorable position to have allegedly delivered "valid Gkeys", when in fact the client hasn't searched it and in any disbursement give this client a stronger payout position, it would also mean that certain key intervals actually
were not searched at all and thus might have contained keys that were overlooked.
Now there is no way, where we could create a 100% airtight PoW for the work done, because that would mean end of search distribution. We could perform the search only on a local server with software we knew was doing what it actually was supposed to do. This is a theoretical issue! We cannot validate the clients, so we must
trust the clients.
TrustThe server trusts a client, because it has control over it to the extent, where you could say the client code is an extension of the server code. The "proof of validity" by client submission. The server has a very itchy trigger finger to put a misbehaving client onto a blacklist and barring it in further pool participation as soon as fishy things start going on - especially client code tampering. Imagine the various attack vectors to get invalid Gkeys to the server:
- Modifying the clients benchmark loop to claim a higher speed (zero impact)
- Modifying client code to accept another generator binary, changing this binary against something "that returns back from work quickly" -> profit (high impact)
- Modifying some Perl CPAN modules (basis for the LBC client) so you actually do not change the LBC client, but the underlying libs. (high impact)
- etc. you get the idea.
All these attack vectors are pretty well known and daily bread and butter in security audits. In order to fight these
without a mathematical (unfakeable) PoW your only chance is to execute
massive validation of the code in question. Having the code locally on your server in your restricted access area is one type of this massive control. Having a Turing-complete way of checking the code is another.
At the moment we cannot think of a way, where even a malicious attacker with a superior skill set could play charade with these checks undetected, at least not indefinitely. Maybe someone feels the urge to try/challenge this concept and prove us wrong. Maybe someone finds a very elegant mathematical way without the concept of client submission. We tried and so did others (you may want to read yourself through the
Byzantine Generals' Problem - especially the part about the traitorous generals.), but you may have a better idea.
So it's either us trusting the clients or the clients trusting us. For the time being, the clients are the passengers on a plane.
"Remote-Code-Execution"This sounds still pretty bad, so it may be necessary to show the difference between REC on - say - a rootkit and what actually happens with a LBC client.
You must know, that the LBC client is
not in some daemon mode (UNIX nomenclature), i.e. constantly listening on some port and waiting for orders.
It is only when there is
client-initiated communication with the server (get/put protocol), when the server can put executable code in its
answer to the client.
If your LBC client is sitting on your hard drive, there is no way, the server could contact it. Also, there is no way any potentially malicious attacker could make use of this feature, because the original unaltered LBC client will only talk to a LBC server and not accept answers from anyone else. In order to hack you, someone would have to take over the
https://lbc.cryptoguru.org SSL connection and mimic the LBC server.
This may make the LBC server seem a valuable target of attack and - again - someone may feel the urge to try. As of now, we can state that the cryptoguru DNS as well as the physical machines beyond the servers do have an enterprise-grade security in place. Hijacking this mission critical part of the infrastructure for malicious attacks on LBC clients seems a little far fetched for now.
History of the CodeThe remote code execution was not always part of the LBC client, it came into the codebase shortly after October, 20th 2016, when some users performed (announced) pentesting and tried fake block submissions. While not successful at that time, it became evident that it's only a matter of effort (thus time) to overcome any mechanism the client might have in place to prevent tampering. More details on that history
see here (german forum).
Summary:As far as we possibly can make an sincere assertion, there is no nor was ever malicious harm intended or is to be expected from the LBC server towards the unaltered client. The harshest reaction from the LBC server to a modified client is a deletion of the LBC client files (and only these) from the hard disk. (Yes - it's only meant as a nuisance, an attacker may try again from a different IP, with a different Id. We do believe however, that our server has the greater staying power here)
Formally every security advisory is right: You do not want to have this software on a machine with sensitive data (wallets, private photos, passwords, etc.) We agree and suggest you should run LBC either on a VM, or on a dedicated (= bare) machine. If this is infeasible and you still would want to run the LBC client, you have our word, but more important other technical options to make sure a LBC client does not compromise your system:
- Don't run the client as root user!
- Have it run with a user/group created just for LBC with minimum permissions for operations (read/write own files) or ACLs
- Use available monitoring tools like e.g. https://en.wikipedia.org/wiki/Open_Source_Tripwire to make sure LBC keeps it's promise and does not "look around"
- Put LBC in a chroot jail or in a lightweight container (not tested with GPU)
Be the collision with you.
- if you delivered 3000 valid Gkeys (or more) via CPU, we know you're committed. You deserve GPU authorization.