
Bitcoin 0.13.0 Binary Safety Warning - pigeons
https://bitcoin.org/en/alert/2016-08-17-binary-safety
======
jimrandomh
The key fingerprint mentioned is 01EA5486DE18A882D4C2684590C8019E36C2E964.
(Mirroring into comments to make life difficult for anyone who wants to modify
bitcoin.org's web page).

~~~
web007
Have you done the rest of the verification necessary to say this is
legitimate?

* Wayback to some months ago for the download page [1]

* Confirm that the content presented matches the existing download content for the 0.12.1 release (or prior)

* Confirm that the content for the "0.11+ key" is the same [2]

* Confirm that the signed release for the 0.12.1 content is correct and valid

* Request that (full-length) key from a public GPG server

If you've done all of those things, it might be a good idea for you to sign
that key and push it back up to a public GPG server - that help with web-of-
trust, and somewhat legitimizes the key versus some arbitrary untrusted
impostor. (I have done all of these steps, and signed with my key
9BB5251DE08569D4DEEA894C85D221C11DD01DF6)

[1]
[http://web.archive.org/web/20160109193420/https://bitcoin.or...](http://web.archive.org/web/20160109193420/https://bitcoin.org/en/download)
[2]
[http://web.archive.org/web/20160109193420/https://bitcoin.or...](http://web.archive.org/web/20160109193420/https://bitcoin.org/laanwj-
releases.asc)

~~~
0x0
Bad idea to sign the key just by looking at possibly newly downloaded old
releases. Shouldn't keys only be signed after meeting in person?

~~~
web007
Ideally yes, but not necessarily.

I can certify that this key is the same one that was used for the 0.12.1
release, and its content has been published on more than just the bitcoin.org
website and more than just $TODAY.

I can see the same content on Reddit's /r/bitcoin wiki page or on Bitcoin
Talk, with an identical signature. I would have to believe that either Bitcoin
is already compromised, or that bitcoin.org, bitcointalk.org, reddit.com AND
archive.org have all been hacked or coerced into changing content with
accurate history intact.

~~~
0x0
I don't know, it feels like it poisons the web of trust. There's definitively
something odd going on, and IF this was a coordinated attack, would it be too
much to think the adversary has managed to post with some sock puppet accounts
on a couple of forums - or even hack them? Or even hack your browser - a
single compromised extension like an ad blocker could search&replace the key
id in any web page rendered to you. I think that if you decide to sign keys
just from an hour's worth of browsing around you are damaging the reputation
of your own key to be honest.

~~~
web007
I'll accept the "damage" to my own key - Realize what you're claiming:

Someone compromised the Bitcoin site > 4 months ago without it being
discovered.

Someone continues to compromise the site today even after this public
attention, since the same message is still there.

That same entity compromised my browser, curl, my Linux laptop, Windows
desktop, Android phone and 3 different networks.

That same entity compromised Archive.org and Reddit 4+ months ago without
being discovered.

That same entity created sockpuppet accounts to publicize the fact that this
info was compromised and nobody discovered the discrepancy.

I don't believe that even the pre-Snowden NSA had all of those powers. If they
did, fake signatures are probably the least of our problems.

It's no longer the original model of Person === Key that requires passport
checks and face-to-face meetings. I would consider this better validation, in
that it certifies real-world and historical usage.

Here's my alternate proposal: How difficult is it for the same attacker to
create a fake passport and show up to a bitcoin meetup claiming to be this
person?

~~~
0x0
I'm just saying that if you go out and verify all those things today (even
looking at archive.org etc), then as long as you're using just one (type of)
browser configuration, compromising a single extension could be enough to
"blur your vision" when you decide to sign that key. A couple of regexes
replacing a few variants of the real fingerprint with the fake fingerprint in
all HTML documents - then every forum post you look at echoing the key might
be a lie. Those scenarios are "OR", not "AND"... :)

Or, you know, for paranoia level 1000, _your_ posts are the sockpuppet ;)

I'll agree this is all super unlikely and I'm not accusing you or anyone here
of shenanigans. I'm just saying that signing keys shouldn't be taken lightly,
because if people start getting sloppy then a lot of the trust in the web of
trust is no longer water tight.

