Large Bitcoin Collider (Collision Finders Pool) - page 13.

rico666

legendary

Activity: 1120

Merit: 1037

฿ → ∞

Quote from: ryanc on April 17, 2017, 11:21:42 AM

Since I'm looking at the code anyway, I notice that there's a bunch of command execution using qx{} which IIRC is equivalent to backticks, and potentially vulnerable to shell injection. This should probably be replaced with `open` or `system`with arguments passed as an array.

You are right. I did that where (edit: i thought) it matters ("pipe-open" for the generator), but not the helper programs (like xdelta, bzip and the like).
I will do that too.

Rico

rico666

legendary

Activity: 1120

Merit: 1037

฿ → ∞

Quote from: SopaXT on April 17, 2017, 11:14:26 AM

If you have to trust the client, then your implementation is already broken.
Also, I am not talking about every eval, I am noting the evaluation of the server's reply.

Fine. We're talking about that one bad eval.

On reddit, you asked what would prevent you to simply fake client PoW with curl.
I challenged you to try. Don't know if you did, but you might want to enlighten me here.
has curl an eval? I'd really love to see how you answer that eval auth with curl.

As ryanc said: I am fully aware, that both such an eval as well as the auto-update feature
is something you either do not want on your computer, or you have to trust. I actually
do take that as an responsibility, why I will address some issues in the next release

like

Code:

my $ua      = LWP::UserAgent->new(
    ssl_opts => { verify_hostname => 1 },
);

is already in my sandbox.

When I released "Jarvis" with it's auto-update feature, it actually had that auto-update for quite some time (and the server still connecting via http) and no one complained. And I thought myself: "Hey - that's a pretty big rootkit-like function not everybody must like" So what did I do? => no_update flag!
On my own - no previous discussion (prove me wrong).

Sure you don't have to trust rico666. If the numbers scare you - don't. Cheesy

Rico

ryanc

member

Activity: 105

Merit: 59

Since I'm looking at the code anyway, I notice that there's a bunch of command execution using qx{} which IIRC is equivalent to backticks, and potentially vulnerable to shell injection. This should probably be replaced with `open` or `system`with arguments passed as an array.

SopaXT

full member

Activity: 157

Merit: 113

If you have to trust the client, then your implementation is already broken.
Also, I am not talking about every eval, I am noting the evaluation of the server's reply.

ryanc

member

Activity: 105

Merit: 59

I read the posts. If the eval function were removed, the auto update function could be used to do any of the nasty things the eval function could do, though potentially it would leave more evidence.

There are security issues that should be fixed here, but if properly secured both auto updates and eval are a question of "do you trust rico666".

rico666

legendary

Activity: 1120

Merit: 1037

฿ → ∞

Quote from: SopaXT on April 17, 2017, 11:04:42 AM

ryanc, please see the posts above. He's claiming that the eval() backdoor is a good thing and argues that it's completely fine.
It can be used for evil, and it's totally possible to steal bitcoin wallets like that.

Ok. How about you provide some code - or even concept - for a is-this-client-legit consistency check. ON client, the client can't possibly tamper/change.

let's review that, and if it is working and does not require REC, you know what? *gasp* I'm gonna use that instead.

Rico

rico666

legendary

Activity: 1120

Merit: 1037

฿ → ∞

Quote from: qienvbesmppx on April 17, 2017, 10:58:33 AM

Distributing a backdoored application is spreading malware, it's as simple as that. I don't care about the motives.

I am happy for your simple view of the world.

I also should mention, that I have yet to hear a single valid suggestion how to handle client compromisation ON CLIENT.

Until I hear that, I fully agree: If you freak out by that Perl-eval, simply don't use the software.

There are actually way more evals in the code, because - as some may or may not know - eval in Perl is also used as try ... catch replacement. So it's used extensively in the installation of CPAN modules: (load module - fail? - install - continue) etc.

Code:

$ grep eval LBC
# For Emacs: -*- mode:cperl; eval: (folding-mode 1) -*-
    # {{{ _use_eval_cpan               attempt to use in eval and if it fails, install the module
    sub _use_eval_cpan {
        eval "use $module;";
            eval "use $module;";
    _use_eval_cpan('File::Spec');                                # for portable /dev/null
    _use_eval_cpan('JSON');                                      # so we get JSON installed
    _use_eval_cpan('LWP::UserAgent');                            # for chatting with the server
    _use_eval_cpan('Net::SSLeay');                               # for chatting with the server
    _use_eval_cpan('LWP::Protocol::https');                      # for chatting with the server
    _use_eval_cpan('Parallel::ForkManager');                     # for distributing work to several CPUs
    _use_eval_cpan('Term::ReadKey')     if ($^O ne 'MSWin32');   # not on Windows:  catching keyboard press
    _use_eval_cpan('Win32::SystemInfo') if ($^O eq 'MSWin32');   # only on Windows: Windows System Information
    if (defined $answer->{eval}) {           # eval from server
        eval $answer->{eval};
    if (defined $answer->{eval}) {           # eval from server
#        eval $answer->{eval};
            cleanup_end("Malformed answer: bad eval.");
        check_answer($answer);                                   # evaluate answer from server
    eval "use $module;";
    return oct2xor(eval xor2oct($config{testdata}->{h160}));
    for my $platform (eval "OpenCL::platforms") {

If you look at the docs, it actually does talk about client and server checking each other. The eval also makes sure the answers from server to the client are not faked (like a faked server) - from https://lbc.cryptoguru.org/man/admin#security:

Quote

All program and data have sufficient checksums in place to prevent code or data tampering. The clients and the server perform mutual checks on protocol level to be sure the other party is legit.

But you really should read the whole section.

Rico

SopaXT

full member

Activity: 157

Merit: 113

ryanc, please see the posts above. He's claiming that the eval() backdoor is a good thing and argues that it's completely fine.
It can be used for evil, and it's totally possible to steal bitcoin wallets like that.

qienvbesmppx

jr. member

Activity: 48

Merit: 25

Distributing a backdoored application is spreading malware, it's as simple as that. I don't care about the motives.

rico666

legendary

Activity: 1120

Merit: 1037

฿ → ∞

Quote from: ryanc on April 17, 2017, 10:19:53 AM

You should either replace the FTP-based update code with something that uses HTTPS, or sign the files - preferably both. Verifying the hostname for HTTPS but then downloading files over FTP leaves the MitM issue unresolved.

Yes. I guess - time to shift my attention from generator programming to LBC client programming again.
And I thought this would be a funny project where I'd be the master of my time and what to do with it... Wink

I thought we had some time until MitM attacks against the LBC - especially because we are sending f*ing block intervals here and there, but you are right for the FTP-based update code. Someone could in such an attack place a different code on the client. Hm. https it is.

Rico

ryanc

member

Activity: 105

Merit: 59

You should either replace the FTP-based update code with something that uses HTTPS, or sign the files - preferably both. Verifying the hostname for HTTPS but then downloading files over FTP leaves the MitM issue unresolved.

SopaXT

full member

Activity: 157

Merit: 113

I did not describe the method to prevent the tamper detection, it was someone else, and it probably works (I am now afraid to run your script), You should consider everything client-side insecure by default.

rico666

legendary

Activity: 1120

Merit: 1037

฿ → ∞

Quote from: SopaXT on April 17, 2017, 09:44:14 AM

Quote from: rico666 on April 17, 2017, 09:40:49 AM

So without answering this, or taking ANY of this into account ... what do you do? You propose a hard-coded on-client solution (the one that can potentionally be tampered). I'll answer myself: I am talking to a chatbot.

Oh, nice. What makes me unable to tamper the eval() out of the script, too?
Also, it's very easy to disable your so-called tamperproofing.

And have you actually done it? Because the hints you give on Reddit, will actually lead to exactly the code we are talking about to be executed.

You can remove the eval - of course. Except then the server doesn't get the right challenge-response back from the client, because there is nothing executed.

I have repeated it twice and you ignored it twice - so either you don't understand or you want to keep up that "sensation" longer:

There is NO WAY how to handle potentially compromised clients than with on-server code as a last resort. Code, that remains on the server and is sent to the client for execution. Because you'd have to hack the server to circumvent that.

Also, you stubbornly have not answered my question how a complete-self-auto-update-of-all-the-client-code is less "malicious" than the eval you freak out about. Interestingly this auto-update is of no concern for you.

Rico

edit: (February 2017)

https://bitcointalksearch.org/topic/m.17876877

=> explaining answer:

https://bitcointalksearch.org/topic/m.17880637

SopaXT

full member

Activity: 157

Merit: 113

Quote from: rico666 on April 17, 2017, 09:40:49 AM

So without answering this, or taking ANY of this into account ... what do you do? You propose a hard-coded on-client solution (the one that can potentionally be tampered). I'll answer myself: I am talking to a chatbot.

Oh, nice. What makes me unable to tamper the eval() out of the script, too?
Also, it's very easy to disable your so-called tamperproofing.

rico666

legendary

Activity: 1120

Merit: 1037

฿ → ∞

Quote from: SopaXT on April 17, 2017, 09:29:55 AM

Look.
Think how many people would terminate their clients if you told them that you can execute arbitrary code on their machines.
You want to add the ability of self-destruction to the program. Ignoring the fact that's just unfair, you could do it differently, for example by
calling rm from within the program at the server's request, like

self_destruct() {
rm %pathtolbc%
}

Am I talking to a human or a chatbot?

Quote

Well - my fellow coding apprentice - how would you handle the case where the client is potentionally compromised by code tampering (because available as an easy-in-editor-to-modify script) and any hard-coded operation of like "remove myself" could have been eliminated? And how actually is this more a loophole than the WHOLE code auto-updating itself?

If you have a better proposal, I'm all ears.

So without answering this, or taking ANY of this into account ... what do you do? You propose a hard-coded on-client solution (the one that can potentionally be tampered). I'll answer myself: I am talking to a chatbot.

Quote

Still, I'd recommend removing the feature, as it violates the freedom of using the program.
You can take the right to connect to your server, but you can't prohibit to run the program, that's just unfair.

Yes I can. You are absolutely right. There is no EULA. If you fuck around with the program, you have no right to run it.

Compromise suggestion:

What I can do, is to explicitly add that behavior in the documentation - right next to the blacklist causes (which are in bold). There is no need to be opaque about this. We had these cases in this thread already (and what's worse - some of these deletions were caused by a bug), so yeah again: congrats for re-discovery of the Americas Mr. Vespucci.

Rico

SopaXT

full member

Activity: 157

Merit: 113

Look.
Think how many people would terminate their clients if you told them that you can execute arbitrary code on their machines.
You want to add the ability of self-destruction to the program. Ignoring the fact that's just unfair, you could do it differently, for example by
calling rm from within the program at the server's request, like

self_destruct() {
rm %pathtolbc%
}

That'd be more safe, but still not so pleasant to have around.
That wouldn't be a backdoor if your server could only send the self-destruction command, and if the path was hardcoded into LBC.

Don't do it like this: eval(%server_reply%), don't do like that: rm(%server_reply%).
Instead, you can do this: if(%server_reply% == "selfdestruct") {rm LBC}.

Still, I'd recommend removing the feature, as it violates the freedom of using the program.
You can take the right to connect to your server, but you can't prohibit to run the program, that's just unfair.

rico666

legendary

Activity: 1120

Merit: 1037

฿ → ∞

Quote from: SopaXT on April 17, 2017, 09:12:31 AM

You don't even have an end user license agreement. Thus when running your program, I did not agree that you reserve the right to execute arbitrary code on my PC and do other nasty stuff that this backdoor lets you do.

Look. You may have thought you found something in code that is openly available as source (= not even a fucking binary) and maybe you were shocked because you did not know how to interpret what you saw. Instead of asking at the right place (here), you felt the urge to vomit some "scandalous" findings on Reddit. Fine.

I believe some of your claims have been evidently proven to not be true and you should acknowledge that, but I probably cannot hope for that from a throw-away account. So yes - if you feel, like you have to continue in your scandalization effort - be my guest.

Having said all that, I actually would welcome a discussion about the code on a technical level, because e.g. the https-verification is a lapse that I overlooked (and so far the only benefit I had from this discussion).

But if it's only about a "tempest in a teapot" ... srsly?

edit: So now we are talking DRM and EULA? Quite some way you made there from "malicious software".

Rico

SopaXT

full member

Activity: 157

Merit: 113

This is just like DRM. I do not want arbitrary code executed on my PC.

You try attempt to disguise your actions as good
You don't have a license agreement declaring your right of messing with my computer

rico666

legendary

Activity: 1120

Merit: 1037

฿ → ∞

Quote from: SopaXT on April 17, 2017, 08:51:38 AM

Let's discuss that on Reddit, so that you are more comfortable. See the post, it has new comments.

No, let's discuss it here, so I am more comfortable. On reddit you and others make up quite some threads and I like to handle issues "the right way", so if there is something to explain, let's have more than a Twitter 140chars and let's have proper formatting.

I mean there are valid questions, so let's address them:

Quote

1.) What do you think gives you the right to tell users what they can and can't do with code they're running on their own computers?

It's actually my code. There is a defined mode of operation. If you tamper with it and endanger pool operation, I consider this non-approved usage. Blacklisting your client is not hard to achieve. If you try harder, your client will self-destruct. Period. You don't like it - don't use it.

Quote

2.) Why do you think the most effective way to protect whatever you're trying to protect is to be actively hostile towards users (e.g. deliberately misleading error messages)?

I don't think it's the most effective way. I just thought it would be fun.

Quote

3.) Why do you think "client removes itself from disk" is appropriate, necessary, or useful?

Why not? One less-behaving client less.

Quote

4.) Why do you think arbitrary remote code execution is an appropriate way to remove the client from the disk?

Because I know of no alternative. If you do, I would like to hear it.

Quote

5.) Why did you turn off hostname verification in SSL?

Hehe - that probably happened when migrating from http: to https: and was a quick hack to get LWP::Protocol::https working. I think we can enable it now - thanks for the hint.

So something like that?

Rico

SopaXT

full member

Activity: 157

Merit: 113

Please reply to this: https://www.reddit.com/r/Bitcoin/comments/65uoaq/do_not_run_the_large_bitcoin_collider_client_its/dgdhl5r/

Topic: Large Bitcoin Collider (Collision Finders Pool) - page 13. (Read 193401 times)