~~~
web007
I don't run that kind of extension [0], but that's the reason I included this
line: > That same entity compromised my browser, curl, my Linux laptop,
Windows desktop, Android phone and 3 different networks. At least 3 platforms,
potentially different 3 browsers, plus command-line.

If I want to do this "properly" it's a lot of work. I'd get 3 or more
independent VPN providers and run the test while connected to each,
independently or in series. I'd run everything in a VM that I created from a
verified source 5+ years ago on hardware from 10+ years ago[1]. I would have
to categorize and confirm that every vulnerability in all software was either
fixable via configuration, or couldn't contribute to remote compromise of the
box. I'd run the test with and without Tor, hard-resetting the VM to its
initial state for every variation and comparing the results across every run
to detect abnormalities. I'd confirm the content at Archive, CommonCrawl,
Yahoo, Google and at least one foreign provider, Yandex or Baidu or whoever
else I could track down. I'd look for that same string in all places I could
find it (web, newsgroups, torrents, friends, friends-of-friends), and confirm
that neither those pages nor any linked pages contain invalidations, or if any
of them contain further evidence to support the identity of said key. By
"linked" I mean both links from those pages, and anything I could discover via
search engine pointing to those pages independently. I'd go find some old
torrents or archives of older versions of the binaries and/or signatures, and
confirm that their content matches the published content. I'd confirm that the
old key was in use before 0.11, and that the new key is indeed the one that
signed release 0.11+. I'm sure there are some further steps I could take to
invalidate any known or theorized attacks from state-level agencies, but at
this point it's probably more difficult to fake than a GPG signature.

And obviously I'm a sockpuppet - nobody should listen to random strangers on
the internet without verifying their identity as well! You could look at my
keybase profile, but A) that's easy to fake and B) that's not the key I used
to sign above - clearly something hinkey is going on. ;)

[0]
[https://chrome.google.com/webstore/detail/ext/apmlngnhgbnjpa...](https://chrome.google.com/webstore/detail/ext/apmlngnhgbnjpajelfkmabhkfapgnoai?hl=en)
[1] [https://libreboot.org/faq/#intel](https://libreboot.org/faq/#intel)

------
vog
This is why I love the approach taken by Debian (and most other distros).

Although they provide binary packages, they insist on building everything from
source, independently from the upstream projects such as Bitcoin. Moreover,
the build process itself must be able to run entirely with Free Software. And
the same must hold for all dependencies. Otherwise a package can't make into
their "main" distribution (just into "contrib" or "non-free", but users of
these parts are warned).

That way, an attacker can't simply tamper with binaries. They have to
distribute the manipulates sources instead. Although that kind of attack may
still be feasible, it requires a lot more openness from the attacker than just
changing sources privately and distributing merely faulty binaries.

This will be futher hardened by Debian's initiative to provide reproducible
builds, so that if one of their many build servers is compromised, this can be
detected by simply comparing hashes of the resulting binary packages produced
by other build servers and/or local build of the maintainers or any curious
user:

[https://wiki.debian.org/ReproducibleBuilds](https://wiki.debian.org/ReproducibleBuilds)

Speaking of Debian, unfortunately Bitcoin never made it beyond Debian/Unstable
(Sid), because the Bitcoin release process appears to be incompatible with the
Debian release process, especially regarding backporting security fixes, so
the Debian people decided to be better safe than sorry:

[https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=718272](https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=718272)

~~~
homero
Isn't it harder to hash every single file in source? There's thousands

~~~
vog
Debian simply hashes the source tarballs, then signs these hashes and some
metadata, just like everybody else does.

For example:

[http://http.debian.net/debian/pool/main/b/bitcoin/bitcoin_0....](http://http.debian.net/debian/pool/main/b/bitcoin/bitcoin_0.11.2-1.dsc)

    
    
        -----BEGIN PGP SIGNED MESSAGE-----
        Hash: SHA1
        
        Format: 3.0 (quilt)
        Source: bitcoin
        [...]
        Checksums-Sha256:
         aab2cd0c4f045970d259cf9fcee5785b43180d20ccbbedc1f90480e697696b25 5955398 bitcoin_0.11.2.orig.tar.gz
         e294975cd99a90c0750255303b51a9d3058a4e2e16087c6450908d7d64581772 33880 bitcoin_0.11.2-1.debian.tar.xz
        
        -----BEGIN PGP SIGNATURE-----
        [...]
        -----END PGP SIGNATURE-----
    

Here, _bitcoin_0.11.2.orig.tar.gz_ is the original source tarball as
downloaded from the Bitcoin project, and _bitcoin_0.11.2-1.debian.tar.xz_ is
the tarball that contains all Debian specific adjustments.

------
jvehent
bitcoin.org does not implement HPKP. Any government that controls a CA can
generate its own cert for bitcoin.org, hijack the site's IP and replace this
page with their own fingerprint.

~~~
jlgaddis
And China has a root CA under their control. I'm on my iPad at the moment so I
can't provide the fingerprints of it right now, but I remember "un-trusting
it" on all of my machines a long while back.

~~~
mynewtb
And the US, host of malicious entities like the CIA and NSA, has several root
CA's under their control.

~~~
jlgaddis
Yes, of course. There's something like, what, around 400 root CAs, I think?

I mentioned the .cn government (and their root CA(s)) because the article
mentioned the .cn government, specifically, and the parent comment mentioned
"any government that controls a CA".

Obviously, any government with a) control over a root CA and b) control over
their entire country's Internet access could carry this out. The article we're
commenting, however, called out .cn by name.

------
jjnoakes
If they can't protect the binaries on their web site, how can they protect the
keys and fingerprints they are publishing?

~~~
chrisfosterelli
The website is vulnerable in a much larger number of ways, since it involves
significantly more infrastructure which is all vulnerable to state actors. A
state could generate fake certificates, physically access hosting servers, or
access the internet connections the website uses.

There is a much smaller attack surface for keys.

If you are talking about protecting the key fingerprint they posted on the
website, the idea is by publishing them now that others can note the
fingerprint and warning before any malicious actor would have a chance to
respond.

This is also the same key they've used in the past I believe, so it can always
be compared to prior releases.

~~~
chatmasta
Is this a good case for distributing downloads via torrent? Or do you then
face the same problem when linking to the torrent file?

~~~
chrisfosterelli
Downloading by torrent hash link is nice because it cannot be altered after
release, while this isn't true with a link to a binary file on a website.

However, you still have to verify the authenticity of the binary with keys if
you don't trust the location you got the torrent hash from (ie, the bitcoin
website). So yes, essentially the same problem I believe!

------
pigeons
I feel irresponsible for submitting this since I'm told no one but the poster
knows anything about this and this did not go through the normal checkin
process for bitcoin.org.

Waiting, we'll see...

~~~
Taek
Vigilance around binaries is a good thing anyway.

I hope though that this does not damage relations with the Chinese community,
as singling them out without good cause is unjust.

~~~
MichaelGG
>without good cause

China has been well known to MITM traffic. No one should be offended by
pointing this out.

~~~
Buge
Yeah, and injecting Javascript malware. I haven't heard of them MITMing HTTPS
though.

~~~
puetzk
[http://ncjolt.org/googles-distrust-of-chinese-digital-
certif...](http://ncjolt.org/googles-distrust-of-chinese-digital-
certificates/)

CNNIC was the root of trust for a breach involving false certificates for
gmail. They claim it was an accident. It might have been. It might not have
been.

------
jarzonpeck
Right or wrong; a dose of paranoia or clarity about the [ulterior] motives of
the core safety warning in /r/btc Reddit.

[https://www.reddit.com/r/btc/comments/4y8sk7/0130_binary_saf...](https://www.reddit.com/r/btc/comments/4y8sk7/0130_binary_safety_warning_bitcoinorg/)

~~~
kanzure
"Core safety warning"? Note that bitcoin.org is not Bitcoin Core (which has a
separate site, bitcoincore.org). See [https://bitcoin.org/en/about-
us](https://bitcoin.org/en/about-us)

------
kondbg
As someone who does not follow Bitcoin news, what makes this release special
enough to warrant an advance warning?

~~~
nfd
It may not be a matter of the release being particularly special; rather, they
might've been tipped off to some insider information or otherwise be aware of
some information they felt it'd be best not to describe in detail right now.

~~~
kanzure
Unfortunately, none of the Bitcoin developers are currently aware of any
"insider info" at all. This was force-pushed by a single individual who has
not been communicating with anyone about this alert.

------
ipsin
Is the concern here specifically related to the NSA Shadow Brokers hack (where
they're supposedly auctioning the goods for bitcoin), or just more generally
that a state adversaries will try to fully identify parties on the network?

------
kanzure
So far, none of the others I have pinged about this has any info as to its
veracity or background. Unlike most contributions to bitcoin.org, this one was
pushed to the master branch without a corresponding pull request (a mechanism
used to solicit review and feedback from others). [https://github.com/bitcoin-
dot-org/bitcoin.org/commit/5e0fd5...](https://github.com/bitcoin-dot-
org/bitcoin.org/commit/5e0fd5292c936324660c680e4e99506da659c9fb)

I suggest skepticism. We should be cautious of anyone skipping peer review
processes, even for security incidents. Poor handling of these situations can
lead to unintentional panic where panic of any kind is unhelpful to resolving
issues. However, everyone should always be encouraged to check the signatures
regardless of alerts, of course. Multiple signatures should always be checked,
and not just Wladimir's signature. Use the gitian signatures repository to get
other signatures, and always verify public key and signature data through
multiple independent channels.

gitian signatures repository: [https://github.com/bitcoin-
core/gitian.sigs](https://github.com/bitcoin-core/gitian.sigs)

GPG build verification steps:
[https://github.com/bitcoin/bitcoin/blob/master/doc/release-p...](https://github.com/bitcoin/bitcoin/blob/master/doc/release-
process.md#verify-other-gitian-builders-signatures-to-your-own-optional)

gitian build steps:
[https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-
bu...](https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md)

gnupg CVE-2016-6316 from today [https://lists.gnupg.org/pipermail/gnupg-
announce/2016q3/0003...](https://lists.gnupg.org/pipermail/gnupg-
announce/2016q3/000395.html)

Also, don't use gpg short ids. Always verify fingerprints. There are gpg short
id matching keys floating around for some Bitcoin developers - for example,
[http://pgp.surfnet.nl:11371/pks/lookup?op=vindex&fingerprint...](http://pgp.surfnet.nl:11371/pks/lookup?op=vindex&fingerprint=on&search=0x2346C9A6)
check out the revoked key.

( This reply is x-posted from
[https://www.reddit.com/r/Bitcoin/comments/4y8m76/0130_binary...](https://www.reddit.com/r/Bitcoin/comments/4y8m76/0130_binary_safety_warning_bitcoinorg/d6luukw)
)

------
akanet
One wonders: if publishing a key fingerprint on a website in advance is
considered a reasonable warning, would a torrent magnet link prove just as
effective?

~~~
desdiv
0.13.0 isn't out yet, and I don't think you can create an "empty" torrent,
publish the magnet link, then update the torrent with the actual file at a
later date while keeping the magnet link the same.

~~~
brokenmachine
That's correct. A Magnet link contains a hash of the file/s so it can be
verified to be identical to the original during download. So you can't put the
hash in there if you don't have the file yet.

[https://en.wikipedia.org/wiki/Magnet_URI_scheme#URN.2C_conta...](https://en.wikipedia.org/wiki/Magnet_URI_scheme#URN.2C_containing_hash_.28xt.29)

~~~
geocar
No. A magnet link contains a hash of the torrent file, which is an extensible
format[1]. One can simply add data to malicious torrent file until it collides
with the target[2].

[1]:
[http://www.bittorrent.org/beps/bep_0000.html](http://www.bittorrent.org/beps/bep_0000.html)

[2]: [https://malicioussha1.github.io/](https://malicioussha1.github.io/)

~~~
brokenmachine
I'm not an expert, so I might be confused, but...

To do that, wouldn't you need to construct a file that _simultaneously_ had
two collisons for the same file: one collision for the torrent sha1, and one
for the hash of the torrent (the magnet uri)?

The link you gave for finding a single collision in certain types of files
(rar, sh, jpg) required putting garbage into the malicious file (eg, in
comments in the sh file).

They didn't mention creating collisions in torrent files.

It seems exceedingly unlikely to me that you'd be able to construct a file
containing two simultaneous collisions, unless there's a spot where you can
add garbage without corrupting the file, both in the torrent file and also in
the hash of the torrent.

I think the RIAA would be _very_ interested if it was that easy to create fake
torrents that hash the same.

Edit: Actually your second link doesn't even show a weakness in SHA1. So you
can't create a malicious torrent using that method.

~~~
geocar
> To do that, wouldn't you need to construct a file that simultaneously had
> two collisons for the same file: one collision for the torrent sha1, and one
> for the hash of the torrent (the magnet uri)?

No.

The magnet URI only contains the hash of (part of) the torrent file. The
portion that is hashed is extensible, so one could introduce additional
content (like garbage or comments).

> I think the RIAA would be very interested if it was that easy to create fake
> torrents that hash the same.

Easy is subjective. It costs around £150k and a month to make one[1].

However I asked them, and they aren't. Or at least the MPAA isn't.

[1]:
[https://sites.google.com/site/itstheshappening/](https://sites.google.com/site/itstheshappening/)

------
basicplus2
Seriously, how can anyone who knows nothing of computers use bitcoin? how can
it possibly become a serious replacement currency?

~~~
UweSchmidt
Bitcoin can not become a serious replacement currency, as no government can
ever give up control over monetary policy and would rather put away lots of
people than allow any threat to how things work.

If you know nothing of computers you might find articles that explain Bitcoin
briefly and then point you to a "wallet" that you can download and to various
exchanges where you can buy Bitcoin for real money. Why not give it a shot,
and "invest" a bit? You need to know quite a bit to understand the unfixable
problems with computer security, and read a little to learn of the cruelty of
the cryptocurrency world: no password resets, no deposit protection, no
sympathy when you lose your money.

------
orblivion
Anybody know how this affects the Bitcoin PPA?

~~~
kanzure
Do not use "the bitcoin PPA". Launchpad compiles this on their own
infrastructure outside of the gitian build process. If, for some insane
reason, if you must use "the bitcoin PPA", always check hashes, always verify
the binaries are correct, and always check signatures regarding those
particular hashes.

edit: livejournal -> launchpad

~~~
orblivion
The PPA seems to be the recommended Ubuntu install instruction on bitcoin.org:

[https://bitcoin.org/en/download](https://bitcoin.org/en/download)

Aren't all of Ubuntu's packages built on launchpad? It's interesting that you
don't trust launchpad, should I not trust my OS either? And as far as checking
signatures, that's what apt does automatically anyway, as I understand.

I know people like Moxie insist that it's only acceptable to have the (at
least) software's author sign the software. Well, personally I'd rather trust
a larger organization with more reputation to lose. (Ideally I'd have both, of
course, when we get to deterministic builds.)

edit: Oh, deterministic builds is what gitian is. Okay I see your point :-)
But still, why trust your OS at that point?

~~~
kanzure
Yes, deterministic debian is a good idea and we should make that happen.

~~~
orblivion
In the meantime, do you recommend against PPAs in general, or just for
specific sensitive things like Bitcoin?

~~~
kanzure
Launchpad build process for bitcoind is not the same as the gitian build
process. My recommendation is specific to Bitcoin Core, although I have not
evaluated the security of other PPAs on launchpad...

~~~
orblivion
Well they're at most as secure as their maintainers.

------
biafra
I wonder who is keeping their secret keys in Bitcoin Core? Are people doing
this? I know, I am not. I am just running it as a full node. What other
attacks would be possible if nobody stored their secret keys in Bitcoin Core?
Probably only attacks that required a lot of installations to be compromised.

------
Alupis
Does anyone know why they suspect this particular release will be targeted by
state sponsored attackers?

It seems they indicate the specific 0.13.0 release will be targeted, why not
the previous releases (or presumably all future releases)?

------
uvesten
The key checks out, at least it's the same as for the last few releases. I
imported it mid-2015, and it's still the same key.

------
matt_wulfeck
This is exactly like going to the ATM and getting you bank account cleaned
out...

Except banks will restore your funds if it's fraudulent.

~~~
Kinnard
Sometimes they will restore your funds . . . not always.

------
wildchild
No worries they want to drive price down.

